Kumusta, ako si Sergey Elantsev, bumuo ako sa Yandex.Cloud. Noong nakaraan, pinangunahan ko ang pagbuo ng L7 balancer para sa portal ng Yandex - nagbibiro ang mga kasamahan na kahit anong gawin ko, ito ay nagiging isang balanse. Sasabihin ko sa mga mambabasa ng Habr kung paano pamahalaan ang load sa isang cloud platform, kung ano ang nakikita natin bilang perpektong tool para sa pagkamit ng layuning ito, at kung paano tayo sumusulong sa pagbuo ng tool na ito.
Una, ipakilala natin ang ilang termino:
- VIP (Virtual IP) - balancer IP address
- Server, backend, halimbawa - isang virtual machine na nagpapatakbo ng isang application
- RIP (Real IP) - IP address ng server
- Healthcheck - pagsusuri sa kahandaan ng server
- Availability Zone, AZ - nakahiwalay na imprastraktura sa isang data center
- Rehiyon - isang unyon ng iba't ibang AZ
Nilulutas ng mga load balancer ang tatlong pangunahing gawain: ginagawa nila ang mismong pagbabalanse, pinapahusay ang fault tolerance ng serbisyo, at pinapasimple ang pag-scale nito. Tinitiyak ang fault tolerance sa pamamagitan ng awtomatikong pamamahala ng trapiko: sinusubaybayan ng balancer ang estado ng application at hindi kasama ang mga pagkakataon mula sa pagbabalanse na hindi pumasa sa liveness check. Sinisiguro ang pag-scale sa pamamagitan ng pantay na pamamahagi ng load sa mga instance, pati na rin ang pag-update ng listahan ng mga instance sa mabilisang paraan. Kung ang pagbabalanse ay hindi sapat na pare-pareho, ang ilan sa mga pagkakataon ay makakatanggap ng load na lampas sa kanilang limitasyon sa kapasidad, at ang serbisyo ay magiging hindi gaanong maaasahan.
Ang isang load balancer ay madalas na inuri ayon sa protocol layer mula sa OSI model kung saan ito tumatakbo. Gumagana ang Cloud Balancer sa antas ng TCP, na tumutugma sa ikaapat na layer, L4.
Lumipat tayo sa isang pangkalahatang-ideya ng arkitektura ng Cloud balancer. Unti-unti nating tataas ang antas ng detalye. Hinahati namin ang mga bahagi ng balancer sa tatlong klase. Ang klase ng config plane ay responsable para sa pakikipag-ugnayan ng user at iniimbak ang target na estado ng system. Iniimbak ng control plane ang kasalukuyang estado ng system at pinamamahalaan ang mga system mula sa klase ng data plane, na direktang responsable sa paghahatid ng trapiko mula sa mga kliyente patungo sa iyong mga pagkakataon.
Data plane
Napupunta ang trapiko sa mga mamahaling device na tinatawag na mga border router. Para mapataas ang fault tolerance, maraming ganoong device ang gumagana nang sabay-sabay sa isang data center. Susunod, ang trapiko ay napupunta sa mga tagabalanse, na nag-aanunsyo ng anycast na mga IP address sa lahat ng AZ sa pamamagitan ng BGP para sa mga kliyente.
Ang trapiko ay ipinapadala sa ECMP - ito ay isang diskarte sa pagruruta ayon sa kung saan maaaring mayroong maraming pantay na magagandang ruta patungo sa target (sa aming kaso, ang target ay ang patutunguhang IP address) at ang mga packet ay maaaring ipadala sa alinman sa mga ito. Sinusuportahan din namin ang trabaho sa ilang mga availability zone ayon sa sumusunod na pamamaraan: nag-a-advertise kami ng isang address sa bawat zone, ang trapiko ay napupunta sa pinakamalapit at hindi lalampas sa mga limitasyon nito. Mamaya sa post ay titingnan natin nang mas detalyado kung ano ang nangyayari sa trapiko.
I-configure ang eroplano
Ang pangunahing bahagi ng config plane ay ang API, kung saan isinasagawa ang mga pangunahing operasyon na may mga balancer: paggawa, pagtanggal, pagbabago ng komposisyon ng mga instance, pagkuha ng mga resulta ng mga pagsusuri sa kalusugan, atbp. Sa isang banda, ito ay isang REST API, at sa iba pa, kami sa Cloud ay madalas na gumagamit ng framework na gRPC, kaya't "isinasalin" namin ang REST sa gRPC at pagkatapos ay gRPC lang ang ginagamit namin. Anumang kahilingan ay humahantong sa paglikha ng isang serye ng mga asynchronous na idempotent na gawain na isinasagawa sa isang karaniwang pool ng mga manggagawa ng Yandex.Cloud. Ang mga gawain ay isinusulat sa paraang maaari silang masuspinde anumang oras at pagkatapos ay i-restart. Tinitiyak nito ang scalability, repeatability at pag-log ng mga operasyon.
Bilang resulta, ang gawain mula sa API ay gagawa ng kahilingan sa controller ng serbisyo ng balanse, na nakasulat sa Go. Maaari itong magdagdag at mag-alis ng mga balancer, baguhin ang komposisyon ng mga backend at setting.
Iniimbak ng serbisyo ang estado nito sa Yandex Database, isang distributed managed database na malapit mo nang magamit. Sa Yandex.Cloud, tulad na namin , ang konsepto ng dog food ay nalalapat: kung kami mismo ang gumagamit ng aming mga serbisyo, kung gayon ang aming mga kliyente ay magiging masaya na gamitin ang mga ito. Ang Yandex Database ay isang halimbawa ng pagpapatupad ng naturang konsepto. Iniimbak namin ang lahat ng aming data sa YDB, at hindi namin kailangang isipin ang tungkol sa pagpapanatili at pag-scale ng database: ang mga problemang ito ay nalutas para sa amin, ginagamit namin ang database bilang isang serbisyo.
Bumalik tayo sa controller ng balancer. Ang gawain nito ay i-save ang impormasyon tungkol sa balancer at magpadala ng isang gawain upang suriin ang kahandaan ng virtual machine sa healthcheck controller.
Kontroler ng Healthcheck
Tumatanggap ito ng mga kahilingan na baguhin ang mga panuntunan sa pag-check, ini-save ang mga ito sa YDB, namamahagi ng mga gawain sa mga node ng healtcheck at pinagsama-sama ang mga resulta, na pagkatapos ay ise-save sa database at ipinadala sa controller ng loadbalancer. Ito naman ay nagpapadala ng kahilingan na baguhin ang komposisyon ng cluster sa data plane sa loadbalancer-node, na tatalakayin ko sa ibaba.
Pag-usapan pa natin ang tungkol sa mga pagsusuri sa kalusugan. Maaari silang hatiin sa ilang mga klase. Ang mga pag-audit ay may iba't ibang pamantayan sa tagumpay. Ang mga pagsusuri sa TCP ay kailangang matagumpay na makapagtatag ng isang koneksyon sa loob ng isang nakapirming tagal ng panahon. Ang mga pagsusuri sa HTTP ay nangangailangan ng parehong matagumpay na koneksyon at isang tugon na may 200 status code.
Gayundin, ang mga pagsusuri ay naiiba sa klase ng pagkilos - sila ay aktibo at pasibo. Sinusubaybayan lamang ng mga passive check kung ano ang nangyayari sa trapiko nang hindi nagsasagawa ng anumang espesyal na aksyon. Hindi ito gumagana nang maayos sa L4 dahil depende ito sa lohika ng mga mas mataas na antas ng protocol: sa L4 walang impormasyon tungkol sa kung gaano katagal ang operasyon o kung ang pagkumpleto ng koneksyon ay mabuti o masama. Ang mga aktibong pagsusuri ay nangangailangan ng balancer na magpadala ng mga kahilingan sa bawat instance ng server.
Karamihan sa mga load balancer ay nagsasagawa ng liveness checks sa kanilang sarili. Sa Cloud, nagpasya kaming paghiwalayin ang mga bahaging ito ng system para mapataas ang scalability. Ang pamamaraang ito ay magbibigay-daan sa amin na madagdagan ang bilang ng mga tagabalanse habang pinapanatili ang bilang ng mga kahilingan sa pagsusuri sa kalusugan sa serbisyo. Isinasagawa ang mga pagsusuri sa pamamagitan ng magkahiwalay na mga node ng pagsusuri sa kalusugan, kung saan ang mga target ng pagsusuri ay hinahati at ginagaya. Hindi ka maaaring magsagawa ng mga pagsusuri mula sa isang host, dahil maaaring mabigo ito. Pagkatapos ay hindi namin makuha ang estado ng mga pagkakataon na sinuri niya. Nagsasagawa kami ng mga pagsusuri sa alinman sa mga pagkakataon mula sa hindi bababa sa tatlong mga healthcheck node. Pinaghiwa-hiwalay namin ang mga layunin ng mga pagsusuri sa pagitan ng mga node gamit ang mga pare-parehong algorithm ng hashing.
Ang paghihiwalay ng pagbabalanse at pagsusuri sa kalusugan ay maaaring humantong sa mga problema. Kung ang healthcheck node ay gagawa ng mga kahilingan sa instance, na nilalampasan ang balancer (na kasalukuyang hindi nagsisilbi sa trapiko), pagkatapos ay isang kakaibang sitwasyon ang lumitaw: ang mapagkukunan ay tila buhay, ngunit ang trapiko ay hindi makakarating dito. Niresolba namin ang problemang ito sa ganitong paraan: ginagarantiyahan naming pasimulan ang trapiko ng healthcheck sa pamamagitan ng mga balancer. Sa madaling salita, ang pamamaraan para sa paglipat ng mga packet na may trapiko mula sa mga kliyente at mula sa mga pagsusuri sa kalusugan ay hindi gaanong naiiba: sa parehong mga kaso, ang mga packet ay makakarating sa mga balancer, na maghahatid sa kanila sa mga target na mapagkukunan.
Ang pagkakaiba ay ang mga kliyente ay gumagawa ng mga kahilingan sa VIP, habang ang mga pagsusuri sa kalusugan ay gumagawa ng mga kahilingan sa bawat indibidwal na RIP. Ang isang kawili-wiling problema ay lumitaw dito: binibigyan namin ang aming mga gumagamit ng pagkakataon na lumikha ng mga mapagkukunan sa mga gray na IP network. Isipin natin na mayroong dalawang magkaibang may-ari ng cloud na itinago ang kanilang mga serbisyo sa likod ng mga balancer. Ang bawat isa sa kanila ay may mga mapagkukunan sa 10.0.0.1/24 subnet, na may parehong mga address. Kailangan mong kahit papaano ay makilala ang mga ito, at dito kailangan mong sumisid sa istraktura ng Yandex.Cloud virtual network. Mas mainam na malaman ang higit pang mga detalye sa , ito ay mahalaga para sa amin ngayon na ang network ay multi-layered at may mga tunnel na maaaring makilala sa pamamagitan ng subnet id.
Ang mga healthcheck node ay nakikipag-ugnayan sa mga balancer gamit ang tinatawag na quasi-IPv6 na mga address. Ang quasi-address ay isang IPv6 address na may IPv4 address at user subnet id na naka-embed sa loob nito. Ang trapiko ay umabot sa balancer, na kumukuha ng IPv4 resource address mula dito, pinapalitan ang IPv6 ng IPv4 at ipinapadala ang packet sa network ng user.
Ang reverse traffic ay napupunta sa parehong paraan: nakikita ng balancer na ang destinasyon ay isang gray na network mula sa mga healthchecker, at kino-convert ang IPv4 sa IPv6.
VPP - ang puso ng data plane
Ang balancer ay ipinatupad gamit ang Vector Packet Processing (VPP) na teknolohiya, isang framework mula sa Cisco para sa batch processing ng network traffic. Sa aming kaso, gumagana ang framework sa itaas ng library ng pamamahala ng device sa network ng user-space - Data Plane Development Kit (DPDK). Tinitiyak nito ang mataas na pagganap ng pagpoproseso ng packet: mas kaunting mga interrupt ang nagaganap sa kernel, at walang mga switch sa konteksto sa pagitan ng kernel space at user space.
Ang VPP ay mas nagpapatuloy at pinipiga ang higit pang pagganap sa labas ng system sa pamamagitan ng pagsasama-sama ng mga pakete sa mga batch. Ang mga nadagdag sa pagganap ay nagmumula sa agresibong paggamit ng mga cache sa mga modernong processor. Ang parehong mga cache ng data ay ginagamit (ang mga packet ay naproseso sa "mga vector", ang data ay malapit sa isa't isa) at mga cache ng pagtuturo: sa VPP, ang pagpoproseso ng packet ay sumusunod sa isang graph, ang mga node na naglalaman ng mga function na gumaganap ng parehong gawain.
Halimbawa, ang pagproseso ng mga IP packet sa VPP ay nangyayari sa sumusunod na pagkakasunud-sunod: una, ang mga packet header ay na-parse sa parsing node, at pagkatapos ay ipinadala ang mga ito sa node, na nagpapasa pa ng mga packet ayon sa mga routing table.
Medyo hardcore. Hindi kinukunsinti ng mga may-akda ng VPP ang mga kompromiso sa paggamit ng mga cache ng processor, kaya ang tipikal na code para sa pagproseso ng vector ng mga packet ay naglalaman ng manual vectorization: mayroong processing loop kung saan ang isang sitwasyon tulad ng "mayroon kaming apat na packet sa pila" ay pinoproseso, pagkatapos ay pareho para sa dalawa, pagkatapos - para sa isa. Ang mga tagubilin sa prefetch ay kadalasang ginagamit upang mag-load ng data sa mga cache upang mapabilis ang pag-access sa mga ito sa mga susunod na pag-ulit.
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);
}Kaya, nakikipag-usap ang Healthchecks sa IPv6 sa VPP, na ginagawang IPv4 ang mga ito. Ginagawa ito ng isang node sa graph, na tinatawag naming algorithmic NAT. Para sa reverse traffic (at conversion mula IPv6 hanggang IPv4) mayroong parehong algorithmic NAT node.
Ang direktang trapiko mula sa mga kliyente ng balancer ay dumadaan sa mga graph node, na nagsasagawa ng mismong pagbabalanse.
Ang unang node ay mga malagkit na session. Iniimbak nito ang hash ng para sa mga naitatag na sesyon. Kasama sa 5-tuple ang address at port ng kliyente kung saan ipinapadala ang impormasyon, ang address at mga port ng mga mapagkukunan na magagamit para sa pagtanggap ng trapiko, pati na rin ang network protocol.
Tinutulungan kami ng 5-tuple na hash na magsagawa ng mas kaunting pag-compute sa kasunod na pare-parehong hashing node, pati na rin ang mas mahusay na paghawak sa mga pagbabago sa listahan ng mapagkukunan sa likod ng balancer. Kapag dumating sa balancer ang isang packet kung saan walang session, ipapadala ito sa pare-parehong hashing node. Dito nangyayari ang pagbabalanse gamit ang pare-parehong pag-hash: pumipili kami ng mapagkukunan mula sa listahan ng mga available na "live" na mapagkukunan. Susunod, ang mga packet ay ipinadala sa NAT node, na aktwal na pumapalit sa patutunguhang address at muling kinakalkula ang mga checksum. Tulad ng nakikita mo, sinusunod namin ang mga patakaran ng VPP - gustong gusto, pagpapangkat ng mga katulad na kalkulasyon upang mapataas ang kahusayan ng mga cache ng processor.
Pare-parehong pag-hash
Bakit natin ito pinili at ano ito? Una, isaalang-alang natin ang nakaraang gawain - pagpili ng mapagkukunan mula sa listahan.
Sa hindi pantay na pag-hash, ang hash ng papasok na packet ay kinakalkula, at ang isang mapagkukunan ay pinili mula sa listahan sa pamamagitan ng natitira sa paghahati ng hash na ito sa bilang ng mga mapagkukunan. Hangga't ang listahan ay nananatiling hindi nagbabago, gumagana nang maayos ang scheme na ito: palagi kaming nagpapadala ng mga packet na may parehong 5-tuple sa parehong pagkakataon. Kung, halimbawa, ang ilang mapagkukunan ay tumigil sa pagtugon sa mga pagsusuri sa kalusugan, kung gayon para sa isang makabuluhang bahagi ng mga hash ay magbabago ang pagpipilian. Masisira ang mga koneksyon ng TCP ng kliyente: ang isang packet na dating naabot sa instance A ay maaaring magsimulang maabot ang instance B, na hindi pamilyar sa session para sa packet na ito.
Ang pare-parehong pag-hash ay nalulutas ang inilarawang problema. Ang pinakamadaling paraan upang ipaliwanag ang konseptong ito ay ito: isipin na mayroon kang singsing kung saan ka namamahagi ng mga mapagkukunan sa pamamagitan ng hash (halimbawa, sa pamamagitan ng IP:port). Ang pagpili ng mapagkukunan ay ang pag-ikot ng gulong sa isang anggulo, na tinutukoy ng hash ng packet.
Pinaliit nito ang muling pamamahagi ng trapiko kapag nagbago ang komposisyon ng mga mapagkukunan. Ang pagtanggal ng mapagkukunan ay makakaapekto lamang sa bahagi ng pare-parehong hashing ring kung saan matatagpuan ang mapagkukunan. Ang pagdaragdag ng isang mapagkukunan ay nagbabago din sa pamamahagi, ngunit mayroon kaming isang malagkit na node ng mga session, na nagbibigay-daan sa amin na huwag ilipat ang mga naitatag nang session sa mga bagong mapagkukunan.
Tiningnan namin kung ano ang nangyayari sa direktang trapiko sa pagitan ng balancer at mga mapagkukunan. Ngayon tingnan natin ang pabalik na trapiko. Ito ay sumusunod sa parehong pattern tulad ng check traffic - sa pamamagitan ng algorithmic NAT, iyon ay, sa pamamagitan ng reverse NAT 44 para sa trapiko ng kliyente at sa pamamagitan ng NAT 46 para sa healthchecks traffic. Sumusunod kami sa aming sariling pamamaraan: pinag-iisa namin ang trapiko ng mga pagsusuri sa kalusugan at trapiko ng tunay na gumagamit.
Loadbalancer-node at mga naka-assemble na bahagi
Ang komposisyon ng mga balancer at mapagkukunan sa VPP ay iniulat ng lokal na serbisyo - loadbalancer-node. Nag-subscribe ito sa stream ng mga kaganapan mula sa loadbalancer-controller at nagagawang i-plot ang pagkakaiba sa pagitan ng kasalukuyang estado ng VPP at ng target na estado na natanggap mula sa controller. Nakakuha kami ng isang closed system: ang mga kaganapan mula sa API ay dumarating sa balancer controller, na nagtatalaga ng mga gawain sa healthcheck controller upang suriin ang "liveness" ng mga mapagkukunan. Iyon, sa turn, ay nagtatalaga ng mga gawain sa healthcheck-node at pinagsama-sama ang mga resulta, pagkatapos nito ibabalik ang mga ito sa controller ng balancer. Nagsu-subscribe ang Loadbalancer-node sa mga kaganapan mula sa controller at binabago ang estado ng VPP. Sa ganitong sistema, alam lamang ng bawat serbisyo kung ano ang kinakailangan tungkol sa mga kalapit na serbisyo. Limitado ang bilang ng mga koneksyon at may kakayahan kaming magpatakbo at mag-scale ng iba't ibang mga segment nang independyente.
Anong mga isyu ang naiwasan?
Ang lahat ng aming mga serbisyo sa control plane ay nakasulat sa Go at may mahusay na scaling at mga katangian ng pagiging maaasahan. Ang Go ay may maraming open source na library para sa pagbuo ng mga distributed system. Aktibong ginagamit namin ang GRPC, lahat ng bahagi ay naglalaman ng open source na pagpapatupad ng pagtuklas ng serbisyo - sinusubaybayan ng aming mga serbisyo ang performance ng isa't isa, maaaring dynamic na baguhin ang kanilang komposisyon, at iniugnay namin ito sa pagbabalanse ng GRPC. Para sa mga sukatan, gumagamit din kami ng open source na solusyon. Sa data plane, nakakuha kami ng disenteng pagganap at isang malaking reserbang mapagkukunan: naging napakahirap na mag-assemble ng isang stand kung saan maaari kaming umasa sa pagganap ng isang VPP, sa halip na isang bakal na network card.
Problema at solusyon
Ano ang hindi gumana nang maayos? Ang Go ay may awtomatikong pamamahala ng memorya, ngunit nangyayari pa rin ang mga pagtagas ng memorya. Ang pinakamadaling paraan upang harapin ang mga ito ay ang patakbuhin ang mga goroutine at tandaan na wakasan ang mga ito. Takeaway: Panoorin ang pagkonsumo ng memory ng iyong mga programa sa Go. Kadalasan ang isang mahusay na tagapagpahiwatig ay ang bilang ng mga goroutine. May plus sa kwentong ito: sa Go madaling makakuha ng runtime data - pagkonsumo ng memorya, ang bilang ng mga tumatakbong goroutine, at marami pang ibang parameter.
Gayundin, maaaring hindi ang Go ang pinakamahusay na pagpipilian para sa mga functional na pagsubok. Ang mga ito ay medyo verbose, at ang karaniwang diskarte ng "pagpapatakbo ng lahat sa CI sa isang batch" ay hindi masyadong angkop para sa kanila. Ang katotohanan ay ang mga functional na pagsubok ay higit na nangangailangan ng mapagkukunan at nagiging sanhi ng mga totoong timeout. Dahil dito, maaaring mabigo ang mga pagsubok dahil abala ang CPU sa mga unit test. Konklusyon: Kung maaari, magsagawa ng "mabibigat" na mga pagsusulit nang hiwalay sa mga pagsubok sa yunit.
Ang arkitektura ng kaganapan sa microservice ay mas kumplikado kaysa sa isang monolith: ang pagkolekta ng mga log sa dose-dosenang iba't ibang mga makina ay hindi masyadong maginhawa. Konklusyon: kung gagawa ka ng mga microservice, isipin kaagad ang pagsubaybay.
Ang aming mga plano
Maglulunsad kami ng internal balancer, isang IPv6 balancer, magdagdag ng suporta para sa mga script ng Kubernetes, patuloy na i-shard ang aming mga serbisyo (kasalukuyang healthcheck-node at healthcheck-ctrl lang ang na-shard), magdagdag ng mga bagong healthcheck, at magpapatupad din ng matalinong pagsasama-sama ng mga tseke. Isinasaalang-alang namin ang posibilidad na gawing mas independyente ang aming mga serbisyo - upang hindi sila direktang makipag-usap sa isa't isa, ngunit gamit ang isang pila ng mensahe. Ang isang serbisyong katugma sa SQS ay lumitaw kamakailan sa Cloud .
Kamakailan, naganap ang pampublikong paglabas ng Yandex Load Balancer. Galugarin sa serbisyo, pamahalaan ang mga balancer sa paraang maginhawa para sa iyo at dagdagan ang fault tolerance ng iyong mga proyekto!
Pinagmulan: www.habr.com