TAK Serverin korkea käytettävyys: klusterointi, vikasietoisuus ja nolla käyttökatkoa

TAK Server on taktisen yhteisen tilannekuvan sydän. Jokainen Cursor on Target (CoT) -tapahtuma — jokainen sijaintiraportti, jokainen kontakti, jokainen päällyste — kulkee sen läpi. Kun tuo palvelin kaatuu, jaettu tilannekuva jäätyy samanaikaisesti jokaiselle yhdistäneelle operaattorille. Varuskunnassa se on harmillista; operaatiossa se on tilannetietoisuuden menetys pahimpaan mahdolliseen hetkeen. Korkea käytettävyys ei siis ole vakavan TAK-käyttöönoton ylellisyysominaisuus — se on ero infrastruktuurin, jonka voit asettaa tehtävän tueksi, ja sellaisen, jota et voi, välillä. Tämä artikkeli tarkastelee, miten ajaa TAK Serveriä ilman yksittäistä vikaantumiskohtaa: sovelluskerroksen klusterointi, tietokannan replikointi, asiakaskuorman tasaus ja sellaisen vikasietosiirron suunnittelu, joka valmistuu nopeammin kuin operaattori ehtii huomata.

Miksi yksi TAK Server -solmu on yksittäinen vikaantumiskohta

Oletusarvoinen TAK Server -asennus on yksittäinen Java-sovellus, jota tukee yksittäinen PostgreSQL/PostGIS-tietokanta yhdellä isäntäkoneella. Se toimii, se on yksinkertainen pystyttää, ja pienelle yksikölle se on täysin riittävä. Mutta tämä yksinkertaisuus kätkee neljä erillistä vikaantumisaluetta, joista mikä tahansa kaataa koko tilannekuvan: sovellusprosessi voi kaatua tai loppua keon (heap) muisti; isäntäkone voi menettää virran, verkon tai levyn; tietokanta voi korruptoitua, täyttää levynsä tai jumiutua lukkiumaan; ja asiakkaiden ja palvelimen välinen verkkopolku voi katketa. Yhden solmun suunnittelussa nämä eivät ole riippumattomia — minkä tahansa yhden menetys on totaalinen.

Korkea käytettävyys tarkoittaa kunkin näistä alueista suunnittelua niin, ettei mikään yksittäinen vika ole kohtalokas. Sovelluskerroksesta tulee keskenään vaihdettavissa olevien solmujen klusteri. Tietokannasta tulee replikoitu ensisijainen-plus-valmiussolmu-joukko automaattisella ylennyksellä. Asiakasyhteydestä tulee tasattu, terveystarkistettu virtuaalinen päätepiste kovakoodatun isännän sijaan. Tuloksena on järjestelmä, jossa solmu voidaan menettää — kaatumiselle, korjauspäivityksen uudelleenkäynnistykselle tai tuhotulle palvelinhuoneelle — ja operaattorit säilyttävät tilannekuvansa.

TAK Serverin klusteritila: viestintätaso

TAK Serverin korkean käytettävyyden perusta on klusteritila. Yhden solmun käyttöönotossa CoT-tapahtumat reititetään prosessin sisäisten jonojen kautta — viestintätaso elää yhden ajossa olevan sovelluksen sisällä. Klusteritilassa tuo taso ulkoistetaan jaetulle viestiväylälle, jotta useat TAK Server -solmut voivat toimia yhtenä loogisena palvelimena. Solmuun A yhdistäneen asiakkaan julkaisema CoT-tapahtuma jaetaan väylän yli ja toimitetaan solmuun B yhdistäneille asiakkaille ilman että nämä asiakkaat koskaan tietävät olevansa eri koneilla.

Tämä irrottaminen tekee sovelluskerroksesta samanaikaisesti vaakatasossa skaalautuvan ja vikasietoisen. Kapasiteetin lisääminen useammille asiakkaille tai suuremmalle jälkitiheydelle muuttuu solmujen lisäämiseksi — sama skaalausvipu, joka käsitellään artikkelissa TAK Serverin suorituskyvyn viritys. Solmun menetyksestä selviäminen muuttuu automaattiseksi, koska jokainen solmu pitää saman näkymän jaettuun tilaustilaan. Solmut ovat tilattomia tilannekuvan suhteen — kaikki pysyvä tila elää jaetussa tietokannassa ja viestiväylässä, ei minkään yksittäisen solmun muistissa.

Tilattomat solmut, jaettu tila

TAK Server -klusterin keskeinen suunnittelusääntö on, että sovellussolmujen on oltava tilattomia. Kaiken, minkä operaattori menettäisi solmun kadotessa, on elettävä solmun ulkopuolella: pysyvä CoT tietokannassa, ryhmä- ja tehtävätila tietokannassa, ja live-tilausreititys viestiväylässä. Kun tämä sääntö pätee, solmun vikaantuminen on datan kannalta ei-tapahtuma — ainoa kustannus on, että kuolleen solmun asiakkaiden on yhdistettävä uudelleen, ja tuo kustannus on rajattu sillä, kuinka nopeasti kuormantasaaja ja asiakkaat huomaavat vian.

Tietokannan korkea käytettävyys: todellinen pullonkaula

Kun sovelluskerros on klusteroitu, PostgreSQL/PostGIS-tietokannasta tulee hallitseva yksittäinen vikaantumiskohta — jokainen klusteroitu solmu riippuu samasta tietokannasta, joten suojaamaton tietokanta kumoaa kaiken sovelluskerroksen kestävyyden. Tietokannan korkea käytettävyys nojaa kolmeen yhdessä toimivaan komponenttiin.

Suoratoistoreplikointi. Ensisijainen solmu ottaa vastaan kaikki kirjoitukset ja lähettää jatkuvasti write-ahead-lokinsa (WAL) yhdelle tai useammalle valmiussolmulle, jotka toistavat sen pysyäkseen ajan tasalla. Synkroninen valmiussolmu kuittaa jokaisen vahvistuksen (commit) ennen kuin ensisijainen raportoi onnistumisesta, mikä takaa nollan datahäviön pienen kirjoitusviivesakon hinnalla; asynkroninen valmiussolmu jää jälkeen sekunnin murto-osan mutta ei lisää vahvistusviivettä. Vankka suunnittelu käyttää vähintään yhtä synkronista valmiussolmua palautumispisteen tavoitteelle ja lisää asynkronisia valmiussolmuja luvun skaalaukseen ja toipumiseen.

Automaattinen vikasietosiirto. Pelkkä replikointi ei tee vikasietosiirtoa — jonkin on havaittava, että ensisijainen on kuollut, ja ylennettävä valmiussolmu. Patroni, joka toimii agenttina jokaisella tietokantasolmulla, hoitaa tämän roolin. Se käyttää hajautettua konfiguraatiovarastoa — etcd tai Consul, käyttöönotettuna parittomana kvorumina kolme tai viisi jäsentä — johtajan lukon pitämiseen. Jos ensisijainen lakkaa uusimasta lukkoaan, Patroni valitsee ajantasaisimman valmiussolmun ja ylentää sen ensisijaiseksi, tyypillisesti 5–15 sekunnissa.

Yhteyden reititys. TAK Server -solmujen on aina yhdistettävä siihen tietokantaan, joka on tällä hetkellä ensisijainen, ilman uudelleenkonfigurointia. Yhteysreititin — PgBouncer tai HAProxy tietokantaporttien edessä — seuraa nykyistä johtajaa (Patroni päivittää sen terveyspäätepisteet ylennyksen yhteydessä) ja reitittää kirjoitusliikenteen sen mukaisesti. TAK Serverin näkökulmasta tietokanta on yksi vakaa virtuaalinen IP; valmiussolmun ylennys tuon IP:n takana on näkymätön.

Toipumistavoitteet ohjaavat suunnittelua

Kaksi lukua hallitsee tietokantakerrosta. Palautumispisteen tavoite (RPO) on se, kuinka paljon dataa sinulla on varaa menettää; vahvistetulle CoT-pysyvyydelle vastaus taktiselle järjestelmälle on yleensä nolla, mikä edellyttää synkronista valmiussolmua. Palautumisajan tavoite (RTO) on se, kuinka kauan vikasietosiirto saa kestää; Patronilla ja terveellä kvorumilla tämä on 5–15 sekunnin ylennysikkuna. Määrittele molemmat eksplisiittisesti ennen provisiointia — ne sanelevat, voitko sietää pelkkää asynkronista replikointia ja kuinka aggressiivisia vian havaitsemisajastimien on oltava.

Kuormantasaus ja asiakkaan uudelleenyhdistys

Asiakaspuolen kerros sitoo klusterin yhteen. ATAK ja muut TAK-asiakkaat pitävät pysyviä, keskinäisesti autentikoituja TLS-yhteyksiä palvelimeen. Jotta nuo yhteydet selviävät solmun menetyksestä, niiden on päätyttävä virtuaaliseen päätepisteeseen tietyn isännän sijaan.

Kerroksen 4 kuormantasaaja — HAProxy, NGINX stream -tila tai pilven L4-tasaaja — esittää yhden virtuaalisen IP:n TLS-asiakasporteille ja jakaa uudet yhteydet terveiden TAK Server -solmujen kesken käyttäen least-connections- tai round-robin-jakelua. Aktiiviset terveystarkistukset kunkin solmun tilapäätepistettä vasten poistavat vikaantuneen solmun kierrosta yhden terveystarkistusvälin sisällä. Ratkaisevasti tasaajan on toimittava kerroksessa 4 ja vietävä TLS läpi koskemattomana, koska TAK Server käyttää asiakassertifikaatin keskinäistä autentikointia, jonka on päätyttävä sovellussolmulle, ei tasaajalle.

Kun solmu vikaantuu, sen asiakkaiden soketit katkeavat. Jokainen asiakas havaitsee kuolleen soketin TCP-keepaliven kautta ja yhdistää uudelleen virtuaaliseen IP:hen, jossa tasaaja reitittää sen eloon jääneeseen solmuun. Koska jokainen solmu jakaa saman tietokannan ja viestiväylän, uudelleen yhdistänyt asiakas synkronoituu välittömästi nykyiseen tilannekuvaan. Havaittu katko määräytyy kokonaan asiakkaan keepalive-välin ja tasaajan terveystarkistuksen tahdin mukaan — viritä molemmat alas muutamaan sekuntiin, ja operaattori näkee hetkellisen "yhdistetään uudelleen" -tilan, ei tietoisuuden menetystä.

Kapasiteetin suunnittelu on tässäkin tärkeää. Mitoita klusteri niin, että yhden solmun menetys jättää silti riittävästi pelivaraa koko asiakaskunnan vastaanottamiseen — N+1-sääntö. Jos kaksi solmua ajavat kumpikin lähellä kyllästymistä ja toinen kuolee, jokainen pudonnut asiakas yhdistää uudelleen eloonjääneeseen ja ylikuormittaa sen, muuttaen yhden solmun vian kaskadiksi. Budjetoi jokainen solmu kantamaan vakaa-tilan osuutensa plus täysi vikasietosiirron osuus, ja varmenna kuorman alla, että eloonjäänyt voi ottaa vastaan piikin tyhjentämättä kekoa tai yhteysrajoja.

Katkoton huolto

Sama koneisto, joka selviää suunnittelemattomasta viasta, mahdollistaa myös suunnitellun huollon ilman käyttökatkoa. Solmun korjaamiseksi tai päivittämiseksi tyhjennä se (drain): käske kuormantasaajaa lopettamaan uusien yhteyksien lähettäminen, anna olemassa olevien asiakkaiden vanheta tai yhdistää muualle, ota sitten solmu alas, päivitä se ja palauta se kiertoon. Kierto klusterin läpi solmu kerrallaan pitää palvelun jatkuvasti saatavilla. Tietokannan päivitykset noudattavat samaa logiikkaa käänteisesti — päivitä valmiussolmut ensin, suorita sitten hallittu vaihto (switchover), joka ylentää jo päivitetyn valmiussolmun, jotta ensisijainen ei ole koskaan se solmu, joka on remontissa. Tämä muuttaa huoltoikkunan suunnitellusta katkosta läpinäkyväksi rullaavaksi operaatioksi.

Maantieteellinen redundanssi ja federointi

Solmun menetyksestä selviäminen on yksi asia; koko sijainnin menetyksestä selviäminen on toinen. Vaisto on venyttää yksi klusteri kahden datakeskuksen yli, mutta tietokannan kirjoituspolku tekee aidosta active-active-monialueklusterista epäkäytännöllisen: synkroninen replikointi suuren viiveen linkin yli lisää tuon edestakaisen matkan jokaiseen vahvistettuun kirjoitukseen, ja pelkkä asynkroninen replikointi alueiden välillä tuo takaisin datahäviön riskin vikasietosiirrossa.

Käytännöllinen malli on active-passive-maantieteellinen redundanssi. Täysi klusteri — klusteroidut sovellussolmut, synkroniset paikalliset valmiussolmut, paikallinen kvorumi — ajetaan ensisijaisessa sijainnissa. Asynkroninen suoratoistoreplikointi syöttää lämmintä valmiusklusteria toisessa sijainnissa, joka voidaan ylentää, jos ensisijainen sijainti menetetään kokonaan. Tämä rajaa sijaintien välisen RPO:n asynkronisen replikoinnin viiveeseen pitäen samalla sijainnin sisäisen kirjoituspolun nopeana.

Kun itsenäisten sijaintien on jaettava tilannekuva jakamatta tietokantaa, federointi on oikea työkalu klusteroinnin sijaan. Federointi yhdistää erilliset TAK Server -klusterit ja vaihtaa CoT:ta niiden välillä politiikan mukaisesti — mekanismi, joka käsitellään artikkelissa TAK Serverin federoinnin asennus. Klusterointi antaa sinulle yhden kestävän palvelimen; federointi yhdistää useita kestäviä palvelimia organisatoristen ja maantieteellisten rajojen yli. Kypsä käyttöönotto käyttää molempia: jokainen komento ajaa klusteroitua, korkeasti käytettävää TAK Serveriä, ja federointi ompelee nuo klusterit teatterinlaajuiseksi tilannekuvaksi.

Operatiivinen kuri: vian testaaminen

Korkean käytettävyyden suunnittelu, joka ei ole koskaan tehnyt vikasietosiirtoa tositilanteessa, on hypoteesi, ei kyvykkyys. Tärkein yksittäinen operatiivinen käytäntö on tarkoituksellisesti ja toistuvasti aiheuttaa vika: sammuta sovellussolmu kuorman alla ja mittaa asiakkaan uudelleenyhdistysaika; sammuta tietokannan ensisijainen ja varmista, että Patroni ylentää valmiussolmun RTO:n sisällä ilman pysyvän CoT:n menetystä; jaa kvorumivarasto osiin ja varmenna, että klusteri kieltäytyy jakautumasta (split-brain). Aja näitä harjoituksia realistisia asiakasmääriä ja jälkitiheyttä vastaan, ei tyhjää palvelinta. Tavoite on alle 30 sekunnin vikasietosiirto ilman operaattorin toimia — ja ainoa tapa luottaa tuohon lukuun on tuottaa se kuorman alla, tarkoituksella, monta kertaa.