ДЕНИС СИЛАКОВ, к.ф.-м.н., старший системный архитектор 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]. Наиболее известными являются:

• Marathon, предназначенный для одноразового запуска задач (например, тех или иных сервисов, которые должны работать без перебоев), – этот фреймворк часто рассматривают в статьях про Mesos;
• Chronos – служит для запуска задач по расписанию, поддерживает зависимости между разными задачами;
• Aurora – разработка Twitter, выпущенная под открытой лицензией в 2013 году. Подходит как для запуска сервисов, которые должны работать непрерывно, так и для выполнения задач по расписанию. Однако по признанию самих разработчиков [6] этот фреймворк отнюдь не прост в развертывании и обслуживании (неудивительно, что большинство обзоров Mesos рассматривают Marathon, а не Aurora), хотя и обладает отличной масштабируемостью.

В виде фреймворков реализованы плагин для 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:

# rpm -Uvh http://repos.mesosphere.io/el/7/noarch/RPMS/mesospehere-el-repo-7-1.noarch.rpm

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

# yum install mesos mesosphere-zookeeper

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

# echo 1 > /var/lib/zookeeper/myid

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

# echo 10.0.3.4 > /etc/mesos-master/ip

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

# echo 10.0.3.4 > /etc/mesos-master/hostname

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

# echo 'zk://10.0.3.4:2181,10.0.3.3:2181,10.0.3.2:2181/mesos' > /etc/mesos/zk

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

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

server.1 = 10.0.3.4:2888:3888
server.2 = 10.0.3.3:2888:3888
server.3 = 10.0.3.2:2888:3888

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

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

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

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

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

# echo "2" > /etc/mesos-master/quorum

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

# systemctl disable mesos-slave
# systemctl start mesos-master
# systemctl start zookeeper

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

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

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

Установка Slave

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

# rpm -Uvh http://repos.mesosphere.io/el/7/noarch/RPMS/mesospehere-el-repo-7-1.noarch.rpm

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

# yum install mesos

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

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

# echo 10.0.3.5 >> /etc/mesos-slave/ip
# cp /etc/mesos-slave/ip /etc/mesos-slave/hostname

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

# systemctl disable mesos-master

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

# echo "zk://10.0.3.4:2181,10.0.3.3:2181,10.0.3.2:2181/mesos" > /etc/mesos/zk

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

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

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

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

# yum install docker

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

# echo "docker,mesos" > /etc/mesos-slave/containerizers

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

# echo '5mins' > /etc/mesos-slave/executor_registration_timeout

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

# systemctl start 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 же по моему большому опыту обеспечивает не только стабильную работу ваших сервисов, но и плавное обновление компонентов кластера по мере необходимости.

1. Яремчук С. Знакомимся с Kubernetes. // «Системный администратор», № 1-2, 2017 г. – С. 41-45. URL: http://samag.ru/news/more/2349.
2. Силаков Д. Инструменты управления множеством контейнеров Docker. // «Системный администратор», № 5, 2015 г. – С. 11-15. URL: http://samag.ru/archive/article/2942.
3. Apache Mesos – http://mesos.apache.org.
4. Apache ZooKeeper – https://zookeeper.apache.org/.
5. Перечень фреймворков Mesos – http://mesos.apache.org/documentation/latest/frameworks/.
6. Marathon vs Aurora and their purposes. // Сравнение от разработчиков Aurora на Stackoverflow – https://stackoverflow.com/questions/28651922/marathon-vs-aurora-and-their-purposes.
7. Силаков Д. Virtuozzo Storage. Распределенное отказоустойчивое хранилище данных для ВМ. // «Системный администратор», № 6, 2017 г. – С. 22-26. URL: http://samag.ru/archive/article/3448.

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

Комментарии могут оставлять только зарегистрированные пользователи