Платформа Apache Hadoop YARN

Перевод: Саянкин А.А.

Предисловие переводчика

---

Данная статья представляет перевод оригинальных публикаций следующих авторов:

• Арун Мёрфи (Arun Murthy) Apache Hadoop YARN – Background & Overview, Apache Hadoop YARN – Concepts & Applications;
• Винод Кумар Вавилапалли (Vinod Kumar Vavilapalli) Apache Hadoop YARN – ResourceManager, Apache Hadoop YARN – NodeManager.

Переводчик выражает благодарность Виктору Жуковскому за ценные правки и обсуждение рукописи.

Apache Hadoop YARN – предыстория и обзор

Парадигма MapReduce

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

Apache Hadoop MapReduce — наиболее популярная реализация модели MapReduce с открытым программным кодом.

В частности, если модель MapReduce используется в паре с распределённой файловой системой Apache Hadoop HDFS, предоставляющей высокую пропускную способность операций ввода/вывода в больших кластерах, то мы получаем исключительно экономичную и в тоже время весьма производительную систему — ключевой фактор в популярности Hadoop. Один из принципов работы — это уменьшение перемещения данных между узлами кластера. Иными словами мы перемещаем вычисления к данным, а не данные по сети к вычислениям. А именно, задачи MapReduce могут быть запущены на том физическом узле, который хранит данные в HDFS, при этом задействовав информацию о топологии кластера. Это значительно уменьшает нагрузку на сетевой ввод/вывод и проводит к тому, что весь ввод/вывод осуществляется в пределах локального диска либо одного вычислительно сегмента — важнейшее преимущество.

Платформа Apache Hadoop MapReduce

Apache Hadoop MapReduce — это проект с открытым исходным кодом копании Apache Software Foundation, представляющий собой реализацию модели вычислений MapReduce, описанную выше. Сам проект Apache Hadoop MapReduce можно разбить на несколько основных частей:

• Программный интерфейс MapReduce API, предназначенный для конечного пользователя, разрабатывающего приложения MapReduce.
• Платформа MapReduce, представляющая собой реализацию времени выполнения различных фаз модели вычислений MapReduce: фазы отображения, сортировки/тасовки/слияния/агрегирования и фазы свёртки.
• Система MapReduce, которая представляет собой набор библиотек для запуска приложений MapReduce, управления ресурсами кластера, управления выполнением тысяч распределённых параллельных заданий.

Такое распределение ответственности имеет значительные преимущества, в особенности для конечных пользователей — они могут полностью сосредоточиться на разработке приложения с использованием программного интерфейса MapReduce, поручив платформе MapReduce и системе MapReduce управление такими низкоуровневыми процессами как распределение ресурсов, обеспечение отказоустойчивости, планировка заданий.

В данный момент система Apache Hadoop MapReduce состоит из трекера заданий (JobTracker) — главного процесса и трекеров задач (TaskTrackers) — подчинённых ему процессов.

Трекер заданий (JobTracker) отвечает за управление ресурсами (управление рабочими узлами, например, трекерами задач (TaskTrackers), которые там работают), за отслеживание потребления/доступности ресурсов и также за жизненный цикл задания (запуск отдельных задач задания, отслеживание прогресса выполнения задач, обеспечение отказоустойчивости задач).

Трекер задач (TaskTrackers) имеет простые обязанности — запуск/остановка задач по команде трекера заданий (JobTracker) и переодическое предоставление трекеру заданий информации о статусе задачи.

Через какое-то время мы поняли, что платформа Apache Hadoop MapReduce требует капитальной переделки. В частности, используя трекер заданий, нам необходимо было реализовать несколько функций, включая масштабируемость, утилизацию (освобождение ресурсов) кластера , управление обновлениями. Под обновлением мы имеем в виду как обновление пользовательского программного обеспечения, работающего на кластере, так и саму платформу MapReduce.

С течением времени мы вносили новые изменения, например реализация высокой доступности трекера заданий (способность трекера заданий восстановить себя после сбоя), но это привело к более ресурсоёмкой поддержке трекера заданий и не решило главных задач: поддержка модели вычислений, отличной от MapReduce и обновление пользовательского программного обеспечения.

Зачем поддерживать модели вычислений, отличные от MapReduce?

Модель вычислений MapReduce прекрасно подходит для многих приложений, но не для всех: другие программные модели лучше удовлетворяют требованиям, возникающим при обработке графов (Google Pregel / Apache Giraph) и интерактивном моделировании (MPI). Если данные уже загружены в HDFS, то исключительно важно иметь несколько путей для их обработки.

Более того, поскольку MapReduce по своей сути пакетно-ориентировання модель вычислений, то поддержка обработки данных в реальном или практически реальном времени (например, потоковые вычисления и CEPFresil) — это те задачи, которые нам предстоит решить в ближайшем будущем.

Зачем улучшать масштабируемость?

Вспомним закон Мура (эмпирическое наблюдение, изначально сделанное Гордоном Муром, согласно которому количество транзисторов, размещаемых на кристалле интегральной схемы, удваивается каждые 24 месяца — прим. перев.). По аналогии вычислительная мощность компьютеров, доступных в дата-центрах, за фиксированную стоимость продолжает быстро расти. Например, сравним типичную мощность узла кластера за разные годы:

• 2009 год — 8 ядер, 16GB памяти RAM, 4x1TB дискового пространства.
• 2012 год — 16+ ядер, 48-96GB памяти RAM, 12x2TB или 12x3TB дискового пространства.

В общем при той же цене, серверы стали в два раза мощнее, чем они были два-три года назад — по каждому из параметров. Apache Hadoop MapReduce успешно управлял кластером из порядка 5000 узлов с аппаратным обеспечением 2009 года выпуска. Следовательно возможность масштабирования должна отражать существующие тенденции в росте аппаратного обеспечения узлов кластера.

Какие общие сценарии освобождения ресурсов кластера?

В текущей системе (Apache Hadoop MapReduce версии 1 — прим. перев.) трекер заданий рассматривает кластер как набор узлов с чётко заданным описанием слотов отображений и слотов свёрток, которые не являются взаимозаменяемыми. Проблемы с освобождением ресурсов возникают когда слоты отображений могут быть «заполненными», в то время как слоты свёрток пусты (и наоборот). Исправление подобной ситуации необходимо для того чтобы гарантировать, что вся система в целом использует максимум своей мощности.

В чём смысл гибкости платформы для заказчиков?

В промышленном использовании Hadoop часто устанавливается как распределённая многопользовательская система. Как результат, изменения и обновления в программном обеспечении Hadoop затрагивают большинство компонент, если не все. С другой стороны пользователи очень болезненно реагируют на необходимость изменения своего кода в связи с изменениями в Hadoop. Поэтому для Hadoop очень важно сделать возможным одновременную работу нескольких версий платформы MapReduce.

Введение в Apache Hadoop YARN

Главная идея YARN — предоставить две основные функции трекера задний — управление ресурсами и запуск/мониторинг задач — двум отдельным компонентам: глобальному менеджеру ресурсов (ResourceManager) и мастеру приложений (ApplicationMaster, AM). Причём каждое приложение пользователя имеет отдельный экземпляр мастера приложений. Менеджер ресурсов имеет подчинённый процесс, который называется менеджер узлов (NodeManager, NM). Менеджер узлов работает отдельно на каждом узле и представляет собой часть общей системы по управлению приложениями в распределённом режиме.

Менеджер ресурсов является последней инстанцией, решающей вопросы распределения ресурсов между всеми приложениями системы. Мастер приложений, запускаемый для каждого приложения в отдельности, — это, в сущности, платформенно зависимый элемент, запрашивающий ресурсы у менеджера ресурсов и взаимодействующий с менеджерами узлов для выполнения и мониторинга задач.

Менеджер ресурсов имеет подключаемый планировщик, который отвечает за выделение ресурсов разнообразным работающим приложениям. Планировщик представляет собой только планировщик и ничего более в том смысле, что он не выполняет мониторинга и не отслеживает статус приложения, не давая ни каких гарантий по повторному запуску аварийно остановленных задач, вне зависимости от причины останова — программного исключения или аппаратного сбоя. Планировщик выполняет свою работу основываясь на запросах приложения о необходимых ресурсах; он использует абстрактное понятие контейнер ресурсов, который включает в себя такие элементы как память, процессор, диск, сеть и другие.

Менеджер узлов — это подчинённый процесс, работающий на каждом узле и отвечающий за запуск контейнеров приложений, мониторинг использования ресурсов контейнера (процессор, память, диск, сеть) и передачу этих данных менеджеру ресурсов. Мастер приложений, запускаемый для каждого приложения в отдельности, отвечает за получение соответствующего контейнера от планировщика, отслеживание статуса контейнера и его прогресса использования. С точки зрения системы, мастер приложений работает как самый обыкновенный контейнер.

Ниже представлена архитектура YARN.

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

Apache Hadoop YARN — концепции и применение

Как было сказано выше YARN — это, по существу, система управления распределёнными приложениями. Она состоит из глобального менеджера ресурсов, который управляет всеми доступными ресурсами кластера и, работающих на каждом узле менеджеров узлов, которыми управляет менеджер ресурсов. Менеджер узлов отвечает за распределение ресурсов на каждом узле.

Рассмотрим компоненты более подробно.

Менеджер ресурсов

В YARN менеджер ресурсов — это только планировщик и не более. По существу он строго ограничен лишь тем, что распределяет ресурсы системы между конкурирующими за ними приложениями, если хотите он как брокерская фирма, котирующая ценные бумаги. Он оптимизирует высвобождение ресурсов кластера (следит, чтобы не было «простаивающих в холостую» ресурсов) с учётом множества ограничений, таких как обязанность выделить все необходимые ресурсы, которые запрашивает приложение, равнодоступность ресурсов для всех приложений и права доступа к ресурсам. Для реализации различных ограничений менеджер ресурсов имеет подключаемый планировщик, который позволяет при необходимости использовать алгоритмы сбалансированного распределения ресурсов.

Мастер приложений

Многие проводят параллели между YARN и существующей системой Hadoop MapReduce (называемой MR1 в Apache Hadoop 1.x). Однако существует ключевое различие — это новая концепция мастера приложений.

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

Мастер приложений позволяет платформе YARN достичь следующих ключевых характеристик:

• Масштабируемость. По сути мастер приложений представляет большую часть традиционного функционала менеджера ресурсов так что система в целом масштабируется достаточно легко. Мы уже провели тестирование масштабирования кластера размером до 10 000 узлов без каких либо значительных затруднений. Менеджер ресурсов является только лишь планировщиком то есть не предоставляет средств отказоустойчивости для ресурсов. Мы переместили эти задачи в зону ответственности менеджера приложений. Более того, поскольку теперь каждому приложению соответствует экземпляр мастера приложений, то сам по себе мастер перестал быть «бутылочным горлышком» кластера.
• Открытость. Переместив весь код, специфический для приложения в мастер приложений, мы получаем общую систему, которая может поддерживать одновременно несколько платформ, таких как MapReduce, MPI (Message Passing Interface, интерфейс передачи сообщений — программный интерфейс (API) для передачи информации, который позволяет обмениваться сообщениями между процессами, выполняющими одну задачу — прим. перев.) и Graph Processing (обработка графов).

Добавим также несколько дополнительных характеристик YARN платформы:

• Мы переместили всю сложность (по мере возможности, конечно) в мастер приложений, предоставив ему всю необходимую функциональность, позволяющую разработчикам достичь гибкости и силы в реализации своего кода.
• Не доверяйте мастеру приложений, поскольку его код в большинстве своём — пользовательский код, то есть мастер приложений не является привилегированным сервисом.
• Система YARN (менеджер узлов и менеджер ресурсов) вынуждены «защищать» сами себя от неисправных или «злонамеренных» мастеров приложений, желающих получить все ресурсы любой ценой.

Полезно помнить, что в реальности каждое приложение имеет свой собственный экземпляр менеджера приложений. Тем не менее, также вполне допустимо реализовать мастер приложений, управляющий набором приложений (например, мастер приложений для Pig или Hive, который управляет целым набором задач MapReduce). К тому же, эта концепция была развита для управления долгоживущими сервисами, которые в свою очередь управляют своими собственными приложениями (например, запускать HBase в YARN с помощью HBaseAppMaster).

Модель ресурсов

YARN поддерживает очень общую модель ресурсов для приложений. Приложение (с помощью мастера приложений) может запрашивать ресурсы предельно точно определяя свои требования, такие как:

• Имя ресурса
• Память (в Мб)
• Процессор (количество ядер)
• Диск, сетевой ввод/вывод

Контейнер и запрос на предоставление ресурсов

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

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

По сути, приложение может выполнить запрос на предоставление необходимых ресурсов посредством мастера приложений. Планировщик отвечает на запрос о предоставлении ресурсов выдачей контейнера, который удовлетворяет требованиям, выставленным мастером приложений в запросе. Давайте рассмотрим запрос на предоставление ресурсов более подробно. Запрос имеет следующую форму:

<имя-ресурса, приоритет, неоходимый-ресурс, число-контейнеров>

Для лучшего понимания рассмотрим каждый компонент запроса на предоставление ресурса более подробно:

• имя-ресурса — это либо имя узла, либо имя сегмента кластера либо *, что означает неопределённое значение. В будущем мы планируем поддерживать более сложные топологии для случая, когда в кластере используются виртуальные машины, либо сложные сетевые топологии.
• приоритет — внутренний приоритет запроса, среди других запросов на предоставление ресурсов этого же приложения. (Обратите внимание, это не приоритет запроса между разными приложениями).
• неоходимый-ресурс — это запрашиваемые мощности, такие как память, процессор. На момент написания данной статьи (Август 2012 — прим. перев.) это только память и процессор в качестве параметров контейнера.
• число-контейнеров — количество контейнеров с заданными ранее параметрами.

Теперь рассмотрим контейнеры. По сути контейнер — это выделенные ресурсы, результат успешного выполнения менеджером ресурсов определённого запроса на выделение ресурсов. Контейнер предоставляет права приложению для использование заданного количества ресурсов (память, процессор) на заданном узле.

Мастер приложений должен взять контейнер и передать его менеджеру узлов, управляющему узлом, на котором расположен контейнер для использования ресурсов при запуске пользовательских задач. Конечно, в безопасном режиме работы кластера проверяются привилегии на выделение ресурсов, чтобы гарантировать отсутствие неправомерных запросов на выделение ресурсов.

Запуск и спецификация контейнера

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

YARN позволяет запускать приложения на разных языках и в отличии от существующей версии Hadoop MapReduce hadoop-1.x (также известной как MR1) не ограничен языком программирования Java.

Программный интерфейс запуска YARN контейнера не зависит от платформы и содержит:

• Интерфейс командой строки для запуска процесса внутри контейнера.
• Переменные окружения.
• Локальные ресурсы, необходимые перед запуском, такие как файлы jar, общие объекты, дополнительные файлы данных.
• Токены безопасности.

Это позволяет мастеру приложений взаимодействовать с менеджером узлов для запуска контейнеров, выполняя широкий спектр приложений, начиная от простых скриптов на C/Java/Python и заканчивая полноценными виртуальными машинами, например KVM (KVM или Kernel-based Virtual Machine - программное решение, обеспечивающее виртуализацию в среде Linux на платформе x86, которая поддерживает аппаратную виртуализацию на базе Intel VT (Virtualization Technology) либо AMD SVM (Secure Virtual Machine) — прим. перев.).

YARN — обзор и анализ

Вооружившись знаниями из предыдущих разделов будет полезно выяснить как собственно приложения работают в YARN. Запуск приложения состоит из следующих шагов:

• Выполнение запроса на запуск приложения.
• Запуск экземпляра мастера приложений для работы с приложением.
• Выполнение приложения под управлением экземпляра мастера приложений.

Пройдёмся по последовательности шагов для выполнения приложения (номера шагов показаны ниже на диаграмме):

1. Клиентская программа выполняет запрос на запуск приложения, содержащий кроме всего прочего необходимые данные для запуска мастера приложений, соответствующего приложению.
2. Менеджер ресурсов принимает на себя ответственность за выделение необходимого контейнера, в котором будет запущен мастер приложений и затем запускает мастер приложений.
3. В ходе первоначальной загрузки мастер приложений регистрируется у менеджера ресурсов. Регистрация позволяет клиентской программе запрашивать у менеджера ресурсов специфическую информацию, необходимую для непосредственного взаимодействия с мастером приложений.
4. В ходе штатной работы мастер приложений с помощью протокола запроса ресурсов запрашивает соответствующий контейнер ресурсов.
5. После успешного получения контейнера мастер приложений запускает контейнер, предоставляя менеджеру узлов спецификацию запуска контейнера. Спецификация запуска контейнера обычно содержит необходимую информацию, позволяющую контейнеру взаимодействовать с мастером приложений.
6. Внутри контейнера происходит старт кода пользовательского приложения. Затем пользовательское приложение посредством специального протокола предоставляет информацию (этап выполнения, статус) своему мастеру приложения.
7. В ходе работы пользовательского приложения клиент, выполнивший запрос на запуск приложения, взаимодействует посредством специально протокола непосредственно с мастером приложения для получения статуса и процента выполнения задачи.
8. Когда приложение завершило выполнение и вся необходимая работа была выполнена, мастер приложений отменяет регистрацию у менеджера ресурсов и останавливает своё выполнение, освобождая контейнер для других целей.

Apache Hadoop YARN — Менеджер ресурсов

Как описано выше, менеджер ресурсов (RM) — это фоновый процесс, который управляет доступными ресурсами кластера и следовательно, помогает управлять распределёнными приложениями в YARN системе. Он работает совместно с менеджерами узлов (NM), один экземпляр которого работает на каждом узле, и мастерами приложений (AM), один экземпляр которого запускается при запуске приложения.

1. Менеджеры узлов получают команды от менеджера ресурсов и управляют ресурсами на узле.
2. Мастер приложений отвечает за запрос ресурсов у менеджера ресурсов и взаимодействие с менеджерами узлов для запуска контейнеров.

Компоненты менеджера ресурсов

Менеджер ресурсов состоит из следующих компонент:

1. Компоненты, предоставляющие клиентам интерфейс взаимодействия с RM
   • Сервис клиента. Это клиентский интерфейс менеджера ресурсов. Этот компонент поддерживает все интерфейсы RPC от клиентов к RM, включая такие операции как запуск приложения, остановка приложения, получение информации об очереди, статистика по кластеру.
   • Сервис администратора. Это администраторский интерфейс менеджера ресурсов. Чтобы гарантировать, что запросы администратора не будут проигнорированы из-за обработки обычных пользовательских запросов, и для предоставления запросам администратора наивысшего приоритета, все операции администрирования, такие как обновление списка узлов, конфигурирование очереди обслуживаются отдельным администраторским интерфейсом.
2. Компоненты, связывающие RM с узлами:
   • Сервис трекера ресурсов. Этот компонент отвечает за RPC вызовы ото всех узлов кластера. Он также отвечает за регистрацию новых узлов, отклонение запросов от не действительных/отключённых узлов, получение периодического сигнала, подтверждающего работоспособность узла, и передачу этого сигнала планировщику YARN. Сервис трекера ресурсов тесно взаимодействует с монитором состояния менеджера узлов и менеджером списка узлов, описание которых приведено ниже.
   • Монитор состояния менеджера узлов. Этот компонент следит за каждым менеджером узлов по специальному периодическому сигналу, который тот отправляет. Любой узел, который не посылает переодического сигнала в течении заданного времени (по умолчанию это 10 минут) считается недействительным и исключается менеджером ресурсов из списка действительных. Все контейнеры, запущенные на недействительном узле, так же помечаются как недействительные. Сознание новых контейнеров на таком узле также прекращается.
   • Менеджер списка узлов. Этот компонент содержит набор действительных и исключённых узлов. Компонент отвечает за чтение конфигурационного файла, определённого в переменных classyarn.resourcemanager.nodes.include-path и yarn.resourcemanager.nodes.exclude-path и формирование начально списка узлов, на основании прочитанных файлов. Он также следит за отключёнными от кластера узлами.
3. Компоненты, взаимодействующие с мастерами приложений
   • Сервис мастера приложений. Этот компонент отвечает за вызовы RPC ото всех мастеров приложений. Он также ответственен за регистрацию новых мастеров приложений, завершение и выполнение запроса на отмену регистрации ото всех закончивших работу мастеров приложений, получение запросов на предоставление/освобождение контейнера ото всех запущенных мастеров приложений и передачу этих запросов YARN планировщику. Сервис мастера приложений тесно взаимодействует с монитором состояния мастеров приложений, описание которого приведено ниже.
   • Монитор состояния мастеров приложений. Этот компонент следит за каждым мастером приложений и временем последнего получения от него сигнала, подтверждающего работоспособность мастера приложений. Полученные данные используются для формирования списка действительных и недействительных/не отвечающих мастеров приложений. Любой мастер приложений, который не посылает переодического сигнала в течении заданного времени (по умолчанию это 10 минут) считается недействительным и исключается менеджером ресурсов из списка действительных. Все контейнеры, запущенные по запросу недействительного мастера приложений, так же помечаются как недействительные. Менеджер ресурсов выполняет повторный запуск недействительного мастера приложений в новом контейнере, при этом по умолчанию число таких попыток равно 4.
4. Ядро менеджера ресурсов — планировщик и связанные с ним компоненты:
   • Менеджер приложений. Этот компонент отвечает за поддержку набора зарегистрированных приложений. Он также хранит кеш завершённых приложений, для выполнения пользовательских запросов через web-интерфейс или командную строку далеко после того, как приложения были завершены.
   • Менеджер списков доступа приложений. Менеджер ресурсов должен выполнять фильтрацию входящих запросов и гарантировать что клиентские и администраторские запросы выполняются только от авторизованных пользователей. Менеджер списков доступа приложений поддерживает списки прав доступа для каждого приложения и при запросах на остановку приложения или получение его статуса проверяет имеет ли приложение право выполнять такой запрос.
   • Модуль запуска мастеров приложений. Поддерживает пул потоков для запуска мастеров приложений как при старте нового приложения так и при повторном старте приложения, закончившего свою работу принудительно по какой-либо причине. Также отвечает за очистку ресурсов приложения чей мастер приложений завершил свою работу успешно либо принудительно.
   • Планировщик YARN. Планировщик отвечает за выделение ресурсов для работающих приложений с учётом ограничений ресурсов, состояния очереди. Он выполняет функцию планирования основываясь на запросах на выделение ресурсов, таких как память, процессор, диск, сеть.
   • Модуль контроля контейнеров. Этот компонент отвечает за то, что все выделенные контейнеры используются мастерами приложений и запущены на соответствующих менеджерах узлов. Мастер приложений представляет собой в общем случае пользовательский код, которому нельзя доверять и, как следствие, это код может потенциально выделать контейнер и не использовать его, что приведёт к перерасходу ресурсов кластера. Для решения этой проблемы модуль контроля контейнеров ведёт список всех выделенных, но не использованных мастером приложений контейнеров на соответствующих менеджерах узлов. Если соответствующий менеджер узлов не сообщает менеджеру ресурсов, что контейнер запущен через заданный интервал времени (по умолчанию 10 минут), контейнер помечается как недействительный и удаляется менеджером ресурсов.
5. Менеджеры токенов безопасности. Менеджер ресурсов имеет набор менеджеров безопасности, которые отвечают за управлениями токенами и ключами безопасности, используемыми аутентификации/авторизации запросов для многочисленных RPC интерфейсов. Коротко о каждом из них:
   • Менеджер токенов безопасности приложений. Для предотвращения несанкционированных запросов менеджер ресурсов использует специальные токены, которые называются токенами приложений. Менеджер токенов безопасности приложений хранит каждый токен приложения локально в памяти до тех пор пока приложение не закончит свою работу и используется для аутентификации всех запросов приходящих от работающих мастеров приложений.
   • Менеджер токенов безопасности контейнеров. Токен безопасности контейнеров представляет собой специальный токен выданный мастеру приложений менеджером ресурсов для работы с контейнером. Токены безопасности контейнеров используются мастером приложений для создания соединения к соответствующему менеджеру узла, на котором расположен контейнер. Этот компонент используется только менеджером ресурсов для слежения за соответствующим мастером и ключами безопасности, а также, при необходимости, за сменой ключей.
   • Менеджер токенов делегирования менеджера ресурсов. Этот компонент используется только менеджером ресурсов. Он отвечает за генерирование токенов делегирования для клиентов. Такие токены могут быть переданы неаутентифицированным процессам, которые намерены взаимодействовать с менеджером ресурсов.
6. Менеджер обновления токенов делегирования. В безопасном режиме менеджер ресурсов использует Kerberos для аутентификации и предоставляет по требованию приложения сервис обновления токенов файловой системы. Данный компонент обновляет токены зарегистрированных приложений пока приложение ещё работает и до тех пор пока обновление допустимо.

Выводы

В архитектуре YARN, менеджер ресурсов в основном предназначен только лишь для управления ресурсами, то есть он распределяет доступные ресурсы системы среди соревнующихся за них приложений, в то время как состоянием самого приложения он не управляет. Из-за такого чёткого распределения ответственности совместно с модульностью менеджера ресурсов, описанной выше и мощным API, он способен выполнить важнейшую из задач, возложенных на него: обеспечить масштабируемость и поддержку альтернативных парадигм программирования (отличных от MapReduce — прим. перев.).

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

Apache Hadoop YARN – Менеджер узлов

Менеджер узлов — это сервис, работающий на каждом узле и отвечающий за отдельные узлы Hadoop кластера. Это включает в себя постоянное взаимодействие с менеджером ресурсов (RM), наблюдение за жизненным циклом контейнеров, мониторинг использования ресурсов (память, центральный процессор) отдельного контейнера, отслеживание работоспособности узлов, управление журналами и вспомогательными сервисами, которые используются разнообразными YARN приложениями.

Компоненты менеджера узлов

Менеджер узлов состоит из следующих компонент:

1. Модуль обновления статуса узлов. При старте узла этот компонент регистрируется у менеджера ресурсов и передаёт информацию о доступности ресурсов на узлах. Последующее взаимодействие между менеджером узлов и менеджером ресурсов предназначено для передачи обновления статуса контейнера
2. Менеджер контейнеров. Это ядро менеджера узлов. Он состоит из следующих под-компонентов, каждая из которых выполняет подмножество задач, необходимое для управления контейнерами, запущенными на узле.
   • Сервер RPC. Менеджер контейнеров принимает запросы от мастера приложений для запуска новых контейнеров или для остановки уже запущенных. Он взаимодействует с менеджером токенов безопасности контейнеров (описанным ниже) для авторизации всех запросов. Все операции, которые выполняются над контейнерами, работающими на данном узле, записываются в журнал аудита и могут быть в дальнейшем обработаны модулями безопасности.
   • Сервис локализации ресурсов. Отвечает за безопасную загрузку обработку множественных ресурсов, которые необходимы контейнерам. Он пытается распределить необходимые файлы по всем доступным дискам. Он также следит за выполнением ограничений контроля доступа над загруженными файлами и налагает соответствующие лимиты использования на них.
   • Модуль запуска контейнеров. Поддерживает пул потоков для подготовки и запуска контейнеров для обеспечения максимально быстродействия. Также удаляет процессы контейнеров, когда такой запрос поступает от менеджера ресурсов или мастера приложений.
   • Вспомогательные сервисы. Менеджер узлов предоставляет платформу для расширения его функциональности с помощью настройки дополнительных сервисов. Это позволяет запускать на узлах специальные сервисы, необходимые для работы определённой платформы, при этом отделив эти сервисы от остальных компонент менеджера узлов. Когда запускается первый контейнер приложения на узле или приложение завершило свою работу, происходит уведомление дополнительных сервисов.
   • Монитор контейнеров. После того как контейнер запущен этот компонент начинает наблюдение за тем как контейнер использует ресурсы во время своей работы. Для обеспечения изоляции и согласованного совместного использования ресурсов таких как память, каждому контейнеру менеджером ресурсов выделяется определённое количество ресурсов. Монитор контейнеров непрерывно наблюдает за использованием контейнеров и если контейнер выходит за установленные границы ресурсов, то монитор сообщает о том, что работу этого контейнера необходимо завершить. Это реализовано для того, чтобы предотвратить влияние такого «плохого» контейнера на тех, кто работает в заданном пространстве ресурсов в пределах одного узла.
   • Обработчик журналов. Это подключаемый компонент имеющий опцию либо непосредственного хранения журналов контейнеров на локальных дисках либо предварительного архивирования и загрузки в файловую систему.
3. Модуль выполнения контейнеров. Взаимодействует с операционной системой для безопасного размещения файлов и директорий, необходимых контейнерам, а также для последующего запуска и удаления в безопасном режиме процессов, соответствующих контейнеру.
4. Сервис проверки состояния узлов. Предоставляет функциональность для проверки состояния узла посредством многоразового запуска сконфигурированного скрипта. Он также время от времени проводит мониторинг состояния дисков путём создания временных файлов и записи их на диск. Любые изменения в состоянии системы передаются модулю обновления статуса узлов (описан выше), который в свою очередь передаёт информацию менеджеру ресурсов.
5. Модуль безопасности.
   • Менеджер списков доступа приложений. Менеджеру узлов необходимо фильтровать пользователей, работающих с его API также как и веб-интерфейсу необходимо отображать журналы контейнеров только авторизированным пользователям. Этот компонент управляет списками контроля доступа и выполняет проверку прав доступа при обращении к ресурсам.
   • Менеджер токенов безопасности контейнеров. Проверяет многочисленные входящие запросы и гарантирует, что все входящие операции на самом деле авторизированны менеджером ресурсов.
6. Веб сервер. Показывает список приложений, список контейнеров, работающих на узле в данный момент времени, информацию о работоспособности узла, и файлы журналов, созданные контейнером.
7. Сервис удаления. Сервис удаляет локальные пути по командам других сервисов.

Краткий обзор функциональности

Запуск контейнера

Для запуска контейнера менеджер узла ожидает получить детальную информацию о программе, которая будет запускаться в контейнере в качестве части спецификации контейнера. Она включает в себя командую строку контейнера, переменные окружения, список ресурсов (файлов), необходимых для работы контейнера и произвольные токены безопасности.

При получении запроса на запуск контейнера — менеджер узлов, во-первых, если включён безопасный режим работы, проверяет допустимость выполнения запроса авторизированным пользователем и правильность присвоения ресурсов. Менеджер узлов выполняет следующий набор шагов для запуска контейнера:

1. Создаётся локальная копия необходимых ресурсов (Распределённый кеш).
2. Создаются выделенные рабочие директории для контейнера, и локальные ресурсы становятся доступными в этих директориях.
3. Командная строка запуска и переменные окружения используются для фактического запускам контейнера.

Агрегация журналов

Работа с журналами пользователей в прошлом была одной из наиболее значительных трудностей в платформе Hadoop. Вместо усечения пользовательских журналов и хранения их на отдельных узлах подобно трекеру задач, менеджер узлов решает задачу управления журналами предоставляя возможность перемещать журналы в файловую систему (например в HDFS) после того как приложение завершилось.

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

Преимущества вспомогательных сервисов

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

Выводы

В платформе YARN менеджер узлов предназначен только для управления абстрактными контейнерами, то есть только отдельными процессами, запущенными в контейнере, а не для управления задачами отображения/свёртки в целом. Менеджер узлов к тому же не использует концепцию «именных» слотов, так что слоты отображений и слоты свёрток не используются. Благодаря такому чёткому распределению обязанностей совместно с модульной архитектурой, описанной выше, менеджер узлов масштабируется гораздо лучше, к тому же его код более прост в поддержке.

Перечень использованных ссылок

1. http://hortonworks.com/blog/apache-hadoop-yarn-background-and-an-overview/
2. http://hortonworks.com/blog/apache-hadoop-yarn-concepts-and-applications/
3. http://hortonworks.com/blog/apache-hadoop-yarn-resourcemanager/
4. http://hortonworks.com/blog/apache-hadoop-yarn-nodemanager/