Taktyczny edge cloud: uruchamianie usług w środowiskach DIL

Oprogramowanie cloud-native jest budowane na założeniu, które niemal nigdy nie sprawdza się na taktycznym brzegu sieci: że sieć jest zawsze dostępna. Odkrywanie usług, rozproszone bazy danych, orkiestratory kontenerów i bezstanowe warstwy API – wszystko to zakłada, że każdy węzeł może dotrzeć do każdego innego węzła w ciągu kilku milisekund przez cały czas. Przenieś to samo oprogramowanie do przedniej bazy operacyjnej, pojazdu w ruchu lub piechura za wzgórzem – a założenie się wali. Łącze zrywa się na godziny, powraca na dziewięćdziesiąt sekund, a potem oferuje dwa kilobity na sekundę przez terminal satelitarny. To jest środowisko DIL – odłączone (disconnected), przerywane (intermittent) i ograniczone (limited) – a uruchamianie w nim usług wymaga odwrócenia wielu domyślnych ustawień, które czynią oprogramowanie chmurowe wygodnym w centrum danych.

Co DIL naprawdę oznacza dla oprogramowania

Trzy litery opisują trzy odrębne tryby awarii, a system taktycznego brzegu sieci musi obsługiwać je wszystkie jednocześnie. Odłączony oznacza, że łącze zupełnie nie istnieje – czasem przez całą duration misji. Patrol może działać przez dwa dni bez żadnego powrotu sygnału. Przerywany oznacza, że łączność migocze nieprzewidywalnie – pojazd przejeżdża za teren, kierunkowa antena traci blokadę, zakłócenia przeciwnika przemiatają przez pasmo. Łącze działa przez sekundy, nie działa przez minuty, a oprogramowanie nie może przewidzieć wzorca. Ograniczony oznacza, że nawet gdy łącze istnieje, jest wąskie i wolne: taktyczny kanał SATCOM może oferować kilka kilobitów na sekundę współdzielonych przez cały element, z opóźnieniami mierzonymi w setkach milisekund lub gorzej.

System zaprojektowany dla centrum danych traktuje każdy z tych stanów jako błąd do ponownej próby. System zaprojektowany dla warunków DIL traktuje je wszystkie jako normalny stan operacyjny. Praktyczna konsekwencja jest taka, że żadna czynność operatora nie może nigdy czekać na zdalną usługę, żadne krytyczne dane nie mogą znajdować się wyłącznie na węźle nieosiągalnym dla operatora, a każdy bajt wysyłany przez łącze musi na to zasługiwać. Te ograniczenia nie są przypadkami brzegowymi przyklejanymi na końcu; kształtują architekturę od pierwszej decyzji projektowej. Ta sama dyscyplina leży u podstaw naszej szerszej pracy nad odporną strategią chmury obronnej, gdzie dostępność w heterogenicznych środowiskach jest wymogiem nadrzędnym.

Local-first: fundamentalne odwrócenie

Najważniejszą decyzją architektoniczną dla taktycznej chmury brzegowej jest uczynienie każdego węzła local-first. W projekcie local-first każdy węzeł brzegowy przechowuje kompletną, autorytatywną kopię danych roboczych, których potrzebuje, i obsługuje każde żądanie operatora z tej lokalnej kopii. Odczyty i zapisy realizowane są na osadzonym magazynie przy lokalnym opóźnieniu. Synchronizacja z innymi węzłami i siecią przedsiębiorstwa jest procesem działającym w tle, uruchamianym okazjonalnie zawsze, gdy pozwala na to łączność – nigdy nie leży na ścieżce krytycznej czynności użytkownika.

To odwraca typowy wzorzec chmury, w którym klient jest cienki, a serwer przechowuje prawdę. Na brzegu sieci węzeł przechowuje prawdę tak długo, jak jest odłączony, a sieć przedsiębiorstwa staje się kolejnym partnerem do uzgadniania, a nie zależnością, która musi być osiągalna. Doświadczenie operatora jest identyczne niezależnie od tego, czy węzeł ma grube łącze powrotne do kwatery głównej, czy nie ma łączności w ogóle – i właśnie ta niezmienność jest istotą systemu. Operator, który musi zastanawiać się, czy sieć działa, zanim zdecyduje, czy czynność zadziała, już został zawiedziony przez system.

Gdzie żyje stan

Local-first oznacza zaopatrzenie każdego węzła w prawdziwą bazę danych, a nie pamięć podręczną. Osadzony SQLite lub osadzony silnik relacyjny przechowujący pełny zestaw roboczy węzła to popularny wybór; dla stanu współpracy dobrze sprawdza się magazyn dokumentów z wbudowaną semantyką replikacji. Magazyn musi być trwały w przypadku zaniku zasilania – sprzęt brzegowy jest ponownie uruchamiany, upuszczany i zasilany z wyczerpujących się baterii – dlatego write-ahead logging i odtwarzanie po awarii nie są opcjonalne. Co kluczowe, lokalny magazyn jest źródłem prawdy w czasie odłączenia. Pokusa traktowania lokalnej kopii jako jednorazowej pamięci podręcznej, którą może unieważnić serwer, jest dokładnie tym odruchem centrum danych, który projekt DIL musi tłumić.

Synchronizacja: przesyłanie tylko tego, co ważne

Jeśli każdy węzeł przechowuje własną autorytatywną kopię, trudnym problemem staje się utrzymywanie tych kopii w użytecznej zgodności przez łącza, które są głównie nieobecne i zawsze wąskie. Naiwna replikacja – przesyłanie strumieniowe pełnej migawki stanu lub natychmiastowe przekazywanie każdego zapisu – jest beznadziejna przy kilku kilobitach na sekundę. Protokół synchronizacji musi być oparty na deltach, priorytetowy, wznawiany i idempotentny.

Oparty na deltach oznacza, że każda wymiana synchronizacji przenosi tylko rekordy, które zmieniły się od ostatniej udanej wymiany z danym partnerem, identyfikowane przez znacznik high-water per-partner lub zegar wektorowy. Priorytetowy oznacza, że kolejka wychodząca jest sortowana według wartości operacyjnej: pozycje własne i wrogie, rozkazy i alerty idą pierwsze; rutynowe aktualizacje statusu następne; media masowe takie jak zobrazowanie i wideo pełnoruchu ostatnie, w oddzielnym torze o niskim priorytecie korzystającym tylko z zapasowej przepustowości. Wznawiany oznacza, że przerwany transfer – normalny przypadek przy przerwanej łączności – restartuje od ostatniego potwierdzonego rekordu, a nie od początku, więc synchronizacja, która uzyska dziewięćdziesiąt sekund łączności, robi dziewięćdziesiąt sekund rzeczywistego postępu. Idempotentny oznacza, że odtworzenie partii częściowo dostarczonej przed zerwaniem łącza nie powoduje duplikatów, ponieważ odbiorca kluczuje na stabilnych identyfikatorach rekordów, a nie na kolejności przybycia.

Kompresja ma tu większe znaczenie niż niemal gdziekolwiek indziej w inżynierii oprogramowania, ponieważ łącze jest ograniczeniem wiążącym. Strukturalne dane operacyjne kompresują się wyjątkowo dobrze, a słownik dostrojony do schematu wiadomości może skurczyć raport pozycji lub rozkaz do ułamka jego rozmiaru na przesyle. Inżynieryjnym celem jest przydatny, aktualny obraz operacyjny synchronizowany przez kanał, który inżynier centrum danych uznałby za bezużyteczny.

Transport okazjonalny i store-and-forward

Ponieważ łączność jest nieprzewidywalna, warstwa transportowa musi być okazjonalna: w momencie pojawienia się jakiegokolwiek łącza – główne radio, siatka line-of-sight do sąsiedniego pojazdu, krótkie okno SATCOM, a nawet kurier przenoszący dysk fizyczny między węzłami – silnik synchronizacji opróżnia tak wiele ze swojej kolejki priorytetowej, ile pozwala okno. Routing store-and-forward pozwala jednemu węzłowi przekazywać oczekujące aktualizacje innego węzła, gdy ma lepszą łączność, więc pojazd wynurzający się zza terenu może nieść raporty piechurów do przodu. To bliższe duchem sieci tolerujących opóźnienia niż API żądanie-odpowiedź, a zaprojektowanie silnika synchronizacji wokół tego modelu – zamiast wokół semantyki HTTP – sprawia, że przeżywa on przypadek przerywany.

Uzgadnianie: rozstrzyganie równoczesnych zmian

Ceną pozwalania każdemu węzłowi na lokalne zapisy podczas odłączenia jest to, że dwa węzły nieuchronnie edytują tę samą rzecz bez widzenia wzajemnych zmian. Kiedy się ponownie łączą, system musi uzgodnić różnice. Nie ma jednej właściwej strategii; właściwa zależy od kształtu danych.

Dzienniki zdarzeń tylko do dołączania całkowicie omijają konflikty. Jeśli węzeł tylko dołącza rekordy – odczyty sensorów, raporty, wpisy dziennika – to scalanie dwóch dzienników jest po prostu sumą, posortowaną według zegara logicznego. Większość danych telemetrycznych i raportowych pasuje do tego modelu i powinien to być domyślny wybór zawsze, gdy dane są naturalnie strumieniem zdarzeń, a nie modyfikowalnym rekordem.

Bezkonfliktowe replikowane typy danych (CRDTs) obsługują współdzielony stan modyfikowalny, który kilka węzłów edytuje wspólnie – wspólna mapa grafiki, aktualizowany wykaz osobowy, zestaw punktów nawigacyjnych. CRDT niesie wystarczająco metadanych, by dowolne dwie repliki scalały się deterministycznie do tego samego wyniku niezależnie od kolejności przybycia aktualizacji – co jest dokładnie gwarancją, której przerywana sieć inaczej nie może zapewnić. Kosztem jest narzut metadanych na rekord, więc CRDTs są zarezerwowane dla naprawdę współpracującego stanu, a nie stosowane powszechnie.

Last-writer-wins z arbitrażem operatora obejmuje resztę: modyfikowalne rekordy, do których nie pasuje ani dziennik zdarzeń, ani CRDT. Hybrydowy zegar logiczny determinuje wygranego w sposób deterministyczny, dzięki czemu system nigdy się nie blokuje, ale przegrany jest zachowany, a rekord oznaczony do przeglądu przez człowieka. Uzasadnienie jest takie, że rzeczywisty konflikt semantyczny – dwóch operatorów niezależnie zmieniających klasyfikację tego samego celu – to osąd, który powinien wydać człowiek, nie automatyczna reguła działająca w ciszy. Ten wzorzec ma konceptualne pokrewieństwo z projektem offline-first stosowanym w odłączonych aplikacjach polowych dla piechurów, gdzie ten sam problem edycji w trybie offline pojawia się na poziomie urządzenia.

Uruchamianie usług cloud-native na sprzęcie brzegowym

Taktyczne węzły brzegowe nie są stojakami hiperskalowymi. To wzmocniony komputer o małym formacie – serwer montowany w pojeździe, klaster w przypadku transportowym przy punkcie dowodzenia, niekiedy jednopłytowy komputer w plecaku – działający na ograniczonym zasilaniu i chłodzeniu. Celem jest jednak nadal uruchamianie usług cloud-native, ponieważ te same konteneryzowane usługi powinny działać identycznie w korporacyjnym centrum danych, regionalnym węźle i na taktycznym brzegu sieci. Ta przenośność pozwala rozwinąć zdolność raz i wdrażać ją wszędzie.

Praktycznym podejściem jest lekki orkiestrator kontenerów dobrany do brzegu sieci, a nie centrum danych. Jednobinarna dystrybucja Kubernetes taka jak K3s, lub mały zarządzany klaster, daje ten sam model wdrożenia i te same manifesty co środowisko korporacyjne bez ciężaru płaszczyzny sterowania, którego sprzęt brzegowy nie może udźwignąć. Ta sama dyscyplina hartowania nadal obowiązuje – model zagrożeń nie łagodnieje dlatego, że klaster jest mały, a praktyki zawarte w naszym przewodniku po hartowaniu Kubernetes dla zastosowań obronnych stosują się bezpośrednio do klastrów brzegowych. Zmienia się wymiarowanie i założenia dotyczące awarii: orkiestrator musi utrzymywać obciążenia robocze bez łączności z centralną płaszczyzną sterowania, pobrania obrazów muszą odbywać się z lokalnego rejestru zasilonego przed wdrożeniem zamiast z pobierania przez internet, a klaster musi tolerować węzeł, który po prostu znika, gdy pojazd wyjeżdża poza zasięg.

Tożsamość i bezpieczeństwo bez powrotu sygnału

Odłączony węzeł nadal musi uwierzytelniać operatorów i autoryzować działania, nie może jednak dzwonić do domu. Poświadczenia i polityka autoryzacji muszą być lokalnie buforowane z rozsądnymi czasami ważności offline – wystarczająco długimi, by przeżyć realistyczne okno odłączenia, wystarczająco krótkimi, by przechwycony węzeł nie pozostawał zaufany w nieskończoność. Unieważnianie certyfikatów to kanonicznie trudny przypadek: węzeł, który nie może dotrzeć do listy unieważnień, musi wracać do certyfikatów krótkoterminowych, których naturalne wygaśnięcie ogranicza ekspozycję. Szyfrowanie lokalnego magazynu i zapewnienie szybkiego, nieodwracalnego zerowania dla sprzętu zagrożonego przechwyceniem to wymagania podstawowe, a nie ulepszenia – węzły brzegowe są tą częścią architektury, która z największym prawdopodobieństwem może trafić w niepowołane ręce.

Walidacja projektu DIL przed wdrożeniem w terenie

Tryb awarii, który kończy programy, to odkrycie w terenie, że system testowany tylko w czystej sieci LAN faktycznie nie działa przez taktyczne radio. Sieć LAN nie ma żadnej z właściwości definiujących DIL, więc zielony zestaw testów w sieci LAN nic nie mówi o zachowaniu w warunkach DIL. Walidacja wymaga emulatora sieci umieszczonego między węzłami, który wstrzykuje rzeczywiste warunki – zaniki łącza o różnym czasie trwania, opóźnienia w setkach milisekund, utratę pakietów i twarde ograniczenia przepustowości dopasowane do docelowych radia. Test akceptacyjny jest dwuczęściowy: operatorzy muszą być w stanie wykonać każde zadanie krytyczne z łączem wyłączonym przez pełny czas trwania misji, a węzły muszą zbiec się do jednego spójnego obrazu po przywróceniu łączności, również w warunkach stresowego jednoczesnego ponownego połączenia kilku węzłów, z których każdy edytował offline.

System, który przechodzi oba testy, zasłużył na miano taktycznej chmury brzegowej. Ten, który działał wyłącznie w sieci LAN, był testowany dla wygody, nie dla środowiska, z którym faktycznie się zetknie.