Ефективне та надійне управління кластерами у будь-якому масштабі з Tupperware
сьогодні на ми представили Tupperware - нашу систему управління кластерами, яка оркеструє контейнери на мільйонах серверів, де працюють майже всі наші сервіси. Вперше ми розгорнули Tupperware у 2011 р., і з того часу наша інфраструктура розрослася з до цілих . Весь цей час Tupperware не стояв на місці та розвивався разом з нами. Ми розповімо, у яких ситуаціях Tupperware забезпечує першокласне управління кластерами, включаючи зручну підтримку stateful-сервісів, єдину панель управління для всіх датацентрів та можливість розподіляти потужності між сервісами у реальному часі. А ще ми поділимося уроками, які засвоїли з розвитком нашої інфраструктури.
Tupperware виконує різні завдання. Розробники додатків з його допомогою постачають програми та керують ними. Він упаковує код і залежність програми в образі і поставляє його на сервери у вигляді контейнерів. Контейнери забезпечують ізоляцію між програмами на одному сервері, щоб розробники займалися логікою програми і не думали про те, як знайти сервери або контролювати оновлення. А ще Tupperware відстежує працездатність сервера, і, якщо знаходить збій, переносить контейнери з проблемного сервера.
Інженери з планування потужностей за допомогою Tupperware розподіляють серверні потужності за командами відповідно до бюджету та обмежень. А ще вони використовують його, щоб підвищити ефективність використання серверів. Оператори датацентрів звертаються до Tupperware, щоб правильно розподілити контейнери по датацентрам та зупиняти або переміщати контейнери на час технічного обслуговування. Завдяки цьому обслуговування серверів, мережі та обладнання потребує мінімальної участі людини.
Архітектура Tupperware
Архітектура Tupperware PRN – це один із регіонів наших датацентрів. Регіон складається з кількох будівель датацентрів (PRN1 та PRN2), розташованих поруч. Ми плануємо зробити одну панель управління, яка керуватиме всіма серверами в одному регіоні.
Розробники додатків постачають послуги у вигляді завдань Tupperware. Завдання складається з декількох контейнерів, і всі вони зазвичай виконують той самий код програми.
Tupperware відповідає за виділення контейнерів та керування їх життєвим циклом. Він складається з кількох компонентів:
- Фронтенд Tupperware надає API для інтерфейсу користувача, CLI та інших інструментів автоматизації, через які можна взаємодіяти з Tupperware. Вони приховують всю внутрішню структуру від власників завдань Tupperware.
- Планувальник Tupperware – це панель управління, відповідальна за керування життєвим циклом контейнера та завдання. Він розгортається на регіональному та глобальному рівнях, де регіональний планувальник управляє серверами в одному регіоні, а глобальний планувальник управляє серверами з різних регіонів. Планувальник розділений на шарди, і кожен шард керує набором завдань.
- Проксі планувальника Tupperware приховує внутрішній поділ на шарди і надає зручну єдину панель управління користувачам Tupperware.
- Розподільник Tupperware призначає контейнери серверам. Зупинкою, запуском, оновленням та відпрацюванням відмови контейнерів займається планувальник. В даний час один розподільник може управляти всім регіоном без поділу на шарди. (Зверніть увагу на різницю в термінології. Наприклад, планувальник у Tupperware відповідає панелі управління в , А розподільник Tupperware називається в Kubernetes планувальником.)
- Брокер ресурсів зберігає джерело істини для сервера та подій обслуговування. Ми запускаємо один брокер ресурсів для кожного датацентру, і він зберігає всі відомості про сервери цього датацентру. Брокер ресурсів та система управління потужностями, або система виділення ресурсів, динамічно вирішують, яке постачання планувальника яким сервером управляє. Сервіс перевірки працездатності моніторить сервери та зберігає дані про їхню працездатність у брокері ресурсів. Якщо сервер має проблеми або він потребує обслуговування, брокер ресурсів велить розподільнику і планувальнику зупинити контейнери або перенести їх на інші сервери.
- Агент Tupperware - це демон, запущений на кожному сервері, який займається підготовкою та видаленням контейнерів. Програми працюють усередині контейнера, що дає їм більше ізоляції та відтворюваності. на ми вже описували, як окремі контейнери Tupperware створюються за допомогою образів, btrfs, cgroupv2 та systemd.
Відмінні риси Tupperware
Tupperware багато в чому схожий на інші системи управління кластерами, наприклад Kubernetes та , але є й відмінності:
- Вбудована підтримка stateful-сервісів.
- Єдина панель управління для серверів у різних датацентрах для автоматизації постачання контейнерів виходячи з наміру, виведення кластерів з експлуатації та обслуговування.
- Зрозумілий поділ панелі керування для збільшення масштабу.
- Еластичні обчислення дають змогу розподіляти потужності між сервісами в реальному часі.
Ми розробили ці класні функції, щоб підтримувати різноманітні stateless- та stateful-додатки у величезному глобальному загальному парку серверів.
Вбудована підтримка stateful-севісів.
Tupperware управляє безліччю критичних stateful-сервісів, які зберігають постійні дані продуктів для Facebook, Instagram, Messenger та WhatsApp. Це можуть бути великі сховища пар «ключ-значення» (наприклад, ) та сховища даних моніторингу (наприклад, и ). Підтримувати stateful-сервіси непросто, адже система має гарантувати, що постачання контейнерів витримають великомасштабні збої, включаючи урвище мережі або відключення електрики. І хоча звичайні методи, наприклад, розподіл контейнерів по доменам збою, добре підходять для stateless-сервісів, stateful-севісам потрібна додаткова підтримка.
Наприклад, якщо в результаті серверного збою одна репліка бази даних стане недоступною, чи потрібно дозволити автоматичне обслуговування, яке оновить ядра на 50 серверах із 10-тисячного пулу? Залежить від ситуації. Якщо на одному з цих 50 серверів є ще одна репліка тієї ж бази даних, краще зачекати і не втрачати відразу дві репліки. Щоб у динамічному режимі приймати рішення про обслуговування та працездатність системи, потрібні відомості про внутрішню реплікацію даних та логіку розміщення кожного stateful-сервісу.
Інтерфейс TaskControl дозволяє stateful-сервісам впливати на рішення, які позначаться на доступності даних. За допомогою цього інтерфейсу планувальник повідомляє зовнішні програми про операції з контейнером (перезапуск, оновлення, міграція, обслуговування). Stateful-сервіс реалізує контролер, який повідомляє Tupperware, коли можна безпечно виконати кожну операцію і ці операції можна міняти місцями або тимчасово відкладати. У наведеному вище прикладі контролер бази даних може наказати Tupperware оновити 49 з 50 серверів, але поки не чіпати певний сервер (X). У підсумку, якщо мине термін оновлення ядра, а база даних так і не зможе відновити проблемну репліку, Tupperware все одно оновить сервер X.
Багато stateful-сервісів у Tupperware використовують TaskControl не безпосередньо, а через ShardManager — поширену платформу створення stateful-сервісів на Facebook. З Tupperware розробники можуть вказати свій намір у тому, як саме контейнери повинні розподілятися по датацентрам. З ShardManager розробники вказують свій намір у тому, як шарди даних мають розподілятися по контейнерам. ShardManager знає про розміщення даних та реплікацію своїх додатків та взаємодіє з Tupperware через інтерфейс TaskControl, щоб планувати операції з контейнерами без прямої участі додатків. Ця інтеграція значно полегшує управління stateful-сервісами, але TaskControl здатний на більше. Наприклад, наш великий веб-рівень є stateless і використовує TaskControl для динамічного коригування швидкості оновлень у контейнерах. В підсумку на день без шкоди для доступності.
Управління серверами в датацентрах
Коли Tupperware тільки-но з'явився в 2011 році, кожним кластером сервера керував окремий планувальник. Тоді кластером Facebook була група серверних стійок, підключених до одного мережного комутатора, а датацентр містив кілька кластерів. Планувальник міг управляти серверами лише у одному кластері, тобто завдання було поширюватися кілька кластерів. Наша інфраструктура зростала, ми все частіше списували кластери. Оскільки Tupperware не міг без змін переносити завдання з кластера, що списується, на інші кластери, потрібно було багато зусиль і ретельна координація між розробниками додатків і операторами датацентру. Цей процес призводив до марної витрати ресурсів, коли сервери місяцями простоювали через процедуру виведення з експлуатації.
Ми створили брокер ресурсів, щоб вирішити проблему списання кластерів та координувати решту типів завдань з обслуговування. Брокер ресурсів відстежує всі фізичні відомості, пов'язані з сервером, і в динамічному режимі вирішує, який планувальник управляє кожним сервером. Динамічна прив'язка серверів до планувальників дозволяє планувальнику керувати серверами у різних датацентрах. Оскільки завдання Tupperware більше не обмежене одним кластером, користувачі Tupperware можуть вказувати, як контейнери мають поширюватися домени збою. Наприклад, розробник може оголосити свій намір (припустимо: "запусти моє завдання на 2 доменах збою в регіоні PRN"), не вказуючи конкретні зони доступності. Tupperware сам знайде відповідні сервери, щоб втілювати цей намір навіть у разі списання кластера чи обслуговування.
Масштабування для підтримки всієї глобальної системи
Історично склалося, що інфраструктура розділена на сотні виділених пулів серверів окремих команд. Через фрагментацію і відсутність стандартів у нас були високі операційні витрати, а сервери, що простоюють, було складніше знову використовувати. На минулорічній конференції ми представили , яка повинна об'єднати нашу інфраструктуру у великий єдиний парк серверів. Але єдиний парк серверів має свої складнощі. Він має відповідати певним вимогам:
- Масштабованість. Наша інфраструктура зростала з додаванням датацентрів у кожен регіон. Сервери стали меншими і енергоефективнішими, тому в кожному регіоні їх розмістилося набагато більше. В результаті єдиний планувальник на регіон не справляється з кількістю контейнерів, яку можна запустити на сотнях тисяч серверів у кожному регіоні.
- Надійність. Навіть якщо масштаб планувальника можна настільки збільшити, через велику область дії планувальника ризик помилок буде вищим, і цілий регіон контейнерів може стати некерованим.
- Відмовостійкість. У разі збою величезної інфраструктури (наприклад, через обрив мережі або відключення електрики відмовить сервери, де запущено планувальник) негативні наслідки повинні торкнутися лише частини серверів регіону.
- Зручність використання. Може здатися, що треба запускати кількох незалежних планувальників на один регіон. Але з точки зору зручності єдина точка входу до загального пулу в регіоні спрощує управління потужностями та завданнями.
Ми розділили планувальник на шарди, щоб вирішувати проблеми із підтримкою великого загального пулу. Кожен шард планувальника управляє своїм набором завдань у регіоні, і це дозволяє знизити ризик, пов'язаний із планувальником. У міру зростання загального пулу ми можемо додавати більше шардів планувальника. Для користувачів Tupperware шарди та проксі планувальника виглядають як одна панель управління. Їм не доводиться працювати з купою шардів, які оркеструють завдання. Шарди планувальника принципово відрізняються від планувальників кластерів, які ми використовували раніше, коли панель управління була розділена без статичного поділу загального пулу серверів з топології мережі.
Підвищення ефективності використання за допомогою еластичних обчислень
Чим більша наша інфраструктура, тим важливіше ефективно використовувати наші сервери, щоб оптимізувати витрати на інфраструктуру та знизити навантаження. Підвищити ефективність використання серверів можна двома способами:
- Еластичні обчислення — зменшувати масштаб онлайн-сервісів у спокійні години і використовувати сервери, що звільнилися, для офлайн-навантажень, наприклад, для машинного навчання та завдань MapReduce.
- Надмірне завантаження – розміщувати онлайн-сервіси та пакетні робочі навантаження на одних серверах, щоб пакетні навантаження виконувались з низьким пріоритетом.
Вузьке місце в наших датацентрах . Тому ми віддаємо перевагу невеликим енергоефективним серверам, які разом надають більше обчислювальної потужності. На жаль, на маленьких серверах з невеликим обсягом процесорних ресурсів та пам'яті надмірне завантаження менш ефективне. Звичайно, ми можемо розмістити на одному маленькому енергоефективному сервері кілька контейнерів маленьких сервісів, які споживають мало процесорних ресурсів і пам'яті, але великі сервіси в такій ситуації мають низьку продуктивність. Тому ми радимо розробникам великих сервісів оптимізувати їх, щоб вони використовували сервери цілком.
В основному ми підвищуємо ефективність використання за допомогою еластичних обчислень. Інтенсивність використання багатьох наших великих сервісів, наприклад, стрічки новин, функції повідомлень та фронтенд-веб-рівня залежить від часу доби. Ми навмисно зменшуємо масштаб онлайн-сервісів у спокійні години і використовуємо сервери, що звільнилися, для офлайн-навантажень, наприклад, для машинного навчання і завдань MapReduce.
За досвідом ми знаємо, що найкраще надавати цілі сервери як одиниці еластичної потужності, тому що великі сервіси - це одночасно головні донори та головні споживачі еластичної потужності, і вони оптимізовані для використання цілих серверів. Коли сервер звільняється від онлайн-сервісу в спокійний годинник, брокер ресурсів віддає сервер у тимчасове користування планувальнику, щоб він запускав на ньому офлайн-навантаження. Якщо в онлайн-сервісі виникає пік навантаження, брокер ресурсів швидко відкликає позичений сервер і разом із планувальником повертає його онлайн-сервісу.
Засвоєні уроки та плани на майбутнє
Останні 8 років ми розвивали Tupperware, щоб не відставати від швидкого розвитку Facebook. Ми розповідаємо про те, чого навчилися, і сподіваємося, що це допоможе іншим керувати інфраструктурами, що швидко ростуть:
- Налаштуйте гнучкий зв'язок між панеллю керування та серверами, якими вона керує. Ця гнучкість дозволяє панелі керування керувати серверами в різних датацентрах, допомагає автоматизувати списання та обслуговування кластерів та забезпечує динамічний розподіл потужностей за допомогою еластичних обчислень.
- З єдиною панеллю управління в регіоні стає зручніше працювати із завданнями та простіше керувати великим загальним парком серверів. Зверніть увагу, що панель керування підтримує єдину точку входу, навіть якщо її внутрішня структура розділена з міркувань масштабу або стійкості до відмов.
- Використовуючи модель плагіна, панель управління може повідомляти зовнішні програми про майбутні операції з контейнером. Більше того, stateful-сервіси можуть використовувати інтерфейс плагіна, щоб налаштовувати управління контейнером. За допомогою такої моделі плагіна панель управління забезпечує простоту і при цьому ефективно обслуговує безліч різних stateful-сервісів.
- Ми вважаємо, що еластичні обчислення, за яких ми забираємо у донорських сервісів цілі сервери для пакетних завдань, машинного навчання та інших несрочних сервісів, це оптимальний спосіб підвищити ефективність використання маленьких та енергоефективних серверів.
Ми ще тільки приступаємо до реалізації . Нині близько 20% наших серверів перебувають у загальному пулі. Щоб досягти 100%, потрібно вирішити безліч питань, включаючи підтримку загального пулу для систем зберігання, автоматизування обслуговування, керування вимогами різних клієнтів, підвищення ефективності використання серверів та покращення підтримки робочих навантажень машинного навчання. Нам не терпиться взятися за вирішення цих завдань та поділитися своїми успіхами.
Джерело: habr.com