Apache mesos что это
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
Apache Mesos
Apache Mesos — это централизованная отказоустойчивая система управления кластером, разработанная для распределенных компьютерных сред c целью обеспечения изоляции ресурсов и удобного управления кластерами подчиненных узлов (mesos slaves). [Источник 1]
Является «сердцем» системы Mesosphere. Apache Mesos представляется как система с открытым исходным кодом, которая обеспечивает эффективную изоляцию ресурсов и совместное использование распределенных приложений или структур. [Источник 2]
Содержание
История
Mesos образовался как исследовательский проект в Университете Калифорнии Бёркли (UC Berkeley Lab) аспирантов Бенджамина Хиндмана, Энди Конвинск и Матея Захария, а также профессор Иана Стоика. Студенты начали совместную работу над проектом в рамках курса по современным направлениям в компьютерных системах (Advanced Topics in Computer Systems), преподаваемых Дэвидом Куллером. Первоначально он был назван Nexus, но из-за конфликта с проектом другого университета, был переименован в Mesos.
Mesos был впервые представлен в 2009 году Энди Конвински на HotCloud ’09. Позднее в 2011 году он был представлен в более зрелом состоянии в сообщении Матея Захария на USENIX симпозиуме по сетевым системам проектирования и реализации конференции о работе «Mesos: Платформа для распределенного совместного использования ресурсов в центре обработки данных» Бенджамина Хиндмана, Энди Конвински, Матея Захария, Али Годси, Энтони Д. Джозефа, Рэнди Каца, Скотта Шенкера, Иана Стоика.
Принцип работы
В некотором смысле суть работы Apache Mesos противоположная традиционной виртуализации — вместо деления физической машины на множество виртуальных предлагается объединять их в одно целое, в единый виртуальный ресурс.
Mesos распределяет ресурсы CPU и памяти в кластере для задач в похожей манере, как ядро Linux выделяет ресурсы железа между локальными процессами.
Если есть необходимость выполнить различные типы задач, можно выделить отдельные виртуальные машины (отдельный кластер) для каждого типа. Эти виртуальные машины, вероятно, не будут полностью загруженными и некоторое время будут простаивать, то есть не будут работать с максимальной эффективностью. Если же все виртуальные машины для всех задач объединить в единый кластер, можно повысить эффективность использования ресурсов и параллельно с тем повысить скорость их выполнения (если задачи краткосрочные или виртуальные машины не загружены полностью все время).
Кластер Mesos (с фреймворком к нему) способен пересоздавать отдельные ресурсы, в случае их падения, масштабировать ресурсы вручную или автоматически при определенных условиях и т.п.
Функции
Mesos обладает большим количеством функций: [Источник 3]
Архитектура
Архитектура Apache Mesos состоит из демонов master и slave (то есть, ведущих и ведомых демонов) и фреймворка.
Краткий обзор этих компонентов и некоторых важных терминов:
С помощью данных компонентов Apache Mesos точно распределяет ресурсы кластера между приложениями в соответствии с их требованиями. [Источник 4] Объем ресурсов, предлагаемых конкретному фреймворку, определяется согласно политике, установленной master нодой. Планировщик решает, какие из офферов использовать, а затем он сообщает Mesos, какие задачи должны быть выполнены, и Mesos запускает эти задачи на соответствующих slave нодах. Когда же задачи выполнены и ранее расходуемые ресурсы освобождаются, этот цикл повторяется снова для планировки других задач.
Apache Mesos + Marathon и Java EE
Apache Mesos — это менеджер кластеров с открытым исходным кодом, который обеспечивает эффективную изоляцию ресурсов и совместное использование в распределенных приложениях или инфраструктурах.
Apache Mesos абстрагирует ресурсы ЦП, памяти, хранилища и других вычислительных ресурсов от машин (физических или виртуальных), что позволяет легко создавать и эффективно эксплуатировать отказоустойчивые и гибкие распределенные системы. Он использует динамическое размещение приложений внутри машин.
В итоге Apache Mesos состоит из мастера и рабов. Мастера отвечают за распределение работы между несколькими рабами и знание состояния каждого раба. У вас может быть более одного мастера для отказоустойчивого.
И затем у нас есть подчиненные, которые отвечают за выполнение приложений. Рабы изолируют исполнителей и задачи (приложения) через контейнеры (cgroups).
Таким образом, каждый подчиненный предлагает свои ресурсы, и Apache Mesos отвечает за расписание, которое подчиненное будет выполнять. Обратите внимание, что каждый ведомый может выполнять более одной задачи, если у него достаточно ресурсов для его выполнения.
Например, допустим, что подчиненный имеет 4 ЦП (для упрощения я не собираюсь принимать во внимание другие параметры), тогда он может выполнить 1 задачу из 4 ЦП, 2 задачи по 2 ЦПУ,…
Marathon — это фреймворк, который работает поверх A pache Mesos и предлагает:
Но одно из главных преимуществ использования Marathon заключается в том, что он упрощает и автоматизирует все эти общие задачи.
Итак, основная задача Marathon — развернуть приложение на разных уровнях, поэтому, если один из них не работает, есть другие подчиненные для обслуживания входящих сообщений. Более того, Marathon позаботится о перераспределении приложения на другое ведомое устройство, чтобы количество подчиненных устройств на приложение поддерживалось постоянным.
Клонирование следующего репо:
И просто запустите команду vagrant-up из каталога:
Первый раз это займет некоторое время, потому что для этого нужно скачать несколько компонентов.
После этого вы можете проверить, правильно ли он установлен, подключившись к Mesos и Marathon Web Console. http://10.141.141.10:5050 и http://10.141.141.10:8080
Установить HAProxy
Загрузите скрипт haproxy-marathon-bridge:
который устанавливает сам скрипт, HAProxy и cronjob, который раз в минуту пингует один из указанных серверов Marathon и обновляет HAProxy, если что-то изменилось.
Единственное, что нам нужно сделать, это отправить документ JSON в формате POST на http://10.141.141.10:8080/v2/apps.
Этот документ JSON заставит Marathon развернуть приложение на одном узле. Давайте объясним каждый атрибут:
id: это идентификатор приложения, здесь не секрет.
mem : память, которая потребуется в узле.
случаи : количество узлов, которые мы хотим повторить это приложение. В этом случае только один, потому что мы работаем локально.
порты : какие порты будут группировать все экземпляры приложений. В основном этот порт используется
HAProxy для маршрутизации на правильный экземпляр. Мы собираемся объяснить глубоко в следующем параграфе.
ограничения : ограничения управляют тем, где запускаются приложения, чтобы оптимизировать отказоустойчивость или локальность. В этом случае мы устанавливаем, что каждое приложение должно быть в другом ведомом устройстве. При таком подходе вы можете избежать коллизии портов.
Итак, позвольте мне объяснить, что здесь происходит или что делает Месосфера :
Прежде всего читает документ JSON и проверяет, у какого ведомого есть узел, который может обрабатывать этот сервис. В этом случае нужно только найти его. (экземпляры = 1).
Когда он найден, элемент uri загружается, распаковывается и выполняет команды, указанные в
Атрибут cmd в текущем каталоге.
$ PORT — это случайный порт, который Mesosphere назначит узлу для связи. Этот порт используется, чтобы гарантировать, что никакие два приложения не могут быть запущены с использованием Marathon с перекрывающимися назначениями портов.
Но он также используется для обнаружения служб и балансировки нагрузки, запуская прокси-сервер TCP на каждом хосте в кластере и прозрачно перенаправляя статический порт на локальном хосте хостам, на которых выполняется приложение. Таким образом, клиенты просто подключаются к этому порту, и детали реализации обнаружения полностью удаляются.
Итак, если порт случайный, как клиент может подключиться, если он не знает, с какого порта запущен? И это цель атрибутов портов. В этом атрибуте мы устанавливаем, что при подключении к порту 10000 я хочу подключиться к приложению, определенному и развернутому на любом подчиненном устройстве, независимо от количества экземпляров.
Да, это может быть немного сложно, но позвольте мне объяснить на простом примере:
Легко. Вы можете использовать IP-адрес Marathon и произвольный порт ( http://10.141.141.10:31456/ ), к которому вы получите доступ к этому конкретному серверу, или вы можете использовать глобально определенный порт ( http://10.141.141.10:10000). / ) который в этом случае HAProxy будет маршрутизировать к одному из экземпляров (в зависимости от правил балансировки нагрузки).
И это все, как вы можете видеть, Apache Mesos и Marathon не так сложны, как вы могли ожидать вначале.
Распределенное выполнение Python-задач с использованием Apache Mesos. Опыт Яндекса
Подготовка релиза картографических данных включают в себя запуск массовой обработки данных. Некоторые задачи хорошо ложатся на идеологию Map-Reduce. В этом случае задача инфраструктуры традиционно решается использованием Hadoop или YT
В реальности часть задач таковы, что разбиение их на маленькие подзадачи невозможно, или нецелесообразно (из-за наличия существующего решения и дорогой разработки, например). Для этого мы в Яндекс.Картах разработали и используем свою систему планирования и выполнения взаимосвязанных задач. Одним из элементов такой системы является планировщик, запускающий задачи на кластере с учетом доступных ресурсов. 
Эта статья о том как мы решили эту задачу с использованием Apache Mesos.
Для простоты предположим, что существующей реализацией продиктован следующий интерфейс на Python:
Терминология
Разберем основные концепции используемые в Mesos, необходимые для выполнения задач Mesos-master — координатор кластера, собирает информацию о имеющихся хостах и их ресурсах и предлагает приложениям.
Схема работы при этом такая:
Установка локальной версии Mesos
Вообще говоря, рекомендованная установка Mesos включает 3 хоста с запущенным процессом Mesos-мастера и использование Zookeeper для их синхронизации.
Но для разработки достаточно одного, запущенного на локальной машине. На данный момент проще всего установить Mesos, собрав его из исходников. Установка для различных платформ описана в разделе Getting Started в документации по Mesos.
Вот как это выглядело для Mac OS (с учетом того, что все девелоперские утилиты у меня уже есть):
Для удобства можно добавить пути до Mesos в переменные окружения.
Запускаем локальный вариант
Теперь Mesos установлен и запущен. Его состояние можно посмотреть по адресу localhost:5050
Первый Framework
Для начала импортируем необходимые библиотеки:
Для запуска нам нужен Scheduler, для начала сделаем просто заглушку:
Опишем наш фреймворк:
Создадим инстанс планировщика:
Запустим driver через который происходит общение планировщика с Mesos-мастером.
Ура! Мы создали фреймворк, который бесконечно получает предложения ресурсов, и никогда их не использует.
Давайте попробуем позапускать задачи. Начнем с простого, с исполнения shell-команд. Для таких задач в Mesos уже есть встроенный Executor.
В принципе этого достаточно, для запуска задачи (если нас не интересует ее судьба). Можно запустить наш скрипт, и увидеть в логах mesos-local заветные строчки «Hello Mesosphere World»
Видимо одной статьи слишком мало чтобы решить поставленную задачу имплементации распределенной очереди. Продолжим ее решение во второй части.
Работа с 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 в целом призвана максимально упростить работу с кластером, полностью устранив эти проблемы.
Руководство по Apache Mesos
1. Обзор
Обычно мы развертываем различные приложения на одном кластере машин. Например, в настоящее время распространено использование механизма распределенной обработки, такого как Apache Spark или Apache Flink, с распределенными базами данных, такими как Apache Cassandra, в одном кластере.
В этой статье мы сначала обсудим несколько проблем распределения ресурсов в приложениях, развернутых в одном кластере. Позже мы увидим, как Apache Mesos обеспечивает лучшее использование ресурсов между приложениями.
2. Совместное использование кластера
Многим приложениям необходимо совместно использовать кластер. По большому счету, есть два общих подхода:
Хотя эти подходы позволяют приложениям работать независимо друг от друга, они не обеспечивают высокого использования ресурсов.
Например, рассмотрим приложение, которое запускается только в течение короткого периода времени, за которым следует период бездействия. Теперь, когда мы выделили этому приложению статические машины или разделы, у нас есть неиспользованные ресурсы в течение неактивного периода.
Мы можем оптимизировать использование ресурсов, перераспределяя свободные ресурсы во время неактивного периода другим приложениям.
Apache Mesos помогает с динамическим распределением ресурсов между приложениями.
3. Apache Mesos
С обоими подходами к совместному использованию кластера, которые мы обсуждали выше, приложения знают только о ресурсах определенного раздела или компьютера, на котором они работают. Однако Apache Mesos предоставляет приложениям абстрактное представление обо всех ресурсах кластера.
Чтобы понять, как работает Mesos, давайте посмотрим на его архитектуру:
Мы поговорим о каждом показанном здесь компоненте в следующих нескольких разделах.
3.1. Мастер Мезоса
Мастер является основным компонентом в этой настройке и хранит текущее состояние ресурсов в кластере. Кроме того, он действует как оркестратор между агентами и приложениями, передавая информацию о таких вещах, как ресурсы и задачи.
Поскольку любой сбой в мастере приводит к потере состояния ресурсов и задач, мы развертываем его в конфигурации высокой доступности. Как видно на диаграмме выше, Mesos развертывает резервные главные демоны вместе с одним лидером. Эти демоны полагаются на Zookeeper для восстановления состояния в случае сбоя.
3.2. Мезосагенты
В следующих разделах мы увидим, как приложения планируют и выполняют задачи на этих агентах.
3.3. Каркасы Mesos
Mesos позволяет приложениям реализовывать абстрактный компонент, который взаимодействует с мастером, чтобы получать доступные ресурсы в кластере и, кроме того, принимать решения по планированию на их основе. Эти компоненты известны как фреймворки.
Фреймворк Mesos состоит из двух подкомпонентов:
Весь этот процесс изображен следующим потоком:
Сначала агенты сообщают о своих ресурсах мастеру. В этот момент мастер предлагает эти ресурсы всем зарегистрированным планировщикам. Этот процесс известен как предложение ресурсов, и мы подробно обсудим его в следующем разделе.
Затем планировщик выбирает лучшего агента и выполняет на нем различные задачи через Мастер. Как только исполнитель завершает поставленную задачу, агенты повторно публикуют свои ресурсы для мастера. Мастер повторяет этот процесс разделения ресурсов для всех фреймворков в кластере.
Точно так же реализация исполнителя должна реализовывать интерфейс Executor :
Мы увидим рабочую версию планировщика и исполнителя в следующем разделе.
4. Управление ресурсами
4.1. Предложения ресурсов
Как мы обсуждали ранее, агенты публикуют информацию о своих ресурсах для мастера. В свою очередь, мастер предлагает эти ресурсы фреймворкам, работающим в кластере. Этот процесс известен как предложение ресурса.
Ресурсы используются для публикации информации об оборудовании машины-агента, такой как память, ЦП и диск.
Для каждого агента есть пять предопределенных ресурсов:
Значения для этих ресурсов могут быть определены одним из трех типов:
By default, Mesos agent tries to detect these resources from the machine.
However, in some situations, we can configure custom resources on an agent. The values for such custom resources should again be in any one of the types discussed above.
For instance, we can start our agent with these resources:
As can be seen, we’ve configured the agent with few of the predefined resources and one custom resource named bugs which is of set type.
In addition to resources, agents can publish key-value attributes to the master. These attributes act as additional metadata for the agent and help frameworks in scheduling decisions.
A useful example can be to add agents into different racks or zones and then schedule various tasks on the same rack or zone to achieve data locality:
Similar to resources, values for attributes can be either a scalar, a range, or a text type.
4.2. Resource Roles
Many modern-day operating systems support multiple users. Similarly, Mesos also supports multiple users in the same cluster. These users are known as roles. We can consider each role as a resource consumer within a cluster.
Due to this, Mesos agents can partition the resources under different roles based on different allocation strategies. Furthermore, frameworks can subscribe to these roles within the cluster and have fine-grained control over resources under different roles.
For example, consider a cluster hosting applications which are serving different users in an organization. So by dividing the resources into roles, every application can work in isolation from one another.
Additionally, frameworks can use these roles to achieve data locality.
For instance, suppose we have two applications in the cluster named producer and consumer. Here, producer writes data to a persistent volume which consumer can read afterward. We can optimize the consumer application by sharing the volume with the producer.
Since Mesos allows multiple applications to subscribe to the same role, we can associate the persistent volume with a resource role. Furthermore, the frameworks for both producer and consumer will both subscribe to the same resource role. Therefore, the consumer application can now launch the data reading task on the same volume as the producer application.
4.3. Resource Reservation
Now the question may arise as to how Mesos allocates cluster resources into different roles. Mesos allocates the resources through reservations.
There are two types of reservations:
Static reservation is similar to the resource allocation on agent startup we discussed in the earlier sections:
The only difference here is that now the Mesos agent reserves eight CPUs and 4096m of memory for the role named baeldung.
Dynamic reservation allows us to reshuffle the resources within roles, unlike the static reservation. Mesos allows frameworks and cluster operators to dynamically change the allocation of resources via framework messages as a response to resource offer or via HTTP endpoints.
Mesos allocates all resources without any role into a default role named (*). Master offers such resources to all frameworks whether or not they have subscribed to it.
4.4. Resource Weights and Quotas
Generally, the Mesos master offers resources using a fairness strategy. It uses the weighted Dominant Resource Fairness (wDRF) to identify the roles that lack resources. The master then offers more resources to the frameworks that have subscribed to these roles.
Event though fair sharing of resources between applications is an important characteristic of Mesos, its not always necessary. Suppose a cluster hosting applications that have a low resource footprint along with those having a high resource demand. In such deployments, we would want to allocate resources based on the nature of the application.
Mesos allows frameworks to demand more resources by subscribing to roles and adding a higher value of weight for that role. Therefore, if there are two roles, one of weight 1 and another of weight 2, Mesos will allocate twice the fair share of resources to the second role.
Similar to resources, we can configure weights via HTTP endpoints.
Besides ensuring a fair share of resources to a role with weights, Mesos also ensures that the minimum resources for a role are allocated.
Mesos allows us to add quotas to the resource roles. A quota specifies the minimum amount of resources that a role is guaranteed to receive.
5. Implementing Framework
As we discussed in an earlier section, Mesos allows applications to provide framework implementations in a language of their choice. In Java, a framework is implemented using the main class – which acts as an entry point for the framework process – and the implementation of Scheduler and Executor discussed earlier.
5.1. Framework Main Class
Before we implement a scheduler and an executor, we’ll first implement the entry point for our framework that:
We’ll first add a Maven dependency for Mesos:
Next, we’ll implement the HelloWorldMain for our framework. One of the first things we’ll do is to start the executor process on the Mesos agent:
Here, we first configured the executor binary location. Mesos agent would download this binary upon framework registration. Next, the agent would run the given command to start the executor process.
Next, we’ll initialize our framework and start the scheduler:
Finally, we’ll start the MesosSchedulerDriver that registers itself with the Master. For successful registration, we must pass the IP of the Master as a program argument args[0] to this main class:
In the class shown above, CommandInfo, ExecutorInfo, and FrameworkInfo are all Java representations of protobuf messages between master and frameworks.
5.2. Implementing Scheduler
Since Mesos 1.0, we can invoke the HTTP endpoint from any Java application to send and receive messages to the Mesos master. Some of these messages include, for example, framework registration, resource offers, and offer rejections.
For Mesos 0.28 or earlier, we need to implement the Scheduler interface:
For the most part, we’ll only focus on the resourceOffers method of the Scheduler. Let’s see how a scheduler receives resources and initializes tasks based on them.
First, we’ll see how the scheduler allocates resources for a task:
Here, we allocated 1 CPU and 128M of memory for our task. Next, we’ll use the SchedulerDriver to launch the task on an agent:
Alternatively, Scheduler often finds the need to reject resource offers. For example, if the Scheduler cannot launch a task on an agent due to lack of resources, it must immediately decline that offer:
5.3. Implementing Executor
As we discussed earlier, the executor component of the framework is responsible for executing application tasks on the Mesos agent.
We used the HTTP endpoints for implementing Scheduler in Mesos 1.0. Likewise, we can use the HTTP endpoint for the executor.
In an earlier section, we discussed how a framework configures an agent to start the executor process:
Notably, this command considers HelloWorldExecutor as the main class. We’ll implement this main method to initialize the MesosExecutorDriver that connects with Mesos agents to receive tasks and share other information like task status:
The last thing to do now is to accept tasks from the framework and launch them on the agent. The information to launch any task is self-contained within the HelloWorldExecutor:
Of course, this is just a simple implementation, but it explains how an executor shares task status with the master at every stage and then executes the task before sending a completion status.
In some cases, executors can also send data back to the scheduler:
6. Conclusion
В этой статье мы кратко обсудили совместное использование ресурсов между приложениями, работающими в одном кластере. Мы также обсудили, как Apache Mesos помогает приложениям достичь максимального использования с абстрактным представлением ресурсов кластера, таких как ЦП и память.
Позже мы обсудили динамическое распределение ресурсов между приложениями на основе различных политик и ролей справедливости. Mesos позволяет приложениям принимать решения о планировании на основе предложений ресурсов от агентов Mesos в кластере.
Наконец, мы увидели реализацию фреймворка Mesos на Java.
Как обычно, все примеры доступны на GitHub.