Silav, ez Sergey Elantsev im, ez pêşve dibim li Yandex.Cloud. Berê, min pêşengiya pêşkeftina balansa L7-ê ji bo portalê Yandex kir - hevkar henekê xwe dikin ku ez çi bikim jî, ew dibe balansek. Ez ê ji xwendevanên Habr re vebêjim ka meriv çawa barkirinê di platformek ewr de rêve dibe, ji bo gihîştina vê armancê em çi wekî amûrek îdeal dibînin, û em çawa ber bi avakirina vê amûrê ve diçin.
Pêşî, em çend şertan bidin nasîn:
- VIP (IP Virtual) - navnîşana IP-ya hevseng
- Server, paşnav, mînak - makîneyek virtual ku serîlêdanek dixebitîne
- RIP (IP-ya rastîn) - navnîşana IP-ya serverê
- Tenduristî - kontrolkirina amadebûna serverê
- Zona Berdestbûnê, AZ - binesaziya veqetandî ya li navendek daneyê
- Herêm - yekîtiya AZ-yên cuda
Balkêşên barkirinê sê karên sereke çareser dikin: ew hevsengiyê bixwe dikin, tolerasyona xeletiya karûbarê baştir dikin, û pîvana wê hêsan dikin. Tolerasyona xeletiyê bi rêveberiya seyrûsefera otomatîkî ve tê peyda kirin: balansek rewşa serîlêdanê dişopîne û mînakên ji hevsengiyê yên ku ji kontrolkirina zindîtiyê derbas nabin derdixe. Scaling bi belavkirina yeksan a barkirinê li ser mînakan, û her weha nûvekirina navnîşa mînakan di firînê de tê misoger kirin. Ger hevseng bi têra xwe yekreng nebe, hin mînak dê barek ku ji sînorê kapasîteya wan derbas dibe bistînin, û karûbar dê kêmtir pêbawer bibe.
Balansek barkirinê bi gelemperî ji hêla qata protokolê ve ji modela OSI ya ku ew lê dimeşe tê dabeş kirin. Cloud Balancer di asta TCP de, ku bi qata çaremîn, L4 re têkildar e, dixebite.
Ka em biçin ser nihêrînek mîmariya balansa Cloud. Em ê gav bi gav asta hûrguliyê zêde bikin. Em hêmanên hevseng li sê çînan dabeş dikin. Dersa balafira mîhengê berpirsiyarê danûstendina bikarhêner e û rewşa armancê ya pergalê hilîne. Balafira kontrolê rewşa heyî ya pergalê hildide û pergalên ji çîna balafira daneyê, yên ku rasterast berpirsiyar in ji gihandina seyrûseferê ji xerîdaran re ji mînakên we re, birêve dibe.
Balafira daneyê
Trafîk bi cîhazên giranbiha yên ku jê re routerên sînor têne gotin diqede. Ji bo zêdekirina tolerasyona xeletiyê, çend cîhazên weha bi hevdemî di yek navendek daneyê de dixebitin. Dûv re, seyrûsefer diçe balanskeran, ku ji bo xerîdaran navnîşanên IP-ya herkasta ji hemî AZ-an re bi navgîniya BGP-ê radigihînin.
Trafîk li ser ECMP-ê tê veguheztin - ev stratejiyek rêvekirinê ye ku li gorî wê dikare çend rêgezên wekhev baş berbi armancê ve bibin (di rewşa me de, mebest dê navnîşana IP-ya meqsedê be) û pakêt dikarin li ser her yekê ji wan werin şandin. Em di heman demê de li gorî pilana jêrîn piştgirî didin xebata li gelek deverên berdestiyê: em navnîşanek li her deverê reklam dikin, seyrûsefer diçe ya herî nêzîk û ji sînorên wê dernakeve. Dûv re di postê de em ê bi hûrgulî li ka çi diqewime li trafîkê binêrin.
Balafira mîhengê
Hêmana sereke ya plana mîhengê API ye, ku bi navgîniya wê operasyonên bingehîn bi balansan re têne kirin: çêkirin, jêbirin, guhertina pêkhateya mînakan, bidestxistina encamên kontrolên tenduristiyê, hwd. Ji aliyekî ve, ev API REST e, û li ser Wekî din, em di Cloud de pir caran çarçoveya gRPC bikar tînin, ji ber vê yekê em REST-ê ji gRPC re "wergerin" û dûv re tenê gRPC bikar tînin. Her daxwazek dibe sedema afirandina rêzek karên idempotent asynchronous ku li ser hewza hevpar a xebatkarên Yandex.Cloud têne darve kirin. Karûbar bi vî rengî têne nivîsandin ku di her kêliyê de bêne sekinandin û dûv re ji nû ve dest pê bikin. Ev pîvanbûn, dubarebûn û têketina operasyonan misoger dike.
Wekî encamek, peywira ji API-ê dê daxwazek ji kontrolkerê karûbarê balanserê, ku di Go de hatî nivîsandin, bike. Ew dikare balanskeran lê zêde bike û jê rake, pêkhateya pişt û mîhengan biguhezîne.
Karûbar rewşa xwe di Daneya Daneya Yandex de hilîne, databasek birêvebir a belavkirî ku hûn ê di demek nêzîk de bikarin bikar bînin. Li Yandex.Cloud, wekî me berê , konsepta xwarina kûçikê derbas dibe: heke em bixwe karûbarên xwe bikar bînin, wê hingê xerîdarên me jî dê kêfxweş bibin ku wan bikar bînin. Daneyên Yandex mînakek pêkanîna têgehek weha ye. Em hemî daneyên xwe di YDB de hilînin, û ne hewce ye ku em li ser parastin û mezinkirina databasê bifikirin: ev pirsgirêk ji bo me têne çareser kirin, em databasê wekî karûbar bikar tînin.
Ka em vegerin ser kontrolkerê balansê. Erka wê ev e ku agahdariya di derheqê balansek de hilîne û peywirek bişîne da ku amadebûna makîneya virtual ji kontrolkera tenduristiyê re kontrol bike.
Kontrolkerê tenduristiyê
Ew daxwazên guhertina qaîdeyên kontrolê distîne, wan di YDB de hilîne, peywiran di nav girêkên healtcheck de belav dike û encaman berhev dike, ku dûv re li databasê têne hilanîn û ji kontrolkerê bargiran re têne şandin. Ew, di encamê de, daxwazek ji bo guheztina pêkhateya komê ya di balafira daneyê de ji barkêş-node re dişîne, ku ez ê li jêr nîqaş bikim.
Ka em bêtir li ser kontrolên tenduristiyê biaxivin. Ew dikarin li çend çînan bêne dabeş kirin. Kontrolkirin pîvanên serfiraziyê yên cûda hene. Kontrolên TCP hewce ne ku di nav demek diyarkirî de pêwendiyek bi serfirazî saz bikin. Kontrolên HTTP hem pêwendiyek serfiraz û hem jî bersivek bi kodek statûya 200 hewce dike.
Di heman demê de, kontrol di çîna çalakiyê de cûda dibin - ew çalak û pasîf in. Kontrolên pasîf bi tenê çavdêriya tiştê ku bi seyrûseferê re diqewime bêyî ku tedbîrek taybetî were girtin. Ev li ser L4 pir baş naxebite ji ber ku ew bi mantiqa protokolên asta bilind ve girêdayî ye: li ser L4 agahdarî tune ku operasyon çiqas dirêj kir an jî ka temamkirina girêdanê baş an xirab bû. Kontrolên çalak hewce dike ku balansek daxwaz ji her mînakek serverê re bişîne.
Piraniya hevsengên barkirinê bi xwe kontrolên zindîtiyê dikin. Li Cloud, me biryar da ku em van beşên pergalê ji hev veqetînin da ku pîvandinê zêde bikin. Ev nêzîkatî dê bihêle ku em di heman demê de hejmara daxwazên kontrolkirina tenduristiyê ji karûbarê re biparêzin, hejmara balansan zêde bikin. Kontrol ji hêla girêkên kontrolê yên tenduristiyê yên cihê ve têne kirin, ku li seranserê wan mebestên kontrolê têne perçekirin û dubare kirin. Hûn nekarin ji yek mêvandar kontrol bikin, ji ber ku dibe ku ew têk nebe. Wê demê em ê rewşa mînakên ku wî kontrol kirine negirin. Em bi kêmî ve sê girêkên kontrolkirina tenduristiyê li ser yek ji wan tiştan kontrol dikin. Em mebestên kontrolê yên di navbera girêkan de bi karanîna algorîtmayên haşkirinê yên domdar vediqetînin.
Veqetandina hevsengî û kontrolkirina tenduristiyê dikare bibe sedema pirsgirêkan. Ger girêka kontrolê ya tenduristiyê daxwazê ji nimûneyê dike, balanserê (ya ku naha ji seyrûseferê re xizmet nake) derbas dike, wê hingê rewşek ecêb derdikeve: çavkanî zindî xuya dike, lê seyrûsefer wê negihîje wê. Em vê pirsgirêkê bi vî rengî çareser dikin: em garantî dikin ku seyrûsefera kontrolkirina tenduristiyê bi navgîniya balansan ve bidin destpêkirin. Bi gotinek din, pilana veguheztina pakêtan bi seyrûseferê ji xerîdar û ji kontrolên tenduristiyê hindiktirîn cûda dibe: di her du rewşan de, pakêt dê bigihîjin balanskeran, ku dê wan bigihîne çavkaniyên armanc.
Cûdahî ev e ku xerîdar ji VIP-ê daxwaz dikin, dema ku kontrolên tenduristiyê ji her RIP-ê kesane daxwaz dikin. Pirsgirêkek balkêş li vir derdikeve: em fersendê didin bikarhênerên xwe ku di torên IP-ya gewr de çavkaniyan biafirînin. Ka em bifikirin ku du xwediyên ewr ên cihêreng hene ku karûbarên xwe li pişt balansan veşartine. Her yek ji wan xwedî çavkaniyên di binneta 10.0.0.1/24 de, bi heman navnîşanan. Hûn hewce ne ku hûn bi rengek wan ji hev cuda bikin, û li vir hûn hewce ne ku di nav avahiya tora virtual ya Yandex.Cloud de bişopînin. Çêtir e ku meriv hûrguliyên bêtir di nav de bibîne , niha ji bo me girîng e ku tor pir-qatî ye û tûnelên wê hene ku ji hêla id subnetê ve têne cûda kirin.
Nokên kontrolê yên tenduristiyê bi balanskeran re têkilî bi navnîşanên ku jê re tê gotin quasi-IPv6 bikar tînin. Navnîşanek quasi-navnîşanek IPv6 e ku navnîşek IPv4 û nasnavê subneta bikarhêner di hundurê wê de veşartiye. Trafîk digihîje balanserê, ku navnîşana çavkaniya IPv4 jê derdixe, IPv6 bi IPv4 diguhezîne û pakêtê dişîne tora bikarhêner.
Trafîka berevajî bi heman rengî diçe: balansek dibîne ku meqsed ji kontrolkerên tenduristiyê toreyek gewr e, û IPv4 vediguherîne IPv6.
VPP - dilê balafira daneyê
Balansek bi karanîna teknolojiya Vector Packet Processing (VPP), çarçoveyek ji Cisco-yê ji bo pêvajoyek hevî ya seyrûsefera torê tête bicîh kirin. Di doza me de, çarçove li ser pirtûkxaneya rêveberiya cîhaza torê ya cîhê bikarhêner - Kit Pêşveçûna Plana Daneyên (DPDK) dixebite. Ev yek performansa hilanîna pakêtê ya bilind misoger dike: di kernelê de pir kêm qutbûn çêdibin, û di navbera cîhê kernel û cîhê bikarhêner de guheztinên konteksê tune.
VPP hê pêşdetir diçe û bi berhevkirina pakêtan di nav koman de hê bêtir performansê ji pergalê derdixe. Destkeftiyên performansê ji karanîna hovane ya cache li ser pêvajoyên nûjen têne. Her du vekêşên daneyê têne bikar anîn (pakêt di "vektoran" de têne hilberandin, dane nêzîkê hev in) û kaşên talîmatê: Di VPP de, pêvajoya pakêtê grafiyek dişopîne, ku girêkên wê fonksiyonên ku heman peywirê pêk tînin dihewîne.
Mînakî, pêvajokirina pakêtên IP-ê di VPP-ê de bi rêza jêrîn pêk tê: yekem, sernavên pakêtê di girêka parskirinê de têne pars kirin, û dûv re ew ji girêkê re têne şandin, ku pakêtan li gorî tabloyên rêvekirinê pêşdetir dişîne.
A hardcore biçûk. Nivîskarên VPP-ê di karanîna kaşên pêvajoyê de lihevhatinan tehemûl nakin, ji ber vê yekê koda tîpîk ji bo hilberandina vektorek pakêtan vektorîzasyona bi destan vedihewîne: pêvajoyek pêvajoyê heye ku tê de rewşek mîna "di rêzê de çar pakêtên me hene" tê pêvajo kirin. paşê heman ji bo du, paşê - ji bo yek. Rêwerzên pêşdibistanê bi gelemperî têne bikar anîn da ku daneyan li cache bar bikin da ku di dubareyên paşîn de gihîştina wan zûtir bikin.
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);
}Ji ber vê yekê, Healthchecks li ser IPv6 bi VPP re diaxivin, ku wan vediguherîne IPv4. Ev ji hêla girêkek di grafikê de, ku em jê re dibêjin NAT algorîtmîkî, tête kirin. Ji bo seyrûsefera berevajî (û veguheztina ji IPv6 bo IPv4) heman girêk algorîtmîkî NAT heye.
Trafîka rasterast ji xerîdarên balanserê di nav girêkên grafîkê re derbas dibe, ku hevsengiyê bixwe pêk tîne.
Xala yekem danişînên asê ne. Ew hash of depo dike ji bo rûniştinên sazkirî. 5-tuple navnîşan û porta xerîdar a ku jê agahdarî tê veguheztin, navnîşan û portên çavkaniyên ku ji bo wergirtina seyrûseferê hene, û her weha protokola torê vedihewîne.
Hash-a 5-caran ji me re dibe alîkar ku di girêka hashkirina domdar a paşîn de kêmtir hesaban pêk bînin, û her weha guhertinên navnîşa çavkaniyê li pişt balansek çêtir bi rê ve bibin. Dema ku pakêtek ku ji bo wê danişîn tune ye digihîje balanserê, ew ji girêka heşkirinê ya domdar re tê şandin. Li vir hevsengî bi karanîna hashkirina domdar pêk tê: em çavkaniyek ji navnîşa çavkaniyên "zindî" yên berdest hilbijêrin. Dûv re, pakêt ji girêka NAT-ê re têne şandin, ku bi rastî navnîşana mebestê diguhezîne û kontrolên kontrolê ji nû ve hesab dike. Wekî ku hûn dikarin bibînin, em rêzikên VPP-ê dişopînin - hez dikin, hesabên wekhev kom dikin da ku karbidestiya kaşên pêvajoyê zêde bikin.
Haşkirina domdar
Çima me ew hilbijart û ew jî çi ye? Pêşîn, bila em karê berê bifikirin - hilbijartina çavkaniyek ji navnîşê.
Bi hashkirina nehevgirtî re, haşa pakêta hatî tê hesibandin, û çavkaniyek ji navnîşê tê hilbijartin ji hêla mayî ve dabeşkirina vê hashê li ser hejmara çavkaniyan. Heya ku navnîş neguherî bimîne, ev nexşe baş dixebite: em her gav pakêtên bi heman 5-tupleyan ji heman nimûneyê re dişînin. Ger, mînakî, hin çavkaniyek bersivdana kontrolên tenduristiyê rawestîne, wê hingê ji bo beşek girîng a haşeyan dê bijarte biguheze. Têkiliyên TCP-ê yên xerîdar dê qut bibin: pakêtek ku berê xwe gihandiye mînaka A-yê dibe ku dest pê bike bigihîje mînaka B, ku bi danişîna vê pakêtê re nizane.
Hashkirina domdar pirsgirêka diyarkirî çareser dike. Rêya herî hêsan a ravekirina vê têgehê ev e: bifikire ku zengilek we heye ku hûn jê re çavkaniyan bi hash belav dikin (mînak, bi IP:port). Hilbijartina çavkaniyek zivirîna çerxê bi goşeyekê ye, ku ji hêla haşa pakêtê ve tê destnîşankirin.
Dema ku pêkhatina çavkaniyan diguhere ev ji nû ve dabeşkirina trafîkê kêm dike. Jêbirina çavkaniyekê tenê dê bandorê li beşa zengila hevgirtî ya ku çavkanî tê de bû bike. Zêdekirina çavkaniyek di heman demê de belavkirinê jî diguhezîne, lê me girêkek danişînê ya zeliqandî heye, ku destûrê dide me ku em danişînên jixwe sazkirî veneguhezînin çavkaniyên nû.
Me li çi diqewime ku seyrûsefera rasterast di navbera hevseng û çavkaniyan de çêdibe. Naha em li trafîka vegerê binêrin. Ew heman şêwaza seyrûsefera kontrolê dişopîne - bi navgîniya NAT-a algorîtmîkî, ango bi NAT 44-a berevajî ve ji bo seyrûsefera xerîdar û bi NAT 46-ê ji bo seyrûsefera kontrolên tenduristiyê. Em bi pilana xwe ve girêdayî ne: em seyrûsefera kontrolên tenduristiyê û seyrûsefera bikarhênerê rastîn yek dikin.
Loadbalancer-node û pêkhateyên kombûyî
Pêkhatina hevseng û çavkaniyan di VPP de ji hêla karûbarê herêmî - loadbalancer-node ve tê ragihandin. Ew di nav herikîna bûyeran de ji loadbalancer-kontroller re têkildar e û dikare cûdahiya di navbera dewleta VPP ya heyî û dewleta armancê ya ku ji kontrolkerê hatî wergirtin de xêz bike. Em pergalek girtî digirin: Bûyerên ji API-ê têne ber kontrolkerê hevsengiyê, ku peywiran dide kontrolkerê tenduristiyê da ku "jiyana" çavkaniyan kontrol bike. Ew, di encamê de, peywiran ji girêka kontrolê ya tenduristiyê re destnîşan dike û encaman berhev dike, dûv re jî wan ji kontrolkerê balansê re vedigerîne. Loadbalancer-node beşdarî bûyerên ji kontrolkerê dibe û rewşa VPP-ê diguhezîne. Di pergalek wusa de, her karûbar tenê di derbarê karûbarên cîran de çi hewce dike dizane. Hejmara pêwendiyan tixûbdar e û şiyana me heye ku em beşên cûda serbixwe tevbigerin û mezin bikin.
Ji kîjan pirsgirêkan dûr ketin?
Hemî karûbarên me yên di balafira kontrolê de li Go-yê têne nivîsandin û taybetmendiyên pîvan û pêbaweriyê yên baş hene. Go ji bo avakirina pergalên belavkirî gelek pirtûkxaneyên çavkaniya vekirî hene. Em bi aktîvî GRPC bikar tînin, hemî pêkhate cîbicîkirina çavkaniyek vekirî ya vedîtina karûbarê vedihewîne - karûbarên me performansa hevûdu dişopînin, dikarin pêkhateya xwe bi rengek dînamîkî biguhezînin, û me vê yekê bi hevsengiya GRPC ve girêda. Ji bo metrîkan, em jî çareseriyek çavkaniyek vekirî bikar tînin. Di balafira daneyê de, me performansa maqûl û rezervek çavkaniyek mezin stend: pir dijwar bû ku em li şûna qerta torê ya hesinî, li ser performansa VPP-ê bispêrin.
Pirsgirêk û Çareserî
Çi baş nexebitî? Go xwedan rêveberiya bîranînê ya otomatîkî ye, lê lewazên bîranîn hîn jî çêdibin. Rêya herî hêsan ku meriv bi wan re mijûl bibe ev e ku meriv gorutinan bimeşîne û ji bîr neke ku wan biqedîne. Takeaway: Li ser vexwarina bîranîna bernameyên Go xwe temaşe bikin. Gelek caran nîşanek baş hejmara gorutinan e. Di vê çîrokê de zêdebûnek heye: di Go de hêsan e ku meriv daneya dema xebitandinê bi dest bixe - vexwarina bîranînê, hejmara gorutinên xebitandinê, û gelek pîvanên din.
Di heman demê de, dibe ku Go ji bo ceribandinên fonksiyonel ne bijareya çêtirîn be. Ew pir devkî ne, û nêzîkatiya standard a "her tiştî di CI-ê de bi hev re dimeşîne" ji wan re ne pir maqûl e. Rastî ev e ku ceribandinên fonksiyonel bêtir çavkanî-daxwaz in û dibin sedema demên rastîn. Ji ber vê yekê, dibe ku ceribandin têk biçin ji ber ku CPU bi ceribandinên yekîneyê re mijûl e. Encam: Heke gengaz be, ceribandinên "giran" ji ceribandinên yekîneyê veqetînin.
Mîmariya bûyera Microservice ji monolîtek tevlihevtir e: berhevkirina têketin li ser bi dehan makîneyên cihêreng ne pir hêsan e. Encam: heke hûn mîkroservisan çêbikin, tavilê li ser şopandinê bifikirin.
Planên me
Em ê balansek hundurîn, hevsengek IPv6 bidin destpêkirin, piştgirî ji bo nivîsarên Kubernetes zêde bikin, parvekirina karûbarên xwe bidomînin (niha tenê tenduristî-node û healthcheck-ctrl têne perçe kirin), kontrolên tenduristiyê yên nû lê zêde bikin, û di heman demê de berhevkirina aqilmend a kontrolê jî bicîh bikin. Em li ser îhtîmala ku em karûbarên xwe hîn bêtir serbixwe bikin - da ku ew ne rasterast bi hevûdu re têkilî daynin, lê rêzek peyamê bikar bînin. Karûbarek SQS-lihevhatî herî dawî di Cloud de xuya bû .
Di van demên dawî de, serbestberdana gelemperî ya Yandex Load Balancer pêk hat. Lêkolîn ji karûbarê re, balanskeran bi awayek ji we re xweş birêve bibin û tolerasyona xeletiya projeyên xwe zêde bikin!
Source: www.habr.com