🥇Yandex. Cloud'i koormuse tasakaalustaja arhitektuur

Tere, mina olen Sergei Jelantsev, arendan võrgutasakaalu jaoturit Yandex.Cloudis. Varem juhin ma Yandexi portaali L7-balansseerija arendust — kolleegid naljatavad, et mida iganes ma teen, tuleb tasakaalustaja välja. Räägin Habr'i lugejatele, kuidas hallata koormust pilveplatvormil, milline on meie ideaalne vahend selle saavutamiseks ja kuidas liigume selle tööriista loomise suunas.

Käime esmalt läbi mõned terminid:

VIP (Virtuaalne IP) — tasakaalustaja IP-aadress
Server, taust, instants — virtuaalne masin, kus töötab rakendus
RIP (Reaalne IP) — serveri IP-aadress
Healthcheck — serveri valmisoleku kontroll
Saadavaloleku tsoon, Availability Zone, AZ — isoleeritud infrastruktuur andmekeskuses
Regioon — erinevate AZ-de kogum

Koormustasakaalustajad lahendavad kolm põhitegevust: nad teostavad tasakaalu ning parandavad teenuse tõrkekindlust ja lihtsustavad selle skaleerimist. Tõrkekindlus saavutatakse automaatse liikluse juhtimise kaudu: tasakaalustaja jälgib rakenduse olekut ja välistab tasakaalus hoidmisest instantsid, mis ei läbinud elujõudluse kontrolli. Skaleerimine saavutatakse koormuse ühtlasy jaotamise kaudu instantside vahel ning instantside nimekirja värskendamisega reaalajas. Kui tasakaalustus ei ole piisavalt ühtlane, saavad mõned instantsid koormuse, mis ületab nende taluvuspiirid, ja teenus muutub vähem usaldusväärseks.

Koormustasakaalustajat klassifitseeritakse sageli OSI mudeli protokolli taseme järgi, millega ta töötab. Pilve tasakaalustaja töötab TCP tasemel, mis vastab neljandale tasemele, L4.

Liigume ülevaate juurde pilve tasakaalustaja arhitektuurist. Tõstame järk-järgult detailide taset. Jagame tasakaalustaja komponente kolme klassi. Klass config plane vastutab kasutajaga suhtlemise ning süsteemi sihtoleku salvestamise eest. Control plane salvestab süsteemi tegeliku oleku ja haldab data plane klassi süsteeme, mis vastutavad liikluse edastamise eest klientidelt teie instantsidele.

Data plane

Liiklus jõuab kallitele seadmetele, mida nimetatakse piirrouteriteks. Tõhususe suurendamiseks töötab ühes andmekeskuses samaaegselt mitu sellist seadet. Edasi jõuab liiklus koormuse tasakaalustajatesse, mis reklaamivad klientidele anycast IP-aadressi kõigis AZ-des BGP kaudu.

Liiklus edastatakse ECMP kaudu — see on marsruutimisstrateegia, mille kohaselt võivad sihtpunkti (meie puhul siht-IP-aadress) suunata mitmed võrdselt head marsruuti ning pakette saab edastada mistahes neist. Samuti toetame mitme kättesaadavuse tsooni tööd järgmisel skeemil: reklaamime aadressi igas tsoonis, liiklus jõuab lähimasse ja ei välju sealt enam. Hiljem postituses vaatame lähemalt, mis juhtub liiklusega.

Config plane

Config plane'i peamine komponent on API, mille kaudu teostatakse põhitegevused koormuse tasakaalustajatega: loomine, kustutamine, instantside koostisosade muutmine, tervisekontrollide tulemuste saamine jne. Ühest küljest on see REST API, aga teisest küljest kasutame Mees Cloudis sageli gRPC raamistikku, seega "tõlgime" REST-i gRPC-ks ning edaspidi kasutame ainult gRPC-d. Iga päring toob kaasa seeria asünkroonseid idempotente ülesandeid, mis täidetakse Yandex Cloudi ühises töötajate basseinis. Ülesanded on kirjutatud nii, et need võivad igal ajal peatuda ja hiljem uuesti käivituda. See tagab operatsioonide skaleeritavuse, korduvuse ja logimise.

Lõpuks teeb API ülesanne päringu koormuse tasakaalustajate teenuse kontrollijale, mis on kirjutatud Go-s. See võib lisada ja kustutada koormuse tasakaalustajaid, muuta tagaplaanide koosseisu ja seadeid.

Teenuse olek salvestatakse Yandex Database'i — jaotatud hallatav andmebaas, millega saate varsti ise tutvuda. Yandex Cloudis, nagu juba ütlesime, rääkinud, kehtib dog foodi kontseptsioon: kui me ise kasutame oma teenuseid, siis kasutavad ka meie kliendid neid hea meelega. Yandex Database on selle kontseptsiooni elluviimise näide. Salvestame YDB-s kõik oma andmed ja meil ei pea olema muret andmebaasi hooldamise ja skaleerimise üle: need probleemid on meie eest lahendatud, kasutame andmebaasi kui teenust.

Naasume tasakaalu kontrolleri juurde. Tema ülesanne on säilitada tasakaalu teavet, edastada kontrolliülesande virtuaalmasina valmiduse kohta tervisekontrolli kontrollerile.

Tervisekontrolli kontroller

See saab päringuid kontrollimisreeglite muutmiseks, salvestab need YDB-sse, jagab ülesanded tervisekontrolli sõlmedele ning kogub tulemused, mis seejärel salvestatakse andmebaasi ja edastatakse tasakaalu kontrollerile. Viimane saadab omakorda päringu klastrikoosseisu muutmiseks andmeplaadi tasakaalu sõlmele, millest räägin allpool.

Räägime lähemalt tervisekontrollidest. Need saab jagada mitmeks klassiks. Kontrollide edukuse kriteeriumid on erinevad. TCP-kontrollid peavad edukalt ühendust looma kindla aja jooksul. HTTP-kontrollid nõuavad nii edukat ühendust kui ka vastust staatuskoodiga 200.

Kontrollid erinevad ka tegevusklasside poolest — need võivad olla aktiivsed ja passiivsed. Passiivsed kontrollid jälgivad lihtsalt, mis toimub liikluses, ega tee erilisi toiminguid. See ei tööta hästi L4 tasemel, kuna sõltub kõrgema taseme protokollide loogikast: L4-l ei ole teavet selle kohta, kui kaua operatsioon kestis ja kas ühenduse lõpetamine oli hea või halb. Aktiivsed kontrollid nõuavad, et tasakaalustaja saadaks päringud iga serveri instantsi kohta.

Enamik koormuse tasakaalustajaid teostab "elu" kontrollid ise. Meie Clouds oleme otsustanud jagada need süsteemi osad skaleeritavuse suurendamiseks. See lähenemine võimaldab meil suurendada tasakaalustajate arvu, säilitades samal ajal tervisekontrolli päringute arvu teenusele. Kontrollid teostatakse eraldi tervisekontrolli sõlmedel, kuhu on jaotatud ja replitseeritud kontrollimise sihid. Ühel hostil ei saa kontrolle teha, kuna see võib ebaõnnestuda. Siis ei saa me infot selle kohta, millised instantsid on kontrollitud. Teeme kontrollid igast instantsist vähemalt kolmest tervisekontrolli sõlmest. Kontrollimise sihid jagame sõlmede vahel, kasutades konsistentsse hashimise algoritme.

Tasakaalu ja tervisekontrolli eraldamine võib põhjustada probleeme. Kui tervisekontrolli sõlm teeb päringuid instantsile, mööda tasakaalustajat (mis hetkel ei töötle liiklust), siis tekib kummaline olukord: ressurss näib olevat elus, kuid liiklus sinna ei pääse. Me lahendame selle probleemi järgmiselt: suuname tervisekontrolli liikluse kindlalt läbi tasakaalustajate. Teisisõnu, klientide ja tervisekontrollide liikluse pakettide edastamise skeem erineb minimaalselt: mõlemal juhul jõuavad paketid tasakaalustajatesse, mis toimetavad need sihtressursside juurde.

Erinevus on selles, et kliendid teevad päringud VIP-ile, samas kui tervisekontrollid pöörduvad iga eraldi RIP-i poole. Siin tekib huvitav probleem: meie kasutajatele anname võimaluse luua ressursse hallides IP-võrkudes. Kujutame ette, et on kaks erinevat pilveomanikku, kes on varjanud oma teenuseid tasakaalustajate taha. Igaühel neist on ressursid alamvõrgus 10.0.0.1/24, millel on samad aadressid. Tuleb osata neid kuidagi eristada, ja siin tuleb süveneda Yandex.Cloudi virtuaalvõrgu struktuuri. Täiendavaid üksikasju on parem teada saada ürituse video kaudu about:cloud, meile on praegu oluline, et võrk on mitmekihiline ning sisaldab tunnelite eristamiseks alamsubneti id-sid.

Tervisekontrolli sõlmed pöörduvad tasakaalustajate poole nn pool-IPv6-aadresside kaudu. Poolaadress on IPv6-aadress, mille sees on peidetud IPv4-aadress ja kasutaja alamsubneti id. Liiklus jõuab tasakaalustajani, kes väljavõtab sellest ressursi IPv4-aadressi, asendab IPv6 IPv4-ga ja saadab paketi kasutaja võrgusse.

Tagasi liiklus kulgeb samamoodi: tasakaalustaja näeb, et sihtkoht on tervisekontrollijate hall võrk, ja muudab IPv4 IPv6-ks.

VPP — andmeplaadi süda

Tasakaalustaja on rakendatud Vector Packet Processing (VPP) tehnoloogia abil — Cisco raamistik, mis on mõeldud võrgu liikluse pakettide töötlemiseks. Meie juhul töötab raamistik üle kasutaja ruumi võrgu seadmete haldamise raamatukogu — Data Plane Development Kit (DPDK). See tagab pakettide töötlemise kõrge jõudluse: tuumas toimub palju vähem katkestusi, puuduvad konteksti vahetused tuuma ja kasutaja ruumi vahel.

VPP läheb veel kaugemale ja pigistab süsteemist veel rohkem jõudlust, ühendades pakette partiitideks. Jõudluse tõus toimub agressiivse kasutamise tõttu kaasaegsete protsessorite vahemälus. Kasutatavad on nii andmevahemälu (pakette töödeldakse "vektoritega", andmed on üksteisele lähedal) kui ka käskude vahemälu: VPP-s pakettide töötlemine järgneb graafile, mille sõlmedes asuvad funktsioonid, mis täidavad ühte ülesannet.

Näiteks IP-pakettide töötlemine VPP-s toimub sellises järjekorras: esmalt toimub sõlmes analüüs pakettide pealkirjadest, seejärel saadetakse need sõlme, mis edastab paketid edasi marsruudi tabelite kohaselt.

Veidi hardcore. VPP autorid ei luba protsessori vahemälu kasutuses kompromisse, seega tüüpiline kood pakettide vektorite töötlemiseks sisaldab käsitsi vektoreerimist: on töötlemise tsükkel, milles käsitletakse olukorda "meil on neli paketti järjekorras", seejärel sama ka kahe jaoks, ja seejärel ühele. Kasutatakse sageli prefetch-käske, mis laadivad andmed vahemäludesse, et kiirendada neile järgmistes iteratsioonides juurde pääsemist.

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)
    {
        // töötle mitu paketti korraga
        u32 next0 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        u32 next1 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        // ...
        /* Eelprefetch järgmise iteratsiooni jaoks. */
        {
            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);
        }
        // tegelikult töötle andmeid
        /* kinnita spekulatiivsed järjekorrastamised, võib-olla lülita praegune järgmine raami * /
        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)
    {
        // töötle pakette ükshaaval
    }

    // töödeldi partii
    vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}

Nii et Healthcheckid teevad IPv6 kaudu VPP-le päringuid, mis muudab need IPv4-ks. Sellega tegeleb graafi sõlm, mida me nimetame algoritmiliseks NAT-iks. Tagasitee liikluse (ja IPv6-st IPv4-ks konverteerimise) jaoks on olemas sama algoritmiline NAT-sõlm.

Otsene liiklus klientidelt tasakaalustaja läbib graafi sõlmi, mis teostavad otsest tasakaalustamist.

Esimene sõlm – sticky sessions. Selles hoitakse hash-i. 5-tuple paigaldatud seansside jaoks. 5-tuple sisaldab kliendi aadressi ja porti, kust teave edastatakse, ressursi aadressi ja porte, mis on saadaval liikluse vastuvõtmiseks, ning võrgu protokolli.

5-tuple'i hash aitab meil järgmises konsistentse hashimise sõlmes vähem arvutusi teha ning paremini hallata ressursside nimekirja muutumist koormuse tasakaalustaja taga. Kui koormuse tasakaalustajale tuleb pakett, mille jaoks pole seanssi, saadetakse see konsistentse hashimise sõlme. Siin toimub tasakaalustus konsistentse hashimise abil: valime ressursi saadaval olevate "elavate" ressursside loendist. Seejärel saadetakse paketid NAT sõlme, mis teeb tegeliku sihtaadressi asendamise ja kontrollsumma ümberarvutamise. Nagu näete, järgime VPP reegleid — sarnane sarnasega, grupeerime sarnased arvutused, et suurendada protsessori vahemälu efektiivsust.

Konsistentne hashimine

Miks me valisime just selle ja mis see üldse on? Alustame varasema ülesande kaalumisest — ressursi valimine loendist.

Ebaühtlases hashimises arvutatakse sissetuleva paketi hash ja ressurssi valitakse loendist selle hash'i jagemise jää järgi ressursside arvuga. Niikaua kui loend jääb muutumatuks, töötab see skeem hästi: me saadame alati samade 5-tuple'idega paketid sama instantsi juurde. Kui aga mõni ressurss enam healthcheck'idele vastata ei suuda, siis muutub suure osa hash'ide valik. Kliendi TCP-ühendused katkeb: pakett, mis varem läks instants A-le, võib hakata minema instantsi B-le, mis ei tunne selle paketi seanssi.

Konsistentne hashimine lahendab kirjeldatud probleemi. Kõige lihtsam on seda kontseptsiooni selgitada järgmiselt: kujutage ette, et teil on ring, millele jaotate ressursid hash'i (näiteks IP:port) järgi. Ressursi valimine on ratta pööramine nurga all, mis määratakse paketi hash'i järgi.

Nii minimeeritakse liikluse ümberjaotamine, kui ressursside koosseis muutub. Ressursi eemaldamine mõjutab ainult seda osa konsistentse hashimise ringist, kus see ressurss asus. Ressursi lisamine muudab samuti jaotust, kuid meil on olemas sticky sessions sõlm, mis võimaldab juba loodud seanssid viia uutele ressurssidele.

Me oleme vaadanud, mis juhtub otse liiklusega tasakaalustaja ja ressursside vahel. Nüüd vaatame tagasiliiklust. See järgib sama skeemi nagu kontrollide liiklus — läbi algoritmilise NAT, st tagas NAT 44 kliendiliikluse jaoks ja NAT 46 healthcheckide liikluse jaoks. Me järgime oma skeemi: ühtlustame healthcheckide liikluse ja tõelise kasutajate liikluse.

Loadbalancer-node ja komponendid kogumina

Loadbalancer-node edastab teavet tasakaalustajate ja ressursside koosseisu VPP-s. See tellib sündmuste vooge loadbalancer-controllerilt, oskab ehitada hetke VPP oleku ja sihtoleku vahe, mis saadakse kontrollerilt. Saame suletud süsteemi: API-s sündmused jõuavad tasakaalustaja kontrollerisse, mis määrab healthcheck-kontrollerile ülesandeid ressursside „elujõu“ kontrollimiseks. See omakorda määrab ülesanded healthcheck-node'ile ja koondab tulemused, edastades need tagasi tasakaalustajate kontrollerile. Loadbalancer-node tellib sündmusi kontrollerilt ja muudab VPP olekut. Sellises süsteemis teab iga teenus ainult vajalikku naabrite teenustest. Seoste arv on piiratud ja meil on võimalus iseseisvalt hallata ja skaleerida erinevaid segmente.

Milliseid küsimusi õnnestus vältida

Kõik meie teenused control plane-s on kirjutatud Go-s ja neil on head skaleeritavuse ja usaldusväärsuse omadused. Go-s on palju avatud lähtekoodiga raamatukogusid jaotatud süsteemide ehitamiseks. Me kasutame aktiivselt GRPC-t, kõik komponendid sisaldavad avatud lähtekoodiga teenuste avastamise teostust — meie teenused jälgivad üksteise töövõimet, saavad dünaamiliselt oma koosseisu muuta ning oleme selle sidunud GRPC tasakaalustamisega. Meetmete jaoks kasutame samuti avatud lähtekoodiga lahendust. Andmeplaanis saavutasime korraliku jõudluse ja suure ressursi reservi: oli väga keeruline kokku panna seista, mille puhul võiksime jõudlusesse kalduda VPP ja mitte riistvaralisse võrgukaardisse.

Probleemid ja lahendused

Mis läks halvasti? Go-s on mälu haldamine automaatne, kuid mälu leke võib siiski esineda. Lihtsaim viis nendega toime tulla on käivitada gorutiinid ja mitte unustada neid lõpetada. Järeldus: jälgige Go-programmide mälutarbimist. Sageli on hea indikaator gorutiinide arv. Selle looga on ka pluss: Go-s on lihtne saada andmeid runtime'i kohta — mälu tarbimise, käivitatud gorutiinide arvu ja paljude muude parameetrite kohta.

Lisaks, Go ei pruugi olla parim valik funktsionaalsete testide jaoks. Need on üsna mahukad ning standardne lähenemine „käivitada kõik CI-s korraga” ei sobi neile just hästi. Asi on selles, et funktsionaalsed testid on ressursinõudlikumad ja need võivad tõeliselt aeguda. Seetõttu võivad testid ebaõnnestuda, kuna CPU on hõivatud ühiktestidega. Järeldus: proovige eraldada „raskemad” testid ühiktestidest.

Mikroteenuste sündmustepõhine arhitektuur on keerulisem kui monoliit: logide grepimine kümnetelt erinevatelt masinatelt pole just mugav. Järeldus: kui teete mikroteenuseid, mõelge kohe jälgimise peale.

Meie plaanid

Käivitame sise-balanseerija, IPv6-balanseerija, lisame Kubernetes'i skriptide toe, jätkame oma teenuste sharding'it (praegu on sharditud ainult healthcheck-node ja healthcheck-ctrl), lisame uusi healthcheck-e ning rakendame nutikat kontrollide koondamist. Uurime võimalust teha meie teenused veel sõltumatumaks — et nad ei suhtleks omavahel otse, vaid sõnumijärjekorra kaudu. Jaanuaris ilmus pilves SQS-i ühilduv teenus. Yandex Message Queue.

Hiljuti toimus Yandex Load Balancer'i avalik väljaanne. Uurige lähemalt dokumentatsioon teenusele, hallake balanseerijaid endale sobival viisil ja suurendage oma projektide taluvust katkestuste suhtes!

Allikas: habr.com