Kaixo, Sergey Elantsev naiz, garatzen naiz Yandex.Cloud-en. Aurretik, Yandex atariaren L7 orekatzailearen garapena zuzendu nuen - lankideek txantxetan esaten dute egiten dudana edozein dela ere, orekatzailea dela bihurtzen du. Habr-eko irakurleei esango diet nola kudeatu karga hodeiko plataforma batean, zein ikusten dugun helburu hori lortzeko tresna aproposa den eta nola goazen tresna hau eraikitzeko bidean.
Lehenik eta behin, aurkez ditzagun termino batzuk:
- VIP (IP birtuala) - balantzailearen IP helbidea
- Zerbitzaria, backend, instantzia - aplikazio bat exekutatzen duen makina birtuala
- RIP (Real IP) - zerbitzariaren IP helbidea
- Healthcheck - zerbitzariaren prest dagoen egiaztatzea
- Availability Zone, AZ - datu-zentro bateko azpiegitura isolatua
- Eskualdea - AZ ezberdinen batasuna
Karga-orekatzaileek hiru zeregin nagusi ebazten dituzte: orekatzea bera egiten dute, zerbitzuaren akatsen tolerantzia hobetzen dute eta bere eskalatzea errazten dute. Akatsen tolerantzia trafikoaren kudeaketa automatikoaren bidez bermatzen da: balantzaileak aplikazioaren egoera kontrolatzen du eta orekatzetik baztertzen ditu bizitasun-egiaztapena gainditzen ez duten kasuak. Eskalatzea kargaren banaketa uniformearen bidez bermatzen da, baita instantzien zerrenda berehala eguneratuz ere. Balantzea nahikoa uniformea ββez bada, instantzia batzuek beren edukiera-muga gainditzen duten karga jasoko dute, eta zerbitzua fidagarriagoa izango da.
Karga-orekatzailea sarritan exekutatzen den OSI ereduko protokolo-geruzaren arabera sailkatzen da. Cloud Balancer-ek TCP mailan funtzionatzen du, hau da, laugarren geruzari dagokio, L4.
Joan gaitezen Cloud balancer arkitekturaren ikuspegi orokor batera. Apurka-apurka xehetasun maila handituko dugu. Balantza-osagaiak hiru klasetan banatzen ditugu. Konfigurazio-plano klasea erabiltzailearen interakzioaz arduratzen da eta sistemaren xede-egoera gordetzen du. Kontrol-planoak sistemaren uneko egoera gordetzen du eta datu-planoaren klaseko sistemak kudeatzen ditu, bezeroetatik zure instantzietara trafikoa helarazteko ardura zuzena dutenak.
Datu-planoa
Trafikoa mugako bideratzaile izeneko gailu garestietan amaitzen da. Akatsen tolerantzia areagotzeko, horrelako hainbat gailuk aldi berean funtzionatzen dute datu-zentro batean. Jarraian, trafikoa orekatzaileetara doa, zeinek edozeincast IP helbideak AZ guztiei iragartzen dizkiete bezeroentzako BGP bidez.
Trafikoa ECMP bidez transmititzen da - hau bideratze-estrategia bat da, zeinaren arabera helbururako hainbat bide onak egon daitezke (gure kasuan, xedea helmuga IP helbidea izango da) eta paketeak horietako edozein batera bidal daitezke. Era berean, hainbat erabilgarritasun gunetan lan egiten dugu, eskema honen arabera: eremu bakoitzean helbide bat iragartzen dugu, trafikoa hurbilenekora doa eta ez du bere mugetatik haratago. Geroago argitalpenean trafikoarekin zer gertatzen den zehatzago aztertuko dugu.
Konfigurazio planoa
Konfigurazio-planoaren funtsezko osagaia APIa da, eta horren bidez orekagailuekin oinarrizko eragiketak egiten dira: instantzien konposizioa sortu, ezabatzea, aldatzea, osasun-kontrolen emaitzak lortzea, etab. Alde batetik, REST API bat da, eta bestetik. bestela, Hodeian oso maiz erabiltzen dugu gRPC markoa, beraz, REST gRPCra "itzultzen" dugu eta gero gRPC bakarrik erabiltzen dugu. Edozein eskaerak Yandex.Cloud-eko langileen multzo komun batean exekutatzen diren ataza idempotente asinkrono sorta bat sortzea dakar. Zereginak edozein unetan eten eta gero berrabiarazi ahal izateko moduan idazten dira. Horrek eskalagarritasuna, errepikakortasuna eta eragiketen erregistroa bermatzen ditu.
Ondorioz, APIaren zereginak Balantza-zerbitzuaren kontrolatzaileari eskaera bat egingo dio, Go-n idatzita dagoena. Orekatzaileak gehitu eta kendu ditzake, backend-en konposizioa eta ezarpenak alda ditzake.
Zerbitzuak Yandex Database-n gordetzen du bere egoera, laster erabili ahal izango duzun kudeatutako datu-base banatuan. Yandex.Cloud-en, dagoeneko dugun bezala , txakurren janariaren kontzeptua aplikatzen da: guk geuk gure zerbitzuak erabiltzen baditugu, gure bezeroek ere pozik erabiliko dituzte. Yandex Database kontzeptu horren ezarpenaren adibide bat da. Gure datu guztiak YDBn gordetzen ditugu, eta ez dugu datu-basea mantentzen eta eskalatzean pentsatu beharrik: arazo hauek konpontzen zaizkigu, datu-basea zerbitzu gisa erabiltzen dugu.
Itzuli gaitezen orekatzailearen kontrolagailura. Bere zeregina orekatzaileari buruzko informazioa gordetzea eta makina birtuala prest dagoen egiaztatzeko zeregin bat bidaltzea da osasun-kontroleko kontrolagailura.
Osasun-kontrola kontrolatzailea
Egiaztapen-arauak aldatzeko eskaerak jasotzen ditu, YDBn gordetzen ditu, zereginak healtcheck nodoen artean banatzen ditu eta emaitzak batzen ditu, datu-basean gorde eta loadbalancer kontrolagailura bidaltzen dira. Era berean, datu-planoko klusterraren konposizioa aldatzeko eskaera bidaltzen du karga-balantza-nodora, jarraian eztabaidatuko dudana.
Hitz egin dezagun osasun-kontrolei buruz. Hainbat klasetan banatu daitezke. Ikuskaritzak arrakasta irizpide desberdinak dituzte. TCP egiaztapenek konexio bat behar bezala ezarri behar dute denbora finko batean. HTTP egiaztapenek konexio arrakastatsua eta 200 egoera-kode batekin erantzuna eskatzen dute.
Gainera, egiaztapenak ekintza klasean desberdinak dira: aktiboak eta pasiboak dira. Kontrol pasiboek trafikoarekin gertatzen dena kontrolatzen dute, inolako neurri berezirik hartu gabe. Honek ez du oso ondo funtzionatzen L4-n, goi-mailako protokoloen logikaren araberakoa baita: L4-n ez dago eragiketak zenbat denbora iraun duen edo konexio-osaketa ona edo txarra izan den jakiteko. Egiaztapen aktiboek balantzaileak zerbitzari-instantzia bakoitzari eskaerak bidaltzea eskatzen du.
Karga-orekatzaile gehienek bizitasun-egiaztapenak egiten dituzte. Cloud-en, sistemaren zati hauek bereiztea erabaki genuen eskalagarritasuna areagotzeko. Planteamendu honek orekatzaileen kopurua handitzeko aukera emango digu, zerbitzura osasun-kontrolen eskaera kopurua mantenduz. Egiaztapenak osasun-egiaztapeneko nodo bereiziek egiten dituzte, eta horietan zehar egiaztapen-helburuak zatitu eta errepikatzen dira. Ezin duzu ostalari batetik egiaztapenik egin, huts egin dezakeelako. Orduan ez dugu lortuko egiaztatu zituen instantzien egoera. Gutxienez hiru osasun-kontrol-nodotako edozein instantziatan egiaztapenak egiten ditugu. Nodoen arteko egiaztapenen helburuak zatikatzen ditugu hashing algoritmo koherenteak erabiliz.
Oreka eta osasun-kontrola bereizteak arazoak sor ditzake. Healthcheck nodoak instantziari eskaerak egiten badio, balantzailea saihestuz (gaur egun trafikoa zerbitzatzen ez duena), egoera arraro bat sortzen da: baliabidea bizirik dagoela dirudi, baina trafikoa ez da bertara iritsiko. Arazo hau horrela konpontzen dugu: orekatzaileen bidez osasun-kontrolen trafikoa hastea bermatuta daukagu. Beste era batera esanda, bezeroen eta osasun-kontrolen trafikoa duten paketeak mugitzeko eskema gutxieneko desberdina da: bi kasuetan, paketeak orekatzaileengana iritsiko dira, eta helburuko baliabideetara entregatuko dituzte.
Aldea da bezeroek VIP-ri eskaerak egiten dizkiotela, eta osasun-kontrolek RIP bakoitzari eskaerak egiten dizkiotela da. Arazo interesgarri bat sortzen da hemen: gure erabiltzaileei IP sare grisetan baliabideak sortzeko aukera ematen diegu. Imajina dezagun bi hodei jabe ezberdin daudela orekatzaileen atzean beren zerbitzuak ezkutatu dituztenak. Horietako bakoitzak baliabideak ditu 10.0.0.1/24 azpisarean, helbide berdinekin. Nolabait bereizteko gai izan behar duzu, eta hemen Yandex.Cloud sare birtualaren egituran murgildu behar duzu. Hobe da xehetasun gehiago aurkitzea , garrantzitsua da guretzat orain sarea geruza anitzekoa dela eta azpisarearen idaren bidez bereiz daitezkeen tunelak dituela.
Healthcheck-eko nodoek orekatzaileekin harremanetan jartzen dira quasi-IPv6 helbideak erabiliz. Kuasi-helbidea IPv6 helbide bat da, barruan IPv4 helbidea eta erabiltzailearen azpi-sarearen ID txertatuta dituena. Trafikoa orekatzailera iristen da, eta honek IPv4 baliabidearen helbidea ateratzen du bertatik, IPv6 IPv4rekin ordezkatzen du eta paketea erabiltzailearen sarera bidaltzen du.
Alderantzizko trafikoa bide beretik doa: orekatzaileak helmuga sare gris bat dela ikusten du osasun-kontrolatzaileetatik, eta IPv4 IPv6 bihurtzen du.
VPP - datu-planoaren bihotza
Balantzailea Vector Packet Processing (VPP) teknologia erabiliz inplementatzen da, Cisco-ren esparru bat sareko trafikoa multzoka prozesatzeko. Gure kasuan, esparruak erabiltzailearen espazioko sareko gailuen kudeaketa liburutegiaren gainean funtzionatzen du - Data Plane Development Kit (DPDK). Horrek paketeen prozesatzeko errendimendu handia bermatzen du: nukleoan askoz eten gutxiago gertatzen dira eta ez dago testuinguru-aldaketarik nukleoaren eta erabiltzaileen espazioaren artean.
VPP are urrunago doa eta sistematik are errendimendu handiagoa ateratzen du paketeak loteetan konbinatuz. Errendimendu-irabaziak prozesadore modernoetan cacheen erabilera oldarkortik datoz. Bi datu-katxeak erabiltzen dira (paketeak βbektoreetanβ prozesatzen dira, datuak elkarrengandik hurbil daude) eta instrukzio-katxeak: VPPn, paketeen prozesamenduak grafiko bati jarraitzen dio, eta nodoek zeregin bera betetzen duten funtzioak dituzte.
Esate baterako, IP paketeen prozesamendua VPPn hurrenkera honetan gertatzen da: lehenik eta behin, paketeen goiburuak analizatzeko nodoan analizatzen dira, eta gero nodora bidaltzen dira, eta horrek paketeak gehiago birbidaltzen ditu bideratze-taulen arabera.
Hardcore pixka bat. VPPren egileek ez dute konpromisorik onartzen prozesadorearen cacheen erabileran, beraz, paketeen bektore bat prozesatzeko kode tipikoak eskuzko bektoretza dauka: prozesatzeko begizta bat dago eta bertan "lau pakete ditugu ilaran" bezalako egoera bat prozesatzen da, gero berdin birentzat, gero - batentzat. Aurrez jasotzeko argibideak maiz erabiltzen dira datuak cacheetan kargatzeko, hurrengo iterazioetan haietarako sarbidea azkartzeko.
n_left_from = frame->n_vectors;
while (n_left_from > 0)
{
vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next);
// ...
while (n_left_from >= 4 && n_left_to_next >= 2)
{
// processing multiple packets at once
u32 next0 = SAMPLE_NEXT_INTERFACE_OUTPUT;
u32 next1 = SAMPLE_NEXT_INTERFACE_OUTPUT;
// ...
/* Prefetch next iteration. */
{
vlib_buffer_t *p2, *p3;
p2 = vlib_get_buffer (vm, from[2]);
p3 = vlib_get_buffer (vm, from[3]);
vlib_prefetch_buffer_header (p2, LOAD);
vlib_prefetch_buffer_header (p3, LOAD);
CLIB_PREFETCH (p2->data, CLIB_CACHE_LINE_BYTES, STORE);
CLIB_PREFETCH (p3->data, CLIB_CACHE_LINE_BYTES, STORE);
}
// actually process data
/* verify speculative enqueues, maybe switch current next frame */
vlib_validate_buffer_enqueue_x2 (vm, node, next_index,
to_next, n_left_to_next,
bi0, bi1, next0, next1);
}
while (n_left_from > 0 && n_left_to_next > 0)
{
// processing packets by one
}
// processed batch
vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}Beraz, Healthchecks-ek IPv6 bidez hitz egiten diote VPPri, eta horrek IPv4 bihurtzen ditu. Hau grafikoko nodo batek egiten du, NAT algoritmikoa deitzen dioguna. Alderantzizko trafikorako (eta IPv6tik IPv4rako bihurtzeko) NAT nodo algoritmiko bera dago.
Balantzailearen bezeroen trafiko zuzena nodo grafikoetatik igarotzen da, eta horiek orekatzea bera egiten dute.
Lehenengo nodoa saio itsaskorrak dira. Hash-a gordetzen du ezarritako saioetarako. 5-tuplak informazioa transmititzen den bezeroaren helbidea eta ataka biltzen ditu, trafikoa jasotzeko dauden baliabideen helbidea eta ataka, baita sareko protokoloa ere.
5-tupla hash-ak kalkulu gutxiago egiten laguntzen digu hurrengo hashing-nodo koherentean, baita orekatzailearen atzean dauden baliabide-zerrenda aldaketak hobeto kudeatzen ere. Saiorik ez duen pakete bat orekatzailera iristen denean, hashing nodo koherentera bidaltzen da. Hemen gertatzen da oreka hashing koherentea erabiliz: baliabide bat "zuzeneko" baliabide erabilgarrien zerrendatik hautatzen dugu. Ondoren, paketeak NAT nodora bidaltzen dira, eta horrek helmuga helbidea ordezkatzen du eta checksumak berriro kalkulatzen ditu. Ikus dezakezunez, VPP-ren arauak jarraitzen ditugu - gustatu nahi izatea, antzeko kalkuluak taldekatuz prozesadorearen cacheen eraginkortasuna areagotzeko.
Hashing koherentea
Zergatik aukeratu dugu eta zer da? Lehenik eta behin, kontuan izan dezagun aurreko zeregina: zerrendako baliabide bat hautatzea.
Hashing koherentearekin, sarrerako paketearen hash-a kalkulatzen da, eta zerrendatik baliabide bat hautatzen da hash hori baliabide kopuruaz zatitzearen gainerakoarekin. Zerrenda aldatzen ez den bitartean, eskema honek ondo funtzionatzen du: beti bidaltzen ditugu 5-tupla berdina duten paketeak instantzia berera. Adibidez, baliabideren batek osasun-kontrolei erantzutea uzten badie, hashen zati garrantzitsu batean aukera aldatuko da. Bezeroaren TCP konexioak hautsiko dira: aurretik A instantziara iritsi zen pakete bat B instantziara iristen has daiteke, pakete honen saioa ezagutzen ez duena.
Hashing koherenteak deskribatutako arazoa konpontzen du. Kontzeptu hau azaltzeko modurik errazena hau da: imajina ezazu hash bidez baliabideak banatzen dituzun eraztun bat duzula (adibidez, IP:port bidez). Baliabide bat hautatzea gurpila angelu batez biratzea da, paketearen hash-ak zehazten duena.
Horrek trafikoaren birbanaketa murrizten du baliabideen konposizioa aldatzen denean. Baliabide bat ezabatzeak baliabidea kokatuta zegoen hashing eraztun koherentearen zatiari bakarrik eragingo dio. Baliabide bat gehitzeak banaketa ere aldatzen du, baina saio-nodo itsaskor bat dugu, eta horri esker, dagoeneko finkatutako saioak baliabide berrietara ez aldatzeko.
Balantzatzailearen eta baliabideen arteko trafikoa zuzentzeko zer gertatzen den aztertu dugu. Ikus dezagun orain itzulerako trafikoa. Egiaztatzeko trafikoaren eredu bera jarraitzen du: NAT algoritmikoaren bidez, hau da, alderantzizko NAT 44 bidez bezeroen trafikorako eta NAT 46 bidez osasun-kontrolen trafikorako. Gure eskemari atxikitzen gara: osasun-kontrolen trafikoa eta erabiltzaileen benetako trafikoa bateratzen ditugu.
Loadbalancer-nodo eta muntatutako osagaiak
VPP-ko orekatzaileen eta baliabideen osaera tokiko zerbitzuaren berri ematen du - loadbalancer-node. Karga-balantza-kontrolagailuaren gertaeren korrontearekin harpidetzen da eta uneko VPP egoeraren eta kontrolagailutik jasotako helburu-egoeraren arteko aldea irudikatzeko gai da. Sistema itxi bat lortzen dugu: APIaren gertaerak orekatzaile-kontrolatzailera iristen dira, eta horrek zereginak esleitzen dizkio osasun-kontrol-kontrolatzaileari baliabideen "bizitasuna" egiaztatzeko. Horrek, aldi berean, zereginak osasun-kontrol-nodoari esleitzen dizkio eta emaitzak batzen ditu, ondoren orekatzaile-kontrolatzailera bidaltzen ditu. Loadbalancer-node kontrolagailuko gertaeretara harpidetzen da eta VPPren egoera aldatzen du. Sistema horretan, zerbitzu bakoitzak ondoko zerbitzuei buruz beharrezkoa dena baino ez daki. Konexio kopurua mugatua da eta segmentu desberdinak modu independentean funtzionatzeko eta eskalatzeko gaitasuna dugu.
Zein gai saihestu ziren?
Kontrol-planoko gure zerbitzu guztiak Go-n idatzita daude eta eskalatze- eta fidagarritasun-ezaugarri onak dituzte. Go-k kode irekiko liburutegi ugari ditu sistema banatuak eraikitzeko. GRPC aktiboki erabiltzen dugu, osagai guztiek zerbitzuen aurkikuntzaren kode irekiko inplementazioa dute - gure zerbitzuek elkarren errendimendua kontrolatzen dute, haien osaera dinamikoki alda dezakete eta GRPC orekatzearekin lotu dugu. Neurrietarako, kode irekiko irtenbide bat ere erabiltzen dugu. Datuen planoan, errendimendu duina eta baliabide erreserba handia lortu genuen: oso zaila izan zen VPP baten errendimenduan fida genitzakeen stand bat muntatzea, burdinazko sare-txartel batean baino.
Arazoak eta irtenbideak
Zerk ez zuen hain ondo funtzionatu? Go-k memoria kudeaketa automatikoa du, baina memoria-ihesak gertatzen dira oraindik. Horiei aurre egiteko modurik errazena goroutinak exekutatu eta amaitzea gogoratzea da. Eramatea: ikusi zure Go programen memoria-kontsumoa. Askotan adierazle ona goroutine kopurua da. Istorio honetan abantaila bat dago: Go-n erraza da exekuzio-datuak eskuratzea: memoria-kontsumoa, exekutatzen diren goroutine kopurua eta beste parametro asko.
Gainera, Go agian ez da aukerarik onena proba funtzionaletarako. Nahiko hitzak dira, eta "CI-n dena lote batean exekutatzeko" ikuspegi estandarra ez da oso egokia haientzat. Kontua da proba funtzionalek baliabide gehiago eskatzen dituztela eta denbora-muga errealak eragiten dituztela. Horregatik, probek huts egin dezakete CPUa unitate-probekin lanpetuta dagoelako. Ondorioa: Ahal izanez gero, egin proba "astunak" proba unitarioetatik bereizita.
Mikrozerbitzuen gertaeren arkitektura monolito bat baino konplexuagoa da: dozenaka makina ezberdinetan erregistroak biltzea ez da oso erosoa. Ondorioa: mikrozerbitzuak egiten badituzu, berehala pentsatu trazamenduan.
Gure planak
Barne-orekatzailea, IPv6-ko orekatzailea abiaraziko dugu, Kubernetes scriptetarako euskarria gehituko dugu, gure zerbitzuak zatikatzen jarraituko dugu (gaur egun healthcheck-node eta healthcheck-ctrl bakarrik zatikatzen dira), osasun-kontrol berriak gehituko ditugu eta egiaztapenen agregazio adimenduna ere ezarriko dugu. Gure zerbitzuak are independenteagoak izateko aukera aztertzen ari gara, elkarren artean zuzenean ez komunikatzeko, mezu-ilara baten bidez baizik. SQS-ekin bateragarria den zerbitzu bat agertu da duela gutxi Hodeian .
Duela gutxi, Yandex Load Balancer-en kaleratu publikoa egin zen. Arakatu zerbitzura, kudeatu orekatzaileak zuretzako modu egokian eta handitu zure proiektuen akatsen tolerantzia!
Iturria: www.habr.com