Halló, ég er Sergey Elantsev, ég þroskast í Yandex.Cloud. Áður leiddi ég þróun L7 jafnvægisbúnaðarins fyrir Yandex gáttina - samstarfsmenn grínast með að það sé sama hvað ég geri, það reynist vera jafnvægistæki. Ég mun segja lesendum Habr hvernig á að stjórna álaginu á skýjapalli, hvað við sjáum sem kjörið tól til að ná þessu markmiði og hvernig við stefnum að því að byggja þetta tól.
Fyrst skulum við kynna nokkur hugtök:
- VIP (Virtual IP) - jafnvægis IP tölu
- Server, backend, dæmi - sýndarvél sem keyrir forrit
- RIP (Real IP) - IP tölu netþjóns
- Heilsuskoðun - athugar viðbúnað netþjónsins
- Availability Zone, AZ - einangruð innviði í gagnaveri
- Region - stéttarfélag mismunandi AZ
Álagsjafnarar leysa þrjú meginverkefni: þeir framkvæma sjálfir jafnvægið, bæta bilanaþol þjónustunnar og einfalda stærðarstærð hennar. Bilunarþol er tryggt með sjálfvirkri umferðarstjórnun: jafnvægisbúnaðurinn fylgist með ástandi forritsins og útilokar frá jafnvægistilvik sem standast ekki lífleikaprófið. Stöðun er tryggð með því að dreifa álaginu jafnt yfir tilvik, auk þess að uppfæra listann yfir tilvik á flugu. Ef jöfnunin er ekki nógu jöfn fá sum tilvikanna álag sem fer yfir afkastagetumörk og þjónustan verður óáreiðanlegri.
Álagsjafnari er oft flokkaður eftir samskiptalagi frá OSI líkaninu sem hann keyrir á. Cloud Balancer starfar á TCP stigi, sem samsvarar fjórða laginu, L4.
Við skulum halda áfram að yfirliti yfir Cloud balancer arkitektúrinn. Við munum smám saman auka smáatriðin. Við skiptum jafnvægishlutunum í þrjá flokka. Stillingar flugvélaflokkurinn er ábyrgur fyrir notendasamskiptum og geymir markástand kerfisins. Stýrivélin geymir núverandi stöðu kerfisins og stjórnar kerfum úr gagnaplanaflokknum, sem bera beina ábyrgð á að senda umferð frá viðskiptavinum til þinna tilvika.
Gagnaplan
Umferðin endar á dýrum tækjum sem kallast landamærabeini. Til að auka bilanaþol starfa nokkur slík tæki samtímis í einni gagnaveri. Næst fer umferðin til jafnvægisaðila, sem tilkynna hvaða IP tölur sem eru sendar til allra AZ í gegnum BGP fyrir viðskiptavini.
Umferð er send yfir ECMP - þetta er leiðaráætlun samkvæmt því að það geta verið nokkrar jafn góðar leiðir að markinu (í okkar tilfelli verður miðið IP-tala áfangastaðarins) og hægt er að senda pakka eftir hvaða þeirra sem er. Við styðjum einnig vinnu á nokkrum framboðssvæðum samkvæmt eftirfarandi kerfi: við auglýsum heimilisfang á hverju svæði, umferð fer á næsta og fer ekki út fyrir mörk þess. Síðar í færslunni munum við skoða nánar hvað verður um umferðina.
Stilla flugvél
Lykilhluti stillingarplansins er API, þar sem grunnaðgerðir með jafnvægisbúnaði eru gerðar: búa til, eyða, breyta samsetningu tilvika, fá niðurstöður úr heilbrigðisskoðun o.s.frv. Annars vegar er þetta REST API, og annars vegar annað, við í skýinu notum mjög oft ramma gRPC, svo við „þýðum“ REST yfir í gRPC og notum síðan aðeins gRPC. Allar beiðnir leiða til þess að búa til röð ósamstilltra, sjálfvirkra verkefna sem eru framkvæmd á sameiginlegum hópi Yandex.Cloud starfsmanna. Verkefni eru skrifuð á þann hátt að hægt er að stöðva þau hvenær sem er og síðan endurræsa. Þetta tryggir sveigjanleika, endurtekningarhæfni og skráningu aðgerða.
Þess vegna mun verkefnið frá API senda beiðni til jafnvægisþjónustustjórans, sem er skrifuð í Go. Það getur bætt við og fjarlægt jafnvægisbúnað, breytt samsetningu bakenda og stillinga.
Þjónustan geymir ástand sitt í Yandex Database, dreifðum stýrðum gagnagrunni sem þú munt fljótlega geta notað. Í Yandex.Cloud, eins og við nú þegar , hundafóðurshugtakið á við: ef við sjálf notum þjónustu okkar, þá munu viðskiptavinir okkar líka vera ánægðir með að nota hana. Yandex Database er dæmi um útfærslu á slíku hugtaki. Við geymum öll gögnin okkar í YDB og við þurfum ekki að hugsa um að viðhalda og stækka gagnagrunninn: þessi vandamál eru leyst fyrir okkur, við notum gagnagrunninn sem þjónustu.
Snúum okkur aftur að jafnvægisstýringunni. Verkefni þess er að vista upplýsingar um jafnvægisbúnaðinn og senda verkefni til að athuga viðbúnað sýndarvélarinnar til heilbrigðiseftirlitsins.
Heilbrigðiseftirlit
Það tekur á móti beiðnum um að breyta eftirlitsreglum, vistar þær í YDB, dreifir verkefnum á milli heilsuskoðunarhnúta og safnar saman niðurstöðunum, sem síðan eru vistaðar í gagnagrunninn og sendar til loadbalancer stjórnandans. Það sendir aftur beiðni um að breyta samsetningu klasans í gagnaplaninu til loadbalancer-hnútinn, sem ég mun fjalla um hér að neðan.
Við skulum tala meira um heilsufarsskoðun. Þeim má skipta í nokkra flokka. Úttektir hafa mismunandi árangursviðmið. TCP athuganir þurfa að koma á tengingu innan ákveðins tíma. HTTP athuganir krefjast bæði árangursríkrar tengingar og svars með 200 stöðukóða.
Einnig eru ávísanir mismunandi eftir aðgerðaflokki - þær eru virkar og óvirkar. Óvirkar athuganir fylgjast einfaldlega með því sem er að gerast með umferðina án þess að grípa til sérstakra aðgerða. Þetta virkar ekki mjög vel á L4 vegna þess að það fer eftir rökfræði samskiptareglunnar á hærra stigi: á L4 eru engar upplýsingar um hversu langan tíma aðgerðin tók eða hvort tengingunni var gott eða slæmt. Virkar athuganir krefjast þess að jafnvægismaðurinn sendi beiðnir til hvers netþjónstilviks.
Flestir álagsjafnarar framkvæma lífleikapróf sjálfir. Við hjá Cloud ákváðum að aðskilja þessa hluta kerfisins til að auka sveigjanleika. Þessi nálgun mun gera okkur kleift að fjölga jafnvægismönnum á sama tíma og við höldum fjölda beiðna um heilbrigðiseftirlit til þjónustunnar. Athuganir eru framkvæmdar af aðskildum heilsuskoðunarhnútum, þar sem eftirlitsmarkmiðum er skipt niður og endurtekið. Þú getur ekki framkvæmt athuganir frá einum gestgjafa, þar sem það gæti mistekist. Þá fáum við ekki stöðu þeirra tilvika sem hann athugaði. Við gerum athuganir á einhverju tilvikanna frá að minnsta kosti þremur heilsuskoðunarhnútum. Við slítum tilgangi athugana á milli hnúta með því að nota samræmda kjötkássa reiknirit.
Að aðskilja jafnvægi og heilsufarsskoðun getur leitt til vandamála. Ef heilsuskoðunarhnúturinn sendir beiðnir til tilviksins, framhjá jafnvægisbúnaðinum (sem þjónar ekki umferð eins og er), þá kemur upp undarleg staða: auðlindin virðist vera á lífi en umferðin mun ekki ná henni. Við leysum þetta vandamál á þennan hátt: Við erum tryggð að hefja heilsufarsskoðun í gegnum jafnvægistæki. Með öðrum orðum, kerfið til að flytja pakka með umferð frá viðskiptavinum og frá heilsufarsskoðunum er lítið frábrugðið: í báðum tilfellum munu pakkarnir ná til jafnvægisaðilanna, sem munu skila þeim til markauðlindanna.
Munurinn er sá að viðskiptavinir leggja fram beiðnir til VIP, á meðan heilsufarsrannsóknir gera beiðnir til hvers RIP. Áhugavert vandamál kemur upp hér: við gefum notendum okkar tækifæri til að búa til auðlindir í gráum IP netum. Við skulum ímynda okkur að það séu tveir mismunandi skýjaeigendur sem hafa falið þjónustu sína á bak við jafnvægistæki. Hver þeirra hefur auðlindir í 10.0.0.1/24 undirnetinu, með sömu vistföng. Þú þarft að vera fær um að greina þá á einhvern hátt og hér þarftu að kafa inn í uppbyggingu Yandex.Cloud sýndarnetsins. Það er betra að fá frekari upplýsingar í , það er mikilvægt fyrir okkur núna að netið er marglaga og hefur göng sem hægt er að greina með undirnetsauðkenni.
Healthcheck hnútar hafa samband við jafnvægisaðila með því að nota svokölluð hálf-IPv6 vistföng. Hálfvistfang er IPv6 vistfang með IPv4 vistfangi og auðkenni notanda undirnets innbyggt í það. Umferðin nær til jafnvægisbúnaðarins, sem dregur IPv4 auðlindavistfangið úr honum, kemur í stað IPv6 fyrir IPv4 og sendir pakkann á net notandans.
Öfug umferð fer á sama hátt: jafnvægismaðurinn sér að áfangastaðurinn er grátt net frá heilbrigðiseftirlitsmönnum og breytir IPv4 í IPv6.
VPP - hjarta gagnaplansins
Jöfnunarbúnaðurinn er útfærður með því að nota Vector Packet Processing (VPP) tækni, ramma frá Cisco fyrir lotuvinnslu á netumferð. Í okkar tilviki virkar ramminn ofan á netkerfisstjórnunarsafnið fyrir notendarýmið - Data Plane Development Kit (DPDK). Þetta tryggir mikla pakkavinnsluafköst: mun færri truflanir eiga sér stað í kjarnanum og engin samhengisskipti eru á milli kjarnarýmis og notendarýmis.
VPP gengur enn lengra og kreistir enn meiri frammistöðu út úr kerfinu með því að sameina pakka í lotur. Ávinningurinn kemur frá árásargjarnri notkun skyndiminni á nútíma örgjörvum. Bæði gagnaskyndiminni eru notuð (pakkar eru unnar í „vektorum“, gögnin eru nálægt hver öðrum) og leiðbeiningaskyndiminni: í VPP fylgir pakkavinnsla línuriti, þar sem hnútarnir innihalda aðgerðir sem framkvæma sama verkefni.
Til dæmis fer vinnsla IP-pakka í VPP fram í eftirfarandi röð: fyrst eru pakkahausarnir flokkaðir í þáttunarhnútnum og síðan eru þeir sendir til hnútsins sem sendir pakkana áfram samkvæmt leiðartöflum.
Smá harðkjarna. Höfundar VPP þola ekki málamiðlanir í notkun örgjörvaskyndiminni, svo dæmigerður kóða fyrir vinnslu pakkavektors inniheldur handvirka vektorun: það er vinnslulykkja þar sem aðstæður eins og „við erum með fjóra pakka í biðröðinni“ er unnin, þá það sama fyrir tvo, þá - fyrir einn. Forsóttarleiðbeiningar eru oft notaðar til að hlaða gögnum inn í skyndiminni til að flýta fyrir aðgangi að þeim í síðari endurteknum.
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);
}Svo, Healthchecks tala yfir IPv6 við VPP, sem breytir þeim í IPv4. Þetta er gert með hnút í línuritinu, sem við köllum algorithmic NAT. Fyrir öfuga umferð (og umbreytingu frá IPv6 í IPv4) er sami reiknirit NAT hnúturinn.
Bein umferð frá viðskiptavinum jafnvægistækisins fer í gegnum grafhnúta, sem framkvæma jafnvægið sjálft.
Fyrsti hnúturinn er klístur fundur. Það geymir kjötkássa af fyrir fasta fundi. 5-tuple felur í sér heimilisfang og höfn viðskiptavinarins sem upplýsingar eru sendar frá, heimilisfang og gáttir auðlinda sem eru tiltækar til að taka á móti umferð, svo og netsamskiptareglur.
5-túlla kjötkássa hjálpar okkur að framkvæma minni útreikninga í síðari samkvæmu kjötkássahnút, auk þess að meðhöndla betur tilfangalistabreytingar á bakvið jafnvægisbúnaðinn. Þegar pakki sem engin lota er fyrir kemur í jafnvægisbúnaðinn er hann sendur á samkvæma kjötkássahnútinn. Þetta er þar sem jafnvægi á sér stað með því að nota stöðuga kjötkássa: við veljum auðlind af listanum yfir tiltækar „lifandi“ auðlindir. Næst eru pakkarnir sendir á NAT hnútinn, sem kemur í raun í stað áfangastaðarins og endurreiknar eftirlitstölurnar. Eins og þú sérð fylgjum við reglum VPP - líkar við, flokkum svipaða útreikninga til að auka skilvirkni skyndiminni örgjörva.
Stöðugt hashing
Hvers vegna völdum við það og hvað er það jafnvel? Í fyrsta lagi skulum við íhuga fyrra verkefni - að velja auðlind af listanum.
Með ósamræmi kjötkássa er kjötkássa komandi pakka reiknuð út og tilföng er valin af listanum með því að deila þessu kjötkássa með fjölda tilfanga. Svo lengi sem listinn er óbreyttur, virkar þetta kerfi vel: við sendum alltaf pakka með sömu 5-tuple til sama tilviks. Ef, til dæmis, einhver auðlind hætti að svara heilbrigðisskoðunum, þá mun valið breytast fyrir verulegan hluta kjötkássa. TCP tengingar viðskiptavinarins verða rofnar: pakki sem áður náði tilviki A gæti byrjað að ná til tilviks B, sem þekkir ekki lotuna fyrir þennan pakka.
Stöðug hass leysir vandamálið sem lýst er. Auðveldasta leiðin til að útskýra þetta hugtak er þessi: ímyndaðu þér að þú sért með hring sem þú dreifir auðlindum til með kjötkássa (til dæmis eftir IP:port). Að velja auðlind er að snúa hjólinu um horn, sem ræðst af kjötkássa pakkans.
Þetta lágmarkar endurdreifingu umferðar þegar samsetning auðlinda breytist. Að eyða tilfangi mun aðeins hafa áhrif á þann hluta samræmda kjötkássahringsins þar sem tilfangið var staðsett. Að bæta við tilföngum breytir einnig dreifingunni, en við erum með klístraðan lotuhnút, sem gerir okkur kleift að skipta ekki þegar stofnuðum lotum yfir í ný tilföng.
Við skoðuðum hvað verður um beina umferð milli jafnvægisbúnaðar og auðlinda. Nú skulum við líta á umferð til baka. Það fylgir sama mynstri og athugunarumferð - í gegnum reiknirit NAT, það er í gegnum öfuga NAT 44 fyrir umferð viðskiptavinar og í gegnum NAT 46 fyrir umferð um heilbrigðiseftirlit. Við fylgjumst með okkar eigin kerfi: við sameinum umferð um heilsufar og raunveruleg notendaumferð.
Loadbalancer-hnútur og samsettir íhlutir
Samsetning jafnvægismanna og auðlinda í VPP er tilkynnt af staðbundinni þjónustu - loadbalancer-hnút. Það gerist áskrifandi að straumi atburða frá hleðslujafnara-stýringu og er fær um að plotta mismuninn á núverandi VPP ástandi og markástandinu sem berast frá stjórnandanum. Við fáum lokað kerfi: atburðir frá API koma til jafnvægisstýringarinnar, sem úthlutar verkefnum til heilbrigðiseftirlitsins til að athuga „lífleika“ auðlinda. Það aftur á móti úthlutar verkefnum til heilsuskoðunarhnútsins og safnar saman niðurstöðunum, eftir það sendir það þær aftur til jafnvægisstjórans. Loadbalancer-node gerist áskrifandi að atburðum frá stjórnanda og breytir stöðu VPP. Í slíku kerfi veit hver þjónusta aðeins það sem þarf um nágrannaþjónustu. Fjöldi tenginga er takmarkaður og við höfum getu til að reka og skala mismunandi hluti sjálfstætt.
Hvaða mál var forðast?
Öll þjónusta okkar í stjórnplaninu er skrifuð í Go og hefur góða stærðar- og áreiðanleikaeiginleika. Go hefur mörg opinn uppspretta bókasöfn til að byggja dreifð kerfi. Við notum GRPC virkan, allir íhlutir innihalda opinn uppspretta útfærslu þjónustuuppgötvunar - þjónusta okkar fylgist með frammistöðu hverrar annarar, getur breytt samsetningu þeirra á kraftmikinn hátt og við tengdum þetta við GRPC jafnvægi. Fyrir mælikvarða notum við einnig opinn uppspretta lausn. Í gagnaplaninu fengum við ágætis frammistöðu og stóran auðlindaforða: það reyndist mjög erfitt að setja saman stand sem við gætum reitt okkur á frammistöðu VPP, frekar en járnnetkort.
Vandamál og lausnir
Hvað virkaði ekki svona vel? Go er með sjálfvirka minnisstjórnun, en minnislekar eiga sér enn stað. Auðveldasta leiðin til að takast á við þá er að keyra goroutines og muna að hætta þeim. Takeaway: Horfðu á minnisnotkun Go forritanna þinna. Oft er góður mælikvarði fjöldi górútína. Það er plús í þessari sögu: í Go er auðvelt að fá keyrslugögn - minnisnotkun, fjöldi hlaupandi goroutines og margar aðrar breytur.
Einnig gæti Go verið ekki besti kosturinn fyrir virknipróf. Þeir eru nokkuð orðaðir og staðalaðferðin að „keyra allt í CI í lotu“ hentar þeim ekki. Staðreyndin er sú að virknipróf eru meira tilföng krefjandi og valda raunverulegum tímamörkum. Vegna þessa geta próf mistekist vegna þess að örgjörvinn er upptekinn við einingapróf. Ályktun: Ef mögulegt er skaltu framkvæma „þung“ próf aðskilið frá einingarprófunum.
Örþjónustuviðburðaarkitektúr er flóknari en einlitur: að safna annálum á tugum mismunandi véla er ekki mjög þægilegt. Ályktun: ef þú býrð til örþjónustu skaltu strax hugsa um að rekja.
Áætlanir okkar
Við munum opna innri jafnvægisbúnað, IPv6 jafnvægisbúnað, bæta við stuðningi við Kubernetes forskriftir, halda áfram að slíta þjónustu okkar (núna eru aðeins healthcheck-node og healthcheck-ctrl sundurliðaðar), bæta við nýjum heilsufarsskoðunum og einnig innleiða snjalla samsöfnun athugana. Við erum að íhuga möguleikann á að gera þjónustu okkar enn sjálfstæðari - þannig að hún hafi ekki bein samskipti sín á milli, heldur með skilaboðaröð. SQS-samhæf þjónusta hefur nýlega birst í skýinu .
Nýlega fór opinber útgáfa af Yandex Load Balancer fram. Kanna til þjónustunnar, stjórnaðu jafnvægistækjum á þann hátt sem hentar þér og auka bilanaþol verkefna þinna!
Heimild: www.habr.com