Hello, ako si Sergey Elantsev, nag-develop ko sa Yandex.Cloud. Kaniadto, gipangunahan nako ang pag-uswag sa L7 balancer alang sa Yandex portal - ang mga kauban nagbiaybiay nga bisan unsa pa ang akong buhaton, kini nahimo nga usa ka balanse. Sultihan ko ang mga magbabasa sa Habr kung giunsa pagdumala ang load sa usa ka platform sa panganod, kung unsa ang among nakita nga sulundon nga himan alang sa pagkab-ot niini nga katuyoan, ug kung giunsa namon ang paglihok padulong sa pagtukod niini nga himan.
Una, atong ipaila ang pipila ka mga termino:
- VIP (Virtual IP) - balanse nga IP address
- Server, backend, pananglitan - usa ka virtual nga makina nga nagpadagan sa usa ka aplikasyon
- RIP (Tinuod nga IP) - server IP address
- Healthcheck - pagsusi sa pagkaandam sa server
- Availability Zone, AZ - nahilit nga imprastraktura sa usa ka sentro sa datos
- Rehiyon - usa ka unyon sa lainlaing mga AZ
Gisulbad sa mga load balancer ang tulo ka nag-unang buluhaton: ilang gihimo ang pagbalanse mismo, gipaayo ang pagtugot sa sayup sa serbisyo, ug gipasimple ang pag-scale niini. Gisiguro ang pagtugot sa sayup pinaagi sa awtomatik nga pagdumala sa trapiko: gimonitor sa balancer ang kahimtang sa aplikasyon ug wala iapil ang mga higayon gikan sa pagbalanse nga wala makapasar sa liveness check. Gisiguro ang pag-scale pinaagi sa parehas nga pag-apod-apod sa load sa mga higayon, ingon man ang pag-update sa lista sa mga higayon sa langaw. Kung ang pagbalanse dili igo nga uniporme, ang pipila sa mga higayon makadawat usa ka load nga molapas sa ilang limitasyon sa kapasidad, ug ang serbisyo mahimong dili kaayo kasaligan.
Ang usa ka load balancer sagad giklasipikar sa protocol layer gikan sa OSI nga modelo diin kini nagdagan. Ang Cloud Balancer naglihok sa lebel sa TCP, nga katumbas sa ikaupat nga layer, L4.
Mopadayon kita sa usa ka kinatibuk-ang ideya sa arkitektura sa Cloud balancer. Hinay-hinay natong dugangan ang lebel sa detalye. Gibahin namon ang mga sangkap sa balanse sa tulo nga mga klase. Ang klase sa config plane maoy responsable sa interaksyon sa user ug gitipigan ang target nga estado sa sistema. Ang control plane nagtipig sa kasamtangan nga kahimtang sa sistema ug nagdumala sa mga sistema gikan sa data plane class, nga direktang responsable sa paghatud sa trapiko gikan sa mga kliyente ngadto sa imong mga higayon.
Data eroplano
Ang trapiko natapos sa mahal nga mga aparato nga gitawag mga border router. Aron madugangan ang pagtugot sa sayup, daghang mga aparato nga dungan nga naglihok sa usa ka sentro sa datos. Sunod, ang trapiko moadto sa mga balanse, nga nagpahibalo sa bisan unsang mga adres sa IP sa tanan nga mga AZ pinaagi sa BGP alang sa mga kliyente.
Ang trapiko gipasa sa ECMP - kini usa ka estratehiya sa pag-ruta diin adunay daghang parehas nga maayong mga ruta sa target (sa among kaso, ang target mao ang destinasyon nga IP address) ug ang mga pakete mahimong ipadala sa bisan kinsa niini. Gisuportahan usab namo ang trabaho sa daghang mga available zone sumala sa mosunod nga pamaagi: nag-advertise kami og address sa matag zone, ang trapiko moadto sa pinakaduol ug dili molapas sa mga limitasyon niini. Sa ulahi sa post atong tan-awon ang mas detalyado kung unsa ang mahitabo sa trapiko.
Pag-configure sa eroplano
Ang yawe nga bahin sa config plane mao ang API, diin ang mga batakang operasyon nga adunay mga balanse gihimo: paghimo, pagtangtang, pagbag-o sa komposisyon sa mga higayon, pagkuha sa mga resulta sa pagsusi sa kahimsog, ug uban pa. Sa usa ka bahin, kini usa ka REST API, ug sa uban pa, kami sa Cloud kanunay nga naggamit sa balangkas nga gRPC, mao nga "gihubad" namon ang REST sa gRPC ug dayon gigamit ra ang gRPC. Ang bisan unsang hangyo magdala ngadto sa paghimo sa usa ka serye sa mga asynchronous nga idempotent nga mga buluhaton nga gipatuman sa usa ka komon nga pool sa Yandex.Cloud nga mga trabahante. Ang mga buluhaton gisulat sa paagi nga kini mahimong masuspinde bisan unsang orasa ug dayon i-restart. Gisiguro niini ang scalability, repeatability ug logging sa mga operasyon.
Ingon usa ka sangputanan, ang buluhaton gikan sa API maghimo usa ka hangyo sa tigdumala sa serbisyo sa balanse, nga gisulat sa Go. Mahimo kini makadugang ug makatangtang sa mga balanse, magbag-o sa komposisyon sa mga backend ug mga setting.
Gitipigan sa serbisyo ang estado niini sa Yandex Database, usa ka gipang-apod-apod nga gidumala nga database nga mahimo nimong magamit sa dili madugay. Sa Yandex.Cloud, ingon nga kami na , ang konsepto sa pagkaon sa iro magamit: kung kita mismo ang mogamit sa atong mga serbisyo, nan ang atong mga kliyente malipay usab sa paggamit niini. Ang Yandex Database usa ka pananglitan sa pagpatuman sa ingon nga konsepto. Among gitipigan ang tanan namong datos sa YDB, ug dili na namo kinahanglang hunahunaon ang pagmentinar ug pag-scale sa database: kini nga mga problema nasulbad para kanamo, among gigamit ang database isip usa ka serbisyo.
Balikan nato ang balancer controller. Ang tahas niini mao ang pagtipig sa kasayuran bahin sa balanse ug magpadala usa ka buluhaton aron masusi ang kaandam sa virtual nga makina sa tigkontrol sa healthcheck.
Kontroler sa Healthcheck
Nakadawat kini og mga hangyo nga usbon ang mga lagda sa tseke, i-save kini sa YDB, ipang-apod-apod ang mga buluhaton taliwala sa mga node sa healtcheck ug giipon ang mga resulta, nga gitipigan sa database ug gipadala sa tigkontrol sa loadbalancer. Kini, sa baylo, nagpadala sa usa ka hangyo nga usbon ang komposisyon sa cluster sa data plane ngadto sa loadbalancer-node, nga akong hisgutan sa ubos.
Maghisgot pa ta bahin sa mga healthcheck. Mahimo silang bahinon sa daghang mga klase. Ang mga pag-audit adunay lainlain nga sukaranan sa kalampusan. Ang mga tseke sa TCP kinahanglan nga malampuson nga makatukod og koneksyon sulod sa gitakdang gidugayon sa panahon. Ang mga pagsusi sa HTTP nanginahanglan usa ka malampuson nga koneksyon ug usa ka tubag nga adunay 200 nga status code.
Usab, ang mga tseke lahi sa klase sa aksyon - kini aktibo ug pasibo. Ang mga passive checks yano nga nagmonitor kung unsa ang nahitabo sa trapiko nga walaβy gihimo nga espesyal nga aksyon. Dili kini maayo sa L4 tungod kay nagdepende kini sa lohika sa mas taas nga lebel nga mga protocol: sa L4 walaβy kasayuran kung unsa kadugay ang operasyon o kung maayo ba o dili maayo ang pagkompleto sa koneksyon. Ang aktibo nga mga pagsusi nanginahanglan sa balanse nga magpadala mga hangyo sa matag pananglitan sa server.
Kadaghanan sa mga load balancer naghimo sa ilang kaugalingon nga liveness check. Sa Cloud, nakahukom kami nga bulagon kini nga mga bahin sa sistema aron madugangan ang scalability. Kini nga pamaagi magtugot kanamo nga madugangan ang gidaghanon sa mga balanse samtang gipadayon ang gidaghanon sa mga hangyo sa healthcheck sa serbisyo. Ang mga pagsusi gihimo pinaagi sa separado nga mga node sa pagsusi sa kahimsog, diin ang mga target sa pagsusi gi-shard ug gisundog. Dili nimo mahimo ang mga pagsusi gikan sa usa ka host, tungod kay mahimo kini mapakyas. Unya dili nato makuha ang estado sa mga instances nga iyang gisusi. Naghimo kami og mga pagsusi sa bisan unsang mga higayon gikan sa labing menos tulo ka mga healthcheck node. Gibahin namo ang mga katuyoan sa mga pagsusi tali sa mga node gamit ang makanunayon nga mga algorithm sa hashing.
Ang pagbulag sa pagbalanse ug pagsusi sa kahimsog mahimong mosangpot sa mga problema. Kung ang healthcheck node mohimo og mga hangyo sa pananglitan, nga molabay sa balancer (nga wala karon nagsilbi sa trapiko), unya usa ka katingad-an nga sitwasyon ang mitungha: ang kapanguhaan daw buhi, apan ang trapiko dili makaabot niini. Gisulbad namo kini nga problema niining paagiha: gigarantiyahan kami nga magsugod sa trapiko sa healthcheck pinaagi sa mga balanse. Sa laing pagkasulti, ang laraw alang sa pagbalhin sa mga pakete nga adunay trapiko gikan sa mga kliyente ug gikan sa mga pagsusi sa kahimsog gamay nga magkalainlain: sa duha nga mga kaso, ang mga pakete makaabut sa mga balanse, nga maghatud kanila sa target nga mga kapanguhaan.
Ang kalainan mao nga ang mga kliyente naghangyo sa VIP, samtang ang mga pagsusi sa kahimsog naghangyo sa matag indibidwal nga RIP. Usa ka makapaikag nga problema ang mitungha dinhi: gihatagan namon ang among mga tiggamit og higayon sa paghimo og mga kapanguhaan sa mga gray nga IP network. Hunahunaa nga adunay duha ka lainlaing mga tag-iya sa panganod nga nagtago sa ilang mga serbisyo sa luyo sa mga balanse. Ang matag usa kanila adunay mga kapanguhaan sa 10.0.0.1/24 subnet, nga adunay parehas nga mga adres. Kinahanglan nimo nga makahimo sa usa ka paagi sa pag-ila kanila, ug dinhi kinahanglan nimo nga mag-dive sa istruktura sa Yandex.Cloud virtual network. Mas maayo nga mahibal-an ang dugang nga mga detalye sa , kini importante alang kanato karon nga ang network multi-layered ug adunay mga tunnels nga mahimong mailhan pinaagi sa subnet id.
Ang mga node sa Healthcheck nagkontak sa mga balanse gamit ang gitawag nga quasi-IPv6 nga mga adres. Ang quasi-address usa ka IPv6 address nga adunay IPv4 address ug user subnet id nga nasulod sa sulod niini. Ang trapiko nakaabot sa balancer, nga nagkuha sa IPv4 resource address gikan niini, gipulihan ang IPv6 sa IPv4 ug gipadala ang packet ngadto sa network sa user.
Ang baligtad nga trapiko moadto sa samang paagi: ang balancer nakakita nga ang destinasyon usa ka gray nga network gikan sa healthcheckers, ug nag-convert sa IPv4 ngadto sa IPv6.
VPP - ang kasingkasing sa data plane
Ang balancer gipatuman gamit ang Vector Packet Processing (VPP) nga teknolohiya, usa ka framework gikan sa Cisco alang sa batch processing sa network traffic. Sa among kaso, ang gambalay nagtrabaho sa ibabaw sa user-space network device management library - Data Plane Development Kit (DPDK). Gipaneguro niini ang taas nga pasundayag sa pagproseso sa packet: mas gamay nga mga interrupt ang mahitabo sa kernel, ug walay mga switch sa konteksto tali sa kernel space ug user space.
Ang VPP mopadayon pa ug mopilit sa mas daghang performance sa sistema pinaagi sa paghiusa sa mga pakete ngadto sa mga batch. Ang mga kadaugan sa pasundayag naggikan sa agresibo nga paggamit sa mga cache sa modernong mga processor. Ang duha ka data cache gigamit (packet giproseso sa "vectors", ang data duol sa usag usa) ug instruksiyon caches: sa VPP, packet pagproseso nagsunod sa usa ka graph, ang mga node nga adunay mga function nga naghimo sa sama nga buluhaton.
Pananglitan, ang pagproseso sa mga IP packet sa VPP mahitabo sa mosunod nga han-ay: una, ang mga packet header gi-parse sa parsing node, ug dayon kini gipadala ngadto sa node, nga nagpasa sa mga packet sa dugang pa sumala sa routing tables.
Usa ka gamay nga hardcore. Ang mga tagsulat sa VPP dili motugot sa mga pagkompromiso sa paggamit sa mga cache sa processor, mao nga ang tipikal nga code alang sa pagproseso sa usa ka vector sa mga pakete naglangkob sa manual vectorization: adunay usa ka pagproseso loop diin ang usa ka sitwasyon sama sa "kami adunay upat ka mga pakete sa pila" giproseso, unya pareho sa duha, unya - sa usa. Ang mga instruksyon sa prefetch sagad gigamit sa pag-load sa datos ngadto sa mga cache aron mapadali ang pag-access niini sa sunod nga mga pag-uli.
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);
}Busa, ang Healthchecks naghisgot sa IPv6 ngadto sa VPP, nga naghimo kanila ngadto sa IPv4. Gihimo kini sa usa ka node sa graph, nga gitawag nato nga algorithmic NAT. Alang sa reverse traffic (ug pagkakabig gikan sa IPv6 ngadto sa IPv4) adunay parehas nga algorithmic NAT node.
Ang direktang trapiko gikan sa mga kliyente sa balanse moagi sa mga graph node, nga naghimo sa pagbalanse mismo.
Ang una nga node mao ang sticky session. Gitipigan niini ang hash sa alang sa natukod nga mga sesyon. Ang 5-tuple naglakip sa adres ug pantalan sa kliyente diin ang impormasyon gipasa, ang adres ug mga pantalan sa mga kapanguhaan nga magamit alang sa pagdawat sa trapiko, ingon man ang network protocol.
Ang 5-tuple hash nagtabang kanamo sa paghimo og gamay nga pag-compute sa sunod nga makanunayon nga hashing node, ingon man usab sa mas maayo nga pagdumala sa mga pagbag-o sa listahan sa kapanguhaan luyo sa balancer. Kung ang usa ka pakete nga walaβy sesyon moabut sa balanse, kini ipadala sa makanunayon nga hashing node. Dinhi mahitabo ang pagbalanse gamit ang makanunayon nga pag-hash: nagpili kami og kahinguhaan gikan sa lista sa anaa nga "live" nga mga kapanguhaan. Sunod, ang mga packet gipadala sa NAT node, nga sa tinuud gipuli ang destinasyon nga adres ug gikalkula pag-usab ang mga checksum. Sama sa imong nakita, gisunod namon ang mga lagda sa VPP - gusto, pag-grupo sa parehas nga mga kalkulasyon aron madugangan ang kahusayan sa mga cache sa processor.
Kanunay nga pag-hash
Nganong gipili nato kini ug unsa man kini? Una, atong tagdon ang miaging buluhaton - pagpili sa usa ka kapanguhaan gikan sa listahan.
Uban sa dili managsama nga pag-hash, ang hash sa umaabot nga pakete gikalkula, ug usa ka kapanguhaan ang gipili gikan sa lista pinaagi sa nahabilin nga pagbahin niini nga hash sa gidaghanon sa mga kapanguhaan. Hangtud nga ang lista magpabilin nga wala mausab, kini nga laraw maayo: kanunay kami magpadala mga pakete nga adunay parehas nga 5-tuple sa parehas nga higayon. Kung, pananglitan, ang pipila ka kapanguhaan mihunong sa pagtubag sa mga pagsusi sa kahimsog, nan alang sa usa ka hinungdanon nga bahin sa mga hash ang kapilian mausab. Ang mga koneksyon sa TCP sa kliyente maputol: ang usa ka pakete nga naabot kaniadto nga pananglitan A mahimong magsugod sa pagkab-ot sa pananglitan B, nga dili pamilyar sa sesyon alang niini nga pakete.
Ang makanunayon nga hashing makasulbad sa gihulagway nga problema. Ang pinakasayon ββnga paagi sa pagpatin-aw niini nga konsepto mao kini: hunahunaa nga ikaw adunay usa ka singsing diin ikaw nag-apod-apod sa mga kapanguhaan pinaagi sa hash (pananglitan, pinaagi sa IP:port). Ang pagpili sa usa ka kapanguhaan mao ang pagliso sa ligid pinaagi sa usa ka anggulo, nga gitino sa hash sa pakete.
Gipamenos niini ang pag-apod-apod sa trapiko kung ang komposisyon sa mga kahinguhaan mausab. Ang pagtangtang sa usa ka kapanguhaan makaapekto lamang sa bahin sa makanunayon nga hashing ring diin nahimutang ang kapanguhaan. Ang pagdugang og kahinguhaan makausab usab sa pag-apod-apod, apan aduna kami usa ka sticky sessions node, nga nagtugot kanamo nga dili ibalhin ang natukod na nga mga sesyon ngadto sa bag-ong mga kapanguhaan.
Gitan-aw namon kung unsa ang mahitabo sa pagdirekta sa trapiko tali sa balanse ug mga kapanguhaan. Karon atong tan-awon ang pagbalik sa trapiko. Nagsunod kini sa parehas nga pattern sama sa check traffic - pinaagi sa algorithmic NAT, nga mao, pinaagi sa reverse NAT 44 para sa trapiko sa kliyente ug pinaagi sa NAT 46 para sa healthchecks nga trapiko. Nagsunod kami sa among kaugalingon nga laraw: gihiusa namon ang trapiko sa mga pagsusi sa kahimsog ug trapiko sa tinuud nga tiggamit.
Loadbalancer-node ug assembled components
Ang komposisyon sa mga balanse ug mga kapanguhaan sa VPP gitaho sa lokal nga serbisyo - loadbalancer-node. Nag-subscribe kini sa stream sa mga panghitabo gikan sa loadbalancer-controller ug makahimo sa pagplano sa kalainan tali sa kasamtangan nga estado sa VPP ug sa target nga estado nga nadawat gikan sa controller. Nakuha namo ang usa ka sirado nga sistema: ang mga panghitabo gikan sa API moabut ngadto sa balancer controller, nga nag-assign sa mga buluhaton sa healthcheck controller aron masusi ang "liveness" sa mga kapanguhaan. Kana, sa baylo, nag-assign sa mga buluhaton sa healthcheck-node ug giipon ang mga resulta, pagkahuman gibalik kini sa tigdumala sa balanse. Ang Loadbalancer-node nag-subscribe sa mga panghitabo gikan sa controller ug nagbag-o sa kahimtang sa VPP. Sa ingon nga sistema, ang matag serbisyo nahibal-an lamang kung unsa ang kinahanglan bahin sa mga silingan nga serbisyo. Limitado ang gidaghanon sa mga koneksyon ug kami adunay katakus sa pag-operate ug pagsukod sa lainlaing mga bahin nga independente.
Unsang mga isyu ang gilikayan?
Ang tanan namon nga mga serbisyo sa control plane gisulat sa Go ug adunay maayo nga scaling ug kasaligan nga mga kinaiya. Ang Go adunay daghang bukas nga gigikanan nga mga librarya alang sa pagtukod sa mga gipang-apod-apod nga sistema. Aktibo namong gigamit ang GRPC, ang tanang component adunay open source nga pagpatuman sa pagdiskubre sa serbisyo - gimonitor sa among mga serbisyo ang performance sa usag usa, mahimong dinamikong mabag-o ang ilang komposisyon, ug gisumpay namo kini sa pagbalanse sa GRPC. Para sa metrics, naggamit sab mi ug open source nga solusyon. Sa data plane, nakakuha kami desente nga pasundayag ug usa ka dako nga reserba sa kapanguhaan: nahimoβg lisud kaayo ang pag-assemble sa usa ka baruganan diin kami makasalig sa pasundayag sa usa ka VPP, kaysa usa ka kard nga puthaw nga network.
Mga Problema ug Solusyon
Unsa ang dili maayo nga nahimo? Ang Go adunay awtomatik nga pagdumala sa memorya, apan ang mga pagtulo sa panumduman mahitabo gihapon. Ang labing kadali nga paagi sa pag-atubang kanila mao ang pagpadagan sa mga goroutine ug hinumdomi nga tapuson kini. Takeaway: Tan-awa ang konsumo sa memorya sa imong mga programa sa Go. Kasagaran ang usa ka maayong timailhan mao ang gidaghanon sa mga goroutine. Adunay usa ka dugang niini nga istorya: sa Go dali nga makakuha og runtime data - konsumo sa memorya, ang gidaghanon sa mga running goroutine, ug daghan pang mga parameter.
Usab, ang Go mahimong dili ang labing kaayo nga kapilian alang sa mga pagsulay nga magamit. Medyo verbose sila, ug ang standard nga pamaagi sa "pagpadagan sa tanan sa CI sa usa ka batch" dili kaayo angay alang kanila. Ang tinuod mao nga ang mga pagsulay sa pag-andar labi nga nanginahanglan sa kapanguhaan ug hinungdan sa mga tinuud nga oras. Tungod niini, ang mga pagsulay mahimong mapakyas tungod kay ang CPU busy sa mga pagsulay sa yunit. Panapos: Kung mahimo, paghimo og "bug-at" nga mga pagsulay nga lahi sa mga pagsulay sa yunit.
Ang arkitektura sa panghitabo sa microservice mas komplikado kaysa usa ka monolith: ang pagkolekta sa mga troso sa daghang lainlaing mga makina dili kaayo kombenyente. Panapos: kung maghimo ka og mga microservice, hunahunaa dayon ang pagsubay.
Atong mga plano
Maglunsad kami og internal balancer, usa ka IPv6 balancer, magdugang og suporta alang sa mga script sa Kubernetes, magpadayon sa pag-shard sa among mga serbisyo (karon ang healthcheck-node ug healthcheck-ctrl lang ang gi-shard), magdugang og mga bag-ong healthcheck, ug mag-implementar usab sa smart aggregation sa mga tseke. Among gikonsiderar ang posibilidad sa paghimo sa among mga serbisyo nga mas independente - aron dili sila direktang makigkomunikar sa usag usa, apan gamit ang pila nga mensahe. Usa ka SQS-compatible nga serbisyo bag-o lang nagpakita sa Cloud .
Bag-ohay lang, ang pagpagawas sa publiko sa Yandex Load Balancer nahitabo. Susihon sa serbisyo, pagdumala sa mga balanse sa paagi nga kombenyente alang kanimo ug dugangi ang pagtugot sa sayup sa imong mga proyekto!
Source: www.habr.com