Salam, mən Sergey Elantsev, mən inkişaf edirəm Yandex.Cloud-da. Əvvəllər mən Yandex portalı üçün L7 balanslaşdırıcısının hazırlanmasına rəhbərlik etdim - həmkarlar zarafat edirlər ki, nə etsəm də, balanslaşdırıcı olur. Mən Habr oxucularına bulud platformasında yükü necə idarə edəcəyimizi, bu məqsədə çatmaq üçün ideal vasitə kimi gördüyümüzü və bu aləti qurmaq istiqamətində necə irəlilədiyimizi izah edəcəyəm.
Əvvəlcə bəzi terminləri təqdim edək:
- VIP (Virtual IP) - balanslaşdırıcı IP ünvanı
- Server, backend, instansiya - proqramla işləyən virtual maşın
- RIP (Real IP) - server IP ünvanı
- Healthcheck - server hazırlığının yoxlanılması
- Availability Zone, AZ - məlumat mərkəzində təcrid olunmuş infrastruktur
- Region - müxtəlif AZ-ların birliyi
Yük balanslaşdırıcıları üç əsas vəzifəni həll edir: onlar balanslaşdırmanı özü həyata keçirir, xidmətin nasazlıqlara qarşı dözümlülüyünü yaxşılaşdırır və onun miqyasını sadələşdirir. Trafikin avtomatik idarə edilməsi vasitəsilə nasazlığa dözümlülük təmin edilir: balanslaşdırıcı tətbiqin vəziyyətinə nəzarət edir və canlılıq yoxlamasından keçməyən halları balanslaşdırmadan istisna edir. Ölçmə yükü instansiyalar arasında bərabər paylamaqla, həmçinin instansiyaların siyahısını tez yeniləməklə təmin edilir. Balanslaşdırma kifayət qədər vahid deyilsə, bəzi nümunələr tutum həddini aşan bir yük alacaq və xidmət daha az etibarlı olacaq.
Yük balanslaşdırıcısı tez-tez işlədiyi OSI modelindən protokol təbəqəsi ilə təsnif edilir. Cloud Balancer dördüncü səviyyəyə, L4-ə uyğun gələn TCP səviyyəsində işləyir.
Bulud balanslaşdırıcısının arxitekturasına ümumi baxışa keçək. Biz təfərrüat səviyyəsini tədricən artıracağıq. Balanslaşdırıcı komponentləri üç sinfə ayırırıq. Konfiqurasiya təyyarəsi sinfi istifadəçinin qarşılıqlı əlaqəsinə cavabdehdir və sistemin hədəf vəziyyətini saxlayır. İdarəetmə müstəvisi sistemin cari vəziyyətini saxlayır və müştərilərdən nümunələrinizə trafikin çatdırılmasına birbaşa cavabdeh olan məlumat təyyarəsi sinfindən sistemləri idarə edir.
Məlumat müstəvisi
Trafik sərhəd marşrutlaşdırıcıları adlanan bahalı cihazlarda başa çatır. Arızaya dözümlülüyü artırmaq üçün bir məlumat mərkəzində eyni vaxtda bir neçə belə cihaz işləyir. Sonra, trafik müştərilər üçün BGP vasitəsilə bütün AZ-lara istənilən yayım IP ünvanlarını elan edən balanslaşdırıcılara gedir.
Trafik ECMP üzərindən ötürülür - bu, hədəfə bir neçə eyni dərəcədə yaxşı marşrut ola bilən bir marşrutlaşdırma strategiyasıdır (bizim vəziyyətimizdə hədəf təyinat IP ünvanı olacaq) və paketlər onlardan hər hansı biri ilə göndərilə bilər. Biz həmçinin aşağıdakı sxemə uyğun olaraq bir neçə mövcud zonada işi dəstəkləyirik: biz hər zonada bir ünvan reklam edirik, trafik ən yaxın birinə gedir və onun hüdudlarından kənara çıxmır. Sonrakı yazıda biz trafiklə nə baş verdiyini daha ətraflı nəzərdən keçirəcəyik.
Təyyarəni konfiqurasiya edin
Konfiqurasiya müstəvisinin əsas komponenti API-dir, onun vasitəsilə balanslaşdırıcılarla əsas əməliyyatlar yerinə yetirilir: nümunələrin yaradılması, silinməsi, tərkibinin dəyişdirilməsi, sağlamlıq yoxlamalarının nəticələrinin əldə edilməsi və s. Bu, bir tərəfdən REST API-dir, digər tərəfdən isə başqa, biz Buludda çox vaxt gRPC çərçivəsini istifadə edirik, ona görə də biz REST-i gRPC-yə “tərcümə edirik” və sonra yalnız gRPC-dən istifadə edirik. İstənilən sorğu Yandex.Cloud işçilərinin ümumi hovuzunda yerinə yetirilən bir sıra asinxron idempotent tapşırıqların yaradılmasına gətirib çıxarır. Tapşırıqlar elə yazılır ki, onları istənilən vaxt dayandırıb yenidən işə salmaq olar. Bu, əməliyyatların miqyasını, təkrarlanmasını və qeydini təmin edir.
Nəticədə, API-dən gələn tapşırıq Go-da yazılmış balanslaşdırıcı xidmət nəzarətçisinə sorğu verəcəkdir. O, balanslaşdırıcıları əlavə edə və silə, arxa və parametrlərin tərkibini dəyişə bilər.
Xidmət öz vəziyyətini tezliklə istifadə edə biləcəyiniz paylanmış idarə olunan verilənlər bazası olan Yandex Database-də saxlayır. Yandex.Cloud-da, bizdə olduğu kimi , it qidası konsepsiyası tətbiq edilir: əgər biz özümüz xidmətlərimizdən istifadə etsək, müştərilərimiz də onlardan məmnuniyyətlə istifadə edəcəklər. Yandex verilənlər bazası belə bir konsepsiyanın həyata keçirilməsinə bir nümunədir. Biz bütün məlumatlarımızı YDB-də saxlayırıq və verilənlər bazasını saxlamaq və miqyasını artırmaq barədə düşünmək məcburiyyətində deyilik: bu problemlər bizim üçün həll olunur, verilənlər bazasından xidmət kimi istifadə edirik.
Balanslaşdırıcı nəzarətçiyə qayıdaq. Onun vəzifəsi balanslaşdırıcı haqqında məlumatı saxlamaq və virtual maşının sağlamlıq yoxlaması nəzarətçisinə hazırlığını yoxlamaq üçün tapşırıq göndərməkdir.
Sağlamlığı yoxlayan nəzarətçi
O, yoxlama qaydalarını dəyişdirmək üçün sorğuları qəbul edir, onları YDB-də saxlayır, sağlamlıq yoxlaması qovşaqları arasında tapşırıqları paylayır və nəticələri birləşdirir, daha sonra verilənlər bazasında saxlanılır və yük balanslaşdırıcı nəzarətçiyə göndərilir. O, öz növbəsində, məlumat müstəvisində klasterin tərkibini aşağıda müzakirə edəcəyim yük balanslaşdırıcı-qovşağına dəyişdirmək üçün sorğu göndərir.
Sağlamlıq yoxlamaları haqqında daha çox danışaq. Onları bir neçə sinfə bölmək olar. Auditlərin müxtəlif müvəffəqiyyət meyarları var. TCP yoxlamaları müəyyən vaxt ərzində uğurla əlaqə qurmalıdır. HTTP yoxlamaları həm uğurlu əlaqə, həm də 200 status kodu ilə cavab tələb edir.
Həmçinin, çeklər fəaliyyət sinfində fərqlənir - onlar aktiv və passivdir. Passiv yoxlamalar heç bir xüsusi tədbir görmədən sadəcə olaraq trafiklə baş verənləri izləyir. Bu, L4-də çox yaxşı işləmir, çünki bu, daha yüksək səviyyəli protokolların məntiqindən asılıdır: L4-də əməliyyatın nə qədər çəkdiyi və ya əlaqənin tamamlanmasının yaxşı və ya pis olması barədə məlumat yoxdur. Aktiv yoxlamalar balanslaşdırıcıdan hər bir server nümunəsinə sorğu göndərməsini tələb edir.
Əksər yük balanslaşdırıcıları canlılıq yoxlamalarını özləri həyata keçirirlər. Cloud-da miqyaslılığı artırmaq üçün sistemin bu hissələrini ayırmağa qərar verdik. Bu yanaşma bizə xidmətə sağlamlıq yoxlaması sorğularının sayını saxlamaqla balanslaşdırıcıların sayını artırmağa imkan verəcək. Yoxlamalar ayrı-ayrı sağlamlıq yoxlanışı qovşaqları tərəfindən həyata keçirilir, onların arasında yoxlama hədəfləri parçalanır və təkrarlanır. Bir hostdan yoxlama apara bilməzsiniz, çünki uğursuz ola bilər. O zaman onun yoxladığı instansiyaların vəziyyətini almayacağıq. Biz ən azı üç sağlamlıq yoxlama qovşağından hər hansı bir nümunə üzərində yoxlamalar həyata keçiririk. Biz ardıcıl hashing alqoritmlərindən istifadə edərək qovşaqlar arasında yoxlamaların məqsədlərini bölüşürük.
Balanslaşdırma və sağlamlıq yoxlamasını ayırmaq problemlərə səbəb ola bilər. Sağlamlıq yoxlama qovşağı balanslaşdırıcıdan yan keçərək (hazırda trafikə xidmət etmir) instansiyaya sorğular göndərirsə, qəribə bir vəziyyət yaranır: resurs canlı görünür, lakin trafik ona çatmayacaq. Biz bu problemi belə həll edirik: balanslaşdırıcılar vasitəsilə trafikin sağlamlığını yoxlamağa başlamağa zəmanət verilir. Başqa sözlə, müştərilərdən və sağlamlıq yoxlamalarından gələn trafiklə paketlərin daşınması sxemi minimal dərəcədə fərqlənir: hər iki halda paketlər balanslaşdırıcılara çatacaq, bu da onları hədəf resurslara çatdıracaq.
Fərq ondadır ki, müştərilər VIP-ə müraciət edir, sağlamlıq yoxlamaları isə hər bir fərdi RIP-ə müraciət edir. Burada maraqlı problem yaranır: biz istifadəçilərimizə boz İP şəbəkələrində resurslar yaratmaq imkanı veririk. Təsəvvür edək ki, öz xidmətlərini balanslaşdırıcıların arxasında gizlədən iki fərqli bulud sahibi var. Onların hər biri 10.0.0.1/24 alt şəbəkəsində eyni ünvanlarla resurslara malikdir. Onları bir növ ayırd etməyi bacarmalısan və burada Yandex.Cloud virtual şəbəkəsinin strukturuna dalmaq lazımdır. Ətraflı təfərrüatları bölmədə öyrənmək daha yaxşıdır , şəbəkənin çoxqatlı olması və alt şəbəkə id-si ilə seçilə bilən tunellərə malik olması indi bizim üçün vacibdir.
Sağlamlıq yoxlaması qovşaqları kvazi-IPv6 ünvanlarından istifadə edərək balanslaşdırıcılarla əlaqə saxlayır. Kvazi-ünvan, IPv6 ünvanı və daxilində quraşdırılmış istifadəçi alt şəbəkə id-si olan bir IPv4 ünvanıdır. Trafik balanslaşdırıcıya çatır, o, ondan IPv4 resurs ünvanını çıxarır, IPv6-nı IPv4 ilə əvəz edir və paketi istifadəçinin şəbəkəsinə göndərir.
Əks trafik eyni şəkildə gedir: balanslaşdırıcı təyinatın sağlamlıq yoxlayıcılarının boz şəbəkəsi olduğunu görür və IPv4-ü IPv6-ya çevirir.
VPP - məlumat təyyarəsinin ürəyi
Balanslaşdırıcı şəbəkə trafikinin toplu işlənməsi üçün Cisco-nun çərçivəsi olan Vector Packet Processing (VPP) texnologiyasından istifadə etməklə həyata keçirilir. Bizim vəziyyətimizdə çərçivə istifadəçi-kosmik şəbəkə cihazlarının idarə edilməsi kitabxanasının - Data Plane Development Kit (DPDK) üzərində işləyir. Bu, yüksək paket emal performansını təmin edir: nüvədə daha az fasilə baş verir və ləpə sahəsi ilə istifadəçi sahəsi arasında kontekst keçidləri yoxdur.
VPP daha da irəli gedir və paketləri partiyalara birləşdirərək sistemdən daha çox performansı sıxışdırır. Performans qazanmaları müasir prosessorlarda keşlərin aqressiv istifadəsindən irəli gəlir. Hər iki məlumat önbelleği istifadə olunur (paketlər “vektorlarda” işlənir, məlumatlar bir-birinə yaxındır) və təlimat keşləri: VPP-də paketlərin işlənməsi qovşaqlarında eyni vəzifəni yerinə yetirən funksiyaları ehtiva edən bir qrafik izləyir.
Məsələn, VPP-də IP paketlərinin işlənməsi aşağıdakı ardıcıllıqla baş verir: əvvəlcə paket başlıqları təhlil qovşağında təhlil edilir, sonra isə marşrutlaşdırma cədvəllərinə uyğun olaraq paketləri daha da irəli aparan qovşağa göndərilir.
Bir az sərt. VPP müəllifləri prosessor keşlərinin istifadəsində kompromislərə dözmürlər, buna görə paketlərin vektorunun emalı üçün tipik kodda əl vektorlaşdırması var: "növbədə dörd paketimiz var" kimi bir vəziyyətin işləndiyi bir emal dövrü var, sonra iki üçün eyni, sonra - bir üçün. Əvvəlcədən gətirmə təlimatları, sonrakı təkrarlamalarda onlara girişi sürətləndirmək üçün məlumatları keşlərə yükləmək üçün tez-tez istifadə olunur.
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);
}Beləliklə, Healthchecks IPv6 üzərindən VPP ilə danışır, bu da onları IPv4-ə çevirir. Bu, alqoritmik NAT dediyimiz qrafikdəki bir qovşaq tərəfindən edilir. Əks trafik (və IPv6-dan IPv4-ə çevrilmə) üçün eyni alqoritmik NAT qovşağı mövcuddur.
Balanslaşdırıcı müştərilərdən birbaşa trafik balanslaşdırmanı özü həyata keçirən qrafik qovşaqlarından keçir.
Birinci node yapışqan seanslardır. Hash-i saxlayır qurulmuş sessiyalar üçün. 5-kartına məlumatın ötürüldüyü müştərinin ünvanı və portu, trafikin qəbulu üçün mövcud olan resursların ünvanı və portları, həmçinin şəbəkə protokolu daxildir.
5-tuple hash bizə sonrakı ardıcıl hashing node-da daha az hesablama aparmağa, həmçinin balanslaşdırıcının arxasındakı resurs siyahısı dəyişikliklərini daha yaxşı idarə etməyə kömək edir. Heç bir sessiyası olmayan paket balanslaşdırıcıya gəldikdə, o, ardıcıl hashing node-a göndərilir. Ardıcıl heşinqdən istifadə edərək balanslaşdırma burada baş verir: biz mövcud “canlı” resurslar siyahısından resurs seçirik. Daha sonra paketlər NAT node-a göndərilir ki, bu da əslində təyinat ünvanını əvəz edir və yoxlama məbləğlərini yenidən hesablayır. Gördüyünüz kimi, biz VPP qaydalarına əməl edirik - bəyənməyi sevirik, prosessor keşlərinin səmərəliliyini artırmaq üçün oxşar hesablamaları qruplaşdırırıq.
Davamlı hashing
Niyə onu seçdik və bu nədir? Birincisi, əvvəlki vəzifəni nəzərdən keçirək - siyahıdan resursun seçilməsi.
Uyğun olmayan hashing ilə, daxil olan paketin hashı hesablanır və bu hashı resursların sayına bölməklə siyahıdan resurs seçilir. Nə qədər ki, siyahı dəyişməz qalıb, bu sxem yaxşı işləyir: biz həmişə eyni 5 dəstli paketləri eyni instansiyaya göndəririk. Məsələn, bəzi resurs sağlamlıq yoxlamalarına cavab verməyi dayandırıbsa, o zaman hashlərin əhəmiyyətli bir hissəsi üçün seçim dəyişəcək. Müştərinin TCP əlaqələri pozulacaq: əvvəllər A instansiyasına çatan paket bu paket üçün sessiya ilə tanış olmayan B nümunəsinə çatmağa başlaya bilər.
Davamlı hashing təsvir olunan problemi həll edir. Bu konsepsiyanı izah etməyin ən asan yolu belədir: təsəvvür edin ki, sizdə resursları hash (məsələn, IP:port vasitəsilə) ilə payladığınız bir üzük var. Resursun seçilməsi təkəri paketin hashı ilə müəyyən edilən bucaqla çevirməkdir.
Bu, resursların tərkibi dəyişdikdə trafikin yenidən bölüşdürülməsini minimuma endirir. Resursun silinməsi yalnız resursun yerləşdiyi ardıcıl hashing halqasının hissəsinə təsir edəcək. Resursun əlavə edilməsi paylanmanı da dəyişir, lakin bizdə yapışqan sessiyalar qovşağı var ki, bu da artıq qurulmuş sessiyaları yeni resurslara keçirməməyə imkan verir.
Biz balanslaşdırıcı və resurslar arasında birbaşa trafikin nə baş verdiyinə baxdıq. İndi isə qayıdan trafikə baxaq. O, yoxlama trafiki ilə eyni nümunəni izləyir - alqoritmik NAT vasitəsilə, yəni müştəri trafiki üçün əks NAT 44 və sağlamlıq yoxlaması trafiki üçün NAT 46 vasitəsilə. Biz öz sxemimizə əməl edirik: biz sağlamlıq yoxlamaları trafikini və real istifadəçi trafikini birləşdiririk.
Loadbalancer-qovşaq və yığılmış komponentlər
VPP-də balanslaşdırıcıların və resursların tərkibini yerli xidmət - yük balansçısı-qovşağı bildirir. O, yük balanslaşdırıcı-nəzarətçisindən hadisələr axınına abunə olur və cari VPP vəziyyəti ilə nəzarətçidən alınan hədəf vəziyyət arasındakı fərqi təyin edə bilir. Biz qapalı bir sistem əldə edirik: API-dən hadisələr resursların "canlılığını" yoxlamaq üçün sağlamlıq yoxlaması nəzarətçisinə tapşırıqlar verən balanslaşdırıcı nəzarətçiyə gəlir. Bu, öz növbəsində, sağlamlıq yoxlama qovşağına tapşırıqlar verir və nəticələri birləşdirir, bundan sonra onları balanslaşdırıcı nəzarətçiyə göndərir. Loadbalancer-node nəzarətçidən hadisələrə abunə olur və VPP-nin vəziyyətini dəyişir. Belə bir sistemdə hər bir xidmət yalnız qonşu xidmətlər haqqında nə lazım olduğunu bilir. Qoşulmaların sayı məhduddur və biz müstəqil olaraq müxtəlif seqmentləri idarə etmək və miqyasını genişləndirmək imkanımız var.
Hansı məsələlərdən qaçınıldı?
İdarəetmə müstəvisindəki bütün xidmətlərimiz Go-da yazılmışdır və yaxşı miqyas və etibarlılıq xüsusiyyətlərinə malikdir. Go-da paylanmış sistemlər qurmaq üçün çoxlu açıq mənbəli kitabxanalar var. Biz GRPC-dən fəal şəkildə istifadə edirik, bütün komponentlər xidmət kəşfinin açıq mənbə tətbiqini ehtiva edir - xidmətlərimiz bir-birinin performansını izləyir, onların tərkibini dinamik şəkildə dəyişə bilər və biz bunu GRPC balanslaşdırması ilə əlaqələndirdik. Metriklər üçün açıq mənbə həllindən də istifadə edirik. Məlumat müstəvisində layiqli performans və böyük resurs ehtiyatı əldə etdik: dəmir şəbəkə kartına deyil, VPP-nin performansına etibar edə biləcəyimiz bir stend yığmaq çox çətin oldu.
Problemlər və həllər
Nə yaxşı işləmədi? Go avtomatik yaddaş idarəetməsinə malikdir, lakin yaddaş sızması hələ də baş verir. Onlarla mübarizə aparmağın ən asan yolu goroutinləri işə salmaq və onları dayandırmağı unutmayın. Paket: Go proqramlarınızın yaddaş istehlakına baxın. Tez-tez yaxşı bir göstərici qorutinlərin sayıdır. Bu hekayədə bir artı var: Go-da iş vaxtı məlumatlarını əldə etmək asandır - yaddaş istehlakı, işləyən goroutinlərin sayı və bir çox digər parametrlər.
Həmçinin, Go funksional testlər üçün ən yaxşı seçim olmaya bilər. Onlar olduqca təfərrüatlıdır və "Hər şeyi CI-də bir dəstədə işlətmək" standart yanaşması onlar üçün çox uyğun deyil. Fakt budur ki, funksional testlər daha çox resurs tələb edir və real fasilələrə səbəb olur. Bu səbəbdən, CPU vahid testləri ilə məşğul olduğu üçün testlər uğursuz ola bilər. Nəticə: Mümkünsə, vahid testlərdən ayrı olaraq "ağır" sınaqları yerinə yetirin.
Mikroservis hadisəsi arxitekturası monolitdən daha mürəkkəbdir: onlarla müxtəlif maşınlarda logların toplanması çox rahat deyil. Nəticə: mikroservislər edirsinizsə, dərhal izləmə haqqında düşünün.
Planlarımız
Biz daxili balanslaşdırıcını, IPv6 balanslaşdırıcısını işə salacağıq, Kubernetes skriptləri üçün dəstək əlavə edəcəyik, xidmətlərimizi parçalamağa davam edəcəyik (hazırda yalnız Healthcheck-node və Healthcheck-ctrl bölünür), yeni sağlamlıq yoxlamaları əlavə edəcəyik, həmçinin yoxlamaların ağıllı birləşməsini həyata keçirəcəyik. Biz xidmətlərimizi daha da müstəqil etmək imkanını nəzərdən keçiririk - belə ki, onlar bir-biri ilə birbaşa deyil, mesaj növbəsindən istifadə etsinlər. Bu yaxınlarda Buludda SQS-ə uyğun xidmət peyda oldu .
Bu yaxınlarda Yandex Load Balancer-ın ictimai buraxılışı baş tutdu. Araşdırın xidmətə, balanslaşdırıcıları sizin üçün əlverişli şəkildə idarə edin və layihələrinizin nasazlıqlara dözümlülüyünü artırın!
Mənbə: www.habr.com