Ефективно и надеждно управление на клъстери във всякакъв мащаб с Tupperware
Днес на представихме Tupperware, нашата система за управление на клъстери, която организира контейнери в милиони сървъри, изпълняващи почти всички наши услуги. За първи път внедрихме Tupperware през 2011 г. и оттогава нашата инфраструктура се разрасна до цяло . През цялото това време Tupperware не стоеше неподвижно и се развиваше с нас. Ще ви покажем как Tupperware осигурява първокласно управление на клъстери, включително удобна поддръжка за услуги със състояние, един контролен панел за всички центрове за данни и възможност за разпределяне на капацитет между услуги в реално време. Ще споделим и уроците, които сме научили, докато нашата инфраструктура се развива.
Tupperware изпълнява различни задачи. Разработчиците на приложения го използват за доставяне и управление на приложения. Той пакетира кода на приложението и зависимостите в изображение и го доставя на сървърите като контейнери. Контейнерите осигуряват изолация между приложенията на един и същи сървър, така че разработчиците да се справят с логиката на приложението и да не се притесняват за намирането на сървъри или управлението на актуализации. Tupperware също следи производителността на сървъра и ако открие повреда, прехвърля контейнери от проблемния сървър.
Инженерите по планиране на капацитет използват Tupperware, за да разпределят сървърния капацитет на екипи въз основа на бюджет и ограничения. Те също го използват за подобряване на използването на сървъра. Операторите на центрове за данни се обръщат към Tupperware, за да разпределят правилно контейнерите в центровете за данни и да спрат или преместят контейнери по време на поддръжка. Благодарение на това поддръжката на сървъри, мрежи и оборудване изисква минимална човешка намеса.
Архитектура на Tupperware
Архитектурата Tupperware PRN е един от регионите на нашите центрове за данни. Регионът се състои от няколко сгради на центъра за данни (PRN1 и PRN2), разположени наблизо. Планираме да направим един контролен панел, който да управлява всички сървъри в един регион.
Разработчиците на приложения предоставят услуги под формата на работни места на Tupperware. Едно задание се състои от множество контейнери и всички те обикновено изпълняват един и същ код на приложение.
Tupperware отговаря за предоставянето на контейнери и управлението на техния жизнен цикъл. Състои се от няколко компонента:
- Предният интерфейс на Tupperware предоставя API за потребителския интерфейс, CLI и други инструменти за автоматизация, чрез които можете да взаимодействате с Tupperware. Те крият цялата вътрешна структура от собствениците на работа в Tupperware.
- Tupperware Scheduler е контролен панел, отговорен за управлението на контейнера и жизнения цикъл на заданието. Разполага се на регионално и глобално ниво, където регионалния планировчик управлява сървъри в един регион, а глобалният планировчик управлява сървъри от различни региони. Планировчикът е разделен на фрагменти и всеки сегмент управлява набор от задачи.
- Проксито за планиране на Tupperware скрива вътрешния шардинг и предоставя удобен единичен прозорец за потребителите на Tupperware.
- Разпределителят на Tupperware присвоява контейнери на сървъри. Планировчикът управлява спирането, стартирането, актуализирането и прехвърлянето на контейнери при отказ. В момента един разпределител може да управлява целия регион, без да се разделя на сегменти. (Обърнете внимание на разликата в терминологията. Например планировчикът в Tupperware съответства на контролния панел в , а разпределителят на Tupperware се нарича планировчик в Kubernetes.)
- Брокерът на ресурси съхранява източника на истина за събитията на сървъра и услугата. Пускаме един брокер на ресурси за всеки център за данни и той съхранява цялата информация за сървърите в този център за данни. Брокерът на ресурси и системата за управление на капацитета, или системата за предоставяне на ресурси, динамично решават кой график за доставка контролира кой сървър. Услугата за проверка на здравето следи сървърите и съхранява данни за тяхното здраве в брокера на ресурси. Ако даден сървър има проблеми или се нуждае от поддръжка, брокерът на ресурси казва на разпределителя и планировчика да спрат контейнерите или да ги преместят на други сървъри.
- Tupperware Agent е демон, работещ на всеки сървър, който подготвя и премахва контейнери. Приложенията работят в контейнер, което им дава по-голяма изолация и възпроизводимост. На Вече описахме как се създават отделни контейнери на Tupperware с помощта на изображения, btrfs, cgroupv2 и systemd.
Отличителни черти на Tupperware
Tupperware е подобен в много отношения на други системи за управление на клъстери като Kubernetes и , но има и разлики:
- Вградена поддръжка за услуги с постоянно състояние.
- Единен контролен панел за сървъри в различни центрове за данни за автоматизиране на доставката на контейнери въз основа на намерение, извеждане от експлоатация на клъстери и поддръжка.
- Ясно разделение на контролния панел за мащабиране.
- Еластичното изчисление ви позволява да разпределяте мощността между услугите в реално време.
Ние разработихме тези страхотни функции, за да поддържаме различни приложения без състояние и състояние в огромен глобален парк от споделени сървъри.
Вградена поддръжка за услуги с постоянно състояние.
Tupperware оперира с различни критични услуги със състояние, които съхраняват постоянни продуктови данни за Facebook, Instagram, Messenger и WhatsApp. Това могат да бъдат големи хранилища на двойки ключ-стойност (напр. ) и хранилища за данни за наблюдение (напр. и ). Поддържането на услуги с постоянно състояние не е лесно, тъй като системата трябва да гарантира, че доставката на контейнери може да издържи на мащабни прекъсвания, включително прекъсвания на мрежата или прекъсвания на захранването. И докато конвенционалните техники, като например разпределяне на контейнери в домейни с грешки, работят добре за услуги без състояние, услугите с постоянно състояние се нуждаят от допълнителна поддръжка.
Например, ако повреда на сървъра направи една реплика на база данни недостъпна, трябва ли да активирате автоматична поддръжка, която ще актуализира ядрата на 50 сървъра от група от 10 50? Зависи от ситуацията. Ако един от тези 2 сървъра има друга реплика на същата база данни, по-добре е да изчакате и да не загубите XNUMX реплики наведнъж. За да вземаме динамично решения относно поддръжката и производителността на системата, се нуждаем от информация за вътрешната репликация на данни и логиката на разположение на всяка услуга с поддържане на състоянието.
Интерфейсът TaskControl позволява на услугите със състояние да влияят върху решенията, които засягат наличността на данни. Използвайки този интерфейс, планировчикът уведомява външни приложения за операциите на контейнера (рестартиране, актуализиране, миграция, поддръжка). Услугата с поддържане на състоянието имплементира контролер, който казва на Tupperware кога е безопасно да извърши всяка операция и тези операции могат да бъдат разменени или отложени временно. В примера по-горе контролерът на базата данни може да каже на Tupperware да актуализира 49 от 50 сървъра, но да остави конкретен сървър (X) сам засега. В резултат на това, ако периодът на актуализиране на ядрото изтече и базата данни все още не може да възстанови проблемната реплика, Tupperware ще продължи да актуализира X сървъра.
Много услуги за поддържане на състоянието в Tupperware използват TaskControl не директно, а чрез ShardManager, обща платформа за създаване на услуги за запазване на състоянието във Facebook. С Tupperware разработчиците могат да определят своето намерение за това как точно трябва да се разпределят контейнерите в центровете за данни. С ShardManager разработчиците уточняват своето намерение за това как фрагментите с данни трябва да бъдат разпределени между контейнерите. ShardManager е наясно с разположението на данните и репликацията на своите приложения и комуникира с Tupperware чрез интерфейса TaskControl, за да планира операциите на контейнера без пряко участие на приложението. Тази интеграция значително опростява управлението на услугите със състояние, но TaskControl е способен на повече. Например, нашето обширно уеб ниво е без състояние и използва TaskControl за динамично регулиране на скоростта на актуализации на контейнерите. В крайна сметка на ден без компромис с наличността.
Управление на сървъри в центрове за данни
Когато Tupperware стартира за първи път през 2011 г., всеки сървърен клъстер се управлява от отделен планировчик. Тогава клъстерът на Facebook беше група от сървърни стелажи, свързани към един мрежов комутатор, а центърът за данни съдържаше няколко клъстера. Планировчикът може да управлява само сървъри в един клъстер, което означава, че заданието не може да се разпространи в множество клъстери. Нашата инфраструктура се разрасна, все повече отписвахме клъстери. Тъй като Tupperware не можеше да премести работата от изведения от експлоатация клъстер към други клъстери без промени, това изискваше много усилия и внимателна координация между разработчиците на приложения и операторите на центрове за данни. Този процес доведе до загуба на ресурси, когато сървърите бяха неактивни в продължение на месеци поради процедури за извеждане от експлоатация.
Създадохме посредник на ресурси, за да разрешим проблема с извеждането от експлоатация на клъстера и да координираме други видове задачи по поддръжката. Брокерът на ресурси следи цялата физическа информация, свързана със сървъра, и динамично решава кой планировчик контролира всеки сървър. Динамичното свързване на сървъри към планировчици позволява на планировчика да управлява сървъри в различни центрове за данни. Тъй като заданието на Tupperware вече не е ограничено до един клъстер, потребителите на Tupperware могат да определят как контейнерите трябва да бъдат разпределени между домейни за грешки. Например, разработчикът може да декларира своето намерение (да кажем: „да изпълня работата си на 2 домейна с грешки в PRN региона“), без да посочва конкретни зони на достъпност. Самият Tupperware ще намери подходящи сървъри за реализиране на това намерение, дори ако клъстерът или услугата бъдат изведени от експлоатация.
Мащабируем за поддръжка на цялата глобална система
В исторически план нашата инфраструктура е била разделена на стотици специализирани сървърни групи за отделни екипи. Поради разпокъсаност и липса на стандарти имахме високи оперативни разходи и неактивните сървъри бяха по-трудни за повторно използване. На миналогодишната конференция представихме , което трябва да обедини нашата инфраструктура в голям единичен сървърен парк. Но един сървърен парк има своите трудности. Тя трябва да отговаря на определени изисквания:
- Мащабируемост. Нашата инфраструктура се разрасна, докато добавяхме центрове за данни във всеки регион. Сървърите са станали по-малки и по-енергийно ефективни, така че има много повече от тях във всеки регион. В резултат на това единичен планировчик за регион не може да се справи с броя на контейнерите, които могат да се изпълняват на стотици хиляди сървъри във всеки регион.
- Надеждност. Дори ако планировчикът може да бъде увеличен толкова много, големият обхват на планировчика означава, че има по-висок риск от грешки и цял регион от контейнери може да стане неуправляем.
- Толерантност към грешки. В случай на огромна повреда в инфраструктурата (например сървърите, работещи с планировчика, се повредят поради повреда в мрежата или прекъсване на захранването), негативните последици трябва да засегнат само част от сървърите в региона.
- Лесна употреба. Може да изглежда, че трябва да стартирате няколко независими планировчици за един регион. Но от гледна точка на удобство, една точка на влизане в споделения пул на региона улеснява управлението на капацитета и работните места.
Разделихме планировчика на сегменти, за да решим проблемите с поддържането на голям споделен пул. Всеки планировчик управлява свой собствен набор от задачи в региона и това намалява риска, свързан с планировчика. С нарастването на споделения пул можем да добавяме още сегменти на планировчик. За потребителите на Tupperware, шардовете и прокситата за планиране изглеждат като един контролен панел. Те не трябва да работят с куп фрагменти, които организират задачи. Схердите на планировчика се различават фундаментално от клъстерните планировчици, които използвахме преди, когато контролният панел беше разделен без статично разделяне на споделения пул от сървъри според топологията на мрежата.
Подобрете ефективността на използване с Elastic Computing
Колкото по-голяма е нашата инфраструктура, толкова по-важно е да използваме нашите сървъри ефективно, за да оптимизираме инфраструктурните разходи и да намалим натоварването. Има два начина за повишаване на ефективността на използването на сървъра:
- Еластично изчисление – намалете мащаба на онлайн услугите по време на спокойни часове и използвайте освободени сървъри за офлайн работни натоварвания, като машинно обучение и задачи на MapReduce.
- Претоварване – Поставете онлайн услугите и груповите натоварвания на едни и същи сървъри, така че пакетните натоварвания да се изпълняват с нисък приоритет.
Тясното място в нашите центрове за данни е . Ето защо ние предпочитаме малки, енергийно ефективни сървъри, които заедно осигуряват повече процесорна мощност. За съжаление, на малки сървъри с малко процесор и памет, претоварването е по-малко ефективно. Разбира се, можем да поставим няколко контейнера с малки услуги на един малък енергийно ефективен сървър, който консумира малко процесорни ресурси и памет, но големите услуги ще имат ниска производителност в тази ситуация. Затова съветваме разработчиците на нашите големи услуги да ги оптимизират така, че да използват целите сървъри.
По принцип подобряваме ефективността на използване с помощта на еластични изчисления. Много от основните ни услуги, като новинарската емисия, функцията за съобщения и преден уеб слой, варират в зависимост от времето на деня. Умишлено намаляваме мащаба на онлайн услугите по време на спокойни часове и използваме освободени сървъри за офлайн работни натоварвания, като машинно обучение и MapReduce задачи.
От опит знаем, че е най-добре да предоставим цели сървъри като единици с еластичен капацитет, тъй като големите услуги са както основни донори, така и основни потребители на еластичен капацитет и са оптимизирани да използват цели сървъри. Когато сървърът бъде освободен от онлайн услуга по време на спокойни часове, брокерът на ресурси наема сървъра на планировчика, за да изпълнява офлайн работни натоварвания върху него. Ако онлайн услугата претърпи пиково натоварване, брокерът на ресурсите бързо извиква заетия сървър и заедно с планировчика го връща на онлайн услугата.
Научени уроци и планове за бъдещето
През последните 8 години ние разработвахме Tupperware, за да сме в крак с бързия растеж на Facebook. Споделяме наученото и се надяваме, че ще помогне на други да управляват бързо разрастващи се инфраструктури:
- Настройте гъвкава връзка между контролния панел и управляваните от него сървъри. Тази гъвкавост позволява на контролния панел да управлява сървъри в различни центрове за данни, помага за автоматизирането на извеждането от експлоатация и поддръжката на клъстери и позволява динамично разпределение на капацитет с помощта на еластично изчисление.
- С един контролен панел в региона става по-удобно да се работи със задачи и по-лесно да се управлява голям споделен сървърен парк. Имайте предвид, че контролният панел поддържа една входна точка, дори ако вътрешната му структура е разделена поради причини, свързани с мащаба или устойчивостта на грешки.
- Използвайки модел на плъгин, контролният панел може да уведомява външни приложения за предстоящи операции с контейнери. Освен това, услугите със състояние могат да използват интерфейса на плъгина, за да персонализират управлението на контейнери. С този модел на плъгини, контролният панел осигурява простота, като същевременно обслужва ефективно много различни услуги със състояние.
- Вярваме, че еластичното изчисление, при което отнемаме цели сървъри от донорски услуги за пакетни задачи, машинно обучение и други неспешни услуги, е оптималният начин за подобряване на ефективността на малки, енергийно ефективни сървъри.
Тепърва започваме да прилагаме . В момента около 20% от нашите сървъри са в споделен пул. За постигане на 100%, много проблеми трябва да бъдат адресирани, включително поддържане на споделен пул за съхранение, автоматизиране на поддръжката, управление на изискванията за кръстосани наематели, подобряване на използването на сървъра и подобряване на поддръжката за натоварвания с машинно обучение. Нямаме търпение да поемем тези предизвикателства и да споделим успехите си.
Източник: www.habr.com