Taktinen reunapilvi: palvelujen suorittaminen DIL-ympäristöissä

Pilvinatiivinen ohjelmisto perustuu oletukseen, joka ei juuri koskaan pidä paikkaansa taktisella reunalla: että verkko on aina saatavilla. Palveluhavainto, hajautetut tietokannat, konttiorkestroijat ja tilaton API-kerros kaikki olettavat, että mikä tahansa solmu voi tavoittaa minkä tahansa muun solmun muutamassa millisekunnissa koko ajan. Siirrä sama ohjelmisto etulinjan tukikohtaan, liikkuvaan ajoneuvoon tai jalkaväkijoukkoon mäen taakse, ja oletus romahtaa. Yhteys katkeaa tunneiksi, palaa yhdeksäksikymmeneksi sekunniksi ja tarjoaa sitten kaksi kilobiittiä sekunnissa satelliittiterminaalin kautta. Tämä on DIL-ympäristö – katkonainen (disconnected), ajoittainen (intermittent) ja rajoitettu (limited) – ja palvelujen suorittaminen siinä edellyttää monien oletusarvojen kääntämistä, jotka tekevät pilvioljelmistosta kätevää datakeskuksessa.

Mitä DIL todella tarkoittaa ohjelmistolle

Kolme kirjainta kuvaavat kolmea erillistä vikatilaa, ja taktisen reunan järjestelmän on käsiteltävä kaikkia niitä samanaikaisesti. Katkosessa yhteys on poissa kokonaan, joskus koko mission keston ajan. Partio voi toimia kaksi päivää ilman minkäänlaista takaisinyhteyttä. Ajoittainen tarkoittaa, että yhteys välkkyy ennakoimattomasti – ajoneuvo kulkee maaston taakse, suunta-antenni menettää lukon, vastustajan häirintä pyyhkii kaistan yli. Yhteys on päällä sekunteja, poissa minuutteja, eikä ohjelmisto voi ennustaa kaavaa. Rajoitettu tarkoittaa, että vaikka yhteys on olemassa, se on kapea ja hidas: taktinen SATCOM-kanava voi tarjota muutaman kilobiittiä sekunnissa jaettuna koko elementin kesken, viiveellä, joka mitataan sadoissa millisekunnissa tai enemmän.

Datakeskukselle suunniteltu järjestelmä pitää mitä tahansa näistä virheenä, joka uusintayritettävä. DIL:lle suunniteltu järjestelmä pitää kaikkia niitä normaalina käyttötilana. Käytännön seuraus on, että mikään operaattorin toiminta ei voi koskaan estää odottamalla etäpalvelua, mikään kriittinen data ei voi sijaita vain solmussa, jota operaattori ei voi tavoittaa, ja jokaisen linkin yli lähetettävän tavun on ansaittava paikkansa. Nämä rajoitteet eivät ole reunatapauksia, joita lisätään jälkeenpäin; ne muokkaavat arkkitehtuuria ensimmäisestä suunnittelupäätöksestä lähtien. Sama kurinalaisuus tukee laajempaa työtämme resilienttistä puolustuksen pilvistrategiasta, jossa saatavuus heterogeenisissä ympäristöissä on ohjaava vaatimus.

Paikallinen ensin: perustavanlaatuinen inversio

Tärkein arkkitehtuurinen päätös taktiselle reunapilvelle on tehdä jokaisesta solmusta paikallinen ensin. Paikallinen ensin -suunnittelussa jokainen reunasolmu pitää hallussaan täydellisen, auktoritatiivisen kopion tarvitsemastaan työdatasta ja palvelee jokaista operaattorin pyyntöä tästä paikallisesta kopiosta. Luet ja kirjoitukset suoritetaan upotettuun varastoon paikallisella viiveellä. Synkronointi vertaisien ja yrityksen kanssa on taustatoiminto, joka toimii opportunistisesti aina kun yhteys sallii – se ei ole koskaan käyttäjän toiminnon kriittisellä polulla.

Tämä kääntää tavanomaisen pilvikaavan, jossa asiakas on ohut ja palvelin pitää totuutta. Reunalla solmu pitää totuutta niin kauan kuin se on irrotettu, ja yrityksestä tulee yksi vertainen, jonka kanssa sovitellaan, eikä riippuvuus, jonka on oltava tavoitettavissa. Operaattorikokemus on identtinen riippumatta siitä, onko solmulla paksu putki takaisin päämajaan tai ei lainkaan yhteyttä – ja tämä invarianssi on koko pointti. Operaattori, jonka on mietittävä onko verkko päällä ennen kuin päättää, toimiiko toiminto, on jo järjestelmän hylkäämä.

Missä tila sijaitsee

Paikallinen ensin tarkoittaa jokaisen solmun varustamista oikealla tietokannalla, ei välimuistilla. Upotettu SQLite tai upotettu relaatiomoottori, joka sisältää solmun täydellisen työsarjan, on yleinen valinta; yhteistoiminnalliselle tilalle dokumenttivarasto sisäänrakennetuilla replikointisemantiikalla toimii hyvin. Varaston on oltava kestävä virranmenetyksen yli – reunalaitteisto käynnistetään uudelleen, pudotetaan ja käytetään tyhjenevillä akuilla – joten kirjoituksen läpinäkyvä lokikirjaus ja kaatumisesta palautuminen eivät ole valinnaisia. Ratkaisevaa on, että paikallinen varasto on totuuden lähde irrotettuna ollessaan. Kiusaus kohdella paikallista kopiota käsiteltävänä välimuistina, jonka palvelin voi mitätöidä, on täsmälleen se datakeskusrefleksi, jonka DIL-suunnittelun on tukahdutettava.

Synkronointi: liikuttaa vain sitä mikä merkitsee

Jos jokainen solmu pitää oman auktoritatiivisen kopionsa, vaikea ongelma on pitää nämä kopiot hyödyllisesti linjassa linkkien yli, jotka ovat suurimmaksi osaksi poissa ja aina kapeat. Naiivin replikointi – koko tilavedoksen suoratoistaminen tai jokaisen kirjoituksen välittömästi lähettäminen – on toivoton muutamalla kilobittiä sekunnissa. Synkronointiprotokollan on oltava delta-pohjainen, priorisoitu, jatkettavissa oleva ja idempotentti.

Delta-pohjainen tarkoittaa, että jokainen synkronointivaihto kuljettaa vain tietueet, jotka muuttuivat viimeisen onnistuneen vaihdon jälkeen kyseisen vertaisensa kanssa, tunnistettuna per-vertais-korkean vesimerkin tai vektorikellon avulla. Priorisoitu tarkoittaa, että lähtevä jono on järjestetty operatiivisen arvon mukaan: ystävälliset ja viholliset sijainnit, käskyt ja hälytykset menevät ensin; rutiini-tilapäivitykset seuraavaksi; bulkkimedia, kuten kuvat ja koko liike-video, viimeksi erillisessä matalan prioriteetin kaistassa, joka käyttää vain vapaata kapasiteettia. Jatkettavissa oleva tarkoittaa, että keskeytynyt siirto – normaali tapaus kun yhteydet ovat ajoittaisia – jatkuu viimeisestä vahvistetusta tietueesta eikä alusta alkaen, joten synkronointi, joka saa yhdeksänkymmentä sekuntia yhteyttä, tekee yhdeksänkymmentä sekuntia todellista edistystä. Idempotentti tarkoittaa, että osittain toimitetun erän toistaminen ennen linkin katkeamista ei tuota kahdennoksia, koska vastaanotin käyttää avaimena vakaita tietuetunnisteita eikä saapumisjärjestystä.

Pakkaus merkitsee enemmän tässä kuin melkein missään muualla ohjelmistosuunnittelussa, koska linkki on sitova rajoite. Jäsennelty operatiivinen data pakkautuu erittäin hyvin, ja viestiskeemaan viritetty sanakirja voi kutistaa sijaintiraportin tai käskyn murto-osaan sen lankakoosta. Suunnittelutavoite on hyödyllinen, ajantasainen operatiivinen kuva, joka synkronoituu kanavan yli, jota datakeskusinsinööri pitäisi käyttökelvottomana.

Opportunistinen ja varastointi-ja-edelleenlähetys -kuljetus

Koska yhteys on ennakoimaton, kuljetuskerroksen on oltava opportunistinen: heti kun jokin yhteys ilmestyy – ensisijainen radio, näköpiirin mesh lähellä olevaan ajoneuvoon, lyhyt SATCOM-ikkuna tai jopa kuriiri, joka kuljettaa fyysistä asemaa solmujen välillä – synkronointimoottori tyhjentää niin paljon prioriteettijonosta kuin ikkuna sallii. Varastointi-ja-edelleenlähetys -reititys antaa yhden solmun välittää toisen solmun odottavat päivitykset, kun sillä on parempi yhteys, joten ajoneuvo, joka nousee pintaan maaston takaa, voi kuljettaa jalkaväkijoukon raportit eteenpäin. Tämä on hengeltään lähempänä viive-toleranttia verkottumista kuin pyyntö-vastaus-API:a, ja synkronointimoottori suunnitellaan tämän mallin ympärille eikä HTTP-semantiikan ympärille, mikä saa sen selviämään ajoittaisesta tapauksesta.

Sovittelu: samanaikaisten muokkausten ratkaiseminen

Hinta, joka maksetaan siitä, että jokainen solmu saa kirjoittaa paikallisesti irrotettuna ollessaan, on se, että kaksi solmua muokkaa väistämättä samaa asiaa näkemättä toistensa muutosta. Kun ne yhdistyvät, järjestelmän on soviteltava. Ei ole yhtä oikeaa strategiaa; oikea riippuu datan muodosta.

Pelkästään liitettävät tapahtumalokiot sivuuttavat konfliktin kokonaan. Jos solmu vain koskaan liittää tietueita – sensorin lukemat, raportit, lokimerkinnät – kahden lokin yhdistäminen on vain unioni, järjestettynä loogisella kellolla. Suurin osa telemetria- ja raportointidatasta sopii tähän malliin, ja sen pitäisi olla oletusarvo aina kun data on luontaisesti tapahtumien virta eikä muuttuva tietue.

Ristiriidattomat replikoitavat tietotyypit (CRDT:t) käsittelevät jaettua muuttuvaa tilaa, jota useat solmut muokkaavat yhteistoiminnallisesti – jaettu grafiikkakartta, käynnissä oleva luettelo, reittipisteiden joukko. CRDT kuljettaa riittävästi metatietoa, että mitkä tahansa kaksi replikaa yhdistyvät deterministisesti samaan tulokseen riippumatta siitä, missä järjestyksessä päivitykset saapuvat, mikä on täsmälleen tae, jonka ajoittainen verkko ei muuten voi antaa. Hinta on per-tietue-metadatayleiskustannus, joten CRDT:t varataan aidosti yhteistoiminnalliselle tilalle eikä niitä sovelleta laajasti kaikkialle.

Viimeksi kirjoittanut voittaa operaattorin arbitraatiolla kattaa loput: muuttuvat tietueet, joihin ei sovi tapahtumalokin eikä CRDT. Hybridilooginen kello päättää deterministisen voittajan, jotta järjestelmä ei koskaan lukkiudu, mutta häviäjä säilytetään ja tietue merkitään ihmistarkastelua varten. Perusteena on, että aito semanttinen ristiriita – kaksi operaattoria muuttaa itsenäisesti saman kohteen luokittelua – on tuomio, jonka ihmisen pitää tehdä, ei sellainen, jonka automaattisen säännön pitäisi hiljaisesti haudata. Tämä kaava jakaa käsitteellisen sukujuuren offline-first-suunnittelun kanssa, jota käytetään jalkaväen kenttäsovelluksissa, jossa sama offline-muokkausongelma ilmenee laitetasolla.

Pilvinatiivien palvelujen suorittaminen reunalaitteistolla

Taktiset reunasolmut eivät ole hyperscale-telineitä. Ne ovat kestäviä pienimuotoisia laskentayksiköitä – ajoneuvoon asennettu palvelin, siirrettävä klusteri komentopaikalla, joskus yksittäinen tietokonelevy repussa – jotka toimivat rajoitetulla virralla ja jäähdytyksellä. Silti tavoitteena on edelleen ajaa pilvinatiiveja palveluja, koska samojen kontitettujen palvelujen pitäisi toimia identtisesti yrityksen datakeskuksessa, alueellisessa solmussa ja etulinjan reunalla. Tämä siirrettävyys on se, mikä antaa kyvykkyyden kehittää kerran ja ottaa käyttöön kaikkialla.

Käytännön lähestymistapa on kevyt konttiorkestroija, joka on mitoitettu reunalle eikä datakeskukselle. Yksittäinen binaari Kubernetes-jakelu, kuten K3s, tai pieni hallittu klusteri antaa saman käyttöönottomalliin ja samat manifestit kuin yrityksessä ilman ohjaustasopainoa, jota reunalaitteisto ei pysty säästämään. Sama kovennuskuri pätee edelleen – uhkamalli ei pehmenee, koska klusteri on pieni, ja käytännöt oppaassamme Kubernetesin koventamisesta puolustustyötaakille siirtyvät suoraan reunaklustereihin. Muuttuu mitoitus ja vikaolettamukset: orkestroijan on pidettävä työtaakat käynnissä ilman takaisinyhteyttä keskitettyyn ohjaustasoon, kuvanvedot on tultava ennen käyttöönottoa siemennetystä paikallisesta rekisteristä eikä internet-vedosta, ja klusterin on siedettävä solmun yksinkertaisesti katoaminen, kun ajoneuvo ajaa pois alueelta.

Identiteetti ja turvallisuus ilman takaisinyhteyttä

Irrotetun solmun on silti autentikoitava operaattorit ja valtuutettava toiminnot, eikä se voi soittaa kotiin tehdäkseen sen. Tunnistetiedot ja valtuutuskäytäntö on välimuistiin tallennettava paikallisesti järkevällä offline-elinajanodotuksella – tarpeeksi pitkä kestämään realistisen katkosikkunan yli, tarpeeksi lyhyt, ettei kaapattu solmu pysy luotettuna loputtomasti. Varmenteen peruutus on kanoninen vaikea tapaus: solmu, joka ei voi tavoittaa peruutuslistaa, on turvauduttava lyhytaikaisiin varmenteisiin, joiden luonnollinen vanhentuminen rajaa altistumisen. Paikallisen varaston salaaminen ja nopean, peruuttamattoman tyhjennyksen tarjoaminen laitteistolle, joka on vaarassa joutua sieppauksen kohteeksi, ovat perustason vaatimuksia, ei parannuksia, koska reunasolmut ovat arkkitehtuurin osa, joka todennäköisimmin joutuu vihamielisiin käsiin.

DIL-suunnittelun validointi ennen käyttöönottoa

Vikatila, joka lopettaa ohjelmat, on huomata kentällä, että järjestelmä, jota on testattu vain puhtaalla LAN:lla, ei oikeasti toimi taktisen radion kautta. LAN:lla ei ole mitään niistä ominaisuuksista, jotka määrittävät DIL:n, joten vihreä testisarja LAN:lla ei kerro mitään DIL-käyttäytymisestä. Validointi edellyttää verkkoemulaattoria, joka sijoitetaan solmujen väliin ja injektoi todelliset olosuhteet – linkkikatkokset vaihtelevalla kestolla, viive sadoissa millisekunnissa, pakettihukka ja tiukat kaistanleveyden rajat, jotka vastaavat kohderadioita. Hyväksymistesti on kaksitahoinen: operaattorien on pystyttävä suorittamaan kaikki missionkriittiset tehtävät linkin ollessa alhaalla koko mission keston ajan, ja solmujen on konvergoitava yhteen yhtenäiseen kuvaan yhteyden palautuessa, myös stressitapauksessa, jossa useat solmut yhdistyvät samanaikaisesti kun kukin on muokannut offline-tilassa.

Järjestelmä, joka läpäisee molemmat testit, on ansainnut oikeuden kutsua itseään taktiseksi reunapilveksi. Se, jota on ajettu vain LAN:lla, on testattu mukavuuden vuoksi, ei ympäristössä, jossa se oikeasti kohtaa.