Здраво, ја сам Сергеи Елантсев, ја се развијам у Иандек.Цлоуд. Раније сам водио развој балансера Л7 за портал Иандек - шале се колеге да шта год да радим, испоставља се да је баланс. Рећи ћу читаоцима Хабра како да управљају оптерећењем на платформи у облаку, шта видимо као идеално средство за постизање овог циља и како идемо ка изградњи овог алата.
Прво, хајде да уведемо неке термине:
- ВИП (Виртуелни ИП) - ИП адреса балансера
- Сервер, бацкенд, инстанца - виртуелна машина која покреће апликацију
- РИП (Реал ИП) - ИП адреса сервера
- Хеалтхцхецк - провера спремности сервера
- Зона доступности, АЗ - изолована инфраструктура у дата центру
- Регион - синдикат различитих АЗ
Балансери оптерећења решавају три главна задатка: они обављају само балансирање, побољшавају толеранцију на грешке сервиса и поједностављују његово скалирање. Толеранција грешака је обезбеђена путем аутоматског управљања саобраћајем: балансер прати стање апликације и искључује случајеве из балансирања који не прођу проверу животности. Скалирање је обезбеђено равномерном дистрибуцијом оптерећења на инстанце, као и ажурирањем листе инстанци у ходу. Ако балансирање није довољно уједначено, неке од инстанци ће добити оптерећење које премашује ограничење њиховог капацитета, а услуга ће постати мање поуздана.
Балансатор оптерећења се често класификује према слоју протокола из ОСИ модела на коме ради. Цлоуд Баланцер ради на ТЦП нивоу, који одговара четвртом слоју, Л4.
Пређимо на преглед архитектуре Цлоуд балансера. Постепено ћемо повећавати ниво детаља. Компоненте балансера делимо у три класе. Класа конфигурационе равни је одговорна за интеракцију корисника и чува циљно стање система. Контролна раван чува тренутно стање система и управља системима из класе равни података, који су директно одговорни за испоруку саобраћаја од клијената до ваших инстанци.
Раван података
Саобраћај завршава на скупим уређајима званим гранични рутери. Да би се повећала толеранција грешака, неколико таквих уређаја ради истовремено у једном дата центру. Затим, саобраћај иде до балансера, који објављују било какве ИП адресе свим АЗ преко БГП-а за клијенте.
Саобраћај се преноси преко ЕЦМП-а - ово је стратегија рутирања према којој може постојати неколико једнако добрих рута до циља (у нашем случају циљ ће бити одредишна ИП адреса) и пакети се могу слати дуж било које од њих. Такође подржавамо рад у неколико зона доступности према следећој шеми: у свакој зони оглашавамо адресу, саобраћај иде до најближе и не прелази њене границе. Касније у посту ћемо детаљније погледати шта се дешава са саобраћајем.
Конфигурациони план
Кључна компонента конфигурационе равни је АПИ, преко којег се изводе основне операције са балансерима: креирање, брисање, промена састава инстанци, добијање резултата провере здравља, итд. С једне стране, ово је РЕСТ АПИ, а са друго, ми у Цлоуд-у веома често користимо оквир гРПЦ, тако да „преводимо“ РЕСТ у гРПЦ и онда користимо само гРПЦ. Сваки захтев води ка креирању низа асинхроних идемпотентних задатака који се извршавају на заједничком скупу Иандек.Цлоуд радника. Задаци су написани на начин да се у било ком тренутку могу обуставити, а затим поново покренути. Ово обезбеђује скалабилност, поновљивост и евидентирање операција.
Као резултат тога, задатак из АПИ-ја ће упутити захтев контролору услуге балансирања, који је написан у Го. Може да додаје и уклања балансере, мења састав позадине и подешавања.
Услуга чува своје стање у Иандек Датабасе, дистрибуираној управљаној бази података коју ћете ускоро моћи да користите. У Иандек.Цлоуд, као што смо већ , примењује се концепт хране за псе: ако ми сами користимо наше услуге, онда ће их и наши клијенти радо користити. Иандек Датабасе је пример имплементације таквог концепта. Све своје податке чувамо у ИДБ-у и не морамо да размишљамо о одржавању и скалирању базе података: ови проблеми су решени за нас, користимо базу података као услугу.
Вратимо се на контролер балансера. Његов задатак је да сачува информације о балансеру и пошаље задатак да провери спремност виртуелне машине контролору здравствене провере.
Контролор здравствене провере
Он прима захтеве за промену правила провере, чува их у ИДБ, дистрибуира задатке међу хеалтцхецк чворовима и агрегира резултате, који се затим чувају у бази података и шаљу контролеру лоадбаланцера. Он, заузврат, шаље захтев за промену састава кластера у равни података чвору лоадбаланцер-а, о чему ћу говорити у наставку.
Хајде да причамо више о здравственим прегледима. Могу се поделити у неколико класа. Ревизије имају различите критеријуме успеха. ТЦП провере треба да успешно успоставе везу у одређеном временском периоду. ХТТП провере захтевају и успешну везу и одговор са статусним кодом 200.
Такође, провере се разликују по класи радње - активне су и пасивне. Пасивне провере једноставно прате шта се дешава са саобраћајем без предузимања посебних радњи. Ово не функционише баш добро на Л4 јер зависи од логике протокола вишег нивоа: на Л4 нема информација о томе колико је операција трајала или да ли је завршетак везе био добар или лош. Активне провере захтевају од балансера да пошаље захтеве свакој инстанци сервера.
Већина балансера оптерећења сама врши проверу животности. У Цлоуд-у смо одлучили да одвојимо ове делове система како бисмо повећали скалабилност. Овај приступ ће нам омогућити да повећамо број балансера уз задржавање броја захтева за здравствени преглед сервису. Провере се обављају од стране засебних чворова за проверу здравља, преко којих су циљеви провере подељени и реплицирани. Не можете вршити провере са једног хоста, јер може да не успе. Тада нећемо добити стање инстанци које је проверио. Вршимо провере на било којој инстанци са најмање три чвора за проверу здравља. Ми делимо сврхе провера између чворова користећи доследне алгоритаме хеширања.
Раздвајање балансирања и здравствене провере може довести до проблема. Ако чвор Хеалтхцхецк упућује захтеве инстанци, заобилазећи балансер (који тренутно не опслужује саобраћај), онда се јавља чудна ситуација: ресурс изгледа да је жив, али саобраћај неће стићи до њега. Овај проблем решавамо на овај начин: гарантовано ћемо покренути здравствени саобраћај преко балансера. Другим речима, шема за премештање пакета са саобраћајем од клијената и са здравствених провера разликује се минимално: у оба случаја, пакети ће стићи до балансера, који ће их испоручити циљним ресурсима.
Разлика је у томе што клијенти упућују захтеве ВИП-у, док здравствени прегледи постављају захтеве сваком појединачном РИП-у. Овде се јавља занимљив проблем: дајемо нашим корисницима могућност да креирају ресурсе у сивим ИП мрежама. Замислимо да постоје два различита власника облака који су сакрили своје услуге иза балансера. Сваки од њих има ресурсе у подмрежи 10.0.0.1/24, са истим адресама. Морате бити у могућности да их некако разликујете, а овде морате да зароните у структуру виртуелне мреже Иандек.Цлоуд. Боље је сазнати више детаља у , за нас је сада важно да је мрежа вишеслојна и да има тунеле који се могу разликовати по ИД-у подмреже.
Хеалтхцхецк чворови контактирају балансере користећи такозване квази-ИПв6 адресе. Квази-адреса је ИПв6 адреса са ИПв4 адресом и ИД-ом корисничке подмреже уграђеним у њу. Саобраћај стиже до балансера, који из њега издваја ИПв4 адресу ресурса, замењује ИПв6 са ИПв4 и шаље пакет у мрежу корисника.
Обрнути саобраћај иде на исти начин: балансер види да је одредиште сива мрежа од здравствених проверача и конвертује ИПв4 у ИПв6.
ВПП - срце равни података
Балансер је имплементиран коришћењем технологије Вецтор Пацкет Процессинг (ВПП), оквира компаније Цисцо за групну обраду мрежног саобраћаја. У нашем случају, оквир ради на врху библиотеке за управљање мрежним уређајима у корисничком простору - Дата Плане Девелопмент Кит (ДПДК). Ово обезбеђује високе перформансе обраде пакета: много мање прекида се дешава у језгру и нема промене контекста између простора кернела и корисничког простора.
ВПП иде још даље и истискује још више перформанси из система комбиновањем пакета у групе. Пораст перформанси долази од агресивне употребе кеш меморије на модерним процесорима. Користе се обе кеш меморије података (пакети се обрађују у „векторима“, подаци су близу један другом) и кеш инструкција: у ВПП-у, обрада пакета прати граф, чији чворови садрже функције које обављају исти задатак.
На пример, обрада ИП пакета у ВПП-у се одвија по следећем редоследу: прво се заглавља пакета рашчлањују у чвору за рашчлањивање, а затим се шаљу чвору, који даље прослеђује пакете према табелама рутирања.
Мало хардкора. Аутори ВПП-а не толеришу компромисе у коришћењу процесорских кеша, па типичан код за обраду вектора пакета садржи ручну векторизацију: постоји петља обраде у којој се обрађује ситуација попут „имамо четири пакета у реду“, па исто за двоје, па - за једног. Инструкције претходног преузимања се често користе за учитавање података у кеш меморије како би им се убрзао приступ у наредним итерацијама.
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);
}Дакле, Хеалтхцхецкс разговарају преко ИПв6 са ВПП-ом, што их претвара у ИПв4. То ради чвор у графу, који називамо алгоритамским НАТ. За обрнути саобраћај (и конверзију са ИПв6 у ИПв4) постоји исти алгоритамски НАТ чвор.
Директан саобраћај од клијената балансера иде кроз чворове графа, који обављају само балансирање.
Први чвор су лепљиве сесије. Чува хеш од за установљене седнице. 5-торка укључује адресу и порт клијента са којег се преносе информације, адресу и портове ресурса доступних за пријем саобраћаја, као и мрежни протокол.
Хеш од 5 точака нам помаже да извршимо мање израчунавања у накнадном конзистентном хеш чвору, као и да боље управљамо променама листе ресурса иза балансера. Када пакет за који не постоји сесија стигне у балансер, он се шаље конзистентном хеш чвору. Овде долази до балансирања коришћењем доследног хеширања: бирамо ресурс са листе доступних „живих“ ресурса. Затим се пакети шаљу у НАТ чвор, који заправо замењује одредишну адресу и поново израчунава контролне суме. Као што видите, ми следимо правила ВПП-а - волимо да лајкујемо, групишемо сличне прорачуне да бисмо повећали ефикасност кеша процесора.
Конзистентно хеширање
Зашто смо га изабрали и шта је то уопште? Прво, размотримо претходни задатак - одабир ресурса са листе.
Код неконзистентног хеширања израчунава се хеш долазног пакета, а ресурс се бира са листе остатком дељења овог хеша са бројем ресурса. Све док листа остаје непромењена, ова шема добро функционише: увек шаљемо пакете са истим 5-торком у исту инстанцу. Ако, на пример, неки ресурс престане да одговара на здравствене провере, онда ће се избор значајног дела хешова променити. ТЦП везе клијента ће бити прекинуте: пакет који је претходно стигао до инстанце А може почети да стиже до инстанце Б, која није упозната са сесијом за овај пакет.
Доследно хеширање решава описани проблем. Најлакши начин да се објасни овај концепт је следећи: замислите да имате прстен на који дистрибуирате ресурсе хешом (на пример, преко ИП:порта). Избор ресурса је окретање точка за угао, који је одређен хешом пакета.
Ово минимизира прерасподелу саобраћаја када се састав ресурса промени. Брисање ресурса ће утицати само на део доследног хеш прстена у коме се налази ресурс. Додавање ресурса такође мења дистрибуцију, али имамо чвор за лепљиве сесије, који нам омогућава да не пребацимо већ успостављене сесије на нове ресурсе.
Погледали смо шта се дешава са директним саобраћајем између балансера и ресурса. Погледајмо сада повратни саобраћај. Прати исти образац као и саобраћај за проверу – преко алгоритамског НАТ-а, односно преко обрнутог НАТ-а 44 за клијентски саобраћај и преко НАТ-а 46 за саобраћај провере здравља. Придржавамо се сопствене шеме: обједињујемо саобраћај здравствених провера и стварни кориснички саобраћај.
Лоадбаланцер-чвор и састављене компоненте
Састав балансера и ресурса у ВПП-у извештава локална услуга - лоадбаланцер-чвор. Он се претплаћује на ток догађаја из контролера за балансирање оптерећења и може да исцрта разлику између тренутног ВПП стања и циљног стања примљеног од контролера. Добијамо затворени систем: догађаји из АПИ-ја долазе до контролора балансирања, који додељује задатке контролору здравствене провере да провери „живост“ ресурса. То, заузврат, додељује задатке чвору Хеалтхцхецк-а и агрегира резултате, након чега их шаље назад у контролер балансирања. Лоадбаланцер-чвор се претплаћује на догађаје из контролера и мења стање ВПП-а. У таквом систему, свака служба зна само оно што је неопходно о суседним услугама. Број конекција је ограничен и имамо могућност самосталног рада и скалирања различитих сегмената.
Која су питања избегнута?
Све наше услуге у контролној равни су написане на Го и имају добре карактеристике скалирања и поузданости. Го има много библиотека отвореног кода за изградњу дистрибуираних система. Активно користимо ГРПЦ, све компоненте садрже имплементацију откривања услуга отвореног кода - наше услуге прате међусобне перформансе, могу динамички да мењају свој састав, а ми смо то повезали са ГРПЦ балансирањем. За метрику такође користимо решење отвореног кода. У нивоу података, добили смо пристојне перформансе и велику резерву ресурса: показало се да је веома тешко саставити постоље на које бисмо могли да се ослонимо на перформансе ВПП-а, а не на гвоздену мрежну картицу.
Проблеми и решења
Шта није функционисало тако добро? Го има аутоматско управљање меморијом, али цурење меморије се и даље дешава. Најлакши начин да се носите са њима је да покренете горутине и запамтите да их прекинете. За понети: Пратите потрошњу меморије ваших Го програма. Често је добар показатељ број горутина. У овој причи постоји плус: у Го-у је лако добити податке о времену извршавања - потрошњу меморије, број покренутих горутина и многе друге параметре.
Такође, Го можда није најбољи избор за функционалне тестове. Они су прилично опсежни, а стандардни приступ „покретања свега у ЦИ у пакету“ није баш прикладан за њих. Чињеница је да су функционални тестови захтевнији за ресурсе и да изазивају реалне тајм-ауте. Због тога, тестови могу бити неуспешни јер је ЦПУ заузет тестовима јединица. Закључак: Ако је могуће, извршите „тешке“ тестове одвојено од јединичних тестова.
Архитектура догађаја микросервиса је сложенија од монолита: прикупљање дневника на десетинама различитих машина није баш згодно. Закључак: ако направите микросервисе, одмах размислите о праћењу.
Наши планови
Покренућемо интерни балансер, ИПв6 балансер, додаћемо подршку за Кубернетес скрипте, наставити да делимо наше услуге (тренутно су подељени само хеалтхцхецк-ноде и хеалтхцхецк-цтрл), додаћемо нове здравствене провере, а такође ћемо применити паметно агрегирање провера. Разматрамо могућност да наше услуге учинимо још независнијим – тако да не комуницирају директно једни са другима, већ користећи ред порука. У Цлоуд-у се недавно појавила услуга компатибилна са СКС-ом .
Недавно је дошло до јавног објављивања Иандек Лоад Баланцер-а. Истражите сервису, управљајте балансерима на начин који вам одговара и повећајте толеранцију на грешке својих пројеката!
Извор: ввв.хабр.цом