Тактична edge-хмара: запуск сервісів у DIL-середовищах

Хмарно-нативне програмне забезпечення будується на припущенні, що майже ніколи не виконується на тактичному краю: мережа завжди доступна. Виявлення сервісів, розподілені бази даних, оркестратори контейнерів і рівні stateless API — всі вони припускають, що будь-який вузол може звернутися до будь-якого іншого вузла протягом кількох мілісекунд, постійно. Перенесіть те саме програмне забезпечення на передову оперативну базу, у транспортний засіб на марші або у спішеній групі за пагорбом — і це припущення руйнується. Канал зникає на години, відновлюється на дев'яносто секунд, потім пропонує два кілобіти на секунду через супутниковий термінал. Це DIL-середовище — disconnected (відключений), intermittent (переривчастий) та limited (обмежений) — і запуск сервісів у ньому вимагає інвертування багатьох стандартних налаштувань, що роблять хмарне програмне забезпечення зручним у центрі обробки даних.

Що DIL насправді означає для програмного забезпечення

Три літери описують три окремі режими відмови, і тактична edge-система повинна одночасно справлятися з усіма ними. Відключений означає, що канал повністю зник, іноді на тривалість усієї місії. Патруль може діяти двоє діб без жодного зв'язку із тилом. Переривчастий означає, що підключення мерехтить непередбачувано — транспортний засіб проходить за рельєфом, спрямована антена втрачає захоплення, радіоелектронне придушення противника охоплює смугу частот. Канал доступний секунди, відсутній хвилини, і програмне забезпечення не може передбачити характер. Обмежений означає, що навіть коли канал є, він вузький і повільний: тактичний супутниковий канал може пропонувати кілька кілобітів на секунду, розподілених між усіма елементами, із затримкою в сотні мілісекунд або більше.

Система, розроблена для центру обробки даних, сприймає будь-яку з цих умов як помилку, яку слід повторити. Система, розроблена для DIL, вважає всі три нормальним робочим станом. Практичним наслідком є те, що жодна дія оператора ніколи не може блокуватися в очікуванні відповіді від віддаленого сервісу, жодні критичні дані не можуть існувати лише на вузлі, недоступному оператору, і кожен байт, відправлений по каналу, повинен виправдовувати своє місце. Ці обмеження — не крайні випадки, які можна прикріпити після факту; вони формують архітектуру з першого проектного рішення. Та сама дисципліна лежить в основі нашої ширшої роботи зі стійкої оборонної хмарної стратегії, де доступність у різнорідних середовищах є ключовою вимогою.

Local-first: фундаментальна інверсія

Найважливішим архітектурним рішенням для тактичної edge-хмари є зробити кожен вузол local-first. У local-first дизайні кожен edge-вузол зберігає повну, авторитетну копію робочих даних, необхідних йому, і обслуговує кожен запит оператора з цієї локальної копії. Читання та запис виконуються відносно вбудованого сховища з локальною затримкою. Синхронізація з рівноправними вузлами та підприємством є фоновим процесом, що виконується опортуністично, коли дозволяє підключення, — вона ніколи не знаходиться на критичному шляху дії користувача.

Це інвертує звичайний хмарний шаблон, де клієнт тонкий, а сервер зберігає правду. На краю вузол зберігає правду доти, доки він відключений, а підприємство стає ще одним рівноправним вузлом для узгодження, а не залежністю, яка повинна бути доступна. Досвід оператора є однаковим незалежно від того, чи є у вузла товстий канал до штабу, чи немає підключення взагалі — і ця інваріантність є суттю системи. Оператор, який повинен думати, чи є мережа, перш ніж вирішити, чи спрацює дія, вже підведений системою.

Де зберігається стан

Local-first означає забезпечення кожного вузла справжньою базою даних, а не кешем. Вбудований SQLite або вбудований реляційний рушій, що містить повний робочий набір вузла, є поширеним вибором; для спільного стану добре підходить сховище документів із вбудованою семантикою реплікації. Сховище повинне витримувати втрату живлення — edge-обладнання перезавантажують, кидають і запускають від акумуляторів, що розряджаються — тому журналювання записів наперед і відновлення після аварійного завершення є обов'язковими. Вирішальним є те, що локальне сховище є джерелом правди під час відключення. Спокуса ставитися до локальної копії як до одноразового кешу, який може бути інвалідований сервером, — це саме рефлекс центру обробки даних, який DIL-дизайн має придушити.

Синхронізація: переміщення лише того, що важливо

Якщо кожен вузол зберігає власну авторитетну копію, складним завданням стає підтримання корисного узгодження цих копій по каналах, які переважно відсутні й завжди вузькі. Наївна реплікація — передача повного знімку стану або відправлення кожного запису у момент його появи — безнадійна при кількох кілобітах на секунду. Протокол синхронізації повинен бути delta-базованим, пріоритизованим, відновлюваним та ідемпотентним.

Delta-базований означає, що кожен обмін при синхронізації містить лише записи, що змінилися з моменту останнього успішного обміну з цим рівноправним вузлом, ідентифіковані за мітками верхньої межі або векторним годинником. Пріоритизований означає, що вихідна черга впорядкована за оперативною цінністю: спочатку позиції дружніх і ворожих сил, накази та сповіщення; потім рутинні оновлення стану; останніми — масові медіа, такі як знімки та відеозаписи повного руху, в окремому низькопріоритетному каналі, що використовує лише вільну ємність. Відновлюваний означає, що перерваний трансфер — звичайний випадок при переривчастих каналах — перезапускається з останнього підтвердженого запису, а не з початку, тому синхронізація, яка отримала дев'яносто секунд підключення, досягає дев'яноста секунд реального прогресу. Ідемпотентний означає, що відтворення пакету, який був частково доставлений до зникнення каналу, не призводить до дублювання, оскільки одержувач використовує стабільні ідентифікатори записів, а не порядок надходження.

Стиснення тут важливіше, ніж майже будь-де в розробці програмного забезпечення, оскільки канал є обмежувальним чинником. Структуровані оперативні дані стискаються надзвичайно добре, і словник, налаштований на схему повідомлень, може зменшити звіт про позицію або наказ до частки його розміру в мережі. Інженерна мета — корисна, актуальна оперативна картина, яка синхронізується по каналу, який інженер центру обробки даних вважав би непридатним для використання.

Опортуністичний транспорт і store-and-forward

Оскільки підключення непередбачуване, транспортний рівень повинен бути опортуністичним: щойно з'являється будь-який канал — основна радіостанція, пряма mesh-мережа до сусіднього транспортного засобу, короткий супутниковий сеанс або навіть кур'єр із фізичним носієм між вузлами — движок синхронізації вичерпує стільки своєї пріоритетної черги, скільки дозволяє вікно. Store-and-forward маршрутизація дозволяє одному вузлу ретранслювати очікуючі оновлення іншого вузла, коли у нього кращий зв'язок, тому транспортний засіб, що виходить з-за рельєфу, може перенести звіти спішеної групи вперед. Це ближче за духом до мереж із затримкою до delay-tolerant networking, ніж до API запит-відповідь, і проектування движка синхронізації навколо цієї моделі, а не HTTP-семантики, і робить його здатним виживати в переривчастому випадку.

Узгодження: вирішення одночасних правок

Ціна дозволу кожному вузлу писати локально під час відключення полягає в тому, що два вузли неминуче редагуватимуть одне й те саме, не бачачи змін один одного. Коли вони повторно підключаться, система повинна узгодити. Немає єдиної правильної стратегії; правильна залежить від форми даних.

Журнали подій лише для додавання повністю обходять конфлікт. Якщо вузол лише додає записи — показання сенсорів, звіти, журнальні записи — то злиття двох журналів є просто об'єднанням, впорядкованим за логічним годинником. Більшість телеметрії та звітних даних відповідає цій моделі, і вона повинна бути стандартною, коли дані природно є потоком подій, а не змінюваним записом.

Conflict-free replicated data types (CRDT) обробляють спільний змінюваний стан, який кілька вузлів редагують колаборативно — спільна карта графіки, поточний список особового складу, набір шляхових точок. CRDT містить достатньо метаданих, щоб будь-які дві репліки детерміновано зливалися до однакового результату незалежно від порядку надходження оновлень, що є саме гарантією, яку переривчаста мережа інакше не може забезпечити. Ціна — накладні витрати метаданих на запис, тому CRDT зарезервовані для справді колаборативного стану, а не застосовуються повсюдно.

Last-writer-wins з арбітражем оператора охоплює решту: змінювані записи, для яких не підходить ні журнал подій, ні CRDT. Гібридний логічний годинник визначає детермінованого переможця, щоб система ніколи не зависала, але переможений зберігається, а запис позначається для перегляду людиною. Логіка полягає в тому, що справжній семантичний конфлікт — два оператори незалежно змінюють класифікацію одного і того ж об'єкта — є рішенням, яке повинна прийняти людина, а не автоматичне правило, яке повинно мовчки приховати. Цей шаблон ділиться концептуальним походженням із offline-first дизайном, що використовується в польових застосунках для спішених бійців, де та сама проблема редагування у відключеному режимі виникає на рівні пристрою.

Запуск хмарно-нативних сервісів на edge-обладнанні

Тактичні edge-вузли — це не стійки гіперскейлера. Це захищені компактні обчислювальні системи — сервер у транспортному засобі, кластер у транзитному кейсі на командному пункті, іноді одноплатний комп'ютер у рюкзаку — що працюють з обмеженим живленням і охолодженням. Проте мета — все одно запускати хмарно-нативні сервіси, оскільки ті самі контейнеризовані сервіси повинні однаково працювати в корпоративному центрі обробки даних, у регіональному вузлі та на передовому краю. Ця портативність дозволяє розробляти можливості один раз і розгортати скрізь.

Практичний підхід — легкий оркестратор контейнерів, розрахований на край, а не на центр обробки даних. Однобінарний дистрибутив Kubernetes, наприклад K3s, або невеликий керований кластер надає ту саму модель розгортання та ті самі маніфести, що й корпоративне середовище, без ваги площини управління, яку не може собі дозволити edge-обладнання. Та сама дисципліна захисту все одно застосовується — модель загроз не пом'якшується через малий розмір кластера, і практики нашого посібника з захисту Kubernetes для оборонних задач безпосередньо застосовуються до edge-кластерів. Що змінюється — це розмір і припущення щодо відмов: оркестратор повинен підтримувати робочі навантаження без зворотного зв'язку з центральною площиною управління, образи повинні завантажуватися з локального реєстру, наповненого перед розгортанням, а не з Інтернету, і кластер повинен витримувати, коли вузол просто зникає, коли транспортний засіб виїжджає з зони досяжності.

Ідентифікація та безпека без зворотного зв'язку

Відключений вузол все одно повинен автентифікувати операторів і авторизовувати дії, і він не може для цього зателефонувати додому. Облікові дані та правила авторизації повинні бути кешовані локально з розумними офлайн-термінами — достатньо довгими, щоб пережити реалістичне вікно відключення, і достатньо короткими, щоб захоплений вузол не залишався авторизованим нескінченно. Відкликання сертифікатів є канонічним складним випадком: вузол, що не може звернутися до списку відкликання, повинен відкотитися до короткотермінових сертифікатів, природний термін дії яких обмежує ризик. Шифрування локального сховища та надання швидкого, незворотного знищення даних для обладнання під загрозою захоплення є базовими вимогами, а не покращеннями, враховуючи, що edge-вузли є частиною архітектури, яка найімовірніше потрапить у ворожі руки.

Перевірка DIL-дизайну перед розгортанням у полі

Режим відмови, який закриває програми, — це виявлення в полі, що система, протестована лише в чистій локальній мережі, насправді не працює по тактичній радіостанції. Локальна мережа не має жодної з властивостей, що визначають DIL, тому зелений набір тестів у локальній мережі нічого не говорить про поведінку в DIL. Перевірка вимагає мережевого емулятора, розміщеного між вузлами, що вводить реальні умови — падіння каналів різної тривалості, затримку в сотні мілісекунд, втрату пакетів і жорсткі обмеження пропускної здатності, відповідні цільовим радіостанціям. Тест прийняття є двостороннім: оператори повинні мати змогу виконати кожне критично важливе завдання при утриманому каналі протягом усієї тривалості місії, а вузли повинні сходитися до єдиної узгодженої картини після відновлення підключення, включаючи стресовий випадок кількох вузлів, що одночасно підключаються після кожного офлайн-редагування.

Система, яка проходить обидва тести, заробила право називатися тактичною edge-хмарою. Та, що працювала лише в локальній мережі, була протестована для зручності, а не для середовища, з яким насправді зіткнеться.