Usanifu wa usawazishaji wa mzigo wa mtandao katika Yandex.Cloud

Habari, mimi ni Sergey Elantsev, ninaendeleza msawazishaji wa mzigo wa mtandao katika Yandex.Cloud. Hapo awali, niliongoza maendeleo ya usawa wa L7 kwa portal ya Yandex - wenzake wanatania kwamba bila kujali ninafanya nini, inageuka kuwa usawa. Nitawaambia wasomaji wa Habr jinsi ya kudhibiti mzigo katika jukwaa la wingu, kile tunachoona kama zana bora ya kufikia lengo hili, na jinsi tunavyosonga kuelekea kuunda zana hii.

Kwanza, hebu tuanzishe baadhi ya maneno:

• VIP (Virtual IP) - anwani ya IP ya usawa
• Seva, mazingira ya nyuma, mfano - mashine pepe inayoendesha programu
• RIP (IP halisi) - anwani ya IP ya seva
• Healthcheck - kuangalia utayari wa seva
• Eneo la Upatikanaji, AZ - miundombinu iliyotengwa katika kituo cha data
• Mkoa - umoja wa AZ tofauti

Mizani ya mizigo hutatua kazi kuu tatu: hufanya kusawazisha yenyewe, kuboresha uvumilivu wa makosa ya huduma, na kurahisisha kuongeza kwake. Uvumilivu wa hitilafu huhakikishwa kupitia usimamizi wa trafiki kiotomatiki: msawazishaji hufuatilia hali ya programu na haijumuishi matukio kutoka kwa kusawazisha ambayo hayapiti ukaguzi wa uhai. Kuongezeka kunahakikishwa kwa kusambaza sawasawa mzigo katika matukio yote, pamoja na kusasisha orodha ya matukio kwenye kuruka. Ikiwa kusawazisha sio sare ya kutosha, baadhi ya matukio yatapata mzigo unaozidi kikomo cha uwezo wao, na huduma itakuwa chini ya kuaminika.

Sawazisha mzigo mara nyingi huainishwa na safu ya itifaki kutoka kwa mfano wa OSI ambayo inaendesha. Cloud Balancer inafanya kazi katika kiwango cha TCP, ambacho kinalingana na safu ya nne, L4.

Wacha tuendelee kwenye muhtasari wa usanifu wa usawazishaji wa Wingu. Hatua kwa hatua tutaongeza kiwango cha maelezo. Tunagawanya vipengele vya usawa katika madarasa matatu. Darasa la ndege ya usanidi linawajibika kwa mwingiliano wa watumiaji na huhifadhi hali inayolengwa ya mfumo. Ndege inayodhibiti huhifadhi hali ya sasa ya mfumo na inadhibiti mifumo kutoka kwa darasa la ndege ya data, ambayo inawajibika moja kwa moja kwa kuwasilisha trafiki kutoka kwa wateja hadi kwa hali zako.

Ndege ya data

Trafiki huishia kwenye vifaa vya gharama kubwa vinavyoitwa vipanga njia vya mpaka. Ili kuongeza uvumilivu wa makosa, vifaa kadhaa vile hufanya kazi wakati huo huo katika kituo kimoja cha data. Kisha, trafiki huenda kwa wasawazishaji, ambao hutangaza anwani zozote za IP kwa AZ zote kupitia BGP kwa wateja. 

Trafiki hupitishwa kupitia ECMP - huu ni mkakati wa kuelekeza kulingana na ambayo kunaweza kuwa na njia kadhaa nzuri kwa lengo (kwa upande wetu, lengo litakuwa anwani ya IP ya mwisho) na pakiti zinaweza kutumwa pamoja na yoyote kati yao. Pia tunasaidia kazi katika maeneo kadhaa ya upatikanaji kulingana na mpango ufuatao: tunatangaza anwani katika kila eneo, trafiki huenda kwa iliyo karibu zaidi na haipiti mipaka yake. Baadaye katika chapisho tutaangalia kwa undani zaidi kile kinachotokea kwa trafiki.

Sanidi ndege

 
Sehemu muhimu ya ndege ya usanidi ni API, ambayo shughuli za kimsingi na wasawazishaji hufanywa: kuunda, kufuta, kubadilisha muundo wa matukio, kupata matokeo ya ukaguzi wa afya, nk Kwa upande mmoja, hii ni API ya REST, na kwa upande mwingine. nyingine, sisi katika Wingu mara nyingi sana tunatumia mfumo wa gRPC, kwa hivyo "tunatafsiri" REST hadi gRPC na kisha kutumia gRPC pekee. Ombi lolote husababisha kuundwa kwa mfululizo wa kazi zisizo za kawaida ambazo hutekelezwa kwenye kundi la kawaida la wafanyakazi wa Yandex.Cloud. Kazi zimeandikwa kwa namna ambayo zinaweza kusimamishwa wakati wowote na kisha kuanza tena. Hii inahakikisha scalability, kurudia na ukataji wa shughuli.

Matokeo yake, kazi kutoka kwa API itafanya ombi kwa mtawala wa huduma ya usawa, ambayo imeandikwa katika Go. Inaweza kuongeza na kuondoa mizani, kubadilisha muundo wa backends na mipangilio. 

Huduma huhifadhi hali yake katika Hifadhidata ya Yandex, hifadhidata iliyosimamiwa iliyosambazwa ambayo utaweza kutumia hivi karibuni. Katika Yandex.Cloud, kama sisi tayari aliiambia, dhana ya chakula cha mbwa inatumika: ikiwa sisi wenyewe tunatumia huduma zetu, basi wateja wetu pia watafurahi kuzitumia. Yandex Database ni mfano wa utekelezaji wa dhana hiyo. Tunahifadhi data zetu zote katika YDB, na si lazima tufikirie kuhusu kudumisha na kuongeza hifadhidata: matatizo haya yanatatuliwa kwa ajili yetu, tunatumia hifadhidata kama huduma.

Wacha turudi kwa kidhibiti cha kusawazisha. Jukumu lake ni kuhifadhi maelezo kuhusu sawazisha na kutuma kazi ya kuangalia utayari wa mashine pepe kwa kidhibiti cha ukaguzi wa afya.

Kidhibiti cha afya

Inapokea maombi ya kubadilisha sheria za hundi, inazihifadhi katika YDB, inasambaza kazi kati ya nodi za afya na kukusanya matokeo, ambayo huhifadhiwa kwenye hifadhidata na kutumwa kwa kidhibiti cha kusawazisha. Ni, kwa upande wake, hutuma ombi la kubadilisha muundo wa nguzo kwenye ndege ya data kwa nodi ya kusawazisha, ambayo nitajadili hapa chini.

Wacha tuzungumze zaidi juu ya ukaguzi wa afya. Wanaweza kugawanywa katika madarasa kadhaa. Ukaguzi una vigezo tofauti vya mafanikio. Ukaguzi wa TCP unahitaji kufanikiwa kuanzisha muunganisho ndani ya muda maalum. Ukaguzi wa HTTP unahitaji muunganisho uliofanikiwa na jibu lenye msimbo wa hali ya 200.

Pia, hundi hutofautiana katika darasa la hatua - ni kazi na passiv. Ukaguzi wa hali ya juu hufuatilia tu kile kinachotokea na trafiki bila kuchukua hatua yoyote maalum. Hii haifanyi kazi vizuri kwenye L4 kwa sababu inategemea mantiki ya itifaki za kiwango cha juu: kwenye L4 hakuna taarifa kuhusu muda ambao operesheni ilichukua au kama kukamilika kwa muunganisho kulikuwa nzuri au mbaya. Ukaguzi unaoendelea unahitaji msawazishaji kutuma maombi kwa kila mfano wa seva.

Wasawazishaji wengi wa mizigo hufanya ukaguzi wa uhai wao wenyewe. Katika Cloud, tuliamua kutenganisha sehemu hizi za mfumo ili kuongeza kasi. Mbinu hii itaturuhusu kuongeza idadi ya wasawazishaji huku tukidumisha idadi ya maombi ya ukaguzi wa afya kwa huduma. Ukaguzi hufanywa na nodi tofauti za ukaguzi wa afya, ambapo shabaha za hundi hugawanywa na kuigwa. Huwezi kufanya ukaguzi kutoka kwa seva pangishi moja, kwani inaweza kushindwa. Kisha hatutapata hali ya matukio aliyoangalia. Tunafanya ukaguzi kwa hali yoyote kutoka kwa angalau nodi tatu za ukaguzi wa afya. Tunagawanya madhumuni ya ukaguzi kati ya nodi kwa kutumia kanuni thabiti za hashing.

Kutenganisha kusawazisha na kuangalia afya kunaweza kusababisha matatizo. Ikiwa nodi ya ukaguzi wa afya itafanya maombi kwa mfano, kupitisha mizani (ambayo haitumiki kwa sasa trafiki), basi hali ya kushangaza inatokea: rasilimali inaonekana kuwa hai, lakini trafiki haitaifikia. Tunatatua tatizo hili kwa njia hii: tumehakikishiwa kuanzisha trafiki ya ukaguzi wa afya kupitia wasawazishaji. Kwa maneno mengine, mpango wa kusonga pakiti na trafiki kutoka kwa wateja na kutoka kwa ukaguzi wa afya hutofautiana kidogo: katika hali zote mbili, pakiti zitafikia usawa, ambazo zitawapeleka kwa rasilimali inayolengwa.

Tofauti ni kwamba wateja hufanya maombi kwa VIP, wakati ukaguzi wa afya hufanya maombi kwa kila RIP binafsi. Tatizo la kuvutia linatokea hapa: tunawapa watumiaji wetu fursa ya kuunda rasilimali katika mitandao ya IP ya kijivu. Wacha tufikirie kuwa kuna wamiliki wawili tofauti wa wingu ambao wameficha huduma zao nyuma ya wasawazishaji. Kila mmoja wao ana rasilimali katika subnet 10.0.0.1/24, na anwani sawa. Unahitaji kuwa na uwezo wa kutofautisha kwa namna fulani, na hapa unahitaji kupiga mbizi kwenye muundo wa mtandao wa Yandex.Cloud. Ni bora kupata maelezo zaidi ndani video kutoka kuhusu:tukio la wingu, ni muhimu kwetu sasa kwamba mtandao una tabaka nyingi na una vichuguu ambavyo vinaweza kutofautishwa na kitambulisho cha subnet.

Nodi za ukaguzi wa afya huwasiliana na visawazishaji kwa kutumia zinazoitwa anwani za nusu-IPv6. Anwani ya nusu ni anwani ya IPv6 yenye anwani ya IPv4 na kitambulisho kidogo cha mtumiaji kilichopachikwa ndani yake. Trafiki hufikia sawazisha, ambayo hutoa anwani ya rasilimali ya IPv4 kutoka kwayo, inachukua nafasi ya IPv6 na IPv4 na kutuma pakiti kwa mtandao wa mtumiaji.

Trafiki ya nyuma huenda kwa njia ile ile: msawazishaji huona kwamba marudio ni mtandao wa kijivu kutoka kwa wakaguzi wa afya, na kubadilisha IPv4 hadi IPv6.

VPP - moyo wa ndege ya data

Usawazishaji unatekelezwa kwa kutumia teknolojia ya Vector Packet Processing (VPP), mfumo kutoka kwa Cisco kwa ajili ya usindikaji wa kundi la trafiki ya mtandao. Kwa upande wetu, mfumo hufanya kazi juu ya maktaba ya usimamizi wa kifaa cha mtandao wa nafasi ya mtumiaji - Data Plane Development Kit (DPDK). Hii inahakikisha utendakazi wa hali ya juu wa uchakataji wa pakiti: vikatizo vichache zaidi hutokea kwenye kernel, na hakuna swichi za muktadha kati ya nafasi ya kernel na nafasi ya mtumiaji. 

VPP inaenda mbali zaidi na kubana utendakazi zaidi nje ya mfumo kwa kuchanganya vifurushi katika makundi. Manufaa ya utendakazi yanatokana na matumizi mabaya ya akiba kwenye vichakataji vya kisasa. Cache zote mbili za data hutumiwa (pakiti zinasindika katika "vectors", data iko karibu na kila mmoja) na cache za maagizo: katika VPP, usindikaji wa pakiti hufuata grafu, nodes ambazo zina kazi zinazofanya kazi sawa.

Kwa mfano, usindikaji wa pakiti za IP katika VPP hutokea kwa utaratibu wafuatayo: kwanza, vichwa vya pakiti vinapigwa kwenye node ya kusambaza, na kisha hutumwa kwenye node, ambayo hupeleka pakiti zaidi kulingana na meza za uelekezaji.

Mgumu kidogo. Waandishi wa VPP hawavumilii maelewano katika utumiaji wa kache za processor, kwa hivyo nambari ya kawaida ya usindikaji wa vekta ya pakiti ina vekta ya mwongozo: kuna kitanzi cha usindikaji ambacho hali kama "tuna pakiti nne kwenye foleni" inachakatwa, basi sawa kwa mbili, basi - kwa moja. Maagizo ya kuleta kabla mara nyingi hutumiwa kupakia data kwenye kache ili kuharakisha ufikiaji kwao katika marudio yanayofuata.

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);
}

Kwa hivyo, Healthchecks huzungumza juu ya IPv6 kwa VPP, ambayo inawageuza kuwa IPv4. Hii inafanywa na nodi kwenye grafu, ambayo tunaiita NAT ya algorithmic. Kwa trafiki ya nyuma (na ubadilishaji kutoka IPv6 hadi IPv4) kuna nodi sawa ya algorithmic ya NAT.

Trafiki ya moja kwa moja kutoka kwa wateja wa usawa hupitia nodes za grafu, ambazo hufanya kusawazisha yenyewe. 

Nodi ya kwanza ni vikao vya kunata. Huhifadhi hashi ya 5-tuple kwa vikao vilivyoanzishwa. 5-tuple inajumuisha anwani na bandari ya mteja ambayo habari hupitishwa, anwani na bandari za rasilimali zinazopatikana kwa kupokea trafiki, pamoja na itifaki ya mtandao. 

Heshi ya 5-tuple hutusaidia kufanya hesabu kidogo katika nodi thabiti inayofuata ya hashing, pamoja na kushughulikia bora mabadiliko ya orodha ya rasilimali nyuma ya kikisawazisha. Wakati pakiti ambayo hakuna kikao inafika kwenye sawazisha, inatumwa kwa nodi thabiti ya hashing. Hapa ndipo kusawazisha hutokea kwa kutumia hashing thabiti: tunachagua nyenzo kutoka kwenye orodha ya rasilimali zinazopatikana "moja kwa moja". Ifuatayo, pakiti hutumwa kwa nodi ya NAT, ambayo kwa kweli inachukua nafasi ya anwani lengwa na kuhesabu upya hundi. Kama unavyoona, tunafuata sheria za VPP - kama kupenda, kupanga mahesabu sawa ili kuongeza ufanisi wa cache za processor.

Hashing thabiti

Kwa nini tuliichagua na ni nini hata? Kwanza, hebu fikiria kazi ya awali - kuchagua rasilimali kutoka kwenye orodha. 

Kwa heshi isiyolingana, heshi ya pakiti inayoingia huhesabiwa, na rasilimali huchaguliwa kutoka kwenye orodha na salio la kugawanya heshi hii kwa idadi ya rasilimali. Alimradi orodha haijabadilika, mpango huu hufanya kazi vizuri: sisi hutuma pakiti zilizo na nakala 5 sawa kila wakati kwa mfano sawa. Ikiwa, kwa mfano, rasilimali fulani iliacha kujibu ukaguzi wa afya, basi kwa sehemu kubwa ya heshi chaguo litabadilika. Miunganisho ya TCP ya mteja itavunjika: pakiti ambayo ilifikiwa awali mfano A inaweza kuanza kufikia mfano B, ambao haufahamu kipindi cha pakiti hii.

Hashing thabiti hutatua tatizo lililoelezwa. Njia rahisi zaidi ya kuelezea dhana hii ni hii: fikiria kuwa una pete ambayo unasambaza rasilimali kwa hashi (kwa mfano, kwa IP: bandari). Kuchagua rasilimali ni kugeuza gurudumu kwa pembe, ambayo imedhamiriwa na hashi ya pakiti.

Hii inapunguza ugawaji upya wa trafiki wakati muundo wa rasilimali unabadilika. Kufuta rasilimali kutaathiri tu sehemu ya pete ya reli thabiti ambayo rasilimali hiyo ilipatikana. Kuongeza rasilimali pia hubadilisha usambazaji, lakini tunayo nodi ya vikao vya kunata, ambayo huturuhusu tusibadilishe vipindi vilivyoanzishwa kuwa rasilimali mpya.

Tuliangalia kile kinachotokea kwa trafiki ya moja kwa moja kati ya mizani na rasilimali. Sasa hebu tuangalie trafiki ya kurudi. Inafuata muundo sawa na trafiki ya kuangalia - kupitia NAT ya algoriti, yaani, kupitia NAT 44 ya kinyume kwa trafiki ya wateja na kupitia NAT 46 kwa trafiki ya ukaguzi wa afya. Tunafuata mpango wetu wenyewe: tunaunganisha trafiki ya ukaguzi wa afya na trafiki halisi ya watumiaji.

Loadbalancer-node na vipengele vilivyokusanyika

Muundo wa wasawazishaji na rasilimali katika VPP unaripotiwa na huduma ya ndani - loadbalancer-node. Inajiandikisha kwa mtiririko wa matukio kutoka kwa kidhibiti-kidhibiti cha mzigo na inaweza kupanga tofauti kati ya hali ya sasa ya VPP na hali inayolengwa iliyopokelewa kutoka kwa kidhibiti. Tunapata mfumo uliofungwa: matukio kutoka kwa API huja kwa kidhibiti cha kusawazisha, ambacho hukabidhi kazi kwa kidhibiti cha ukaguzi wa afya kuangalia "uhuishaji" wa rasilimali. Hiyo, kwa upande wake, inapeana kazi kwa nodi ya ukaguzi wa afya na kujumlisha matokeo, na kisha kuyarudisha kwa kidhibiti cha kusawazisha. Loadbalancer-nodi hujiandikisha kupokea matukio kutoka kwa kidhibiti na kubadilisha hali ya VPP. Katika mfumo huo, kila huduma inajua tu kile kinachohitajika kuhusu huduma za jirani. Idadi ya miunganisho ni ndogo na tuna uwezo wa kufanya kazi na kupima sehemu tofauti kwa kujitegemea.

Ni masuala gani yameepukwa?

Huduma zetu zote katika ndege ya udhibiti zimeandikwa katika Go na zina sifa nzuri za kuongeza alama na kutegemewa. Go ina maktaba nyingi huria za kujenga mifumo iliyosambazwa. Tunatumia GRPC kikamilifu, vipengee vyote vina utekelezaji wa chanzo huria wa ugunduzi wa huduma - huduma zetu hufuatilia utendaji wa kila mmoja, zinaweza kubadilisha utunzi wake kwa nguvu, na tuliunganisha hili na kusawazisha GRPC. Kwa vipimo, pia tunatumia suluhisho la chanzo huria. Katika ndege ya data, tulipata utendaji mzuri na hifadhi kubwa ya rasilimali: ikawa vigumu sana kukusanya msimamo ambao tunaweza kutegemea utendaji wa VPP, badala ya kadi ya mtandao ya chuma.

Matatizo na ufumbuzi

Nini haikufanya kazi vizuri? Go ina usimamizi wa kumbukumbu otomatiki, lakini uvujaji wa kumbukumbu bado hutokea. Njia rahisi zaidi ya kukabiliana nao ni kuendesha goroutines na kukumbuka kuwakatisha. Takeaway: Tazama matumizi ya kumbukumbu ya programu zako za Go. Mara nyingi kiashiria kizuri ni idadi ya goroutines. Kuna nyongeza katika hadithi hii: katika Go ni rahisi kupata data ya wakati wa utekelezaji - matumizi ya kumbukumbu, idadi ya goroutines zinazoendeshwa, na vigezo vingine vingi.

Pia, Go inaweza isiwe chaguo bora kwa majaribio ya utendakazi. Wao ni kitenzi kabisa, na mbinu ya kawaida ya "kuendesha kila kitu katika CI katika kundi" haifai sana kwao. Ukweli ni kwamba majaribio ya utendaji yanahitaji rasilimali zaidi na husababisha kuisha kwa muda halisi. Kwa sababu hii, majaribio yanaweza kushindwa kwa sababu CPU ina shughuli nyingi na majaribio ya kitengo. Hitimisho: Ikiwezekana, fanya majaribio "nzito" tofauti na majaribio ya kitengo. 

Usanifu wa tukio la Microservice ni ngumu zaidi kuliko monolith: kukusanya magogo kwenye kadhaa ya mashine tofauti sio rahisi sana. Hitimisho: ikiwa unafanya microservices, mara moja fikiria juu ya kufuatilia.

Mipango yetu

Tutazindua kisawazisha cha ndani, kisawazisha cha IPv6, kuongeza usaidizi kwa hati za Kubernetes, kuendelea kugawa huduma zetu (kwa sasa ni healthcheck-node na healthcheck-ctrl pekee ndizo zimegawanywa), kuongeza ukaguzi mpya wa afya, na pia kutekeleza ujumlishaji mahiri wa hundi. Tunazingatia uwezekano wa kufanya huduma zetu kuwa huru zaidi - ili ziwasiliane sio moja kwa moja, lakini kwa kutumia foleni ya ujumbe. Huduma inayolingana na SQS imeonekana hivi karibuni kwenye Cloud Foleni ya Ujumbe wa Yandex.

Hivi karibuni, kutolewa kwa umma kwa Yandex Load Balancer kulifanyika. Chunguza nyaraka kwa huduma, dhibiti wasawazishaji kwa njia inayofaa kwako na uongeze uvumilivu wa makosa ya miradi yako!

Chanzo: mapenzi.com