apache mesos что это

ДЕНИС СИЛАКОВ, к.ф.-м.н., старший системный архитектор Virtuozzo, dsilakov@virtuozzo.com

Apache Mesos
Знакомимся с конкурентом Kubernetes и Docker Swarm

С ростом популярности контейнеризации приложений растет спрос на приложения, способные управлять большим количеством контейнеров. На слуху прежде всего Kubernetes [1] и Docker Swarm [2]. Однако у них есть и другие достойные открытые конкуренты. В этой статье мы рассмотрим Mesos, развиваемый фондом Apache

Начавшись как исследовательский проект в одной из лабораторий университета Калифорнии в Беркли, Mesos [3] был впервые представлен в 2009 году под именем Nexus. Некоторое время проект находился в ранге исследовательских, аверсия «1» была выпущена только в 2016 году под крылом Apache Software Foundation.

Впрочем, к этому времени Mesos уже использовался в Twitter, Airbnb, eBay и даже в сервисе Apple Siri. Однако, несмотря на таких серьезных пользователей, открытость и покровительство Apache, обзоров Mesos в сети в настоящее время нетак уж и много. И пользователей, судя по всему, тоже. Тем не менее продукт этот заслуживает внимания – не только ради расширения кругозора, но и с целью практического применения благодаря стабильной работе и относительной простоте развертывания и настройки.

В данной статье мы рассмотрим процесс создания кластера Mesos на машинах под управлением Virtuozzo Linux и его интеграцию с фреймворком Jenkins с целью динамического создания контейнеров для выполнения задач непрерывной интеграции.

Архитектура

Суть работы Mesos сводится к объединению физических ресурсов нескольких серверов в единый виртуальный пул, из которого они будут выделяться для выполнения конкретных задач. Можно сравнить Mesos с планировщиком ресурсов традиционных ОС – с той разницей, что физически подвластные ему ресурсы расположены на разных серверах. Однако распределенная природа дает Mesos ряд принципиально новых возможностей – например, способность переживать потерю части «железных» ресурсов с сохранением всех работающих процессов.

Управляемые Mesos машины объединяются в кластер, ядром которого являются управляющие (master) серверы. В кластере может быть (и должно быть для обеспечения отказоустойчивости) несколько мастер-серверов. В любой момент активным является только один из них. Координация мастеров и выбор активного осуществляются с помощью сервиса ZooKeeper [4].

Сервисные машины-узлы (slaves) предоставляют мощности для выполнения задач. Задачи выполняются в отдельных контейнерах – поддерживается как Docker, так и собственная контейнеризация Mesos, также основанная на штатных механизмах Linux (cgroups).

Mesos предоставляет ресурсы для выполнения тех или иных задач, но сам по себе никаких задач запускать не может – для этого используются другие приложения, называемые фреймворками.

Полный список фреймворков доступен на [5]. Наиболее известными являются:

В виде фреймворков реализованы плагин для Jenkins, позволяющий запускать машины-узлы Jenkins (Jenkins slaves) на кластере Mesos. При этом осуществляется динамический мониторинг количества запущенных машин – при необходимости добавляются новые, а при длительном простое удаляются излишние. Аналогичным образом реализованы плагины для Hadoop, Apache Spark и Apache Torque.

Рассмотрим использование Mesos совместно с Jenkins, основанное на опыте работы с этой комбинацией. Но для начала давайте создадим кластер Mesos. В нашем примере кластер будет состоять из трех мастер-серверов с адресами 10.0.3.2,10.0.3.3 и 10.0.3.4 и одного вычислительного узла (slave) с адресом 10.0.3.5. Количество вычислительных узлов можно увеличивать согласно вашим нуждам – они настраиваются абсолютно одинаково. Знать количество master-машин и их адреса необходимо на начальном этапе, чтобы не менять потом конфигурацию всех узлов кластера.

Установка master-сервера

В данной статье мы будем устанавливать все компоненты Mesos на машины под управлением Virtuozzo Linux 7. Все инструкции могут быть без изменения использованы для машин под управлением CentOS 7 и ее производных.

Для развертывания мастер-серверов на каждом из них необходимо добавить RPM-репозитории Mesos:

и установить соответствующие пакеты:

Для идентификации в ZooKeeper каждому мастеру (ниже мы будем в качестве примера использовать 10.0.3.4) надо вручную выбрать и прописать уникальный числовой идентификатор в диапазоне от 1 до 255:

явно прописать IP-адрес, по которому он будут доступен:

и имя машины (hostname). Если разрешимого через DNS имени у машины нет, в этот файл надо также прописать IP-адрес, пустовать он не должен:

В отдельном файле настроек Mesos необходимо указать адреса всех мастер-нод:

(2181 – это порт, который по умолчанию слушает ZooKeeper).

Для самого ZooKeeper необходимо в файл /etc/zookeeper/conf/zoo.cfg добавить адреса мастер-нод в следующем виде:

Здесь 1, 2, 3 – не порядковые номера, а идентификаторы, которые указаны в файле /var/lib/zookeeper/myid каждого сервера.

Порт 2888 используется для взаимодействия с активным мастером, 3888 – для выбора нового мастера при необходимости.

От ZooKeeper в первую очередь требуется возможность выбрать лидера среди имеющихся мастер-узлов. Производится это с помощью алгоритма распределенного консенсуса ZAB. Для работы алгоритма необходимо указать значение кворума – минимально необходимое количество узлов, которые должны участвовать в выборе лидера. В общем случае это значение должно быть больше половины общего количество узлов, иначе возможна ситуация, когда ваш кластер из-за неполадок в сети распадется на две невзаимодействующие части, каждая из которых сможет выбрать себе своего лидера.

Поэтому минимальна конфигурация кластера Mesos при условии, что вы заботитесь о его отказоустойчивости – это три мастер-сервера и значение кворума, равное двум. Такая конфигурация позволяет пережить потерю одного мастера. Достаточно типичной является конфигурация 5:3, при которой можно потерять два узла из пяти (напомним, что исходя из схожих соображений выбираются рекомендуемые настройки Virtuozzo Storage [7]).

Значение кворума указывается в отдельном файле настроек:

В завершение отключаем сервис mesos-slave и рестартуем mesos и zookeeper (при установке пакетов все эти сервисы добавляются в набор загружаемых при старте системы, но не стартуют сразу ввиду отсутствия конфигурации):

После установки веб-интерфейс Mesos (см. рис. 1) будет доступен по адресу любого из мастеров на порту 5050.

Рисунок 1. Веб-интерфейс Mesos доступен по адресу любой из master-машин

По нашему опыту этот веб-интерфейс удобно использовать для мониторинга происходящих в кластере событий (особенно если что-то пошло не так; впрочем, в таких случаях иногда полезнее посмотреть в журналы в директории /var/log/mesos на мастер-узлах либо на вычислительном узле, где произошла ошибка). Управлять же кластером особой необходимости не возникает; настройка и контроль реальных задач осуществляется в используемом у вас фреймворке (например, Marathon имеет свой веб-интерфейс, а конфигурация плагина Jenkins осуществляется в самом Jenkins).

Установка Slave

Для установки вычислительных узлов используются пакеты из того же репозитория, что и для мастер-нод:

Из этих репозиториев достаточно установить пакет Mesos:

Обратите внимание, что это тот же пакет, который используется для запуска мастер-нод. И это неудивительно – роль вычислительного узла и мастера можно совмещать.

Аналогично мастер-нодам необходимо для каждой машины прописать IP-адрес и имя машины:

Если на данной машине установлен только slave, то надо отключить запуск сервиса mesos-master:

Все мастер-серверы необходимо указать в /etc/mesos/zk:

Вычислительные узлы будут время от времени опрашивать ZooKeeper на предмет текущего лидера и подключаться к нему, предоставляя свои ресурсы.

Изначально в Mesos для запуска задач использовались собственные контейнеры, но в соответствии с веянием времени была добавлена поддержка Docker. Что именно будет использоваться, зависит от конкретного фреймворка и его настроек.

Например, плагин Jenkins по-прежнему создает Mesos-контейнеры, а вот Marathon (входящий в официальные репозитории Mesos) использует Docker. Несмотря на последний факт, по умолчанию Docker-контейнеризация на вычислительных узлах недоступна, требуется выполнить ряд действий, чтобы ее включить.

Во-первых, необходимо установить сам Docker:

А затем добавить его в список доступных типов контейнеризации:

При использовании Docker рекомендуется увеличить тайм-аут регистрации нового контейнера – надо закладываться на ситуацию, когда нужного docker-образа нет в локальном кэше и его надо сначала скачать по сети:

Наконец запустим сервис mesos-slave:

Если все прошло успешно, новый сервисный узел появится на вкладке Agents в веб-интерфейсе Mesos (см. рис. 2).

Рисунок 2. По мере ввода в строй новых сервисных узлов они появляются в соответствующей вкладке веб-интерфейса Mesos

Использование совместно с Jenkins

В данной статье мы рассмотрим настройку Jenkins на использование Mesos для размещения вычислительных узлов (Jenkins slaves). Данный функционал реализован с помощью плагина mesos, однако перед его установкой в Jenkins необходимо выполнить ряд подготовительных действий (не считая развертывания самого Jenkins – далее мы предполагаем, что он уже установлен и работает на машине, не входящей в кластер Mesos).

Во-первых, на каждой машине с Mesos slave необходимо завести пользователя с именем jenkins, установить java (мы использовали стандартный пакет java-1.8.0-openjdk из репозиториев Virtuozzo Linux) и прописать экспорт переменной JAVA_HOME в профиль пользователя.

На сервер Jenkins необходимо добавить библиотеку libmesos для взаимодействия с кластером. В нашей конфигурации Jenkins также работает на машине с Virtuozzo Linux, поэтому взять библиотеку можно из RPM-пакета mesos либо непосредственно с одной из машин Mesos-кластера – она располагается в директории /usr/lib, имя ее начинается на libmesos (например, libmesos-1.5.0.so). Обратите внимание, что в этой директории также есть файл /usr/lib/libmesos.so, но онявляется символьной ссылкой на реальную библиотеку.

Положить файл с библиотекой необходимо на сервер Jenkins в любое место, доступное фреймворку, – например, в /usr/local/lib/. Путь к ней необходимо будет указать при настройке плагина.

Теперь можно идти в веб-интерфейс Jenkins и искать плагин mesos в списке секции Manage Plugins. Вместе с ним необходимо установить плагин metrics – хотя он и отмечен в документации как опциональный, без него в нашем Jenkins плагин mesos работать отказался, попытка его использовать приводила к генерации исключения Java.

После установки плагинов переходим в секцию настроек Jenkins (Configure). Внизу этой секции у вас должна появиться кнопка Add a new cloud, при нажатии на которую в качестве одного из вариантов должна быть доступна опция Mesos cloud (см. рис. 3).

Рисунок 3. После установки плагина mesos вы сможете добавить «Облако Mesos» для размещения вычислительных узлов Jenkins

При ее выборе обязательно надо указать путь к библиотеке mesos на сервере Jenkins (параметре Mesos native library path), URL самого Jenkins, а также адреса мастер-узлов Mesos. В последнем поле можно указать адрес конкретного мастера, а можно сразу ссылку Zookeer (zk://10.0.3.4:2181,10.0.3.3:2181,10.0.3.2:2181/mesos).

Тут же можно нажать кнопку Test connection для проверки соединения с кластером (см. рис. 4). Обратите внимание, что если вы указали адрес в формате ZooKeeper, то сначала необходимо нажать кнопку Save.

Рисунок 4. Базовая настройка интеграции Jenkins и Mesos сводится к вводу параметров кластера

В расширенных (Advanced) настройках можно указать, следует ли создавать контейнеры в кластере по мере необходимости (On-demand framework registration) либо вы будете создавать их вручную. Нам интересен вариант, когда контейнеры создаются автоматически – если на Jenkins будет запущено слишком много задач и им не станет хватать машин для выполнения, автоматически будет создан новый контейнер в кластере Mesos (естественно при наличии ресурсов).

На этой же странице указывается ограничение по ресурсам создаваемых узлов. Прежде всего сколько им будет доступно процессорного времени и памяти.

При желании можно указать метку (Label), которая будет присваиваться всем вычислительным узлам Jenkins, создаваемым в кластере Mesos. Это позволит вам регулировать, какие задачи можно запускать на таких узлах, а какие – нет.

Наконец, вместо «родных» контейнеров Mesos можно использовать Docker. Главным преимуществом такого выбора является возможность запускать контейнер из произвольного образа, который вы укажете, так что можно подготовить образ под свои нужды, с теми программами, которые вам нужны.

В случае же использования контейнеров Mesos вам придется довольствоваться тем, что установил в них плагин. Такой подход избавляет от необходимости готовить контейнер или образ самостоятельно, и этого хватает для большинства базовых задач Jenkins, сводящихся к выполнению тех или иных плагинов с нужными параметрами. Но если вы запускаете свои собственные скрипты, то с большой вероятностью вам надо переключаться на Docker. В таком случае вам надо будет указать, какой контейнер запускать и с какими параметрами.

Проверить, как ведет себя связка Jenkins и Mesos, достаточно легко – просто запустите несколько «долгих» задач, общее количество которых будет превышать число имеющихся у вас в данный момент узлов Jenkins. При этом помните, что плагин mesos создает новый контейнер не сразу по мере появления новых нераспределенных задач в очереди, а только если узлов для выполнения задач не хватает уже в течение нескольких минут. В таком поведении, безусловно, естьлогика, ведь создание контейнера происходит не мгновенно (так что вы вполне можете наблюдать за появлением нового узла непосредственно в веб-интерфейсе Jenkins, см. рис. 5).

Рисунок 5. Если Jenkins не хватает узлов для выполнения задач, Mesos оперативно развернет новые контейнеры

Заключение

С точки зрения производительности и отказоустойчивости Mesos показывает вполне достойные характеристики и по праву считается конкурентом Kubernetes и Docker Swarm.

В данной статье мы рассмотрели его использование совместно с Jenkins, однако в сети можно найти немало руководств по запуску произвольных приложений и сервисов. В то же время этому проекту явно не хватает раскрученности, что сказывается на скорости его развития и реализованном функционале.

Например, для развертывания кластера Mesos по-прежнему предлагается заходить на каждую машину и выполнять на ней установку пакетов и конфигурацию, в то время как для того же Kubernetes активно развиваются средства автоматического развертывания кластера.

Также можно отметить более гибкий подход Kubernetes к обеспечению устойчивости кластера к исчезновению мастер-узлов.

Однако если вы не гонитесь за последними новшествами, то Mesos – неплохой выбор. В конце концов активное развитие многих проектов нередко включает в себя не только появление нового функционала, но и переделку (а то и поломку) существующего. Как следствие, переход на новую версию таких продуктов может вызвать немало проблем у системного администратора.

Mesos же по моему большому опыту обеспечивает не только стабильную работу ваших сервисов, но и плавное обновление компонентов кластера по мере необходимости.

Ключевые слова: Mesos, Docker, виртуализация, Linux.

Источник

Работа с Mesosphere: вступление

Что такое Mesosphere?

Mesosphere – это программное решение, которое расширяет возможности управления кластерами Apache Mesos; программа обладает дополнительными компонентами, предоставляющими новый способ управления серверными инфраструктурами. В сочетании с другими компонентами (например, с Marathon и Chronos) Mesosphere позволяет легко масштабировать приложения, избегая многих связанных с этим процессом проблем.

Mesosphere обладает такими функциями, как планирование приложений, масштабирование приложений, отказоустойчивость и самовосстановление. Кроме того, эта программа обеспечивает обнаружение сервисов (service discovery) и объединение портов приложений.

Чтобы дать более полное представление о том, как работают вышеупомянутые функции Mesosphere, данное руководство предоставляет краткое описание каждого ключевого компонента программы, начиная с Apache Mesos, и демонстрирует использование каждого из них в контексте Mesosphere.

Краткий обзор Apache Mesos

Apache Mesos – это открытый менеджер кластеров, который упрощает запуск приложений на масштабируемом кластере серверов и является «сердцем» системы Mesosphere.

Mesos обладает большим количеством функций:

Архитектура Mesos

Архитектура Apache Mesos состоит из демонов master и slave (то есть, ведущих и ведомых демонов) и фреймворка.

Краткий обзор этих компонентов и некоторых важных терминов:

Ведущий демон (или Master daemon) запускается на ведущем узле (или ноде) и управляет ведомыми демонами.

Ведомый демон (или Slave daemon) работает на ведущей ноде и выполняет задачи фреймворка.

Фреймворк (или приложение Mesos) состоит из планировщика, который совмещается с нодой master, чтобы получать офферы (resource offers) исполнителей (executors), запускающих задачи на нодах slave. Примерами фреймворков Mesos могут служить Marathon, Chronos и Hadoop.

Оффер (Offer) – это список доступных ресурсов CPU и памяти slave ноды. Все slave ноды отправляют офферы ноде master, который передает их доступным фреймворкам.

Задача (Task) – запланированная фреймворком единица работы, которая выполняется на ведомом узле. Задачей может быть что угодно, начиная с команды или скрипта bash и заканчивая SQL-запросами и процессами Hadoop.

Apache ZooKeeper (или ZK): программное обеспечение, которое используется для координации master нод.

Такая архитектура позволяет Apache Mesos точно распределять ресурсы кластера между приложениями согласно их требованиям. Объем ресурсов, предлагаемых конкретному фреймворку, определяется согласно политике, установленной master нодой. Планировщик решает, какие из офферов использовать, а затем он сообщает Mesos, какие задачи должны быть выполнены, и Mesos запускает эти задачи на соответствующих slave нодах. Когда же задачи выполнены и ранее расходуемые ресурсы освобождаются, этот цикл повторяется снова для планировки других задач.

Высокая доступность

Высокая доступность (High Availability, или HA) master узлов Mesos в кластере активируется с помощью программы Apache Zookeeper, которая используется для репликации master нод и формирует кворум (quorum). Также ZooKeeper координирует выборы лидера кластера и лидера среди компонентов Mesos (то есть, slave нод и фреймворков).

Для настройки высокой доступности нужно, по крайней мере, три master ноды; этого достаточно для проведения кворума. Но чтобы сделать производственную среду более гибкой, рекомендуется использовать пять master нод; такой подход позволяет проводить кворум, оставляя две master ноды в автономном режиме.

Более подробную информацию можно найти в официальной документации Apache Mesos.

Краткий обзор Marathon

Marathon – это фреймворк Mesos, который предназначен для запуска долго работающих приложений; в Mesosphere данная программа служит в качестве замены традиционной системы инициализации (init system). Marathon имеет много функций, которые упрощают запуск приложений в кластерной среде; среди таких функций можно выделить высокую доступность, ограничение нод, диагностику приложений, интерфейс для scriptability и обнаружения сервисов, а также дружественный пользовательский веб-интерфейс. Кроме того, благодаря Marathon программа Mesosphere имеет функции масштабирования и самовосстановления.

Marathon можно использовать для запуска других фреймворков Mesos или процессов стандартной оболочки. Поскольку данный фреймворк предназначен для запуска долго работающих приложений, он может обеспечить работу приложения даже в случае отказа slave ноды, на котором запущено приложение.

Более подробную информацию о Marathon можно найти на странице GitHub.

Краткий обзор Chronos

Chronos – это фреймворк Mesos, изначально разработанный компанией Airbnb в качестве замены cron. Chronos является полнофункциональным, распределенным и отказоустойчивым планировщиком Mesos, который облегчает организацию работы программы и составление наборов задач. Данный фреймворк включает в себя программный интерфейс для разработки скриптов планирования задач (jobs) и веб-интерфейс для простоты использования.

В Mesosphere Chronos дополняет Marathon, предоставляя еще один способ запуска приложений (согласно графику или каким-либо другим условиям, например, в соответствии с завершением работы другого приложения). Также данный фреймворк способен составлять расписания для запуска приложений/процессов на нескольких slave нодах Mesos; кроме того, он предоставляет статистику об ошибках и успехах. Посетите страницу GitHub, чтобы узнать о Chronos больше.

Краткий обзор HAProxy

HAProxy – популярное решение обратного проксирования и балансировки нагрузки с открытым исходным кодом. HAProxy может быть использован в Mesosphere для маршрутизации сетевого трафика известных хостов (как правило, это master ноды Mesos), на действующие сервисы, запущенные на slave нодах Mesos. Для динамической настройки HAProxy можно использовать функция обнаружения сервисов Mesos; это позволит маршрутизировать входящий трафик на соответствующие slave ноды бэк-энда.

Итоги

Разработанная с упором на кластеризацию и масштабируемость, система Mesosphere использует парадигмы серверной инфраструктуры, которые сначала могут показаться непонятными. Каждый базовый компонент Mesosphere является решением типичных проблем кластеризации и масштабирования серверной инфраструктуры. Система Mesosphere в целом призвана максимально упростить работу с кластером, полностью устранив эти проблемы.

Источник

• ← что полезнее виски или ром
• Что испечь с маскарпоне бисквит →