Përshëndetje, Habr! Po ju prezantoj një përkthim të artikullit «Plani i të dhënave të rrjetit të shërbimeve vs plani kontrollues» autori Matt Klein.

Këtë herë, kam «vërejtur dhe përkthyer» përshkrimin e të dy componenteve të rrjetit të shërbimeve, plani i të dhënave dhe plani kontrollues. Ky përshkrim më dukej më i qartë dhe interesant, dhe më e rëndësishmja, e çon drejt kuptimit «A është e nevojshme действительно?»

Duke qenë se ideja e «Rrjetit të shërbimeve» po bëhet gjithnjë e më popullore gjatë dy viteve të fundit (artikulli origjinal nga 10 tetori 2017), dhe numri i pjesëmarrësve në këtë hapësirë është rritur, kam vërejtur një rritje proporcionale të konfuzionit në mesin e gjithë komunitetit teknik në lidhje me mënyrën se si të krahasohen dhe përballen zgjidhjet e ndryshme.

Situatën e përshkruan më së miri seria e mëposhtme e tweets që kam shkruar në korrik:

Konfuzioni me rrjetin e shërbimeve nr. 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Asnjë prej tyre nuk është i barabartë me Istio. Istio është diçka krejtësisht tjetër. 1 /

Të parat janë thjesht plane të dhënash. Ato vetë nuk bëjnë asgjë. Ato duhet të konfigurohen për diçka më të madhe. 2 /

Istio është një shembull i një plani kontrollues që lidh pjesët së bashku. Është një shtresë tjetër. /fund

Në tweets e mëparshme përmenden disa projekte të ndryshme (Linkerd, NGINX, HAProxy, Envoy dhe Istio), por, më e rëndësishmja, prezantohen konceptet e zakonshme të planeve të dhënash, rrjetit të shërbimeve dhe planeve kontrolluese. Në këtë post, do të bëj një hap prapa dhe do të shpjegoj se çfarë kam parasysh me termat «plani i të dhënave» dhe «plani kontrollues» në një nivel shumë të lartë, dhe pastaj do të diskutoj se si këto terma lidhen me projektet e përmendura në tweets.

Çfarë është në të vërtetë një rrjet shërbimesh?

Figura 1: Pasqyrë e rrjetit të shërbimeve

Figura 1 ilustron konceptin e rrjetit të shërbimeve në nivelin më bazik. Ka katër klasterë shërbimesh (A-D). Çdo instancë shërbimi është e lidhur me një server proxy lokal. I gjithë trafiku rrjetor (HTTP, REST, gRPC, Redis etj.) nga një instancë e veçantë e aplikacionit kalon përmes serverit proxy lokal në klasterët shërbimesh përkatës. Në këtë mënyrë, instanca e aplikacionit nuk e di për rrjetin në tërësi dhe di vetën për serverin e saj lokal proxy. Në fakt, rrjeti i sistemit të shpërndarë është hequr nga shërbimi.

Plani i të dhënave

Në rrjetin e shërbimeve, serveri proxy lokal për aplikacionin kryen detyrat e mëposhtme:

• Zbulimi i shërbimeve (Service discovery). Cilat shërbime/faqe/aplikacione janë të disponueshme për aplikacionin tuaj?
• Kontrolli i shëndetit (Health checking). A janë instancat e shërbimeve, të kthyera nga zbulimi i shërbimeve (service discovery), të shëndetshme dhe të gatshme për të pranuar trafik rrjeti? Kjo mund të përfshijë si kontrolle aktive (p.sh., kontroll ndaj përgjigjes / healthcheck), ashtu edhe kontrolle pasive (p.sh., duke përdorur 3 gabime 5xx radhazi si një tregues të një gjendjeje të papërshtatshme të shërbimit).
• Rruga (Routing). Pasi të keni marrë një kërkesë REST nga shërbimi për "\/foo", në cilin grup shërbimesh duhet të dërgohet kërkesa?
• Balancimi i ngarkesës (Load balancing). Pasi të jetë zgjedhur një grup shërbimesh gjatë rrugës, në cilin instancë të shërbimit duhet të dërgohet kërkesa? Me çfarë periudhe pritjeje? Me çfarë cilësimesh për ndalimin e lidhjes (circuit breaking)? Nëse kërkesa dështon, a duhet të përsëritet?
• Autentikimi dhe autorizimi (Authentication and authorization). Për kërkesat hyrëse, mund të identifikohet/autorizohet shërbimi thirrës në mënyrë kriptografike me mTLS ose ndonjë mekanizëm tjetër? Nëse ai identifikohet/autorizohet, a i lejohet atij të thërrasë operacionin e kërkuar (endpoint) në shërbim, ose duhet kthyer një përgjigje jo të autentikuar?
• Vëzhgueshmëria (Observability). Për çdo kërkesë duhet të gjenerohen të dhëna të detajuara statistikore, regjistrime/loge dhe të dhëna të gjurmimit të shpërndarë, në mënyrë që operatorët të mund të kuptojnë fluksin e shpërndarë të trafikut dhe problemet e krijuara gjatë zhvillimit të tyre.

Për të gjitha pikat e mësipërme në rrjetin e shërbimeve (service mesh), përgjigjet plani i të dhënave (data plane). Në thelb, proxy lokal për shërbimin (sidecar) është plani i të dhënave (data plane). Në fjalë të tjera, plani i të dhënave (data plane) është përgjegjës për transaksionin, dërgimin dhe vëzhgimin e çdo pakete rrjeti që dërgohet në shërbim ose dërgohet nga ai.

Plani i kontrollit (The control plane)

Abstraksioni rrjetor që ofron një proksi lokal në planin e të dhënave (data plane) është magjik (?); megjithatë, si e di me të vërtetë proksi se si të arrijë në rrugën «/foo» për shërbimin B? Si mund të përdoren të dhënat e zbulimit të shërbimeve (service discovery) që mbushen me kërkesa proksi? Si janë të konfiguruara parametrat e balancimit të ngarkesës, kohëzgjatjes (timeout), ndërprerjes së zinxhirit (circuit breaking), etj.? Si realizohet shpërndarja e aplikacioneve duke përdorur metodën blu/jeshile (blue/green) ose metodën e kalimit gradual të trafikut? Kush konfiguron parametrat e autentifikimit dhe autorizimit sistemik?

Të gjitha piketat e lartpërmendura janë nën menaxhimin e planit të kontrollit (control plane) të rrjetit të shërbimeve (service mesh). Plani i kontrollit (control plane) merr një grup proksi të izoluarserverësh pa gjendje dhe i shndërron në një sistem të shpërndarë..

Mendoj se arsyeja pse shumë teknologë e gjejnë të komplikuar ndarjen e koncepteve të planit të të dhënave (data plane) dhe planit të kontrollit (control plane) është se për shumicën e njerëzve plani i të dhënave është i njohur, ndërsa plani i kontrollit është i huaj/jo i kuptueshëm. Ne kemi punuar me kalim shumë kohë me router-a dhe switch-a fizikë të rrjetit. Ne e kuptojmë se paketat/kërkesat duhet të shkojnë nga pika A në pikën B dhe se çfarë mund të përdorim për këtë, hardware dhe software. Brezi i ri i proksi-ve softuerike është thjesht versione moderne të mjeteve që kemi përdorur për një kohë të gjatë.

Figur 2: Plani i kontrollit njerëzor (Human control plane)

Megjithatë, ne kemi përdorur prej kohësh plane kontrolli (control plane), edhe pse shumica e operatorëve të rrjetit mund të mos e lidhin këtë pjesë të sistemit me ndonjë komponent teknologjik. Arsyeja është e thjeshtë:
Shumica e planeve të kontrollit (control plane) që përdoren sot janë… ne.

Në në figurën 2. shfaqet ajo që e quaj «Niveli i kontrollit njerëzor (Human control plane)». Në këtë lloj implementimi, i cili ende ndodh shpesh, operatori njeri, ndoshta nervoz, krijon konfiguracione statike — potencialisht me ndihmën e skriptave — dhe i implementon ato përmes një procesi të caktuar në të gjitha serverat proxy. Pastaj, proxy fillojnë të përdorin këtë konfiguracion dhe fillojnë të përpunojnë nivelin e të dhënave (data plane) duke përdorur parametrat e rinj.

Figura 3: Niveli i avancuar i kontrollit të rrjetit të shërbimeve (Advanced service mesh control plane)

Në figura 3 tregon «niveli i avancuar» i kontrollit (control plane) të rrjetit të shërbimeve (service mesh). Ai përbëhet nga këto pjesë:

• Njeriu (The human): Akoma ka një njeri (shpresoj, më pak i mërzitur), i cili merr vendime në nivel të lartë në lidhje me të gjithë sistemin si një tërësi.
• Interfejsi i përdoruesit të nivelit të kontrollit (Control plane UI): Njeriu ndërvepron me një lloj interfejsi përdoruesi për të menaxhuar sistemin. Kjo mund të jetë një portal web, një aplikacion për linjë komandimi (CLI) ose një interfejs tjetër. Me anë të interfejsit të përdoruesit, operatori ka qasje në parametrat globalë të konfigurimit të sistemit, si:
  • Menaxhimi i implementimit, blue/green dhe/o gradual i kalimit të trafikut
  • Parametrat e autentifikimit dhe autorizimit
  • Specifikimet e tabelës së routing, p.sh., kur aplikacioni A kërkon informacion mbi «/foo», çfarë ndodh
  • Cilësimet e balancuesit të ngarkesës, p.sh., kohë të skadimit (timeouts), ripërpjekje (retries), parametrat e ndalimit të qarkut (circuit breaking) etj.
• Planifikuesi i ngarkesave (Workload scheduler): Shërbimet nisin në infrastrukturë përmes një sistemi planifikimi/orchestrimi të caktuar, si Kubernetes ose Nomad. Planifikuesi është përgjegjës për ngarkimin e shërbimit me serverin e tij lokal proxy.
• Zbulimi i shërbimit (Service discovery). Kur planifikuesi nis dhe ndalon ekzemplarët e shërbimit, ai raporton gjendjen e punës në sistemin e zbulimit të shërbimit.
• API-të e konfigurimit të serverit proxy lokal (Sidecar proxy configuration APIs) : Serverat lokale proxy nxjerrin dinamikinë nga komponentë të ndryshëm të sistemit sipas modelit të "konsistencës në fund" (eventually consistent) pa ndërhyrjen e operatorit. E gjithë sistemi, e përbërë nga të gjithë instancat aktive të shërbimeve dhe serverave lokalë proxy, përfundimisht bashkohet në një ekosistem. API e planit të të dhënave (data plane) në Envoy është një nga shembujt se si funksionon në praktikë.

Në thelb, qëllimi i planit të kontrollit (control plane) është të vendosë politikën që përfundimisht do të njihet nga plani i të dhënave (data plane). Planët më të avancuar të kontrollit (control plane) do të largojnë më shumë detaje nga operatori të disa sistemeve dhe do të kërkojnë më pak ndihmë manuale, për sa kohë që funksionojnë siç duhet!..

Plani i të dhënave dhe plani i kontrollit. Përmbledhje (Data plane vs. control plane summary)

• Plani i të dhënave të rrjetit të shërbimeve (Service mesh data plane): prek çdo paketë / kërkesë në sistem. Është përgjegjës për zbulimin e aplikacioneve / shërbimeve, kontrollin e funksionit, routing, shpërndarjen e ngarkesës, autentifikimin / autorizimin dhe vëzhgimin.
• Plani i kontrollit të rrjetit të shërbimeve (Service mesh control plane): ofron politikën dhe konfigurimin për të gjitha planet e punës të të dhënave brenda rrjetit të shërbimeve. Nuk prek asnjë paketë / kërkesë në sistem. Plani i kontrollit e kthen të gjithë planet e të dhënave në një sistem të shpërndarë.

Gjendja aktuale e projektit (Current project landscape)

Pas shpjegimit të mësipërm, le të shikojmë gjendjen aktuale të projektit "rrjeti i shërbimeve (service mesh)".

• Planet e të dhënave (Data planes): Linkerd, NGINX, HAProxy, Envoy, Traefik
• Planet e kontrollit (Control planes): Istio, Nelson, SmartStack

Në vend që të bëj një analizë të thellë të secilit nga zgjidhjet e mësipërme, do të ndalem shkurtimisht në disa pika që, sipas mendimit tim, shkaktojnë shumicën e konfuzionit në ekosistem tani për tani.

Në fillim të vitit 2016, Linkerd ishte një nga serverët proxy të parë të planit të dhënave për rrjetin e shërbimeve dhe kreu një punë fantastike në rritjen e ndërgjegjshmërisë dhe tërheqjes ndaj modelit të projektimit 'rrjeti i shërbimeve'. Rreth 6 muaj pas kësaj, Envoy iu bashkua Linkerd, ndonëse kishte punuar në Lyft që nga fundi i vitit 2015. Linkerd dhe Envoy janë dy projektet që përmenden më shpesh kur diskutohet për rrjetet e shërbimeve.

Istio u shpall në maj 2017. Objektivat e projektit Istio janë shumë të ngjashme me planin e avancuar të menaxhimit të treguar në figura 3. Envoy për Istio është serveri proxy 'ngjashëm'. Kështu që Istio është plani i menaxhimit dhe Envoy është plani i dhënave. Në një kohë të shkurtër, Istio shkaktoi shumë entuziazëm, dhe plane të tjera të dhënash filluan integrimin si zëvendësues të Envoy (si Linkerd ashtu edhe NGINX demonstruan integrimin me Istio). Fakti që në një plan menaxhimi mund të përdoren plane të ndryshme të dhënash do të thotë se plani i menaxhimit dhe plani i dhënave nuk janë domosdoshmërisht të lidhur ngushtësisht. Një API si API universale i planit të dhënave Envoy mund të formojë një urë midis dy pjesëve të sistemit.

Nelson dhe SmartStack ndihmojnë për të ilustruar më tej ndarjen e planit të menaxhimit dhe planit të dhënave. Nelson përdor Envoy si proxy dhe ndërton një plan të besueshëm menaxhimi të rrjetit të shërbimeve mbi stek HashiCorp, dmth. Nomad etj. SmartStack është ndoshta i pari i një vale të re të rrjeteve të shërbimeve. SmartStack formon planin e menaxhimit përreth HAProxy ose NGINX, duke demonstruar mundësinë e ndarjes së planit të menaxhimit të rrjetit të shërbimeve me planin e dhënave.

Arkitektura mikroservisave me rrjetin e shërbimeve (service mesh) po tërheq gjithnjë e më shumë vëmendje (si duhet!), dhe gjithnjë e më shumë projekte dhe ofrues po fillojnë të punojnë në këtë drejtim. Gjatë viteve të ardhshme do të shohim shumë innovacione si në fushat e të dhënave (data plane) ashtu edhe në fushat e menaxhimit (control plane), si dhe një përzierje të mëtejshme të komponentëve të ndryshëm. Në fund të fundit, arkitektura mikroservisave duhet të bëhet më e qartë dhe më magjike (?) për operatorin.
Shpresoj për më pak e më pak irritim.

Pikat kyçe (Key takeaways)

• Rrjeti i shërbimeve (service mesh) përbëhet nga dy pjesë të ndryshme: fushata e të dhënave (data plane) dhe fushata e menaxhimit (control plane). Të dy komponentët janë të domosdoshëm, dhe pa ta, sistemi nuk do të funksiononte.
• Të gjithë janë të njohur me fushatën e menaxhimit (control plane), dhe për momentin, fushata e menaxhimit (control plane) mund të jeni ju!
• Të gjitha fushat e të dhënave (data plane) konkurrojnë me njëra-tjetrën për funksione, performancë, konfiguroshmëri dhe zgjerueshmëri.
• Të gjitha fushat e menaxhimit (control plane) konkurrojnë me njëra-tjetrën për funksione, konfiguroshmëri, zgjerueshmëri dhe përdorshmëri.
• Një fushatë e menaxhimit (control plane) mund të përmbajë abstraksione dhe API të përshtatshme që lejojnë përdorimin e disa fushave të të dhënave (data plane).

Burimi: habr.com