Helo, Sergey Elantsev ydw i, dwi'n datblygu yn Yandex.Cloud. Yn flaenorol, fe wnes i arwain datblygiad y balancer L7 ar gyfer y porth Yandex - mae cydweithwyr yn cellwair, ni waeth beth rydw i'n ei wneud, mae'n troi allan i fod yn gydbwysedd. Byddaf yn dweud wrth ddarllenwyr Habr sut i reoli'r llwyth mewn platfform cwmwl, yr hyn a welwn fel yr offeryn delfrydol ar gyfer cyflawni'r nod hwn, a sut yr ydym yn symud tuag at adeiladu'r offeryn hwn.
Yn gyntaf, gadewch i ni gyflwyno rhai termau:
- VIP (Rhith IP) - cyfeiriad IP balancer
- Gweinydd, backend, enghraifft - peiriant rhithwir yn rhedeg cymhwysiad
- RIP (Real IP) - cyfeiriad IP gweinyddwr
- Healthcheck - gwirio parodrwydd gweinydd
- Parth Argaeledd, AZ - seilwaith ynysig mewn canolfan ddata
- Rhanbarth - undeb o wahanol AZs
Mae balanswyr llwyth yn datrys tair prif dasg: maen nhw'n cyflawni'r cydbwyso ei hun, yn gwella goddefgarwch bai'r gwasanaeth, ac yn symleiddio ei raddio. Sicrheir goddefgarwch nam trwy reolaeth traffig awtomatig: mae'r cydbwyseddwr yn monitro cyflwr y cais ac yn eithrio achosion o gydbwyso nad ydynt yn pasio'r gwiriad bywiogrwydd. Sicrheir graddio trwy ddosbarthu'r llwyth yn gyfartal ar draws achosion, yn ogystal â diweddaru'r rhestr o achosion ar y hedfan. Os nad yw'r cydbwyso'n ddigon unffurf, bydd rhai o'r achosion yn derbyn llwyth sy'n fwy na'u terfyn gallu, a bydd y gwasanaeth yn dod yn llai dibynadwy.
Mae cydbwysedd llwyth yn aml yn cael ei ddosbarthu yn ôl yr haen protocol o'r model OSI y mae'n rhedeg arno. Mae'r Cloud Balancer yn gweithredu ar lefel TCP, sy'n cyfateb i'r bedwaredd haen, L4.
Gadewch i ni symud ymlaen i drosolwg o bensaernïaeth balancer Cloud. Byddwn yn cynyddu lefel y manylder yn raddol. Rydyn ni'n rhannu'r cydrannau cydbwysedd yn dri dosbarth. Mae'r dosbarth awyren ffurfweddu yn gyfrifol am ryngweithio defnyddwyr ac yn storio cyflwr targed y system. Mae'r awyren reoli yn storio cyflwr presennol y system ac yn rheoli systemau o'r dosbarth awyren ddata, sy'n uniongyrchol gyfrifol am gludo traffig o gleientiaid i'ch achosion chi.
Awyren ddata
Mae'r traffig yn dod i ben i fyny ar ddyfeisiau drud a elwir yn llwybryddion ffin. Er mwyn cynyddu goddefgarwch namau, mae sawl dyfais o'r fath yn gweithredu ar yr un pryd mewn un ganolfan ddata. Nesaf, mae'r traffig yn mynd i fantolwyr, sy'n cyhoeddi unrhyw gyfeiriadau IP cast i bob AZ trwy BGP ar gyfer cleientiaid.
Mae traffig yn cael ei drosglwyddo dros ECMP - mae hon yn strategaeth lwybro lle gall fod sawl llwybr yr un mor dda i'r targed (yn ein hachos ni, y targed fydd cyfeiriad IP y gyrchfan) a gellir anfon pecynnau ar hyd unrhyw un ohonynt. Rydym hefyd yn cefnogi gwaith mewn sawl parth argaeledd yn unol â'r cynllun a ganlyn: rydym yn hysbysebu cyfeiriad ym mhob parth, mae traffig yn mynd i'r un agosaf ac nid yw'n mynd y tu hwnt i'w derfynau. Yn ddiweddarach yn y post byddwn yn edrych yn fanylach ar yr hyn sy'n digwydd i draffig.
Config awyren
Elfen allweddol yr awyren ffurfweddu yw'r API, lle mae gweithrediadau sylfaenol gyda balanswyr yn cael eu perfformio: creu, dileu, newid cyfansoddiad achosion, cael canlyniadau gwiriadau iechyd, ac ati. Ar y naill law, mae hwn yn API REST, ac ar y arall, rydyn ni yn y Cwmwl yn aml iawn yn defnyddio'r fframwaith gRPC, felly rydyn ni'n “cyfieithu” REST i gRPC ac yna'n defnyddio gRPC yn unig. Mae unrhyw gais yn arwain at greu cyfres o dasgau segur asyncronig sy'n cael eu cyflawni ar gronfa gyffredin o weithwyr Yandex.Cloud. Ysgrifennir tasgau yn y fath fodd fel y gellir eu hatal ar unrhyw adeg ac yna eu hailddechrau. Mae hyn yn sicrhau graddadwyedd, ailadroddadwyedd a chofnodi gweithrediadau.
O ganlyniad, bydd y dasg o'r API yn gwneud cais i'r rheolwr gwasanaeth balancer, sydd wedi'i ysgrifennu yn Go. Gall ychwanegu a chael gwared ar gydbwysedd, newid cyfansoddiad backends a gosodiadau.
Mae'r gwasanaeth yn storio ei gyflwr yng Nghronfa Ddata Yandex, cronfa ddata ddosbarthedig a reolir y byddwch yn gallu ei defnyddio cyn bo hir. Yn Yandex.Cloud, fel yr ydym eisoes , mae'r cysyniad bwyd ci yn berthnasol: os ydym ni ein hunain yn defnyddio ein gwasanaethau, yna bydd ein cleientiaid hefyd yn hapus i'w defnyddio. Mae Cronfa Ddata Yandex yn enghraifft o weithredu cysyniad o'r fath. Rydym yn storio ein holl ddata yn YDB, ac nid oes rhaid i ni feddwl am gynnal a graddio'r gronfa ddata: mae'r problemau hyn yn cael eu datrys i ni, rydym yn defnyddio'r gronfa ddata fel gwasanaeth.
Gadewch i ni ddychwelyd at y rheolydd balancer. Ei dasg yw arbed gwybodaeth am y cydbwyseddwr ac anfon tasg i wirio parodrwydd y peiriant rhithwir i'r rheolydd gwiriad iechyd.
Rheolydd Gwiriad Iechyd
Mae'n derbyn ceisiadau i newid rheolau siec, yn eu harbed yn YDB, yn dosbarthu tasgau ymhlith nodau healtcheck ac yn agregu'r canlyniadau, sydd wedyn yn cael eu cadw i'r gronfa ddata a'u hanfon at y rheolydd loadbalancer. Mae, yn ei dro, yn anfon cais i newid cyfansoddiad y clwstwr yn yr awyren ddata i'r nod loadbalancer, y byddaf yn ei drafod isod.
Gadewch i ni siarad mwy am wiriadau iechyd. Gellir eu rhannu yn nifer o ddosbarthiadau. Mae gan archwiliadau feini prawf llwyddiant gwahanol. Mae angen i wiriadau TCP sefydlu cysylltiad yn llwyddiannus o fewn cyfnod penodol o amser. Mae gwiriadau HTTP yn gofyn am gysylltiad llwyddiannus ac ymateb gyda chod statws 200.
Hefyd, mae gwiriadau yn amrywio yn y dosbarth gweithredu - maent yn weithredol ac yn oddefol. Yn syml, mae gwiriadau goddefol yn monitro'r hyn sy'n digwydd gyda thraffig heb gymryd unrhyw gamau arbennig. Nid yw hyn yn gweithio'n dda iawn ar L4 oherwydd mae'n dibynnu ar resymeg y protocolau lefel uwch: ar L4 nid oes unrhyw wybodaeth am ba mor hir a gymerodd y gweithrediad nac a oedd cwblhau'r cysylltiad yn dda neu'n ddrwg. Mae gwiriadau gweithredol yn ei gwneud yn ofynnol i'r balansiwr anfon ceisiadau i bob achos gweinydd.
Mae'r rhan fwyaf o gydbwyswyr llwyth yn cynnal gwiriadau bywiogrwydd eu hunain. Yn Cloud, fe benderfynon ni wahanu'r rhannau hyn o'r system i gynyddu'r gallu i dyfu. Bydd y dull hwn yn ein galluogi i gynyddu nifer y balansau tra'n cynnal nifer y ceisiadau am wiriad iechyd i'r gwasanaeth. Cynhelir gwiriadau gan nodau prawf iechyd ar wahân, a chaiff targedau gwirio eu rhannu a'u hailadrodd ar eu traws. Ni allwch gynnal gwiriadau gan un gwesteiwr, gan y gallai fethu. Yna ni fyddwn yn cael cyflwr yr achosion a wiriodd. Rydym yn cynnal gwiriadau ar unrhyw un o'r achosion o o leiaf dri nod prawf iechyd. Rydym yn rhannu dibenion gwiriadau rhwng nodau gan ddefnyddio algorithmau stwnsio cyson.
Gall gwahanu cydbwyso a gwiriad iechyd arwain at broblemau. Os yw nod y gwiriad iechyd yn gwneud ceisiadau i'r enghraifft, gan osgoi'r cydbwysedd (nad yw'n gwasanaethu traffig ar hyn o bryd), yna mae sefyllfa ryfedd yn codi: mae'n ymddangos bod yr adnodd yn fyw, ond ni fydd y traffig yn ei gyrraedd. Rydyn ni'n datrys y broblem hon fel hyn: rydyn ni'n sicr o gychwyn traffig gwirio iechyd trwy falanswyr. Mewn geiriau eraill, ychydig iawn o wahaniaeth sydd rhwng y cynllun ar gyfer symud pecynnau gyda thraffig gan gleientiaid ac o wiriadau iechyd: yn y ddau achos, bydd y pecynnau'n cyrraedd y balanswyr, a fydd yn eu cludo i'r adnoddau targed.
Y gwahaniaeth yw bod cleientiaid yn gwneud ceisiadau i PCC, tra bod gwiriadau iechyd yn gwneud ceisiadau i bob RIP unigol. Mae problem ddiddorol yn codi yma: rydyn ni'n rhoi cyfle i'n defnyddwyr greu adnoddau mewn rhwydweithiau IP llwyd. Gadewch i ni ddychmygu bod yna ddau berchennog cwmwl gwahanol sydd wedi cuddio eu gwasanaethau y tu ôl i balancers. Mae gan bob un ohonynt adnoddau yn yr is-rwydwaith 10.0.0.1/24, gyda'r un cyfeiriadau. Mae angen i chi allu gwahaniaethu rhyngddynt rywsut, ac yma mae angen i chi blymio i strwythur rhwydwaith rhithwir Yandex.Cloud. Mae'n well cael mwy o fanylion yn , mae'n bwysig i ni nawr bod y rhwydwaith yn aml-haenog ac mae ganddo dwneli y gellir eu gwahaniaethu gan subnet id.
Mae nodau prawf iechyd yn cysylltu â balanswyr gan ddefnyddio cyfeiriadau lled-IPv6 fel y'u gelwir. Cyfeiriad IPv6 yw cyfeiriad lled-gyfeiriad gyda chyfeiriad IPv4 ac is-rwydwaith defnyddiwr wedi'i fewnosod y tu mewn iddo. Mae'r traffig yn cyrraedd y balancer, sy'n tynnu'r cyfeiriad adnodd IPv4 ohono, yn disodli IPv6 gyda IPv4 ac yn anfon y pecyn i rwydwaith y defnyddiwr.
Mae'r traffig cefn yn mynd yr un ffordd: mae'r cydbwysedd yn gweld bod y cyrchfan yn rhwydwaith llwyd o wirwyr iechyd, ac yn trosi IPv4 i IPv6.
VPP - calon yr awyren ddata
Mae'r balancer yn cael ei weithredu gan ddefnyddio technoleg Prosesu Pecyn Vector (VPP), fframwaith gan Cisco ar gyfer prosesu swp o draffig rhwydwaith. Yn ein hachos ni, mae'r fframwaith yn gweithio ar ben y llyfrgell rheoli dyfeisiau rhwydwaith gofod defnyddiwr - Pecyn Datblygu Plane Data (DPDK). Mae hyn yn sicrhau perfformiad prosesu pecynnau uchel: mae llawer llai o ymyriadau yn digwydd yn y cnewyllyn, ac nid oes switshis cyd-destun rhwng gofod cnewyllyn a gofod defnyddwyr.
Mae VPP yn mynd hyd yn oed ymhellach ac yn gwasgu hyd yn oed mwy o berfformiad allan o'r system trwy gyfuno pecynnau yn sypiau. Daw'r enillion perfformiad o'r defnydd ymosodol o caches ar broseswyr modern. Defnyddir y ddau storfa ddata (mae pecynnau'n cael eu prosesu mewn “fectorau", mae'r data'n agos at ei gilydd) a storfa gyfarwyddiadau: yn VPP, mae prosesu pecynnau yn dilyn graff, y mae ei nodau'n cynnwys swyddogaethau sy'n cyflawni'r un dasg.
Er enghraifft, mae prosesu pecynnau IP yn VPP yn digwydd yn y drefn ganlynol: yn gyntaf, caiff penawdau'r pecyn eu dosrannu yn y nod dosrannu, ac yna cânt eu hanfon at y nod, sy'n anfon y pecynnau ymlaen ymhellach yn ôl y tablau llwybro.
Ychydig o graidd caled. Nid yw awduron VPP yn goddef cyfaddawdu yn y defnydd o caches prosesydd, felly mae cod nodweddiadol ar gyfer prosesu fector o becynnau yn cynnwys fectoreiddio â llaw: mae dolen brosesu lle mae sefyllfa fel “mae gennym ni bedwar pecyn yn y ciw” yn cael ei phrosesu, yna yr un peth ar gyfer dau, yna - ar gyfer un. Defnyddir cyfarwyddiadau rhagosodedig yn aml i lwytho data i mewn i gelciau er mwyn cyflymu mynediad iddynt mewn iteriadau dilynol.
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);
}Felly, mae Healthchecks yn siarad dros IPv6 i'r VPP, sy'n eu troi'n IPv4. Gwneir hyn gan nod yn y graff, yr ydym yn ei alw'n NAT algorithmig. Ar gyfer traffig o chwith (a throsi o IPv6 i IPv4) mae'r un nod NAT algorithmig.
Mae traffig uniongyrchol o'r cleientiaid balancer yn mynd trwy'r nodau graff, sy'n perfformio'r cydbwyso ei hun.
Y nod cyntaf yw sesiynau gludiog. Mae'n storio'r hash o ar gyfer sesiynau sefydledig. Mae 5-tuple yn cynnwys cyfeiriad a phorthladd y cleient y mae gwybodaeth yn cael ei throsglwyddo ohono, y cyfeiriad a'r porthladdoedd adnoddau sydd ar gael ar gyfer derbyn traffig, yn ogystal â'r protocol rhwydwaith.
Mae'r hash 5-tuple yn ein helpu i berfformio llai o gyfrifiant yn y nod stwnsio cyson dilynol, yn ogystal â thrin newidiadau rhestr adnoddau yn well y tu ôl i'r balancer. Pan fydd pecyn nad oes sesiwn ar ei gyfer yn cyrraedd y balans, caiff ei anfon at y nod stwnsio cyson. Dyma lle mae cydbwyso'n digwydd gan ddefnyddio stwnsio cyson: rydyn ni'n dewis adnodd o'r rhestr o adnoddau “byw” sydd ar gael. Nesaf, anfonir y pecynnau i'r nod NAT, sydd mewn gwirionedd yn disodli'r cyfeiriad cyrchfan ac yn ailgyfrifo'r sieciau. Fel y gwelwch, rydym yn dilyn rheolau VPP - hoffi hoffi, gan grwpio cyfrifiadau tebyg i gynyddu effeithlonrwydd caches prosesydd.
Stwnsio cyson
Pam wnaethon ni ei ddewis a beth yw hyd yn oed? Yn gyntaf, gadewch i ni ystyried y dasg flaenorol - dewis adnodd o'r rhestr.
Gyda stwnsio anghyson, cyfrifir hash y pecyn sy'n dod i mewn, a dewisir adnodd o'r rhestr trwy weddill rhannu'r hash hwn â nifer yr adnoddau. Cyn belled â bod y rhestr yn aros heb ei newid, mae'r cynllun hwn yn gweithio'n dda: rydym bob amser yn anfon pecynnau gyda'r un 5-tuple i'r un achos. Er enghraifft, os bydd rhywfaint o adnoddau yn peidio ag ymateb i wiriadau iechyd, yna am ran sylweddol o'r hashes bydd y dewis yn newid. Bydd cysylltiadau TCP y cleient yn cael eu torri: gall pecyn a gyrhaeddodd enghraifft A yn flaenorol ddechrau cyrraedd enghraifft B, nad yw'n gyfarwydd â'r sesiwn ar gyfer y pecyn hwn.
Mae stwnsio cyson yn datrys y broblem a ddisgrifir. Y ffordd hawsaf o esbonio'r cysyniad hwn yw hyn: dychmygwch fod gennych fodrwy y byddwch yn dosbarthu adnoddau iddi trwy hash (er enghraifft, trwy IP:port). Mae dewis adnodd yn troi'r olwyn gan ongl, sy'n cael ei bennu gan hash y pecyn.
Mae hyn yn lleihau ailddosbarthu traffig pan fydd cyfansoddiad adnoddau yn newid. Bydd dileu adnodd ond yn effeithio ar y rhan o'r cylch stwnsio cyson y lleolwyd yr adnodd ynddo. Mae ychwanegu adnodd hefyd yn newid y dosbarthiad, ond mae gennym nod sesiynau gludiog, sy'n ein galluogi i beidio â newid sesiynau sydd eisoes wedi'u sefydlu i adnoddau newydd.
Gwnaethom edrych ar yr hyn sy'n digwydd i gyfeirio traffig rhwng y cydbwyseddwr ac adnoddau. Nawr, gadewch i ni edrych ar draffig dychwelyd. Mae'n dilyn yr un patrwm â thraffig siec - trwy NAT algorithmig, hynny yw, trwy NAT 44 cefn ar gyfer traffig cleientiaid a thrwy NAT 46 ar gyfer traffig gwiriadau iechyd. Rydym yn cadw at ein cynllun ein hunain: rydym yn uno traffig gwiriadau iechyd a thraffig defnyddwyr go iawn.
Loadbalancer-nod a chydrannau cydosod
Mae cyfansoddiad y balanswyr ac adnoddau yn VPP yn cael ei adrodd gan y gwasanaeth lleol - loadbalancer-nod. Mae'n tanysgrifio i'r llif o ddigwyddiadau o loadbalancer-rheolwr ac yn gallu plotio'r gwahaniaeth rhwng y cyflwr VPP presennol a'r cyflwr targed a dderbyniwyd gan y rheolydd. Rydyn ni'n cael system gaeedig: mae digwyddiadau o'r API yn dod i'r rheolydd cydbwysedd, sy'n aseinio tasgau i'r rheolwr gwiriad iechyd i wirio “bywder” adnoddau. Mae hynny, yn ei dro, yn aseinio tasgau i'r nod gwirio iechyd ac yn agregu'r canlyniadau, ac ar ôl hynny mae'n eu hanfon yn ôl at y rheolydd cydbwysedd. Mae Loadbalancer-node yn tanysgrifio i ddigwyddiadau gan y rheolydd ac yn newid cyflwr y VPP. Mewn system o'r fath, dim ond yr hyn sy'n angenrheidiol am wasanaethau cyfagos y mae pob gwasanaeth yn ei wybod. Mae nifer y cysylltiadau yn gyfyngedig ac mae gennym y gallu i weithredu a graddio gwahanol segmentau yn annibynnol.
Pa faterion a gafodd eu hosgoi?
Mae ein holl wasanaethau yn yr awyren reoli wedi'u hysgrifennu yn Go ac mae ganddynt nodweddion graddio a dibynadwyedd da. Mae gan Go lawer o lyfrgelloedd ffynhonnell agored ar gyfer adeiladu systemau dosbarthedig. Rydym yn defnyddio GRPC yn weithredol, mae pob cydran yn cynnwys gweithrediad ffynhonnell agored o ddarganfod gwasanaeth - mae ein gwasanaethau'n monitro perfformiad ei gilydd, yn gallu newid eu cyfansoddiad yn ddeinamig, ac fe wnaethom gysylltu hyn â chydbwyso GRPC. Ar gyfer metrigau, rydym hefyd yn defnyddio datrysiad ffynhonnell agored. Yn yr awyren ddata, cawsom berfformiad gweddus a chronfa adnoddau fawr: trodd yn anodd iawn cydosod stondin y gallem ddibynnu arno ar berfformiad VPP, yn hytrach na cherdyn rhwydwaith haearn.
Problemau ac atebion
Beth na weithiodd cystal? Mae gan Go reolaeth cof awtomatig, ond mae gollyngiadau cof yn dal i ddigwydd. Y ffordd hawsaf o ddelio â nhw yw rhedeg goroutines a chofiwch eu terfynu. Tecawe: Gwyliwch faint o gof sy'n cael ei fwyta gan raglenni Go. Yn aml, dangosydd da yw nifer y goroutines. Mae mantais yn y stori hon: yn Go mae'n hawdd cael data amser rhedeg - defnydd cof, nifer y goroutines rhedeg, a llawer o baramedrau eraill.
Hefyd, efallai nad Go yw'r dewis gorau ar gyfer profion swyddogaethol. Maen nhw’n eithaf llafar, ac nid yw’r dull safonol o “redeg popeth yn CI mewn swp” yn addas iawn ar eu cyfer. Y ffaith yw bod profion swyddogaethol yn gofyn am fwy o adnoddau ac yn achosi seibiannau gwirioneddol. Oherwydd hyn, gall profion fethu oherwydd bod y CPU yn brysur gyda phrofion uned. Casgliad: Os yn bosibl, gwnewch brofion “trwm” ar wahân i brofion uned.
Mae pensaernïaeth digwyddiad microservice yn fwy cymhleth na monolith: nid yw casglu boncyffion ar ddwsinau o wahanol beiriannau yn gyfleus iawn. Casgliad: os gwnewch ficrowasanaethau, meddyliwch ar unwaith am olrhain.
Ein cynlluniau
Byddwn yn lansio cydbwysedd mewnol, balans IPv6, yn ychwanegu cefnogaeth ar gyfer sgriptiau Kubernetes, yn parhau i dorri ein gwasanaethau (ar hyn o bryd dim ond nod iechyd a checkcheck-ctrl sy'n cael eu darnio), ychwanegu gwiriadau iechyd newydd, a hefyd gweithredu agregu gwiriadau smart. Rydym yn ystyried y posibilrwydd o wneud ein gwasanaethau hyd yn oed yn fwy annibynnol - fel eu bod yn cyfathrebu nid yn uniongyrchol â'i gilydd, ond gan ddefnyddio ciw neges. Mae gwasanaeth sy'n gydnaws â SQS wedi ymddangos yn y Cwmwl yn ddiweddar .
Yn ddiweddar, rhyddhawyd Yandex Load Balancer yn gyhoeddus. Archwiliwch i'r gwasanaeth, rheoli balanswyr mewn ffordd sy'n gyfleus i chi a chynyddu goddefgarwch bai eich prosiectau!
Ffynhonnell: hab.com