Mesos и YARN. История о двух кластерах

Это история о двух изолированных кластерах. Первый из них – кластер Apache Hadoop. Он представляет собой «остров», ресурсы которого полностью принадлежат Hadoop и его процессам. Второй кластер – это, согласно моему определению, все ресурсы, не являющиеся частью кластера Hadoop.

Я разделил их таким образом, потому что Hadoop управляет своими собственными ресурсами посредством Apache YARN (Yet Another Resource Negotiator – «еще один ресурсный посредник»). Это удобно для Hadoop, но слишком часто эти ресурсы используются неполноценно, когда в очереди нет заданий по обработке больших данных. А потом, когда задания появляются, эти ресурсы используются на пределе, и, вероятно, возникает потребность в дополнительных ресурсах. Пребывание на «острове» может быть достаточно трудным.

Изолированные кластеры

Предполагалось, что Hadoop должен «разрушать стены». Хотя это и стены изолированных хранилищ данных, но все же стены. Однако произошло так, что после разрушения одних стен, на их месте возникли другие.

Другая технология под названием Apache Mesos также должна была «разрушать стены». Но Mesos обычно позиционируется, как модуль для управления «вторым кластером», к которому относится вся остальная рабочая нагрузка, не связанная с Hadoop.

Здесь как раз и начинается история о Mesos и YARN. Эти модули часто противопоставляются друг другу, как будто они несовместимы. Но, оказывается, они могут работать совместно. Об этом и пойдет речь в моей истории.

Краткое объяснение технологий Mesos и YARN

Основные различия между Mesos и YARN заключаются в приоритетах и походах к планированию заданий. Mesos был создан, как масштабируемый глобальный менеджер ресурсов для всего дата-центра. Он был разработан в Калифорнийском университете в Беркли в 2007 году и «закален» в реальных условиях такими компаниями, как Twitter и Airbnb.

YARN был создан из-за необходимости обеспечить масштабируемость для Hadoop. До создания YARN функция управления ресурсами была встроена в модуль Hadoop MapReduce V1, но возникла необходимость исключить эту функциональность, чтобы обеспечить масштабируемость для MapReduce. Встроенный планировщик заданий MapReduce 1 JobTracker на практике не обеспечивал масштабируемость более нескольких тысяч машин. Создание YARN стало существенной частью следующего шага в жизненном цикле Hadoop. В первую очередь, это касается достигнутого прогресса в области масштабируемости.

Планирование с помощью Mesos

Mesos определяет, какие ресурсы доступны, и отправляет предложения на получение ресурсов (offer) обратно планировщику приложения (планировщик приложения и его исполнитель имеют название «фреймворк»). Эти предложения могут быть приняты или отклонены фреймворком. Такая модель считается немонолитной, поскольку представляет собой «двухуровневый» планировщик с подключаемыми алгоритмами планирования. Mesos позволяет использовать бесконечное количество алгоритмов планирования, каждый со своей собственной стратегией относительно принятия или отклонения предложений, и может объединять тысячи таких планировщиков, выполняющихся в мультиарендном (multitenant) режиме  на одном кластере.

Двухуровневая модель планирования, применяемая в Mesos, позволяет каждому фреймворку определять, какой алгоритм необходимо использовать для планирования заданий, которые он должен выполнить. Mesos играет роль арбитра: выделяет ресурсы для различных планировщиков, разрешает конфликты и обеспечивает эффективное распределение ресурсов в соответствии с бизнес-стратегией. Когда приходит предложение, фреймворк может выполнить задачу, потребляющую предложенные ресурсы. Также фреймворк может отклонить данное предложение и ждать другое.

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

Планирование с помощью YARN

Теперь давайте посмотрим, что происходит в случае YARN. Когда запрос на выполнение задания приходит к менеджеру ресурсов YARN, YARN оценивает все доступные ресурсы и размещает задание. YARN самостоятельно принимает решение о том, куда необходимо направить задание; таким образом он имеет в своей основе монолитную модель. Важно подчеркнуть, что YARN был разработан в результате необходимости эволюционного развития фреймворка MapReduce. В качестве основы для YARN была взята модель управления ресурсами, применявшаяся в MapReduce 1 JobTracker, которая затем была обобщена и перемещена в собственный компонент YARN под названием ResourceManager. Мотивацией, в значительной степени, послужила потребность в масштабировании заданий Hadoop.

YARN оптимизирован для планирования заданий Hadoop, исторически (и в настоящее время) являющихся пакетными заданиями с длительным временем выполнения. Это означает, что YARN не предназначен ни для длительно работающих служб, ни для кратковременных интерактивных запросов (таких как небольшие и быстрые задания Spark). И хотя YARN может планировать другие типы рабочих нагрузок, для них это будет не идеальная модель. Потребности в ресурсах, модель выполнения и архитектурные потребности MapReduce значительно отличаются от соответствующих параметров для длительно работающих служб, таких как веб-серверы, SOA-приложения (service-oriented architecture – сервис-ориентированная архитектура) или задания реального времени, как в случае Spark или Storm.

Кроме того, YARN был спроектирован для работы с пакетными заданиями, которые выполняются без учета состояния (stateless) и могут быть легко перезапущены, если их выполнение было прервано. Он не работает со службами, учитывающими состояние (stateful), такими как распределенные файловые системы или базы данных. Хотя монолитный планировщик YARN теоретически мог бы развиваться, чтобы управлять различными типами рабочих нагрузок (путем включения новых алгоритмов в планирующий код), это не настолько «легкая» модель, чтобы поддерживать возрастающее количество текущих и будущих алгоритмов планирования.

Действительно ли YARN не совместим с Mesos?

При сравнении YARN и Mesos важно учесть общие возможности масштабирования и причины, по которым некоторые могут предпочесть одну технологию вместо другой. Кто-то может утверждать, что YARN и Mesos конкурируют за одно и то же пространство, но на самом деле это не так. Люди, внедрявшие эти модели, изначально имели различные цели, и это нормально. Нет ничего явно отрицательного ни в одной, ни в другой модели, но каждый подход будет давать различные результаты в долгосрочном периоде. Я считаю, что это ключевой показатель, позволяющий выбрать, когда применять первую модель, когда вторую, а когда обе.

Mesos был разработан в то же время, когда и Google Omega. Бен Хиндман (Ben Hindman) и команда Berkeley AMPlab работали в тесном сотрудничестве с командой Google при разработке Omega, таким образом, обе команды могли извлечь уроки из проекта Google Borg и создать более эффективный немонолитный планировщик.

Когда вы решаете, как управлять своим дата-центром в целом, у вас есть два варианта: с одной стороны, вы можете использовать Mesos, способный управлять всеми ресурсами вашего дата-центра, а с другой стороны, вы можете применить YARN, способный надежно управлять заданиями Hadoop, но не подходящий для управления целым дата-центром. Операторы дата-центров, обычно решают этот вопрос путем разделения своих кластеров на два «мира», один из которых предназначен для Hadoop, а второй – для других систем.

Чтобы использовать Mesos и YARN в одном дата-центре и получать преимущества обоих менеджеров ресурсов, на текущий момент необходимо создать два статических раздела. Использование обоих будет означать, что определенными ресурсами будет управлять YARN, а остальными – Mesos. Возможно, это слишком упрощенное представление, но, в принципе, это то, что мы и обсуждаем. По сути, это та проблема, которой мы хотим избежать.

Проект Myriad

Это приводит нас к вопросу о том, можем ли мы совместно использовать YARN и Mesos? Можем ли мы заставить их работать гармонично на благо предприятия и дата-центра? Ответ – да. Несколько известных компаний – eBay, MapR и Mesosphere – в сотрудничестве разработали проект Myriad.

Этот проект с открытым исходным кодом объединяет в себе фреймворк Mesos и планировщик YARN, что позволяет модулю Mesos управлять запросами ресурсов YARN. Когда задание приходит в YARN, он планирует его посредством планировщика Myriad Scheduler, ставящего в соответствие запросу входящие предложения ресурсов от Mesos. Mesos, в свою очередь, передает его на свои рабочие узлы. Узлы Mesos передают запрос исполнителю Myriad, взаимодействующему с менеджером узлов YARN. Myriad запускает менеджеры узлов YARN на ресурсах Mesos, которые затем сообщают менеджеру ресурсов YARN, какие ресурсы им доступны. Затем YARN может потреблять ресурсы по своему усмотрению. Myriad обеспечивает органичную связь между пулом ресурсов, доступных в Mesos, и задачами YARN, которым необходимы эти ресурсы.

Принцип работы Myriad

Эстетика этого подхода заключается не только в том, что он позволяет YARN гибко работать на общем кластере, но также в том, что в результате YARN становится более динамичным и гибким, чем должен был быть по замыслу. Этот подход также позволяет команде, обслуживающей дата-центр, легко увеличивать количество ресурсов, выделенных для YARN (или уменьшать это количество, в зависимости от ситуации), без необходимости изменять конфигурацию кластера YARN. Таким образом, становится очень легко динамически управлять целым дата-центром. Эта модель также позволяет использовать несколько различных реализаций YARN и даже разные версии YARN на одном кластере.

 

Совместное использование ресурсов

 

Myriad объединяет в себе все лучшие свойства обеих технологий YARN и Mesos. Mesos и YARN могут работать совместно посредством Myriad, и такое сочетание позволит вашей компании динамично адаптироваться к текущей ситуации. Анализ данных может выполняться на том же оборудовании, на котором работают ваши производственные службы. Вам больше не придется сталкиваться с такими явлениями, как ограниченность ресурсов и неполноценное использование ресурсов, вызванными наличием статических разделов. Ресурсы могут быть гибко перераспределены, чтобы соответствовать текущим запросам компании.

Заключительные мысли

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

Mesos нуждается в комплексной архитектуре безопасности, и я не рекомендовал бы останавливаться на технологии Kerberos для этих целей, поскольку, как показывает мой личный опыт, использовать ее не так просто. Другая область улучшения Mesos, которая может оказаться очень сложной в реализации, это то, что я буду называть аннулированием (revocation) и вытеснение (preemption) ресурсов.

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

На текущий момент существуют методы, позволяющие реализовать это, но я с нетерпением жду результатов работы, проводимой разработчиками Mesos с целью решить эту проблему посредством технологий динамического резервирования (Dynamic Reservations) и оптимистичных (аннулируемых) предложений ресурсов (Optimistic (Revocable) Resources Offers).

По материалам: O’Reilly Radar

Добавить комментарий

Ваш адрес email не будет опубликован.

закрыть

Поделиться

Отправить на почту
закрыть

Вход

закрыть

Регистрация

+ =