- PVSM.RU - https://www.pvsm.ru -
Эффективное и надежное управление кластерами в любом масштабе с Tupperware
Сегодня на конференции Systems @Scale [1] мы представили Tupperware — нашу систему управления кластерами, которая оркестрирует контейнеры на миллионах серверов, где работают почти все наши сервисы. Впервые мы развернули Tupperware в 2011 г., и с тех пор наша инфраструктура разрослась с 1 датацентра [2] до целых 15 геораспределенных датацентров [3]. Все это время Tupperware не стоял на месте и развивался вместе с нами. Мы расскажем, в каких ситуациях Tupperware обеспечивает первоклассное управление кластерами, включая удобную поддержку stateful-сервисов, единую панель управления для всех датацентров и возможность распределять мощности между сервисами в реальном времени. А еще мы поделимся уроками, которые усвоили по мере развития нашей инфраструктуры.
Tupperware выполняет разные задачи. Разработчики приложений с его помощью поставляют приложения и управляют ими. Он упаковывает код и зависимости приложения в образ и поставляет его на серверы в виде контейнеров. Контейнеры обеспечивают изоляцию между приложениями на одном сервере, чтобы разработчики занимались логикой приложения и не думали о том, как найти серверы или контролировать обновления. А еще Tupperware отслеживает работоспособность сервера, и если находит сбой, переносит контейнеры с проблемного сервера.
Инженеры по планированию мощностей с помощью Tupperware распределяют серверные мощности по командам в соответствии с бюджетом и ограничениями. А еще они используют его, чтобы повысить эффективность использования серверов. Операторы датацентров обращаются к Tupperware, чтобы правильно распределить контейнеры по датацентрам и останавливать или перемещать контейнеры на время техобслуживания. Благодаря этому обслуживание серверов, сети и оборудования требует минимального участия человека.
Архитектура Tupperware PRN — это один из регионов наших датацентров. Регион состоит из нескольких зданий датацентров (PRN1 и PRN2), расположенных рядом. Мы планируем сделать одну панель управления, которая будет управлять всеми серверами в одном регионе.
Разработчики приложений поставляют сервисы в виде заданий Tupperware. Задание состоит из нескольких контейнеров, и все они обычно выполняют один и тот же код приложения.
Tupperware отвечает за выделение контейнеров и управление их жизненным циклом. Он состоит из нескольких компонентов:
Tupperware во многом похож на другие системы управления кластерами, например Kubernetes и Mesos [7], но есть и отличия:
Мы разработали эти классные функции, чтобы поддерживать разнообразные stateless- и stateful-приложения в огромном глобальном общем парке серверов.
Tupperware управляет множеством критических stateful-сервисов, которые хранят постоянные данные продуктов для Facebook, Instagram, Messenger и WhatsApp. Это могут быть большие хранилища пар «ключ-значение» (например, ZippyDB [8]) и хранилища данных мониторинга (например, ODS Gorilla [9] и Scuba [10]). Поддерживать stateful-сервисы непросто, ведь система должна гарантировать, что поставки контейнеров выдержат крупномасштабные сбои, включая обрыв сети или отключение электричества. И хотя обычные методы, например, распределение контейнеров по доменам сбоя, хорошо подходят для stateless-сервисов, stateful-севисам нужна дополнительная поддержка.
Например, если в результате серверного сбоя одна реплика базы данных станет недоступна, нужно ли разрешить автоматическое обслуживание, которое обновит ядра на 50 серверах из 10-тысячного пула? Зависит от ситуации. Если на одном из этих 50 серверов есть еще одна реплика той же базы данных, лучше подождать и не терять сразу 2 реплики. Чтобы в динамическом режиме принимать решения об обслуживании и работоспособности системы, нужны сведения о внутренней репликации данных и логике размещения каждого 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 для динамической корректировки скорости обновлений в контейнерах. В итоге веб-уровень способен быстро выполнить несколько выпусков ПО [12] в день без ущерба для доступности.
Когда Tupperware только появился в 2011 году, каждым кластером сервера управлял отдельный планировщик. Тогда кластером Facebook была группа серверных стоек, подключенных к одному сетевому коммутатору, а датацентр вмещал несколько кластеров. Планировщик мог управлять серверами только в одном кластере, то есть задание не могло распространяться на несколько кластеров. Наша инфраструктура росла, мы все чаще списывали кластеры. Раз Tupperware не мог без изменений переносить задание со списываемого кластера на другие кластеры, требовалось много усилий и тщательная координация между разработчиками приложений и операторами датацентра. Этот процесс приводил к напрасной трате ресурсов, когда серверы месяцами простаивали из-за процедуры вывода из эксплуатации.
Мы создали брокер ресурсов, чтобы решить проблему списания кластеров и координировать остальные типы задач по обслуживанию. Брокер ресурсов отслеживает все физические сведения, связанные с сервером, и в динамическом режиме решает, какой планировщик управляет каждым сервером. Динамическая привязка серверов к планировщикам позволяет планировщику управлять серверами в разных датацентрах. Поскольку задание Tupperware больше не ограничено одним кластером, пользователи Tupperware могут указывать, как контейнеры должны распространяться по доменам сбоя. Например, разработчик может объявить свое намерение (допустим: «запусти мое задание на 2 доменах сбоя в регионе PRN»), не указывая конкретные зоны доступности. Tupperware сам найдет подходящие серверы, чтобы воплощать это намерение даже в случае списания кластера или обслуживания.
Исторически сложилось, что наша инфраструктура разделена на сотни выделенных пулов серверов для отдельных команд. Из-за фрагментации и отсутствия стандартов у нас были высокие операционные издержки, а простаивающие серверы было сложнее снова использовать. На прошлогодней конференции Systems @Scale [13] мы представили инфраструктуру как услугу (IaaS) [14], которая должна объединить нашу инфраструктуру в большой единый парк серверов. Но у единого парка серверов свои сложности. Он должен отвечать определенным требованиям:
Мы разделили планировщик на шарды, чтобы решать проблемы с поддержкой большого общего пула. Каждый шард планировщика управляет своим набором заданий в регионе, и это позволяет снизить риск, связанный с планировщиком. По мере роста общего пула мы можем добавлять больше шардов планировщика. Для пользователей Tupperware шарды и прокси планировщика выглядят как одна панель управления. Им не приходится работать с кучей шардов, которые оркестрируют задания. Шарды планировщика принципиально отличаются от планировщиков кластеров, которые мы использовали раньше, когда панель управления была разделена без статического разделения общего пула серверов по топологии сети.
Чем больше наша инфраструктура, тем важнее эффективно использовать наши серверы, чтобы оптимизировать расходы на инфраструктуру и снизить нагрузку. Повысить эффективность использования серверов можно двумя способами:
Узкое место в наших датацентрах — энергопотребление [15]. Поэтому мы предпочитаем небольшие энергоэффективные серверы, которые вместе предоставляют больше вычислительной мощности. К сожалению, на маленьких серверах с маленьким объемом процессорных ресурсов и памяти чрезмерная загрузка менее эффективна. Конечно, мы можем разместить на одном маленьком энергоэффективном сервере несколько контейнеров маленьких сервисов, которые потребляют мало процессорных ресурсов и памяти, но у больших сервисов в такой ситуации будет низкая производительность. Поэтому мы советуем разработчикам наших больших сервисов оптимизировать их, чтобы они использовали серверы целиком.
В основном, мы повышаем эффективность использования с помощью эластичных вычислений. Интенсивность использования многих наших крупных сервисов, например, ленты новостей, функции сообщений и фронтенд-веб-уровня, зависит от времени суток. Мы намеренно уменьшаем масштаб онлайн-сервисов в спокойные часы и используем освободившиеся серверы для офлайн-нагрузок, например, для машинного обучения и заданий MapReduce.
По опыту мы знаем, что лучше всего предоставлять целые серверы в качестве единиц эластичной мощности, потому что большие сервисы — это одновременно главные доноры и главные потребители эластичной мощности, и они оптимизированы для использования целых серверов. Когда сервер освобождается от онлайн-сервиса в спокойные часы, брокер ресурсов отдает сервер во временное пользование планировщику, чтобы он запускал на нем офлайн-нагрузки. Если в онлайн-сервисе возникает пик нагрузки, брокер ресурсов быстро отзывает одолженный сервер и вместе с планировщиком возвращает его онлайн-сервису.
В последние 8 лет мы развивали Tupperware, чтобы не отставать от быстрого развития Facebook. Мы рассказываем о том, чему научились, и надеемся, что это поможет другим управлять быстро растущими инфраструктурами:
Мы еще только приступаем к реализации единого глобального общего парка серверов [14]. Сейчас около 20% наших серверов находятся в общем пуле. Чтобы достичь 100%, нужно решить множество вопросов, включая поддержку общего пула для систем хранения, автоматизирование обслуживания, управление требованиями разных клиентов, повышение эффективности использования серверов и улучшение поддержки рабочих нагрузок машинного обучения. Нам не терпится взяться за решение этих задач и поделиться своими успехами.
Автор: nAbdullin
Источник [17]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/facebook/320465
Ссылки в тексте:
[1] конференции Systems @Scale: https://atscaleconference.com/events/systems-scale-2019/
[2] 1 датацентра: https://www.facebook.com/notes/prineville-data-center/press-release-facebook-opens-first-data-center-in-prineville-oregon/10150150581753133/
[3] 15 геораспределенных датацентров: https://code.fb.com/data-center-engineering/data-centers-2018/
[4] Image: https://habrastorage.org/webt/e7/q1/oz/e7q1ozhv85xlsvgczzofpgwoikg.jpeg
[5] Kubernetes: https://kubernetes.io/
[6] прошлогодней конференции Systems @Scale: https://atscaleconference.com/videos/holding-it-in-scale-the-systemd-tails-on-containers-composable-services-and-runtime-fun-times/
[7] Mesos: http://mesos.apache.org/
[8] ZippyDB: https://www.youtube.com/watch?v=DfiN7pG0D0k
[9] ODS Gorilla: https://www.vldb.org/pvldb/vol8/p1816-teller.pdf
[10] Scuba: https://research.fb.com/publications/scuba-diving-into-data-at-facebook/
[11] Image: https://habrastorage.org/webt/xu/xi/5q/xuxi5qpox1v3gpc6khbipxgna0i.jpeg
[12] веб-уровень способен быстро выполнить несколько выпусков ПО: https://www.facebook.com/watch/?v=2131703120436114
[13] Systems @Scale: https://code.fb.com/core-data/systems-scale-2018-recap/
[14] инфраструктуру как услугу (IaaS): https://atscaleconference.com/videos/systems-scale-2018-compute-as-a-service-moving-toward-a-global-shared-fleet/
[15] энергопотребление: https://www.facebook.com/notes/facebook-engineering/designing-a-very-efficient-data-center/10150148003778920/
[16] Image: https://habrastorage.org/webt/6w/zu/dp/6wzudppzm9tobgoryvtrssaxlra.jpeg
[17] Источник: https://habr.com/ru/post/455579/?utm_campaign=455579&utm_source=habrahabr&utm_medium=rss
Нажмите здесь для печати.