Wysoka dostępność TAK Server: klastrowanie, failover i zero przestojów

TAK Server jest sercem taktycznego wspólnego obrazu operacyjnego. Każde zdarzenie Cursor on Target (CoT) — każdy raport pozycji, każdy kontakt, każda nakładka — przepływa przez niego. Gdy ten serwer przestaje działać, wspólny obraz zamiera jednocześnie dla każdego podłączonego operatora. W garnizonie to niedogodność; w operacji to utrata świadomości sytuacyjnej w najgorszym możliwym momencie. Wysoka dostępność nie jest więc luksusową funkcją poważnego wdrożenia TAK — jest różnicą między infrastrukturą, którą można postawić za misją, a infrastrukturą, której nie można. Ten artykuł analizuje, jak uruchomić TAK Server bez pojedynczego punktu awarii: klastrowanie warstwy aplikacyjnej, replikacja bazy danych, równoważenie obciążenia klientów oraz inżynieria failover, który kończy się szybciej, niż operator zdąży to zauważyć.

Dlaczego pojedynczy węzeł TAK Server jest pojedynczym punktem awarii

Domyślna instalacja TAK Server to pojedyncza aplikacja Java oparta na pojedynczej bazie danych PostgreSQL/PostGIS na pojedynczym hoście. Działa, jest prosta w uruchomieniu i dla małego pododdziału jest całkowicie wystarczająca. Ta prostota ukrywa jednak cztery odrębne domeny awarii, z których każda samodzielnie kładzie cały obraz: proces aplikacji może ulec awarii lub wyczerpać stertę; host może stracić zasilanie, sieć lub dysk; baza danych może ulec uszkodzeniu, zapełnić swój wolumin lub zakleszczyć się; a ścieżka sieciowa między klientami a serwerem może zostać przerwana. W projekcie jednowęzłowym nie są one niezależne — utrata którejkolwiek z nich oznacza utratę całości.

Wysoka dostępność oznacza takie zaprojektowanie każdej z tych domen, aby żadna pojedyncza awaria nie była śmiertelna. Warstwa aplikacyjna staje się klastrem wymiennych węzłów. Baza danych staje się replikowanym zestawem podstawowy-plus-zapasowy z automatyczną promocją. Połączenie klienta staje się zrównoważonym, sprawdzanym pod kątem kondycji wirtualnym punktem końcowym, a nie zakodowanym na stałe hostem. Rezultatem jest system, w którym węzeł może zostać utracony — wskutek awarii, restartu po aktualizacji lub zniszczenia serwerowni — a operatorzy zachowują swój obraz.

Tryb klastra TAK Server: płaszczyzna komunikacyjna

Podstawą wysokiej dostępności TAK Server jest tryb klastra. We wdrożeniu jednowęzłowym zdarzenia CoT są kierowane przez kolejki wewnątrzprocesowe — płaszczyzna komunikacyjna żyje wewnątrz jednej działającej aplikacji. W trybie klastra ta płaszczyzna jest wyniesiona na współdzieloną magistralę komunikatów, tak aby wiele węzłów TAK Server mogło współpracować jako jeden logiczny serwer. Zdarzenie CoT opublikowane przez klienta połączonego z węzłem A jest rozdystrybuowane po magistrali i dostarczane do klientów połączonych z węzłem B, przy czym ci klienci nigdy nie wiedzą, że znajdują się na różnych maszynach.

To rozprzężenie sprawia, że warstwa aplikacyjna jest jednocześnie skalowalna poziomo i odporna na awarie. Dodawanie pojemności dla większej liczby klientów lub wyższej gęstości śladów staje się kwestią dodawania węzłów — tej samej dźwigni skalowania, którą opisano w artykule dostrajanie wydajności TAK Server. Przetrwanie utraty węzła staje się automatyczne, ponieważ każdy węzeł posiada ten sam widok współdzielonego stanu subskrypcji. Węzły są bezstanowe względem obrazu — cały trwały stan żyje we współdzielonej bazie danych i magistrali komunikatów, a nie w pamięci pojedynczego węzła.

Bezstanowe węzły, współdzielony stan

Kardynalną zasadą projektową klastra TAK Server jest to, że węzły aplikacyjne muszą być bezstanowe. Wszystko, co operator straciłby, gdyby węzeł zniknął, musi żyć poza węzłem: utrwalone CoT w bazie danych, stan grup i misji w bazie danych oraz routing aktywnych subskrypcji w magistrali komunikatów. Gdy ta zasada jest spełniona, awaria węzła jest nieistotna dla danych — jedynym kosztem jest to, że klienci na martwym węźle muszą połączyć się ponownie, a koszt ten jest ograniczony tym, jak szybko load balancer i klienci zauważą awarię.

Wysoka dostępność bazy danych: prawdziwe wąskie gardło

Gdy warstwa aplikacyjna jest już sklastrowana, baza danych PostgreSQL/PostGIS staje się dominującym pojedynczym punktem awarii — każdy sklastrowany węzeł zależy od tej samej bazy danych, więc niezabezpieczona baza danych unieważnia całą odporność warstwy aplikacyjnej. Wysoka dostępność bazy danych opiera się na trzech współdziałających komponentach.

Replikacja strumieniowa. Węzeł podstawowy przyjmuje wszystkie zapisy i nieprzerwanie przesyła swój dziennik write-ahead (WAL) do jednego lub więcej węzłów zapasowych, które odtwarzają go, aby pozostać aktualnymi. Synchroniczny węzeł zapasowy potwierdza każdy commit, zanim węzeł podstawowy zgłosi sukces, co gwarantuje zero utraty danych kosztem niewielkiej kary w opóźnieniu zapisu; asynchroniczny węzeł zapasowy opóźnia się o ułamek sekundy, ale nie dodaje opóźnienia commitu. Solidny projekt wykorzystuje co najmniej jeden synchroniczny węzeł zapasowy dla recovery point objective oraz dodatkowe asynchroniczne węzły zapasowe do skalowania odczytów i disaster recovery.

Automatyczny failover. Sama replikacja nie wykonuje failover — coś musi wykryć, że węzeł podstawowy jest martwy, i promować węzeł zapasowy. Tę rolę pełni Patroni, działający jako agent na każdym węźle bazy danych. Wykorzystuje on rozproszony magazyn konfiguracji — etcd lub Consul, wdrożony jako nieparzyste kworum trzech lub pięciu członków — do przechowywania blokady lidera. Jeśli węzeł podstawowy przestanie odnawiać swoją blokadę, Patroni wybiera najbardziej aktualny węzeł zapasowy i promuje go na podstawowy, zwykle w ciągu 5 do 15 sekund.

Routing połączeń. Węzły TAK Server muszą zawsze łączyć się z tą bazą danych, która jest aktualnie podstawowa, bez rekonfiguracji. Router połączeń — PgBouncer lub HAProxy stojący przed portami bazy danych — śledzi bieżącego lidera (Patroni aktualizuje jego punkty końcowe kondycji przy promocji) i odpowiednio kieruje ruch zapisu. Z perspektywy TAK Server baza danych jest pojedynczym stabilnym wirtualnym IP; promocja węzła zapasowego za tym IP jest niewidoczna.

Cele odtwarzania kształtują projekt

Dwie liczby rządzą warstwą bazy danych. Recovery point objective (RPO) to ilość danych, jaką możesz sobie pozwolić utracić; dla zatwierdzonej trwałości CoT odpowiedź dla systemu taktycznego to zwykle zero, co nakazuje synchroniczny węzeł zapasowy. Recovery time objective (RTO) to czas, jaki może zająć failover; z Patroni i sprawnym kworum jest to okno promocji od 5 do 15 sekund. Zdefiniuj oba jawnie przed provisioningiem — dyktują one, czy możesz tolerować replikację wyłącznie asynchroniczną i jak agresywne muszą być liczniki wykrywania awarii.

Równoważenie obciążenia i ponowne łączenie klientów

Warstwa obsługująca klientów spina klaster w całość. ATAK i inni klienci TAK utrzymują trwałe, wzajemnie uwierzytelniane połączenia TLS z serwerem. Aby te połączenia przetrwały utratę węzła, muszą kończyć się na wirtualnym punkcie końcowym, a nie na konkretnym hoście.

Load balancer warstwy 4 — HAProxy, NGINX w trybie stream lub chmurowy balancer L4 — udostępnia pojedynczy wirtualny IP dla portów klienckich TLS i rozdziela nowe połączenia między sprawne węzły TAK Server za pomocą least-connections lub round-robin. Aktywne health-checki wobec punktu końcowego statusu każdego węzła usuwają z rotacji uszkodzony węzeł w ramach jednego interwału health-check. Co istotne, balancer musi działać na warstwie 4 i przepuszczać TLS nienaruszony, ponieważ TAK Server używa wzajemnego uwierzytelniania certyfikatem klienta, które musi kończyć się na węźle aplikacyjnym, a nie na balancerze.

Gdy węzeł ulega awarii, gniazda jego klientów są zrywane. Każdy klient wykrywa martwe gniazdo dzięki TCP keepalive i łączy się ponownie z wirtualnym IP, gdzie balancer kieruje go do ocalałego węzła. Ponieważ każdy węzeł współdzieli tę samą bazę danych i magistralę komunikatów, ponownie połączony klient natychmiast resynchronizuje się z bieżącym obrazem. Odczuwalna przerwa jest rządzona wyłącznie interwałem keepalive klienta i częstotliwością health-check balancera — dostrój oba do kilku sekund, a operator zobaczy chwilowy stan „ponowne łączenie”, a nie utratę świadomości.

Planowanie pojemności również ma tu znaczenie. Wymiaruj klaster tak, aby utrata jednego węzła nadal pozostawiała wystarczający zapas, by wchłonąć całą populację klientów — reguła N+1. Jeśli dwa węzły działają niemal na granicy nasycenia i jeden ginie, każdy zerwany klient łączy się ponownie z ocalałym i go przeciąża, zamieniając awarię pojedynczego węzła w kaskadę. Zaplanuj budżet każdego węzła tak, aby udźwignął swój udział w stanie ustalonym plus pełny udział failover, i zweryfikuj pod obciążeniem, że ocalały węzeł poradzi sobie ze skokiem bez wyczerpania sterty lub limitów połączeń.

Konserwacja bez przestojów

Ta sama maszyneria, która pozwala przetrwać nieplanowaną awarię, umożliwia również planową konserwację bez przestoju. Aby załatać lub zaktualizować węzeł, opróżnij go: poleć load balancerowi zaprzestanie kierowania nowych połączeń, pozwól istniejącym klientom wygasnąć lub połączyć się gdzie indziej, a następnie wyłącz węzeł, zaktualizuj go i przywróć do rotacji. Przechodzenie przez klaster po jednym węźle naraz utrzymuje usługę w ciągłej dostępności. Aktualizacje bazy danych przebiegają tą samą logiką, ale odwrotnie — najpierw aktualizuj węzły zapasowe, a następnie wykonaj kontrolowany switchover, który promuje już zaktualizowany węzeł zapasowy, tak aby węzeł podstawowy nigdy nie był tym pod kluczem. To zamienia okno konserwacji z zaplanowanego przestoju w przezroczystą operację kroczącą.

Redundancja geograficzna i federacja

Przetrwanie utraty węzła to jedno; przetrwanie utraty całej lokalizacji to coś innego. Instynkt podpowiada, by rozciągnąć pojedynczy klaster na dwa centra danych, ale ścieżka zapisu bazy danych czyni prawdziwy klaster active-active obejmujący wiele regionów niepraktycznym: replikacja synchroniczna przez łącze o dużym opóźnieniu dodaje ten round trip do każdego zatwierdzonego zapisu, a replikacja wyłącznie asynchroniczna między regionami ponownie wprowadza ryzyko utraty danych przy failover.

Praktycznym wzorcem jest redundancja geograficzna active-passive. Pełny klaster — sklastrowane węzły aplikacyjne, synchroniczne lokalne węzły zapasowe, lokalne kworum — działa w lokalizacji podstawowej. Asynchroniczna replikacja strumieniowa zasila ciepły klaster zapasowy w drugiej lokalizacji, który można promować, jeśli lokalizacja podstawowa zostanie całkowicie utracona. To ogranicza międzylokalizacyjne RPO do opóźnienia replikacji asynchronicznej, jednocześnie utrzymując szybką ścieżkę zapisu w obrębie lokalizacji.

Tam, gdzie niezależne lokalizacje muszą współdzielić obraz bez współdzielenia bazy danych, właściwym narzędziem jest federacja, a nie klastrowanie. Federacja łączy odrębne klastry TAK Server i wymienia między nimi CoT zgodnie z polityką — mechanizm opisany w artykule konfiguracja federacji TAK Server. Klastrowanie daje pojedynczy odporny serwer; federacja łączy wiele odpornych serwerów ponad granicami organizacyjnymi i geograficznymi. Dojrzałe wdrożenie wykorzystuje oba: każde dowództwo uruchamia sklastrowany, wysoce dostępny TAK Server, a federacja zszywa te klastry w obraz obejmujący cały teatr działań.

Dyscyplina operacyjna: testowanie awarii

Projekt wysokiej dostępności, który nigdy nie wykonał failover na ostro, jest hipotezą, a nie zdolnością. Najważniejszą praktyką operacyjną jest celowe i wielokrotne wywoływanie awarii: wyłącz węzeł aplikacyjny pod obciążeniem i zmierz czas ponownego połączenia klientów; wyłącz węzeł podstawowy bazy danych i potwierdź, że Patroni promuje węzeł zapasowy w ramach RTO z zerową utratą utrwalonego CoT; podziel magazyn kworum i zweryfikuj, że klaster odmawia rozpadu na split-brain. Przeprowadzaj te ćwiczenia wobec realistycznej liczby klientów i gęstości śladów, a nie na pustym serwerze. Celem jest failover poniżej 30 sekund bez działania operatora — a jedynym sposobem, by zaufać tej liczbie, jest osiągnięcie jej pod obciążeniem, celowo, wielokrotnie.