YARN (Yet Another Resource Negotiator)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 17:19, 23 января 2019.
Open book.svg Авторство
А. А. Вернидуб
Согласовано: 23.01.2019
YARN
Yarn.png
Разработчики: Apache Software Foundation
Выпущена: 2013
Состояние разработки: Активно
Платформа: Кроссплатформенная
Локализация: English
Тип ПО: демон
Лицензия: Apache License 2.0
Веб-сайт официальный сайт

YARN (англ.  Yet Another Resource Negotiator — «ещё один ресурсный посредник») — модуль, отвечающий за управление ресурсами кластеров и планирование заданий. YARN функционирует как самостоятельный демон — планировщик ресурсов, абстрагирующий все вычислительные ресурсы кластера и управляющий их предоставлением приложениям распределённой обработки. Под управлением YARN могут работать как MapReduce-программы, так и любые другие распределённые приложения, поддерживающие соответствующие программные интерфейсы. YARN обеспечивает возможность параллельного выполнения нескольких различных задач в рамках кластера и их изоляцию по принципам мультиарендности. [Источник 1]

История возникновения

Apache Hadoop – это программная инфраструктура с открытым исходным кодом, устанавливаемая в кластере стандартных машин для совместного распределенного хранения и обработки больших объемов данных.
Первоначально Hadoop состояла из двух основных компонентов, которые позволяли реализовать выполнение программ в виде заданий MapReduce: распределенной файловой системы HDFS (Hadoop Distributed Filesystem) и механизма распределенных вычислений (см. рисунок 1) [Источник 2].

Наиболее серьезные ограничения классического механизма MapReduce в первую очередь были связаны с масштабируемостью ввиду наличия единственного процесса JobTracker, отвечающего за управление вычислительными ресурсами и координацией задач. Для решения данной проблемы вместо одного процесса JobTracker в новом подходе вводится менеджер кластера, полностью отвечающий за отслеживание в кластере работоспособных узлов и доступных ресурсов, а также за назначение их задачам. Для каждого задания в кластере запускается отдельный короткоживущий процесс для управления выполнением задач только в данном задании. Таким образом, благодаря такому подходу задания выполняются параллельно, а масштабируемость резко возрастает.
Еще одной важной проблемой являлось то, что Hadoop разрабатывался только для выполнения заданий MapReduce. Но с ростом и усложнением моделей программирования росла потребность в поддержке отличных от MapReduce парадигм программирования для того, чтобы использовать те же кластеры и общие ресурсы более эффективно. Появление YARN значительно расширило потенциальные возможности использования Hadoop. [Источник 3]

Рисунок 1 - Различия между Hadoop v1.0 и Hadoop v2.0

YARN

Apache Hadoop YARN - это система для планирования заданий и управления кластером. До получения официального названия YARN неофициально назывался MapReduce 2 или NextGen MapReduce.
Будучи одним из основных компонентов Apache Hadoop, YARN отвечет за распределение системных ресурсов различным приложениям, работающим в кластере Hadoop, и за и планирование задач, выполняемых на разных узлах кластера.

Ключевые компоненты

ResourceManager (RM) - менеджер ресурсов, задачей которого является распределение ресурсов, необходимых для работы приложений, и наблюдение за вычислительными узлами, на которых эти приложения выполняются. В свою очередь, ResourceManager включает в себя следующие компоненты [Источник 4]:

  • Scheduler – планировщик, ответственный за распределение ресурсов между приложениями, которые нуждаются в ресурах, с учетом ограничений вычислительных мощностей, наличия очереди и т.д. Scheduler является не ведет мониторинга и не отслеживает статус приложений. Он также не дает никаких гарантий о совершении перезапуска неудачных задач из-за сбоя в работе приложения или аппаратного сбоя.
  • ApplicationsManager (AsM) – компонент, ответственный за прием задач и запуск экземпляров ApplicationMaster, а также мониторингов узлов (контейнеров), на которых происходит выполнение, и предоставляет сервис для перезапуска контейнера ApplicationMaster при сбое.

ApplicationMaster (AM) – компонент, ответственный за планирование жизненного цикла, координацию и отслеживание статуса выполнения распределенного приложения. Каждое приложение имеет свой экземпляр ApplicationMaster. ApplicationMaster управляет всеми аспектами жизненного цикла, включая динамическое увеличение и уменьшение потребления ресурсов, управление потоком выполнения, обработку ошибок и искажений вычислений и выполнение других локальных оптимизаций. Фактически, AM может выполнять произвольный пользовательский код и может быть написан на любом языке программирования, поскольку вся связь с RM и NM кодируется с использованием расширяемых протоколов связи.

NodeManager (NM) – агент, запущенный на вычислительном узле и отвечающий за отслеживание используемых вычислительных ресурсов (ЦП, RAM и т.д.), за управление логами и за отправку отчетов по используемым ресурсам планировщику менеджера ресурсов ResourceManager/Scheduler. NodeManager управляет абстрактными контейнерами, которые представляют собой ресурсы на узле, доступные для конкретного приложения.

Контейнер (Container) - набор физических ресурсов, таких как ЦП, RAM, диски и др. в одной ноде.

Протоколы взаимодействия YARN

Взаимодействие основных компонентов YARN происходит посредством следующих протоколов:

  • ClientRMProtocol – протокол взаимодействия клиента с ResourceManager для запуска, завершения и проверки статуса приложений.
  • AMRMProtocol - протокол, используемый ApplicationMaster для регистрации/отмены регистрации в ResourceManager, а также для запроса ресурсов у Scheduler.
  • ContainerManager — протокол взаимодействия ApplicationMaster с NodeManager для запуска/остановки и получения информации о необходимости обновления контейнеров, находящихся под управлением NM.

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

Кластер YARN вступает в работу с приходом запроса от клиента (см. рисунок 2). ResourceManager выделяет необходимые ресурсы для контейнера и запускает ApplicationMaster для обслуживания указанного приложения. Запуском контейнеров управляет Container Launch Context (CLC), приходящий в качестве запроса от ApplicationMaster к NodeManager. ApplicationMaster выделяет контейнеры для приложения в каждом узле и контролирует их работу до завершения работы приложения. Чтобы запустить контейнер, NM копирует все необходимые зависимости - файлы данных, исполняемые файлы, архивы - в локальное хранилище. Затем, когда задача завершена, ApplicationMaster отменяет выделения контейнера в ResourceManager, и цикл завершается. Клиент может отслеживать состояние приложения, обращаясь к ResourceManager или напрямую к ApplicationMaster, если он поддерживает такую функцию. При необходимости клиент также может завершить работу приложения. [Источник 5]
Поскольку AM сам является контейнером, работающим в кластере, он должен быть устойчивым к сбоям. YARN обеспечивает некоторую поддержку для восстановления в случае сбоев, но поскольку отказоустойчивость и семантика приложений так тесно связаны, большая часть нагрузки все равно ложится на AM .

Рисунок 2 - Архитектура YARN

Взаимодействие ResourceManager и ApplicationManager

На рис.3 представлены следующие этапы взаимодействия RM и AM (номер пункта соответствует номеру стрелки на рисунке):

  1. AM регистрируется в RM. Он также передает такую информацию, как RPC-порт, который AM будет слушать, URL-адрес для мониторинга состояния приложения и т.д.
  2. RM отвечает AM, и ответ содержит важную информацию для AM, такую ​​как, к примеру, минимальное и максимальное количество ресурсов для этого кластера. АМ будет использовать эту ​​информацию при расчете и запросе любых ресурсов для отдельных задач приложения.
  3. Запрос на выделение ресурсов от AM к RM в основном содержит список запрошенных контейнеров и может также содержать список освобожденных контейнеров.
  4. Информация о ходе выполнения задачи также передается через запросы выделения ресурсов.
  5. Когда Scheduler получает запрос на выделение ресурсов, он вычисляет те контейнеры, которые удовлетворяют этому запросу, и отправляет обратно ответ, содержащий список выделенных ресурсов.
  6. Используя полученный список ресурсов, AM начинает связываться с NM, и, когда работа завершается, AM отправляет сообщение Finish Application в Resource Manager и завершает работу.

Рисунок 3 - Взаимодействие ResourceManager и ApplicationManager

Взаимодействие ApplicationManager и NodeManager

На рис.4 представлены следующие этапы взаимодействия AM и NM (номер пункта соответствует номеру стрелки на рисунке) [Источник 6]:

  1. AM отправляет запрос к NM для запуска контейнеров.
  2. Во время работы контейнеров AM может запрашивать отчет об их состоянии.
  3. Во время работы контейнеров AM может получать от NM отчет об их состоянии.

Рисунок 4 - Взаимодействие ApplicationManager и NodeManager

Преимущества появления YARN в Hadoop v2.0

В сравнении с предыдущим подходом в Hadoop v1.0 в новом решении появились следующие аспекты [Источник 7]:

  • Доступность - В Hadoop MapReduce 2.0 сохраняется состояние компонентов ResourceManager и ApplicationMaster и обеспечивается система автоматического перезапуска компонентов при сбое с сохранением и загрузкой последнего успешно сохраненного состояния.
  • Масштабируемость - Hadoop MapReduce 2.0 может работать на кластерах до 10000 вычислительных узлов, в сравнении с классической подходом, где предел масштабируемости был в районе 4000 машин.
  • Утилизация ресурсов - В Hadoop MapReduce 2.0 введена концепция универсальных контейнеров – набора взаимозаменяемых изолированных ресурсов.
  • Связанность - В Hadoop MapReduce 2.0 был выделен фреймворк распределенных вычислений YARN и фреймворк вычислений в рамках программной модели map/reduce, базирующийся на основе YARN – MR2.

Источники

  1. Apache Hadoop [Электронный ресурс]. Статья про Apache Hadoop / Дата обращения: 15.12.2018. Режим доступа: https://ru.wikipedia.org/wiki/Hadoop
  2. Apache Hadoop YARN Architecture [Электронный ресурс]. Hadoop YARN Tutorial – Learn the Fundamentals of YARN Architecture / Дата обращения: 23.12.2018. Режим доступа: https://www.edureka.co/blog/hadoop-yarn-tutorial/
  3. Hadoop YARN [Электронный ресурс]. Использование Hadoop YARN / Дата обращения: 15.12.2018. Режим доступа: https://www.ibm.com/developerworks/ru/library/bd-hadoopyarn/index.html
  4. Apache Hadoop YARN [Электронный ресурс]. Apache Hadoop YARN / Дата обращения: 13.12.2018. Режим доступа: https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/YARN.html
  5. YARN Walkthrough [Электронный ресурс]. Apache Hadoop YARN – Concepts and Applications / Дата обращения: 13.12.2018. Режим доступа: https://hortonworks.com/blog/apache-hadoop-yarn-concepts-and-applications/
  6. MapReduce 2.0 [Электронный ресурс]. MapReduce 2.0 in Apache Hadoop 0.23 / Дата обращения: 15.12.2018. Режим доступа: https://blog.cloudera.com/blog/2012/02/mapreduce-2-0-in-hadoop-0-23/
  7. YARN [Электронный ресурс]. MapReduce 2.0. Какой он современный цифровой слон? / Дата обращения: 16.12.2018. Режим доступа: https://habr.com/post/161437/