Један облак - ОС на нивоу центра података у Одноклассники

Алоха, људи! Моје име је Олег Анастасјев, радим у Одноклассники у тиму Платформе. И поред мене, у Одноклассники ради много хардвера. Имамо четири дата центра са око 500 рекова са више од 8 хиљада сервера. У одређеном тренутку смо схватили да ће нам увођење новог система управљања омогућити ефикасније учитавање опреме, олакшати управљање приступом, аутоматизовати (ре)дистрибуцију рачунарских ресурса, убрзати покретање нових услуга и убрзати одговоре. до несрећа великих размера.

Шта је из тога произашло?

Поред мене и гомиле хардвера, ту су и људи који раде са овим хардвером: инжењери који се налазе директно у дата центрима; мрежари који постављају мрежни софтвер; администратори, или СРЕ, који обезбеђују отпорност инфраструктуре; и развојни тимови, сваки од њих је одговоран за део функција портала. Софтвер који креирају ради отприлике овако:

Захтеви корисника се примају и на фронтовима главног портала ввв.ок.ру, и на другим, на пример на фронтовима музичког АПИ-ја. За обраду пословне логике позивају сервер апликација, који приликом обраде захтева позива потребне специјализоване микросервисе – оне-грапх (граф друштвених веза), усер-цацхе (кеш корисничких профила) итд.

Сваки од ових сервиса је распоређен на много машина, а свака од њих има одговорне програмере одговорне за функционисање модула, њихов рад и технолошки развој. Сви ови сервиси раде на хардверским серверима, а до недавно смо покретали тачно један задатак по серверу, односно био је специјализован за одређени задатак.

Зашто је то? Овај приступ је имао неколико предности:

• Растерећено масовно управљање. Рецимо да задатак захтева неке библиотеке, нека подешавања. Затим је сервер додељен тачно једној одређеној групи, описана је политика цфенгине за ову групу (или је већ описана), а ова конфигурација се централно и аутоматски примењује на све сервере у овој групи.
• Поједностављено дијагностика. Рецимо да погледате повећано оптерећење централног процесора и схватите да ово оптерећење може да генерише само задатак који се изводи на овом хардверском процесору. Потрага за окривљеним се врло брзо завршава.
• Поједностављено надгледање. Ако нешто није у реду са сервером, монитор то пријављује, а ви тачно знате ко је крив.

Сервису који се састоји од неколико реплика додељује се неколико сервера - по један за сваки. Тада се рачунарски ресурс за услугу додељује врло једноставно: број сервера које услуга има, максимална количина ресурса коју може да потроши. „Лако“ овде не значи да је лако за коришћење, већ у смислу да се алокација ресурса врши ручно.

Овај приступ нам је такође омогућио специјализоване конфигурације гвожђа за задатак који се изводи на овом серверу. Ако задатак складишти велике количине података, онда користимо 4У сервер са шасијом са 38 дискова. Ако је задатак чисто рачунски, онда можемо купити јефтинији 1У сервер. Ово је рачунарски ефикасно. Између осталог, овај приступ нам омогућава да користимо четири пута мање машина са оптерећењем упоредивим са једном пријатељском друштвеном мрежом.

Таква ефикасност у коришћењу рачунарских ресурса требало би да обезбеди и економску ефикасност, ако се полази од претпоставке да су најскупљи сервери. Дуго времена је хардвер био најскупљи, а ми смо уложили много труда да смањимо цену хардвера, осмишљавајући алгоритме толеранције грешака како бисмо смањили захтеве за поузданост хардвера. И данас смо дошли до фазе у којој је цена сервера престала да буде одлучујућа. Ако не узмете у обзир најновије егзотике, онда специфична конфигурација сервера у сталку није битна. Сада имамо још један проблем - цену простора који сервер заузима у дата центру, односно простора у рек-у.

Схвативши да је то случај, одлучили смо да израчунамо колико ефикасно користимо полице.
Узели смо цену најмоћнијег сервера од економски оправданих, израчунали колико таквих сервера можемо да поставимо у рекове, колико задатака на њима извршавамо по старом моделу „један сервер = један задатак“ и колико таквих сервера задаци могу користити опрему. Бројали су и сузе лили. Испоставило се да је наша ефикасност у коришћењу регала око 11%. Закључак је очигледан: треба повећати ефикасност коришћења дата центара. Чини се да је решење очигледно: потребно је да покренете неколико задатака на једном серверу одједном. Али ту почињу потешкоће.

Масовна конфигурација постаје драматично компликованија – сада је немогуће доделити било коју групу серверу. На крају крајева, сада се на једном серверу може покренути неколико задатака различитих команди. Поред тога, конфигурација може бити конфликтна за различите апликације. Дијагноза такође постаје компликованија: ако видите повећану потрошњу процесора или диска на серверу, не знате који задатак изазива проблеме.

Али главна ствар је да не постоји изолација између задатака који се извршавају на истој машини. Ево, на пример, графика просечног времена одзива серверског задатка пре и након што је на истом серверу покренута друга рачунарска апликација, ни на који начин у вези са првом – време одговора главног задатка се значајно повећало.

Очигледно, задатке морате да покрећете или у контејнерима или у виртуелним машинама. Пошто се скоро сви наши задаци извршавају под једним ОС (Линук) или су прилагођени за њега, не морамо да подржавамо много различитих оперативних система. Сходно томе, виртуелизација није потребна; због додатних трошкова, биће мање ефикасна од контејнеризације.

Као имплементација контејнера за покретање задатака директно на серверима, Доцкер је добар кандидат: слике система датотека добро решавају проблеме са конфликтним конфигурацијама. Чињеница да слике могу бити састављене од неколико слојева нам омогућава да значајно смањимо количину података потребних за њихово постављање на инфраструктуру, раздвајајући заједничке делове у засебне основне слојеве. Тада ће се основни (и најобимнији) слојеви прилично брзо кеширати у целој инфраструктури, а да би се испоручило много различитих типова апликација и верзија, биће потребно пренети само мале слојеве.

Поред тога, готови регистар и означавање слика у Доцкер-у нам дају готове примитиве за верзионисање и испоруку кода у продукцију.

Доцкер, као и свака друга слична технологија, пружа нам одређени ниво изолације контејнера из кутије. На пример, изолација меморије – сваком контејнеру је дато ограничење употребе машинске меморије, преко које се неће трошити. Такође можете изоловати контејнере на основу употребе ЦПУ-а. Нама, међутим, стандардна изолација није била довољна. Али више о томе у наставку.

Директно покретање контејнера на серверима је само део проблема. Други део се односи на хостовање контејнера на серверима. Морате разумети који контејнер се може поставити на који сервер. Ово није тако лак задатак, јер контејнере треба поставити на сервере што је гушће могуће без смањења њихове брзине. Такво постављање такође може бити тешко са тачке гледишта толеранције грешака. Често желимо да поставимо реплике исте услуге у различите полице или чак у различите просторије центра података, тако да ако сталак или соба покваре, не изгубимо одмах све реплике сервиса.

Ручна дистрибуција контејнера није опција када имате 8 хиљада сервера и 8-16 хиљада контејнера.

Поред тога, желели смо да програмерима дамо већу независност у расподели ресурса како би сами могли да хостују своје услуге у продукцији, без помоћи администратора. У исто време, желели смо да задржимо контролу како нека ситна услуга не би потрошила све ресурсе наших дата центара.

Очигледно, потребан нам је контролни слој који би то урадио аутоматски.

Тако смо дошли до једноставне и разумљиве слике коју обожавају све архитекте: три квадрата.

оне-цлоуд мастерс је кластер за превазилажење грешке одговоран за оркестрацију облака. Програмер шаље манифест мастеру, који садржи све информације неопходне за хостовање услуге. На основу тога, господар даје команде одабраним минионима (машинама дизајнираним за покретање контејнера). Послужници имају нашег агента, који прима команду, издаје њене команде Доцкер-у, а Доцкер конфигурише линукс језгро да покрене одговарајући контејнер. Поред извршавања команди, агент континуирано извештава мастера о променама у стању како минион машине тако и контејнера који на њој раде.

Распределение ресурса

Погледајмо сада проблем сложеније алокације ресурса за многе слуге.

Рачунарски ресурс у једном облаку је:

• Количина снаге процесора коју троши одређени задатак.
• Количина меморије доступне задатку.
• Мрежни саобраћај. Сваки од мињона има специфичан мрежни интерфејс са ограниченим пропусним опсегом, тако да је немогуће дистрибуирати задатке без узимања у обзир количине података које преносе преко мреже.
• Дискови. Поред тога, очигледно, простору за ове задатке додељујемо и тип диска: ХДД или ССД. Дискови могу послужити коначан број захтева у секунди - ИОПС. Стога, за задатке који генеришу више ИОПС-а него што један диск може да обради, такође додељујемо „вретена“ – то јест, диск уређаје који морају бити искључиво резервисани за задатак.

Затим за неки сервис, на пример за кориснички кеш, можемо снимити потрошене ресурсе на овај начин: 400 процесорских језгара, 2,5 ТБ меморије, 50 Гбит/с саобраћаја у оба смера, 6 ТБ ХДД простора који се налази на 100 вретена. Или у познатијем облику као што је овај:

alloc:
    cpu: 400
    mem: 2500
    lan_in: 50g
    lan_out: 50g
    hdd:100x6T

Ресурси услуге корисничког кеша троше само део свих расположивих ресурса у производној инфраструктури. Због тога желим да се уверим да одједном, због грешке оператера или не, кориснички кеш не троши више ресурса него што му је додељено. Односно, морамо ограничити ресурсе. Али за шта бисмо могли везати квоту?

Вратимо се нашем веома поједностављеном дијаграму интеракције компоненти и прецртамо га са више детаља - овако:

Оно што упада у очи:

• Веб фронтенд и музика користе изоловане кластере истог сервера апликација.
• Можемо разликовати логичке слојеве којима ови кластери припадају: фронтови, кеш меморије, складиште података и слој управљања.
• Фронтенд је хетероген, састоји се од различитих функционалних подсистема.
• Кешови такође могу бити расути по подсистему чије податке кеширају.

Хајде да поново нацртамо слику:

Бах! Да, видимо хијерархију! То значи да можете да дистрибуирате ресурсе у већим деловима: доделите одговорног програмера чвору ове хијерархије који одговара функционалном подсистему (као „музика“ на слици) и приложите квоту истом нивоу хијерархије. Ова хијерархија нам такође омогућава да флексибилније организујемо услуге ради лакшег управљања. На пример, цео веб, пошто се ради о веома великој групи сервера, делимо на неколико мањих група, приказаних на слици као група1, група2.

Уклањањем додатних линија, можемо написати сваки чвор наше слике у равнијем облику: гроуп1.веб.фронт, апи.мусиц.фронт, усер-цацхе.цацхе.

Тако долазимо до концепта „хијерархијског реда”. Има име попут "гроуп1.веб.фронт". Њему је додељена квота за ресурсе и корисничка права. Даћемо особи из ДевОпс-а права да пошаље услугу у ред, и такав запослени може да покрене нешто у реду, а особа из ОпсДев-а ће имати администраторска права, и сада може да управља редом, да тамо додељује људе, дајте овим људима права, итд. Услуге које се покрећу у овом реду ће се покретати унутар квоте реда. Ако рачунарска квота реда није довољна за извршавање свих услуга одједном, оне ће се извршавати узастопно, формирајући сам ред.

Хајде да детаљније погледамо услуге. Услуга има потпуно квалификовано име, које увек укључује име реда. Тада ће предња веб услуга имати име ок-веб.гроуп1.веб.фронт. И биће позвана услуга сервера апликација којој приступа ок-апп.гроуп1.веб.фронт. Сваки сервис има манифест, који наводи све потребне информације за постављање на одређене машине: колико ресурса овај задатак троши, која му је конфигурација потребна, колико реплика треба да има, својства за руковање кваровима ове услуге. А након што се сервис постави директно на машине, појављују се његове инстанце. Они су такође именовани недвосмислено - као број инстанце и име услуге: 1.ок-веб.гроуп1.веб.фронт, 2.ок-веб.гроуп1.веб.фронт, …

Ово је веома згодно: гледајући само назив контејнера који се покреће, одмах можемо сазнати много.

Сада погледајмо ближе шта ове инстанце заправо обављају: задатке.

Часови изолације задатака

Сви задаци у ОК (и, вероватно, свуда) могу се поделити у групе:

• Задаци са кратким кашњењем - прод. За такве задатке и услуге веома је важно кашњење одговора (латенција), колико брзо ће систем обрадити сваки од захтева. Примери задатака: веб фронтови, кеш меморије, сервери апликација, ОЛТП складиште итд.
• Рачунски проблеми - серија. Овде брзина обраде сваког конкретног захтева није битна. За њих је важно колико ће прорачуна обавити овај задатак у одређеном (дугом) временском периоду (пропусност). То ће бити било који задаци МапРедуце-а, Хадооп-а, машинског учења, статистике.
• Позадински задаци - неактивни. За такве задатке ни кашњење ни пропусност нису од велике важности. Ово укључује различите тестове, миграције, поновна израчунавања и конверзију података из једног формата у други. С једне стране, они су слични прорачунатима, с друге стране, није нам битно колико брзо се завршавају.

Хајде да видимо како такви задаци троше ресурсе, на пример, централни процесор.

Задаци са кратким одлагањем. Такав задатак ће имати образац потрошње процесора сличан овом:

Прима се захтев од корисника на обраду, задатак почиње да користи сва доступна ЦПУ језгра, обрађује га, враћа одговор, чека следећи захтев и зауставља се. Стигао је следећи захтев – опет смо изабрали све што је било, израчунали и чекамо следећи.

Да бисмо гарантовали минимално кашњење за такав задатак, морамо узети максималне ресурсе које он троши и резервисати потребан број језгара на миниону (машини која ће извршити задатак). Тада ће формула резервације за наш проблем бити следећа:

alloc: cpu = 4 (max)

а ако имамо минион машину са 16 језгара, онда се на њу могу поставити тачно четири таква задатка. Посебно напомињемо да је просечна потрошња процесора оваквих задатака често веома ниска – што је очигледно, пошто значајан део времена задатак чека на захтев и не ради ништа.

Рачунски задаци. Њихов образац ће бити мало другачији:

Просечна потрошња ЦПУ ресурса за такве задатке је прилично висока. Често желимо да се рачунски задатак заврши у одређеном временском року, тако да морамо да резервишемо минимални број процесора који му је потребан тако да се цео прорачун заврши у прихватљивом времену. Његова формула за резервацију ће изгледати овако:

alloc: cpu = [1,*)

„Молим вас, ставите га на миниона где има бар једно слободно језгро, а онда ће онолико колико их има, прогутаће све.

Овде је ефикасност употребе већ много боља него на задацима са кратким закашњењем. Али добитак ће бити много већи ако комбинујете обе врсте задатака на једној минион машини и дистрибуирате њене ресурсе у покрету. Када задатак са кратким кашњењем захтева процесор, он га одмах прима, а када ресурси више нису потребни, они се пребацују у рачунски задатак, односно отприлике овако:

Али како то учинити?

Прво, погледајмо прод и његову алокацију: цпу = 4. Морамо да резервишемо четири језгра. У покретању Доцкер-а то се може урадити на два начина:

• Користећи опцију --cpuset=1-4, тј. доделити четири специфична језгра на машини задатку.
• Употреба --cpuquota=400_000 --cpuperiod=100_000, доделите квоту за процесорско време, односно назначите да сваких 100 мс реалног времена задатак не троши више од 400 мс процесорског времена. Добија се иста четири језгра.

Али која од ових метода је прикладна?

цпусет изгледа прилично атрактивно. Задатак има четири наменска језгра, што значи да ће кеш процесора радити што је могуће ефикасније. Ово такође има и лошу страну: морали бисмо да преузмемо задатак дистрибуције прорачуна преко неоптерећених језгара машине уместо ОС, а то је прилично нетривијалан задатак, посебно ако покушамо да поставимо групне задатке на такав машина. Тестови су показали да опција са квотом овде више одговара: на овај начин оперативни систем има више слободе у избору језгра за обављање задатка у тренутном тренутку и време процесора се ефикасније распоређује.

Хајде да схватимо како направити резервације у Доцкер-у на основу минималног броја језгара. Квота за пакетне задатке више није примењива, јер нема потребе за ограничавањем максимума, довољно је само гарантовати минимум. И овде се опција добро уклапа docker run --cpushares.

Сложили смо се да ако серија захтева гаранцију за најмање једно језгро, онда назначимо --cpushares=1024, а ако постоје најмање два језгра, онда указујемо --cpushares=2048. Део процесора ни на који начин не омета дистрибуцију процесорског времена све док га има довољно. Дакле, ако прод тренутно не користи сва своја четири језгра, ништа не ограничава пакетне задатке и они могу да користе додатно време процесора. Али у ситуацији када постоји недостатак процесора, ако је прод потрошио сва четири језгра и достигао своју квоту, преостало процесорско време ће бити подељено пропорционално цпусхарес-у, односно у ситуацији са три слободна језгра, једно ће бити дати задатку са 1024 цпусхарес-а, а преостала два ће бити дата задатку са 2048 цпусхарес-а.

Али коришћење квота и акција није довољно. Морамо да се уверимо да задатак са кратким кашњењем добије приоритет у односу на пакетни задатак када додељује време процесора. Без таквог приоритета, пакетни задатак ће заузети сво време процесора у тренутку када је потребан производу. Не постоје опције за одређивање приоритета контејнера у покретању Доцкер-а, али политике распореда Линук ЦПУ-а добро долазе. О њима можете прочитати детаљно овде, а у оквиру овог чланка ћемо их укратко проћи:

• СЦХЕД_ОТХЕР
  Подразумевано, сви нормални кориснички процеси на Линук машини примају.
• СЦХЕД_БАТЦХ
  Дизајниран за процесе који захтевају велике количине ресурса. Када се задатак поставља на процесор, уводи се такозвана казна активације: мања је вероватноћа да ће такав задатак добити ресурсе процесора ако га тренутно користи задатак са СЦХЕД_ОТХЕР
• СЦХЕД_ИДЛЕ
  Позадински процес са веома ниским приоритетом, чак нижим од лепог -19. Користимо нашу библиотеку отвореног кода оне-нио, да бисте поставили потребну политику при покретању контејнера позивом

one.nio.os.Proc.sched_setscheduler( pid, Proc.SCHED_IDLE )

Али чак и ако не програмирате у Јави, иста ствар се може урадити помоћу команде цхрт:

chrt -i 0 $pid

Хајде да сумирамо све наше нивое изолације у једну табелу ради јасноће:

Класа изолације
Аллоц пример
Опције покретања Доцкер-а
сцхед_сетсцхедулер цхрт*

Прод
процесор = 4
--cpuquota=400000 --cpuperiod=100000
СЦХЕД_ОТХЕР

Серија
Цпу = [1, *)
--cpushares=1024
СЦХЕД_БАТЦХ

Идле
Цпу= [2, *)
--cpushares=2048
СЦХЕД_ИДЛЕ

*Ако радите цхрт из унутрашњости контејнера, можда ће вам требати могућност сис_нице, јер Доцкер подразумевано уклања ову могућност приликом покретања контејнера.

Али задаци троше не само процесор, већ и саобраћај, што утиче на кашњење мрежног задатка чак и више од нетачне алокације ресурса процесора. Стога, природно желимо да добијемо потпуно исту слику о саобраћају. То јест, када прод задатак пошаље неке пакете у мрежу, ми ограничавамо максималну брзину (формула аллоц: лан=[*,500мбпс) ), са којим прод то може да уради. А за серију гарантујемо само минималну пропусност, али не ограничавамо максималну (формула аллоц: лан=[10Мбпс,*) ) У овом случају, прод саобраћај треба да добије приоритет над задацима серије.
Овде Доцкер нема никакве примитиве које можемо да користимо. Али долази нам у помоћ Линук контрола саобраћаја. Уз помоћ дисциплине успели смо да постигнемо жељени резултат Хијерархијска кривуља поштених услуга. Уз његову помоћ разликујемо две класе саобраћаја: прод високог приоритета и батцх/идле ниског приоритета. Као резултат, конфигурација за одлазни саобраћај је следећа:

овде 1:0 је „коренски кдисц“ хсфц дисциплине; 1:1 - хсфц подређена класа са укупним ограничењем пропусног опсега од 8 Гбит/с, испод које су смештене подређене класе свих контејнера; 1:2 - хсфц подређена класа је заједничка за све пакетне и неактивне задатке са „динамичким“ ограничењем, о чему се говори у наставку. Преостале хсфц подређене класе су наменске класе за тренутно покренуте прод контејнере са ограничењима која одговарају њиховим манифестима - 450 и 400 Мбит/с. Свакој хсфц класи је додељен кдисц куеуе фк или фк_цодел, у зависности од верзије Линук кернела, да би се избегао губитак пакета током рафала саобраћаја.

Типично, тц дисциплине служе за давање приоритета само одлазном саобраћају. Али желимо да дамо приоритет и долазном саобраћају – на крају крајева, неки скупни задатак може лако да изабере цео долазни канал, примајући, на пример, велику серију улазних података за мапирање&редуце. За ово користимо модул ифб, који креира ифбКс виртуелни интерфејс за сваки мрежни интерфејс и преусмерава долазни саобраћај са интерфејса на одлазни саобраћај на ифбКс-у. Даље, за ифбКс, све исте дисциплине раде на контроли одлазног саобраћаја, за који ће хсфц конфигурација бити веома слична:

Током експеримената смо открили да хсфц показује најбоље резултате када је класа неприоритетног скупног/празног саобраћаја 1:2 ограничена на минион машинама само на одређену слободну траку. У супротном, неприоритетни саобраћај има превише утицаја на кашњење прод задатака. минионд одређује тренутну количину слободног пропусног опсега сваке секунде, мерећи просечну потрошњу саобраћаја свих производних задатака датог миниона и одузимањем од пропусног опсега мрежног интерфејса са малом маргином, тј.

Опсези се дефинишу независно за долазни и одлазни саобраћај. А према новим вредностима, минионд реконфигурише ограничење класе неприоритета 1:2.

Тако смо имплементирали све три класе изолације: прод, батцх и идле. Ове класе у великој мери утичу на карактеристике перформанси задатака. Стога смо одлучили да овај атрибут поставимо на врх хијерархије, тако да када погледамо назив хијерархијског реда, одмах буде јасно о чему се ради:

Сви наши пријатељи web и музика фронтови се затим постављају у хијерархију под прод. На пример, под батцх, поставимо услугу музички каталог, који периодично саставља каталог нумера из скупа мп3 датотека отпремљених у Одноклассники. Пример услуге у стању мировања би био музички трансформатор, који нормализује ниво јачине музике.

Када су додатни редови поново уклоњени, можемо да напишемо имена наших услуга равније додавањем класе изолације задатака на крај пуног назива услуге: веб.фронт.прод, цаталог.мусиц.батцх, трансформатор.мусиц.идле.

А сада, гледајући назив услуге, разумемо не само коју функцију обавља, већ и њену класу изолације, што значи њену критичност итд.

Све је супер, али има једна горка истина. Немогуће је потпуно изоловати задатке који се извршавају на једној машини.

Шта смо успели да постигнемо: ако се серија интензивно троши само ЦПУ ресурси, затим уграђени Линук ЦПУ планер ради свој посао веома добро, и практично нема утицаја на прод задатак. Али ако овај скупни задатак почне активно да ради са меморијом, тада се већ појављује међусобни утицај. Ово се дешава зато што се прод задатак „испере“ из меморијских кеша процесора – као резултат тога, промашаји кеша се повећавају, а процесор спорије обрађује прод задатак. Такав скупни задатак може повећати кашњење нашег типичног прод контејнера за 10%.

Изоловање саобраћаја је још теже због чињенице да модерне мрежне картице имају интерни ред пакета. Ако пакет из пакетног задатка стигне тамо први, онда ће он бити први који ће се пренети преко кабла и ништа се не може учинити поводом тога.

Поред тога, до сада смо успели да решимо само проблем давања приоритета ТЦП саобраћају: хсфц приступ не ради за УДП. Чак иу случају ТЦП саобраћаја, ако пакетни задатак генерише много саобраћаја, ово такође даје око 10% повећање кашњења прод задатка.

толеранција грешака

Један од циљева при развоју једног облака био је побољшање толеранције грешака Одноклассники. Стога бих следеће желео да детаљније размотрим могуће сценарије кварова и несрећа. Почнимо са једноставним сценаријем - квар контејнера.

Сам контејнер може пропасти на неколико начина. Ово може бити нека врста експеримента, грешке или грешке у манифесту, због чега прод задатак почиње да троши више ресурса него што је назначено у манифесту. Имали смо случај: програмер је имплементирао један сложен алгоритам, прерадио га много пута, превише размишљао и постао толико збуњен да је на крају проблем отишао у врло нетривијалну петљу. А пошто прод задатак има већи приоритет од свих осталих на истим минионима, почео је да троши све расположиве ресурсе процесора. У овој ситуацији, изолација, односно квота ЦПУ времена, спасила је дан. Ако је задатку додељена квота, задатак неће трошити више. Стога, пакетни и други прод задаци који су радили на истој машини нису ништа приметили.

Други могући проблем је пад контејнера. И овде нас спасавају политике поновног покретања, сви их знају, сам Доцкер ради одличан посао. Скоро сви задаци производа имају политику увек рестарт. Понекад користимо он_фаилуре за групне задатке или за отклањање грешака у контејнерима производа.

Шта можете да урадите ако је цео минион недоступан?

Очигледно, покрените контејнер на другој машини. Интересантан део овде је шта се дешава са ИП адресом(ама) додељеним контејнеру.

Контејнерима можемо доделити исте ИП адресе као и минион машинама на којима ови контејнери раде. Затим, када се контејнер покрене на другој машини, његова ИП адреса се мења и сви клијенти морају да схвате да се контејнер померио и сада треба да оду на другу адресу, што захтева посебну услугу откривања услуге.

Сервице Дисцовери је згодан. На тржишту постоји много решења различитог степена толеранције грешака за организовање сервисног регистра. Често таква решења имплементирају логику балансирања оптерећења, складиште додатну конфигурацију у облику КВ складишта итд.
Међутим, желели бисмо да избегнемо потребу за увођењем посебног регистра, јер би то значило увођење критичног система који користе сви сервиси у производњи. То значи да је ово потенцијална тачка неуспеха и да морате да изаберете или развијете решење отпорно на грешке, које је очигледно веома тешко, дуготрајно и скупо.

И још један велики недостатак: да би наша стара инфраструктура радила са новом, морали бисмо да препишемо апсолутно све задатке да бисмо користили неку врсту система за откривање услуга. Има ПУНО посла, а на неким местима је готово немогуће када су у питању уређаји ниског нивоа који раде на нивоу језгра ОС-а или директно са хардвером. Имплементација ове функционалности коришћењем утврђених образаца решења, као нпр бочна колица би на неким местима значило додатно оптерећење, на другим - компликацију рада и додатне сценарије отказа. Нисмо хтели да компликујемо ствари, па смо одлучили да коришћење Сервице Дисцовери-а учинимо опционим.

У једном облаку, ИП прати контејнер, односно свака инстанца задатка има своју ИП адресу. Ова адреса је „статична“: додељује се свакој инстанци када се услуга први пут пошаље у облак. Ако је услуга имала различит број инстанци током свог живота, онда ће јој на крају бити додељено онолико ИП адреса колико је било максимално инстанци.

Након тога, ове адресе се не мењају: додељују се једном и настављају да постоје током читавог животног века услуге у производњи. ИП адресе прате контејнере широм мреже. Ако се контејнер пребаци на другог миниона, адреса ће га пратити.

Дакле, мапирање имена услуге у њену листу ИП адреса се веома ретко мења. Ако поново погледате називе сервисних инстанци које смо споменули на почетку чланка (1.ок-веб.гроуп1.веб.фронт.прод, 2.ок-веб.гроуп1.веб.фронт.прод, …), приметићемо да личе на ФКДН-ове који се користе у ДНС-у. Тако је, да бисмо мапирали имена инстанци услуга на њихове ИП адресе, користимо ДНС протокол. Штавише, овај ДНС враћа све резервисане ИП адресе свих контејнера - и покренутих и заустављених (рецимо да се користе три реплике, а ми имамо пет адреса резервисаних тамо - свих пет ће бити враћено). Клијенти ће, након што добију ову информацију, покушати да успоставе везу са свих пет реплика - и тако одреде оне које раде. Ова опција за одређивање доступности је много поузданија; не укључује ни ДНС ни откривање услуга, што значи да нема тешких проблема за решавање у обезбеђивању релевантности информација и толеранције грешака ових система. Штавише, у критичним сервисима од којих зависи рад целог портала, уопште не можемо да користимо ДНС, већ једноставно уносимо ИП адресе у конфигурацију.

Имплементација таквог ИП преноса иза контејнера може бити нетривијална - а ми ћемо погледати како то функционише на следећем примеру:

Рецимо да господар једног облака даје команду миниону М1 за покретање 1.ок-веб.гроуп1.веб.фронт.прод са адресом 1.1.1.1. Ради на миниону БИРД, који ову адресу рекламира посебним серверима рефлектор руте. Ови други имају БГП сесију са мрежним хардвером, у коју се преводи рута адресе 1.1.1.1 на М1. М1 усмерава пакете унутар контејнера користећи Линук. Постоје три сервера рефлектора рута, пошто је ово веома критичан део инфраструктуре једног облака - без њих мрежа у једном облаку неће функционисати. Постављамо их у различите полице, ако је могуће, смештене у различитим просторијама дата центра, како бисмо смањили вероватноћу да сва три покваре у исто време.

Претпоставимо сада да је веза између мастера једног облака и М1 миниона изгубљена. Мастер једног облака ће сада деловати под претпоставком да је М1 потпуно заказао. Односно, то ће дати команду М2 миниону за лансирање веб.гроуп1.веб.фронт.прод са истом адресом 1.1.1.1. Сада имамо две конфликтне руте на мрежи за 1.1.1.1: на М1 и на М2. Да бисмо решили такве конфликте, користимо Мулти Екит Дисцриминатор, који је наведен у БГП најави. Ово је број који показује тежину оглашене руте. Међу конфликтним рутама биће изабрана рута са нижом МЕД вредношћу. Мастер једног облака подржава МЕД као саставни део ИП адреса контејнера. По први пут се адреса исписује са довољно великим МЕД = 1 000 000. У ситуацији таквог хитног преноса контејнера, мастер смањује МЕД, а М2 ће већ добити команду да оглашава адресу 1.1.1.1 са МЕД = 999 999. Инстанца која ради на М1 остаће на месту у овом случају везе нема, а његова даља судбина нас мало интересује док се веза са мастером не успостави, када ће он бити заустављен као стари потез.

незгоде

Сви системи за управљање центрима података увек прихватају мање кварове. Преливање контејнера је норма скоро свуда.

Хајде да погледамо како поступамо у хитним случајевима, као што је нестанак струје у једној или више просторија дата центра.

Шта несрећа значи за систем управљања центром података? Пре свега, ово је масовни једнократни квар многих машина, а контролни систем треба да мигрира много контејнера у исто време. Али ако је катастрофа веома великих размера, онда се може десити да се сви задаци не могу поново доделити другим минионима, јер капацитет ресурса дата центра пада испод 100% оптерећења.

Често су незгоде праћене отказом контролног слоја. То се може догодити због квара његове опреме, али чешће због чињенице да се несреће не тестирају, а сам контролни слој пада због повећаног оптерећења.

Шта можете учинити поводом свега овога?

Масовне миграције значе да се у инфраструктури дешава велики број активности, миграција и распоређивања. Свака од миграција може потрајати неко време потребно за испоруку и распакивање слика контејнера минионима, покретање и иницијализацију контејнера итд. Због тога је пожељно да се важнији задаци покрећу пре мање важних.

Хајде да поново погледамо хијерархију услуга са којом смо упознати и покушамо да одлучимо које задатке желимо да покренемо први.

Наравно, реч је о процесима који су директно укључени у обраду захтева корисника, тј. Ово указујемо са приоритет пласмана — број који се може доделити реду. Ако ред има већи приоритет, његове услуге се постављају на прво место.

На прод додељујемо више приоритете, 0; на серији - мало ниже, 100; у празном ходу - још ниже, 200. Приоритети се примењују хијерархијски. Сви задаци ниже у хијерархији ће имати одговарајући приоритет. Ако желимо да се кешови унутар прод-а покрећу пре фронтенда, онда додељујемо приоритете кешу = 0 и предњим потредовима = 1. Ако, на пример, желимо да се главни портал покрене прво са фронта, а само музички фронт онда, онда можемо доделити нижи приоритет овом последњем - 10.

Следећи проблем је недостатак ресурса. Дакле, отказала је велика количина опреме, читаве хале дата центра, а ми смо поново покренули толико сервиса да сада нема довољно ресурса за све. Морате да одлучите које задатке ћете жртвовати да бисте одржали рад главних критичних услуга.

За разлику од приоритета пласмана, не можемо неселективно жртвовати све пакетне задатке, неки од њих су важни за рад портала. Стога смо посебно истакли приоритет приоритета задатака. Када се постави, задатак вишег приоритета може да предузме, односно заустави, задатак нижег приоритета ако више нема слободних миниона. У овом случају, задатак са ниским приоритетом ће вероватно остати непостављен, односно више неће бити одговарајућег миниона за њега са довољно слободних ресурса.

У нашој хијерархији, врло је једноставно навести приоритет приоритета тако да производни и батцх задаци преузму или заустављају неактивне задатке, али не једни друге, навођењем приоритета за мировање једнак 200. Баш као иу случају приоритета постављања, ми може користити нашу хијерархију да опише сложенија правила. На пример, назначимо да жртвујемо музичку функцију ако немамо довољно ресурса за главни веб портал, постављајући нижи приоритет за одговарајуће чворове: 10.

Читаве ДЦ несреће

Зашто би цео центар података могао да пропадне? Елемент. Био је добар пост ураган је утицао на рад дата центра. Елементи се могу сматрати бескућницима који су некада спалили оптику у колектору, а дата центар је потпуно изгубио контакт са другим сајтовима. Узрок квара може бити и људски фактор: оператер ће издати такву команду да ће цео дата центар пасти. Ово се може догодити због велике грешке. Генерално, колапс центара података није неуобичајен. То нам се дешава једном у неколико месеци.

И ово је оно што радимо да спречимо било кога да твитује #жив.

Прва стратегија је изолација. Свака инстанца са једним облаком је изолована и може управљати машинама у само једном центру података. То јест, губитак облака због грешака или нетачних команди оператера је губитак само једног центра података. Спремни смо за ово: постоји политика редундантности у којој се реплике апликације и података налазе у свим дата центрима. Користимо базе података отпорне на грешке и повремено тестирамо грешке.
Пошто данас имамо четири дата центра, то значи четири одвојене, потпуно изоловане инстанце једног облака.

Овај приступ не само да штити од физичког квара, већ може заштитити и од грешке оператера.

Шта се још може урадити са људским фактором? Када оператер да облаку неку чудну или потенцијално опасну команду, од њега се изненада може тражити да реши мали проблем да види колико је добро размишљао. На пример, ако је ово нека врста масовног заустављања многих реплика или само чудна команда - смањење броја реплика или промена назива слике, а не само броја верзије у новом манифесту.

Резултати

Карактеристичне карактеристике једног облака:

• Хијерархијска и визуелна шема именовања за услуге и контејнере, што вам омогућава да врло брзо сазнате шта је задатак, на шта се односи и како функционише и ко је за њега одговоран.
• Примењујемо наше техника комбиновања производа и серијезадаци на минионима за побољшање ефикасности дељења машина. Уместо скупа процесора користимо ЦПУ квоте, дељења, политике ЦПУ планера и Линук КоС.
• Није било могуће потпуно изоловати контејнере који раде на истој машини, али њихов међусобни утицај остаје унутар 20%.
• Организовање услуга у хијерархију помаже при аутоматском опоравку од катастрофе приоритети пласмана и превенције.

ФАК

Зашто нисмо узели готово решење?

• Различите класе изолације задатака захтевају различиту логику када се постављају на слуге. Ако се прод задаци могу поставити једноставним резервисањем ресурса, онда се морају поставити пакетни и неактивни задаци, пратећи стварну употребу ресурса на машинама миниона.
• Потреба да се узму у обзир ресурси који се троше задацима, као што су:
  • пропусни опсег мреже;
  • врсте и „вретена” дискова.
• Потреба да се назначе приоритети услуга током хитног реаговања, права и квоте команди за ресурсе, што се решава коришћењем хијерархијских редова у једном облаку.
• Потреба за људским именовањем контејнера како би се смањило време реаговања на несреће и инциденте
• Немогућност једнократне широке имплементације Сервице Дисцовери-а; потреба да се дуго коегзистира са задацима који се налазе на хардверским хостовима – нешто што се решава „статичним” ИП адресама које прате контејнере, и, као последица тога, потреба за јединственом интеграцијом са великом мрежном инфраструктуром.

Све ове функције захтевале би значајне модификације постојећих решења како би нам одговарале, а проценом обима посла схватили смо да можемо да развијемо сопствено решење са приближно истим трошковима рада. Али ваше решење ће бити много лакше за рад и развој – оно не садржи непотребне апстракције које подржавају функционалност која нам није потребна.

Онима који су прочитали последње редове, хвала на стрпљењу и пажњи!

Извор: ввв.хабр.цом