Для будущих узлов я выбрал следующие адреса:
 Таким образом, имея 6 готовых серверов (виртуальных машин) с Ubuntu 14.04, мы готовы к бою. MESOS MASTERS / MARATHON INSTALLATION Выполняем полностью аналогичные действия на всех 3-х Mesos мастер-серверах. Добавляем Mesos / Marathon-репозитории: Mesos и Marathon требуют Java-машину для работы. Поэтому установим последнюю от Oracle: Проверим работает ли Java: Хотя, кажется, OpenJDK также подходит. На каждый из будущих мастеров проинсталлируем Mesos и Marathon: Между прочим, фреймворк Marathon написан на Scala. По зависимостям также будет установлено Zookeeper. Укажем ему адреса наших мастер нод: 2181 — порт на котором работает Zookeeper. Для каждой ноды мастера выберем уникальный ID: Для второго и третьего сервера я выбрал 2 и 3 соответственно. Номера можно выбирать от 1 до 255. Редактируем /etc/zookeeper/conf/zoo.cfg: 1,2,3 — ID, что мы указали в /etc/zookeeper/conf/myid каждого сервера.
2888 — порт, использующий Zookeeper для коммуникаций с выбранным мастером, а 3888 — для проведения новых выборов, если с действующим мастером что-то случилось. Переходим к настройке кворума. Кворум — это минимальное количество рабочих узлов, которое требуется для выбора нового лидера. Эта опция необходима для предотвращения Split-brain кластера. Представим себе, что кластер состоит только из 2-х серверов с кворумом 1. В таком случае только наличие 1 рабочего сервера достаточно для выбора нового лидера: собственно каждый сервер может сам выбрать себе лидером. В случае падения одного из серверов такое поведение более чем логично. Однако, что будет, когда только сетевое соединение между ними нарушится? Правильно: вероятный вариант, когда каждый из серверов будет по очереди перетягивать на себя основной трафик. В случае, если же такой кластер состоит из баз — то возможна вообще потеря эталонных данных и будет даже не понятно с чего восстанавливаться. Итак, наличие 3-х серверов — это минимум для обеспечения высокой доступности. Значение кворума в таком случае — 2. Если только один сервер перестанет быть доступным — остальные 2 смогут кого-то выбрать между собой. Если же два сервера испытывают поломки или узлы не видят друг друга в сети — группа, для сохранности данных, вообще не будет проводить избрание нового мастера до достижения необходимого кворума (появления одного из серверов в сети). Почему не имеет особого смысла выбирать 4 (четное количество) серверов? Потому что в таком случае, как и в случае с 3-мя серверами, только отсутствие одного сервера некритична для работы кластера: падение второго сервера будет фатальной для кластера по причине возможного Split-brain. Но в случае 5 серверов (и уровня кворума 3) уже падения 2 серверов не критично. Вот так. Так что лучше всего выбирать кластеры с 5 и более узлов, а то кто знает, что может произойти во время технического обслуживания на одном из них. В случае, если Zookeeper будет вынесен отдельно, Mesos-мастеров может быть любое, в т.ч. и парное, количество. Указываем одинаковый уровень кворума для мастеров: Указываем IP соответственно для каждого узла: Если у серверов отсутствует доменнейм — копируем IP-адрес для использования его в качестве имени хоста: Аналогично для 10.0.3.12 и 10.0.3.13. Настраиваем фреймворк Marathon. Создадим директорию для конфигурационных файлов и скопируем в нее хостнейм: Скопируем для Marathon настройки Zookeeper: Последние несколько отредактируем: И наконец запрещаем загрузки демону mesos-slave на мастерах: Перезапускаем сервисы на всех узлах: Откроем веб-панель Mesos на порту 5050:
 Проверяем коректно ли была установлена Java: Необходимо также запретить запуск процессов Zookeeper и Mesos-master, т.к. они здесь не нужны: Укажем домены и IP-адреса для слейва: Аналогичное действие также необходимо выполнить для 10.0.3.52 и 10.0.3.53 (конечно, с отдельным адресом для каждого сервера). И описать все мастера в /etc/mesos/zk: Слейв будут время от времени опрашивать Zookeeper на предмет текущего лидера и подключаться к нему, предоставляя свои ресурсы. Во время запуска слейва, может возникнуть следующая ошибка: В таком случае нужно внести изменения в /etc/default/mesos-slave: И запустить mesos-slave снова: Если все будет выполнено верно, Слейвы подключатся в качестве ресурсов для текущего лидера:
 С активацией Docker в Mesos также особо нет ничего сложного. Сначала необходимо проинсталлировать сам Docker на всех слейвах кластера: Для проверки корректности установки запустим тестовый контейнер hello-world: Указываем новый тип контейнеризации для Mesos Slaves: Создание нового контейнера, обаза которого еще нет в локальном кэше, может занять больше времени. Поэтому поднимем значение таймаута регистрации нового контейнера в фреймворка: Ну и, как обычно, перегрузим сервис после подобных изменений: Создадим новую задачу в Marathon и запустим ее в Docker-контейнере. JSON будет выглядеть следующим образом: То есть в контейнере будет запущен вечный цикл while с выводом текущей даты. Несложно, правда?
Docker.json можно прямо влить через веб-панель Marathon, активировав переключатель JSON при создании новой задачи:
 Конечно, также ко всем нодам кластера Mesos (и других нод с которых будет производится доступ к сервисам в контейнерах) стоит добавить адрес сервера Mesos-DNS в качестве основного в /etc/resolv.conf, на первую позицию: После изменения resolv.conf, стоит убедиться, что все имена резовляться именно через 10.0.3.60: Для демонстрации работы Mesos-DNS запустим через Marathon следующую задачу: Эта задача установит контейнер с Nginx, а Mesos-DNS зарегистрирует для него имя nginx.marathon.mesos: Таким образом будет работать балансировка между двумя нодами на уровне DNS. Стоит заметить, что Mesos-DNS, кроме А-записей, также создает SRV-запись в DNS для каждой задачи (контейнера). SRV-запись связывает название сервиса и хостнейм-IP-порт на котором он доступен. Проверим SRV-запись для задачи nginx, что мы запустили раньше (не масштабируемой до двух инстансов): Для того, чтобы не вносить изменения в настройки resolv.conf каждого сервера — можно внести изменения к внутреннему DNS инфраструктуры. В случае Bind9 эти изменения будут выглядеть так: А в конфиге Mesos-DNS (представим, что он сейчас по адресу 192.168.0.100) следует внести следующие изменения: "externalon": false указывает на то, что Mesos-DNS имеет право отказывать в обслуживанию запросам, которые пришли не с доменов mesos. После внесенных изменений необходимо перегрузить Bind и Mesos-DNS. Mesos-DNS также имеет API https://docs.mesosphere.com/1.7/usage/service-discovery/mesos-dns/http-interface/, который может помочь в решении задач автоматизации. Mesos-DNS, кроме создания записей для работающих задач, автоматически создает записи (A и SRV) также для Mesos Slaves, Mesos Masters (и отдельно для лидера среди них), фреймворков. Все для нашего с вами удобства.
 То есть большинство проблем возникают вследствие самой природы DNS. Именно для устранения этих недостатков стартовал подпроект Marathon-lb. Marathon-lb — это скрипт на языке Python, который опрашивает Marathon API и на основе полученных данных (адрес Mesos-слейва, на котором физически находится контейнер и порт работы сервиса) создает конфигурационный файл HAproxy и делает reload его процесса. Однако стоит отметить, что Marathon-lb работает только с Marathon, в отличие от Mesos-DNS. Поэтому в случае другого фреймворка нужно будет искать другие программные решения.
 Для настройки Marathon-lb я использовал отдельную виртуальную машину с адресом 10.0.3.61. В официальной документации также приведены варианты запуска Marathon-lb в docker-контейнере, в качестве задачи, запущенной с Marathon Настройка Marathon-lb и HAproxy проходит довольно не сложно. Нужен последний стабильный релиз HAproxy и для Ubuntu 14.04 это версия 1.6: Загружаем код проекта Marathon-lb: Установим необходимые для работы python-пакеты: Генерируем ключи, которые требует по-умолчанию marathon-lb: Выполняем первый запуск marathon-lb: Если не возникло серьезных ошибок — можно переходить к созданию задачи в Marathon: Сразу после перехода задачи в режим Running, опросим Marathon: Название группы должно совпадать с ярлыком "HAPROXY_GROUP" в поставленной задаче. Это сделано для возможности использовать несколько балансировщиков, которые будут обслуживать разные группы. С последнего вывода видим в haproxy.cfg было добавлено проксирование из порта 10001 в адрес 10.0.3.52:31187. И HAproxy действительно открыл соответствующий порт: Конфигурация haproxy.cfg теперь выглядит так: Соответственно, если будет 2 инстанса в задаче на Marathon — то будет и 2 адреса в бэкенде nginx-internal_10001. Но опять таки, помнить и использовать номер порта соединения — не самая лучшая затея. Поэтому идеальный вариант — это использование virtual host mapping для HAproxy. Суть этого всего в том, что в зависимости от запрошенного домена в HAproxy, будет происходить переадресация на конечный слейв и порт к нему. Поставим еще одну задачу для того чтобы проверить все это в деле: Итак, мы добавили дополнительный ярлык "HAPROXY_0_VHOST" с указанием домена, который должен проксировать HAproxy. Выждав минуту, запускаем marathon_lb.py: И проверим конфигурационный файл HAproxy: Поэтому теперь, если будет запрошен домен nginx.external.com, который предварительно необходимо привязать к серверу HAproxy, запрос будет переадресован на порт и хост задачи на Mesos слейве. Проверим результат в браузере:
 Первый вариант реализации — это marathon-autoscale. Скрипт по API Marathon может следить за использованием CPU/памяти задачи и поднимать количество инстансов в зависисмости от заданных условий. Другой, более интеллектуальный, — marathon-lb-autoscale. Этот вариант основан на опросе Marathon-lb сервиса. В случае превышения определенного уровня запросов в единицу времени — скрипт будет поднимать количество инстансов задачи в Marathon. Ну вот и все. Надеюсь вы не устали читать все это. Конечно же, в статье могут быть неточности — поэтому небезразличные могут написать об этом в комментариях. Эта же статья на украинском языке http://blog.ipeacocks.info/2016/06/mesos-cluster-management.html Ссылки: Getting Stated https://www.digitalocean.com/community/tutorials/how-to-configure-a-production-ready-mesosphere-cluster-on-ubuntu-14-04
https://open.mesosphere.com/advanced-course/introduction/
https://open.mesosphere.com/getting-started/install/
http://iankent.uk/blog/a-quick-introduction-to-apache-mesos/
http://frankhinek.com/tag/mesos/
https://mesosphere.github.io/marathon/docs/service-discovery-load-balancing.html
https://mesosphere.github.io/marathon/
https://mesosphere.github.io/marathon/docs/ports.html
https://beingasysadmin.wordpress.com/2014/06/27/managing-docker-clusters-using-mesos-and-marathon/
http://mesos.readthedocs.io/en/latest/ Docker http://mesos.apache.org/documentation/latest/containerizer/#Composing
http://mesos.apache.org/documentation/latest/docker-containerizer/
https://mesosphere.github.io/marathon/docs/native-docker.html Mesos-DNS https://tech.plista.com/devops/mesos-dns/
http://programmableinfrastructure.com/guides/service-discovery/mesos-dns-haproxy-marathon/
http://mesosphere.github.io/mesos-dns/docs/tutorial-systemd.html
http://mesosphere.github.io/mesos-dns/docs/configuration-parameters.html
https://mesosphere.github.io/mesos-dns/docs/tutorial.html
https://mesosphere.github.io/mesos-dns/docs/tutorial-forward.html
https://github.com/mesosphere/mesos-dns Marathon-lb https://mesosphere.com/blog/2015/12/04/dcos-marathon-lb/
https://mesosphere.com/blog/2015/12/13/service-discovery-and-load-balancing-with-dcos-and-marathon-lb-part-2/
https://docs.mesosphere.com/1.7/usage/service-discovery/marathon-lb/
https://github.com/mesosphere/marathon-lb
https://dcos.io/docs/1.7/usage/service-discovery/marathon-lb/usage/ Autoscaling https://docs.mesosphere.com/1.7/usage/tutorials/autoscaling/
https://docs.mesosphere.com/1.7/usage/tutorials/autoscaling/cpu-memory/
https://docs.mesosphere.com/1.7/usage/tutorials/autoscaling/requests-second/
https://github.com/mesosphere/marathon-autoscale Other https://clusterhq.com/2016/04/15/resilient-riak-mesos/
https://github.com/CiscoCloud/mesos-consul/blob/master/README.md#comparisons-to-other-discovery-software
http://programmableinfrastructure.com/guides/load-balancing/traefik/
https://opensource.com/business/14/8/interview-chris-aniszczyk-twitter-apache-mesos
http://www.slideshare.net/akirillov/data-processing-platforms-architectures-with-spark-mesos-akka-cassandra-and-kafka
http://www.slideshare.net/mesosphere/scaling-like-twitter-with-apache-mesos
http://www.slideshare.net/subicura/mesos-on-coreos
https://www.youtube.com/watch?v=RciM1U_zltM
http://www.slideshare.net/JuliaMateo1/deploying-a-dockerized-distributed-application-in-mesossos-and-marathon/
http://mesos.readthedocs.io/en/latest/ Docker http://mesos.apache.org/documentation/latest/containerizer/#Composing
http://mesos.apache.org/documentation/latest/docker-containerizer/
https://mesosphere.github.io/marathon/docs/native-docker.html Mesos-DNS https://tech.plista.com/devops/mesos-dns/
http://programmableinfrastructure.com/guides/service-discovery/mesos-dns-haproxy-marathon/
http://mesosphere.github.io/mesos-dns/docs/tutorial-systemd.html
http://mesosphere.github.io/mesos-dns/docs/configuration-parameters.html
https://mesosphere.github.io/mesos-dns/docs/tutorial.html
https://mesosphere.github.io/mesos-dns/docs/tutorial-forward.html
https://github.com/mesosphere/mesos-dns Marathon-lb https://mesosphere.com/blog/2015/12/04/dcos-marathon-lb/
https://mesosphere.com/blog/2015/12/13/service-discovery-and-load-balancing-with-dcos-and-marathon-lb-part-2/
https://docs.mesosphere.com/1.7/usage/service-discovery/marathon-lb/
https://github.com/mesosphere/marathon-lb
https://dcos.io/docs/1.7/usage/service-discovery/marathon-lb/usage/ Autoscaling https://docs.mesosphere.com/1.7/usage/tutorials/autoscaling/
https://docs.mesosphere.com/1.7/usage/tutorials/autoscaling/cpu-memory/
https://docs.mesosphere.com/1.7/usage/tutorials/autoscaling/requests-second/
https://github.com/mesosphere/marathon-autoscale Other https://clusterhq.com/2016/04/15/resilient-riak-mesos/
https://github.com/CiscoCloud/mesos-consul/blob/master/README.md#comparisons-to-other-discovery-software
http://programmableinfrastructure.com/guides/load-balancing/traefik/
https://opensource.com/business/14/8/interview-chris-aniszczyk-twitter-apache-mesos
http://www.slideshare.net/akirillov/data-processing-platforms-architectures-with-spark-mesos-akka-cassandra-and-kafka
http://www.slideshare.net/mesosphere/scaling-like-twitter-with-apache-mesos
http://www.slideshare.net/subicura/mesos-on-coreos
https://www.youtube.com/watch?v=RciM1U_zltM
http://www.slideshare.net/JuliaMateo1/deploying-a-dockerized-distributed-application-in-mesos