Tere Habr! Esitan teie tähelepanu artikli tõlkele "Teenuse võrgu andmetasand vs juhttasand" autor Matt Klein.

Seekord "tahtsin ja tõlkisin" nii teenindusvõrgu komponentide, andmetasandi kui ka juhttasandi kirjelduse. See kirjeldus tundus mulle kõige arusaadavam ja huvitavam ning mis kõige tähtsam viis mõistmiseni küsimusest "Kas seda on üldse vaja?"

Kuna "Teenusevõrgu" idee on viimase kahe aasta jooksul muutunud üha populaarsemaks (algne artikkel 10. oktoober 2017) ja ruumis osalejate arv on suurenenud, olen näinud segaduse proportsionaalset kasvu kogu kogu tehnoloogiakogukond, kuidas võrrelda ja vastandada erinevaid lahendusi.

Olukorra võtavad kõige paremini kokku järgmised säutsud, mille ma juulis kirjutasin:

Teenindusvõrgu segadus nr 1: Linkerd ~ = Nginx ~ = Haproxy ~ = saadik. Ükski neist pole Istioga võrdne. Istio on midagi täiesti erinevat. 1/

Esimesed on lihtsalt andmetasandid. Iseenesest ei tee nad midagi. Neil peab olema tuju millekski enamaks. 2/

Istio on näide juhttasandist, mis seob osad kokku. See on teine ​​kiht. /lõpp

Eelmistes säutsudes mainitakse mitmeid erinevaid projekte (Linkerd, NGINX, HAProxy, Envoy ja Istio), kuid mis veelgi olulisem, tutvustatakse andmetasandi, teenindusvõrgu ja juhtimistasandi üldmõisteid. Selles postituses astun sammu tagasi ja räägin väga kõrgel tasemel, mida ma mõtlen mõistete "andmetasand" ja "juhttasand" all ning seejärel räägin sellest, kuidas terminid säutsudes mainitud projektide kohta käivad.

Mis on tõesti teenindusvõrk?

Joonis 1: hooldusvõrgu ülevaade

Joonis 1 illustreerib teenindusvõrgu kontseptsiooni selle kõige elementaarsemal tasemel. Teenuste klastreid (AD) on neli. Iga teenuse eksemplar on seotud kohaliku puhverserveriga. Kogu võrguliiklus (HTTP, REST, gRPC, Redis jne) ühest rakenduse eksemplarist edastatakse kohaliku puhverserveri kaudu vastavatesse välisteenuste klastritesse. Nii ei tunne rakenduse eksemplar võrgust kui tervikust ja on teadlik ainult oma kohalikust puhverserverist. Tegelikult eemaldati hajutatud süsteemivõrk teenusest.

Andmetasand

Teenusvõrgus täidab rakenduse lokaalselt asuv puhverserver järgmisi ülesandeid.

• Teenuse avastamine. Millised teenused/rakendused on teie rakenduse jaoks saadaval?
• Tervisekontroll. Kas teenusetuvastusega tagastatud teenuse eksemplarid on terved ja on võrguliikluse vastuvõtmiseks valmis? See võib hõlmata nii aktiivset (nt vastus/tervisekontroll) kui ka passiivset (nt 3 järjestikuse 5xx vea kasutamine ebatervisliku teenuse oleku indikaatorina) tervisekontrolli.
• Marsruutimine. Millisele teenuseklastrile tuleks päring saata, kui saate REST-teenuselt päringu aadressile "/foo"?
• Koormuse tasakaalustamine. Kui teenuseklaster on marsruutimise käigus valitud, siis millisele teenuse eksemplarile tuleks päring saata? Millise ajapiiranguga? Milliste voolukatkestusseadetega? Kui taotlus ebaõnnestub, kas tuleks seda uuesti proovida?
• Autentimine ja autoriseerimine. Kas sissetulevate päringute puhul saab helistamisteenust krüptograafiliselt tuvastada/volitada mTLS-i või mõne muu mehhanismi abil? Kui see on tuvastatud/volitatud, kas on lubatud teenuses taotletud toimingut (otspunkti) kutsuda või tuleks tagastada autentimata vastus?
• Vaadeldavus. Iga päringu jaoks tuleks luua üksikasjalik statistika, logid/logid ja hajutatud jälgimisandmed, et operaatorid saaksid aru hajutatud liiklusvoo ja silumisprobleemidest, kui need tekivad.

Andmetasand vastutab teenindusvõrgu kõigi eelnevate punktide eest. Tegelikult on teenuse (külgkorvi) kohalik puhverserver andmetasand. Teisisõnu vastutab andmetasand iga teenusesse või teenusest saadetud võrgupaketi tingimusliku levitamise, edastamise ja jälgimise eest.

Juhttasand

Võrgu abstraktsioon, mida kohalik puhverserver andmetasandil pakub, on maagiline (?). Kuidas aga puhverserver tegelikult teab teenuse B marsruudi "/foo" kohta? Kuidas saab kasutada puhverserveri päringutega täidetud teenuse avastamise andmeid? Kuidas on konfigureeritud koormuse tasakaalustamise, ajalõpu, voolukatkestuse jne parameetrid? Kuidas juurutada rakendust sinise/rohelise või graatsilise liikluse ülemineku meetodil? Kes konfigureerib kogu süsteemi autentimise ja autoriseerimise seadeid?

Kõik ülaltoodud elemendid on hooldusvõrgu juhttasandi kontrolli all. Juhttasand võtab isoleeritud olekuta puhverserverite komplekti ja muudab need hajutatud süsteemiks.

Arvan, et põhjus, miks paljud tehnoloogid peavad andmetasandi ja juhttasandi eraldi mõisteid segadust tekitavaks, on see, et enamiku inimeste jaoks on andmetasand tuttav, samas kui juhttasand on võõras/arusaamatu. Oleme pikka aega töötanud füüsiliste võrgu ruuterite ja kommutaatoritega. Mõistame, et paketid/päringud peavad jõudma punktist A punkti B ja et saame selleks kasutada riist- ja tarkvara. Uue põlvkonna tarkvara puhverserverid on lihtsalt väljamõeldud versioonid tööriistadest, mida oleme pikka aega kasutanud.

Joonis 2: Inimese juhtimistasand

Juhttasandeid oleme aga kasutanud juba pikka aega, kuigi enamik võrguoperaatoreid ei pruugi seda süsteemi osa ühegi tehnoloogiakomponendiga seostada. Põhjus on lihtne:
Enamik tänapäeval kasutusel olevaid juhtimislennukeid on... meie.

Edasi Joonis 2 näitab seda, mida ma nimetan "inimjuhtimistasandiks". Seda tüüpi juurutamise puhul, mis on endiselt väga levinud, loob tõenäoliselt tõre inimoperaator staatilised konfiguratsioonid – potentsiaalselt skriptide kaudu – ja juurutab need mõne eriprotsessi kaudu kõikidele puhverserveritele. Seejärel hakkavad puhverserverid seda konfiguratsiooni kasutama ja alustavad andmetasandi töötlemist värskendatud sätete abil.

Joonis 3: Täiustatud teenindusvõrgu juhttasand

Edasi Joonis 3 näitab hooldusvõrgu "laiendatud" juhttasapinda. See koosneb järgmistest osadest:

• Inimene: Ikka on inimene (loodetavasti vähem vihane), kes teeb kõrgel tasemel otsuseid kogu süsteemi kui terviku suhtes.
• Juhttasandi kasutajaliides: inimene suhtleb süsteemi juhtimiseks teatud tüüpi kasutajaliidesega. See võib olla veebiportaal, käsurearakendus (CLI) või mõni muu liides. Kasutajaliidese abil on operaatoril juurdepääs globaalsetele süsteemi konfiguratsiooniparameetritele, näiteks:
  • Kasutuselevõtu juhtimine, sinine/roheline ja/või järkjärguline üleminek liiklusele
  • Autentimise ja autoriseerimise valikud
  • Marsruutimistabeli spetsifikatsioonid, näiteks kui rakendus A küsib teavet "/foo" kohta, mis juhtub
  • Koormuse tasakaalustaja seaded, nagu ajalõpud, korduskatsed, voolukatkestuse seaded jne.
• Töökoormuse planeerija: teenuseid juhitakse infrastruktuuris teatud tüüpi ajastamis-/orkestreerimissüsteemi kaudu, näiteks Kubernetes või Nomad. Planeerija vastutab teenuse laadimise eest koos kohaliku puhverserveriga.
• Teenuse avastamine. Kui planeerija käivitab ja peatab teenuse eksemplarid, teatab see teenusetuvastussüsteemile terviseseisundi.
• Külgkorvi puhverserveri konfiguratsiooni API-d : kohalikud puhverserverid eraldavad dünaamiliselt oleku erinevatest süsteemikomponentidest, kasutades lõpuks ühtset mudelit ilma operaatori sekkumiseta. Kogu süsteem, mis koosneb kõigist praegu töötavatest teenuse eksemplaridest ja kohalikest puhverserveritest, koondub lõpuks üheks ökosüsteemiks. Envoy universaalne andmetasandi API on üks näide sellest, kuidas see praktikas töötab.

Põhimõtteliselt on juhttasandi eesmärk määrata poliitika, mille andmetasand lõpuks aktsepteerib. Täiustatud juhtimistasandid eemaldavad operaatorilt rohkem osi mõnest süsteemist ja nõuavad vähem käsitsi juhtimist, eeldusel, et need töötavad õigesti!...

Andmetasand ja juhtimistasand. Andmetasandi vs juhttasandi kokkuvõte

• Teenindusvõrgu andmetasand: mõjutab iga paketti/päringut süsteemis. Vastutab rakenduste/teenuste avastamise, tervisekontrolli, marsruutimise, koormuse tasakaalustamise, autentimise/volitamise ja vaadeldavuse eest.
• Hooldusvõrgu juhttasand: pakub poliitikat ja konfiguratsiooni kõikidele teenindusvõrgus töötavatele andmetasanditele. Ei puuduta ühtegi süsteemi paketti/päringut. Juhttasand muudab kõik andmetasandid hajutatud süsteemiks.

Praegune projektimaastik

Olles ülaltoodud selgitusest aru saanud, vaatame teenindusvõrgu projekti hetkeseisu.

• Andmetasandid: Linkerd, NGINX, HAProxy, Envoy, Traefik
• Juhtlennukid: Istio, Nelson, SmartStack

Selle asemel, et minna iga ülaltoodud lahenduse süvaanalüüsi, käsitlen lühidalt mõningaid punkte, mis minu arvates põhjustavad praegu ökosüsteemis suurt segadust.

Linkerd oli 2016. aasta alguses üks esimesi andmetasandi puhverservereid teenindusvõrgu jaoks ja on teinud fantastilist tööd teenindusvõrgu disainimudeli teadlikkuse ja tähelepanu tõstmisel. Umbes 6 kuud pärast seda liitus Envoy Linkerdiga (kuigi ta oli Lyftis olnud alates 2015. aasta lõpust). Linkerd ja Envoy on kaks projekti, mida teenindusvõrkude arutamisel kõige sagedamini mainitakse.

Istio kuulutati välja 2017. aasta mais. Istio projekti eesmärgid on väga sarnased joonisel näidatud laiendatud juhttasandiga Joonis 3. Envoy for Istio on vaikepuhverserver. Seega on Istio juhttasand ja Envoy on andmetasand. Lühikese ajaga tekitas Istio palju põnevust ja teised andmetasandid hakkasid Envoy asendusena integreerima (nii Linkerd kui ka NGINX demonstreerisid integreerimist Istioga). Asjaolu, et samal juhttasandil saab kasutada erinevaid andmetasandiid, tähendab, et juhttasand ja andmetasand ei pruugi olla tihedalt seotud. API, nagu Envoy üldine andmetasandi API, võib moodustada silla süsteemi kahe osa vahel.

Nelson ja SmartStack aitavad veelgi illustreerida juhttasandi ja andmetasandi eraldamist. Nelson kasutab oma puhverserverina Envoy'd ja ehitab HashiCorpi pinu alusel teenindusvõrgu jaoks usaldusväärse juhttasandi, st. Nomad jne. SmartStack oli võib-olla esimene teenindusvõrkude uuest lainest. SmartStack ehitab HAProxy või NGINX ümber juhttasandi, näidates võimet juhttasandit andmetasandist teenindusvõrgust lahti ühendada.

Teenusevõrguga mikroteenuste arhitektuur pälvib üha rohkem tähelepanu (õigustatult!) ning üha enam projekte ja hankijaid hakkab selles suunas tööle. Järgmise paari aasta jooksul näeme nii andmetasandil kui ka juhtimistasandil palju uuendusi, aga ka erinevate komponentide edasist segamist. Lõppkokkuvõttes peaks mikroteenuste arhitektuur muutuma operaatori jaoks läbipaistvamaks ja maagilisemaks (?).
Loodetavasti aina vähem ärritunud.

Võtmed kaasavõtmiseks

• Teenindusvõrk koosneb kahest erinevast osast: andmetasandist ja juhttasandist. Mõlemad komponendid on vajalikud ja ilma nendeta süsteem ei tööta.
• Juhttasand on kõigile tuttav ja praegusel hetkel võiks juhttasand olla sina!
• Kõik andmetasandid konkureerivad üksteisega funktsioonide, jõudluse, konfigureeritavuse ja laiendatavuse osas.
• Kõik juhtimistasandid konkureerivad üksteisega funktsioonide, konfigureeritavuse, laiendatavuse ja kasutuslihtsuse poolest.
• Üks juhttasand võib sisaldada õigeid abstraktsioone ja API-sid, nii et saab kasutada mitut andmetasandit.

Allikas: www.habr.com