Ефикасно и поуздано управљање кластерима на било ком нивоу са Тупперваре-ом
Danas na представили смо Тупперваре, наш систем за управљање кластерима који оркестрира контејнере на милионима сервера који покрећу скоро све наше услуге. Тупперваре смо први пут применили 2011. године и од тада је наша инфраструктура порасла до целине . Све ово време, Тупперваре није стајао мирно и развијао се са нама. Показаћемо вам како Тупперваре пружа првокласно управљање кластерима, укључујући практичну подршку за услуге са статусом, јединствену контролну таблу за све центре података и могућност расподеле капацитета између услуга у реалном времену. Такође ћемо поделити лекције које смо научили како се наша инфраструктура развија.
Тупперваре обавља различите задатке. Програмери апликација га користе за испоруку апликација и управљање њима. Пакује код апликације и зависности у слику и испоручује је серверима као контејнере. Контејнери обезбеђују изолацију између апликација на истом серверу, тако да се програмери баве логиком апликације и не морају да брину о проналажењу сервера или управљању ажурирањима. Тупперваре такође прати перформансе сервера и ако пронађе квар, преноси контејнере са проблематичног сервера.
Инжењери за планирање капацитета користе Тупперваре за додељивање капацитета сервера тимовима на основу буџета и ограничења. Такође га користе за побољшање коришћења сервера. Оператери центара података се обраћају Тупперваре-у како би правилно дистрибуирали контејнере у центрима података и зауставили или померили контејнере током одржавања. Захваљујући томе, одржавање сервера, мрежа и опреме захтева минималну људску интервенцију.
Тупперваре архитектура
Тупперваре ПРН архитектура је један од региона наших центара података. Регион се састоји од неколико зграда центара података (ПРН1 и ПРН2) које се налазе у близини. Планирамо да направимо један контролни панел који ће управљати свим серверима у једном региону.
Програмери апликација пружају услуге у облику Тупперваре послова. Посао се састоји од више контејнера и сви они обично покрећу исти код апликације.
Тупперваре је одговоран за обезбеђивање контејнера и управљање њиховим животним циклусом. Састоји се од неколико компоненти:
- Тупперваре фронтенд пружа АПИ-је за кориснички интерфејс, ЦЛИ и друге алате за аутоматизацију преко којих можете да комуницирате са Тупперваре-ом. Они скривају целокупну интерну структуру од власника послова Тупперваре-а.
- Тупперваре Сцхедулер је контролна табла одговорна за управљање контејнером и животним циклусом посла. Примењује се на регионалном и глобалном нивоу, где регионални планер управља серверима у једном региону, а глобални планер управља серверима из различитих региона. Планер је подељен на делове и сваки део управља скупом послова.
- Тупперваре-ов Сцхедулер Проки сакрива унутрашње дијељење и пружа згодан једно стакло за кориснике Тупперваре-а.
- Тупперваре алокатор додељује контејнере серверима. Планер управља заустављањем, покретањем, ажурирањем и преласком на грешку контејнера. Тренутно, један алокатор може да управља целим регионом без раздвајања на делове. (Обратите пажњу на разлику у терминологији. На пример, планер у Тупперваре-у одговара контролној табли у , а Тупперваре алокатор се у Кубернетесу зове планер.)
- Посредник ресурса чува извор истине за серверске и сервисне догађаје. Покрећемо једног посредника ресурса за сваки центар података и он чува све информације о серверима у том центру података. Посредник ресурса и систем управљања капацитетом, или систем за обезбеђивање ресурса, динамички одлучују који планер испоруке контролише који сервер. Услуга провере здравља надгледа сервере и чува податке о њиховом здрављу у посреднику ресурса. Ако сервер има проблема или му је потребно одржавање, посредник ресурса каже алокатору и планеру да зауставе контејнере или да их преместе на друге сервере.
- Тупперваре Агент је демон који ради на сваком серверу који управља обезбеђивањем и уклањањем контејнера. Апликације се покрећу унутар контејнера, што им даје већу изолацију и поновљивост. на Већ смо описали како се појединачни Тупперваре контејнери креирају помоћу слика, бтрфс, цгроупв2 и системд.
Карактеристичне карактеристике Тупперваре-а
Тупперваре је на много начина сличан другим системима за управљање кластерима као што су Кубернетес и , али постоје и разлике:
- Уграђена подршка за услуге са статусом.
- Јединствена контролна табла за сервере у различитим центрима података за аутоматизацију испоруке контејнера на основу намере, декомисије кластера и одржавања.
- Јасна подела контролне табле за зумирање.
- Еластично рачунарство вам омогућава да дистрибуирате снагу између услуга у реалном времену.
Развили смо ове сјајне функције да подржимо низ апликација без стања и статуса у огромној глобалној флоти заједничких сервера.
Уграђена подршка за услуге праћења стања.
Тупперваре управља разним критичним сервисима који чувају сталне податке о производима за Фацебоок, Инстаграм, Мессенгер и ВхатсАпп. То могу бити велика складишта парова кључ/вредност (нпр. ) и надгледање спремишта података (нпр. и ). Одржавање услуга са статусом није лако, јер систем мора да обезбеди да снабдевање контејнера може да издржи велике сметње, укључујући прекиде мреже или струје. И док конвенционалне технике, као што је дистрибуција контејнера у доменима грешака, добро функционишу за услуге без стања, услугама са статусом потребна је додатна подршка.
На пример, ако грешка сервера учини једну реплику базе података недоступном, да ли треба да омогућите аутоматско одржавање које ће ажурирати језгра на 50 сервера из групе од 10? Зависи од ситуације. Ако један од ових 50 сервера има још једну реплику исте базе података, боље је сачекати и не изгубити 2 реплике одједном. Да бисмо динамички доносили одлуке о одржавању и перформансама система, потребне су нам информације о интерној репликацији података и логици постављања сваке услуге која прати стање.
Интерфејс ТаскЦонтрол омогућава услугама са стањем да утичу на одлуке које утичу на доступност података. Користећи овај интерфејс, планер обавештава спољне апликације о операцијама контејнера (поновно покретање, ажурирање, миграција, одржавање). Услуга која прати стање имплементира контролер који говори Тупперваре-у када је безбедно да изврши сваку операцију, а ове операције се могу заменити или привремено одложити. У горњем примеру, контролор базе података може рећи Тупперваре-у да ажурира 49 од 50 сервера, али да остави одређени сервер (Кс) на миру за сада. Као резултат тога, ако период ажурирања кернела прође, а база података и даље не може да врати проблематичну реплику, Тупперваре ће и даље ажурирати Кс сервер.
Многи сервиси за праћење стања у Тупперваре-у користе ТаскЦонтрол не директно, већ преко СхардМанагер-а, уобичајене платформе за креирање услуга са подацима о стању на Фацебооку. Са Тупперваре-ом, програмери могу одредити своју намеру за тачно како би контејнери требало да буду дистрибуирани у центрима података. Са СхардМанагер-ом, програмери одређују своју намеру за то како би делови података требало да се дистрибуирају по контејнерима. СхардМанагер је свестан постављања података и репликације својих апликација и комуницира са Тупперваре-ом преко ТаскЦонтрол интерфејса како би заказао операције контејнера без директног укључивања апликације. Ова интеграција у великој мери поједностављује управљање услугама са статусом, али ТаскЦонтрол је способан за више. На пример, наш широки веб ниво је без државности и користи ТаскЦонтрол за динамичко прилагођавање стопе ажурирања контејнера. Коначно дневно без угрожавања доступности.
Управљање серверима у дата центрима
Када је Тупперваре први пут лансиран 2011. године, сваким кластером сервера управљао је посебан планер. Тада је Фацебоок кластер био група серверских рекова повезаних на један мрежни прекидач, а центар података је имао неколико кластера. Планер је могао да управља само серверима у једном кластеру, што значи да се посао не може ширити на више кластера. Наша инфраструктура је расла, све више смо отписивали кластере. Пошто Тупперваре није могао да премести посао са распуштеног кластера у друге кластере без промена, било је потребно много труда и пажљиве координације између програмера апликација и оператера центара података. Овај процес је резултирао губитком ресурса када су сервери месецима били неактивни због поступака разградње.
Направили смо посредника ресурса да решимо проблем декомисије кластера и координирамо друге врсте задатака одржавања. Посредник ресурса прати све физичке информације повезане са сервером и динамички одлучује који планер контролише сваки сервер. Динамичко повезивање сервера са планерима омогућава планеру да управља серверима у различитим центрима података. Пошто Тупперваре посао више није ограничен на један кластер, корисници Тупперваре-а могу одредити како контејнери треба да буду дистрибуирани у доменима грешке. На пример, програмер може да изјави своју намеру (рецимо: „покрени мој посао на 2 домена грешке у ПРН региону“) без навођења одређених зона доступности. Сам Тупперваре ће пронаћи одговарајуће сервере за имплементацију ове намере, чак и ако се кластер или услуга повуче из употребе.
Скалабилан да подржи цео глобални систем
Историјски гледано, наша инфраструктура је подељена на стотине наменских скупова сервера за појединачне тимове. Због фрагментације и недостатка стандарда, имали смо високе оперативне трошкове, а сервере у стању мировања поново је било теже користити. На прошлогодишњој конференцији представили смо , који би требало да уједини нашу инфраструктуру у велики јединствени серверски парк. Али један парк сервера има своје потешкоће. Мора да испуњава одређене услове:
- Прилагодљивост. Наша инфраструктура је расла како смо додавали центре података у сваком региону. Сервери су постали мањи и енергетски ефикаснији, тако да их је много више у сваком региону. Као резултат тога, један планер по региону не може да поднесе број контејнера који се могу покренути на стотинама хиљада сервера у сваком региону.
- Поузданост. Чак и ако се планер може толико повећати, велики обим планера значи да постоји већи ризик од грешака и читав регион контејнера може постати неуправљив.
- Толеранција грешака. У случају великог инфраструктурног квара (на пример, сервери који покрећу планер отказују због квара на мрежи или нестанка струје), негативне последице би требало да утичу само на део сервера у региону.
- Једноставност употребе. Можда се чини да морате покренути неколико независних планера за један регион. Али из перспективе погодности, једна тачка уласка у заједнички скуп региона олакшава управљање капацитетима и пословима.
Поделили смо планер на делове да бисмо решили проблеме одржавања великог заједничког базена. Сваки део планера управља сопственим скупом послова у региону и то смањује ризик повезан са планером. Како заједнички скуп расте, можемо додати још фрагмената планера. За кориснике Тупперваре-а, делови и прокси програмери изгледају као једна контролна табла. Не морају да раде са гомилом крхотина које оркестрирају задатке. Делови планера се суштински разликују од планера кластера које смо раније користили, када је контролна табла била партиционисана без статички дељења дељене групе сервера према топологији мреже.
Побољшајте ефикасност коришћења помоћу Еластиц Цомпутинг
Што је наша инфраструктура већа, то је важније да ефикасно користимо наше сервере за оптимизацију трошкова инфраструктуре и смањење оптерећења. Постоје два начина за повећање ефикасности коришћења сервера:
- Еластично рачунарство – смањите онлајн услуге током тихих сати и користите ослобођене сервере за ванмрежна радна оптерећења, као што су машинско учење и МапРедуце послови.
- Преоптерећење – Поставите онлајн услуге и групна радна оптерећења на исте сервере тако да се групна радна оптерећења покрећу са ниским приоритетом.
Уско грло у нашим центрима података је . Због тога преферирамо мале, енергетски ефикасне сервере који заједно пружају више процесорске снаге. Нажалост, на малим серверима са мало ЦПУ-а и меморије, преоптерећење је мање ефикасно. Наравно, можемо поставити неколико контејнера малих услуга на један мали енергетски ефикасан сервер који троше мало процесорских ресурса и меморије, али ће велике услуге у овој ситуацији имати ниске перформансе. Због тога саветујемо програмере наших великих сервиса да их оптимизују тако да користе читаве сервере.
У основи, побољшавамо ефикасност коришћења користећи еластично рачунарство. Многе наше главне услуге, као што су Невс Феед, функција за размену порука и фронт-енд веб ниво, разликују се у зависности од доба дана. Намерно смањујемо онлајн услуге током тихих сати и користимо ослобођене сервере за ванмрежна радна оптерећења, као што су машинско учење и МапРедуце послови.
Из искуства знамо да је најбоље обезбедити целе сервере као јединице еластичног капацитета јер су велике услуге и главни донатори и главни потрошачи еластичног капацитета, и оптимизовани су за коришћење целих сервера. Када се сервер ослободи из онлајн услуге током тихих сати, посредник ресурса изнајмљује сервер планеру да на њему покреће ванмрежна радна оптерећења. Ако онлајн услуга доживи највеће оптерећење, посредник ресурса брзо позива позајмљени сервер и, заједно са планером, враћа га онлајн сервису.
Научене лекције и планови за будућност
Током протеклих 8 година, развијали смо Тупперваре како бисмо били у току са брзим растом Фацебоок-а. Делимо оно што смо научили и надамо се да ће то помоћи другима да управљају инфраструктурама које се брзо развијају:
- Подесите флексибилну везу између контролне табле и сервера којима управља. Ова флексибилност омогућава контролном панелу да управља серверима у различитим центрима података, помаже у аутоматизацији декомисије и одржавања кластера и омогућава динамичку алокацију капацитета коришћењем еластичног рачунарства.
- Са једним контролним панелом у региону, постаје згодније радити са задацима и лакше управљати великом флотом заједничких сервера. Имајте на уму да контролна табла одржава једну улазну тачку, чак и ако је њена унутрашња структура одвојена из разлога скале или толеранције грешке.
- Користећи модел додатка, контролна табла може да обавести спољне апликације о предстојећим операцијама контејнера. Штавише, услуге са стањем могу да користе интерфејс додатака за прилагођавање управљања контејнерима. Са овим моделом додатака, контролна табла пружа једноставност док ефикасно опслужује многе различите услуге са подацима о стању.
- Верујемо да је еластично рачунарство, где одузимамо целе сервере донаторским услугама за групне послове, машинско учење и друге услуге које нису хитне, оптималан начин да се побољша ефикасност малих, енергетски ефикасних сервера.
Тек почињемо да спроводимо . Тренутно је око 20% наших сервера у заједничком скупу. Да би се постигао 100%, потребно је решити многа питања, укључујући одржавање заједничког складишног простора, аутоматизовање одржавања, управљање захтевима међу закупцима, побољшање коришћења сервера и побољшање подршке за радна оптерећења машинског учења. Једва чекамо да прихватимо ове изазове и поделимо своје успехе.
Извор: ввв.хабр.цом