Архитектура YARN: ResourceManager, NodeManager, ApplicationMaster, контейнеры
YARN (Yet Another Resource Negotiator) являет собой ядро управления ресурсами Hadoop-экосистемы после эпохи MapReduce v1. Его задача - обеспечить эффективное распределение ресурсов кластера между различными приложениями, обеспечить изоляцию процессов и устойчивость к сбоям. Глава посвящена детальному рассмотрению архитектуры YARN: ролям ResourceManager, NodeManager и ApplicationMaster, механизмам взаимодействия, жизненному циклу приложений и ключевым аспектам планирования ресурсов. В контексте методологии архитектурной трансформации Hadoop/YARN становится понятным, как обеспечить масштабируемость, многопользовательский доступ и совместную эксплуатацию разных обработчиков данных на одной инфраструктуре.
В основе YARN лежит принцип разделения ответственности: глобальный планировщик ресурсов в ResourceManager оперирует кластерами, локальные ресурсы управляются NodeManager на каждом узле, а ApplicationMaster отвечает за конкретное приложение, включая планирование задач внутри него. Контейнеры становятся единицами распределения ресурсов и изоляции, благодаря чему можно запускать MapReduce, Tez, Spark и другие фреймворки на одной площадке без жесткой привязки к конкретному приложению.
Далее приводятся механизмы взаимодействия между компонентами, типовые сценарии ошибок и соответствующие механизмы устойчивости. Разбор основан на принципах консистентности и устойчивости к сбоям: RM и NM обмениваются heartbeats, AM через RM запрашивает ресурсы и запускает контейнеры, а управление жизненным циклом приложения обеспечивается на уровне AM и RM.
Краткое содержание главы
- Архитектура YARN: роли ResourceManager, NodeManager, ApplicationMaster и контейнеров, принципы разделения ответственности.
- Контейнеры и модель ресурсов: как задаются ресурсы, какие изоляционные механизмы применяются и как lifecycle контейнеров интегрирован с планировщиком.
- Взаимодействия и протоколы: основные RPC-профили между RM, NM и AM, тайминги heartbeat и обработка сбоев.
- Жизненный цикл приложения и алгоритмы планирования: шаги подачи заявки, ходы AM, механизмы планирования (Capacity, Fair), роль предиктивной остановки и перезапуска.
- Безопасность, мониторинг и интеграции: аутентификация, токены, шифрование RPC, интеграция с HDFS, Tez и Spark, мониторинг и управление.
Архитектура YARN: разделение ролей и взаимодействие
ResourceManager является глобальным планировщиком кластера. Он отвечает за распределение доступных ресурсов между всеми запущенными приложениями и за создание жизненного цикла каждого приложения через ApplicationMaster. В состав RM входят компоненты, ответственные за планирование, учет и обслуживание запросов от приложений. ResourceManager принимает запросы на выделение ресурсов через протокол Allocate и координирует запуск контейнеров на NodeManager’ах.
NodeManager разворачивает и контролирует выполнение контейнеров на конкретном узле. Он управляет процессами внутри контейнеров, мониторит ресурсные показатели и отчитывается RM о состоянии узла, загрузке CPU/memory и о завершении задач. NM также отвечает за загрузку локальных ресурсов (JAR-файлы, конфигурации, зависимости) в контейнер и за настройку окружения выполнения.
ApplicationMaster - автономный, но прикрепленный к каждому конкретному приложению процесс. Он осуществляет управление задачами внутри приложения, запрашивает ресурсы у RM, координирует постановку задачи в контейнеры, следит за завершением работы и в случае сбоев инициирует перезапуск некоторых контейнеров или всего этапа обработки. AM не является «администратором» кластера; это представитель конкретного приложения, отвечающий за оптимизацию исполнения в рамках согласованных правил планирования.
Контейнеры - это единицы распределения ресурсов и изоляции. Каждый контейнер получает заданное количество памяти и виртуальных CPU, а также набор локальных ресурсов и окружение (ENV, переменные, файлы). Контейнеры запускаются на узлах NodeManager и проходят жизненный цикл через протоколы RM и AM: запрашиваются, запускаются, мониторятся и завершаются. Изоляция достигается за счет операционной системы и механизмов управления ресурсами (например, cgroups в Linux), что минимизирует влияние одного приложения на другие.
Три ключевых принципа, которые определяют архитектуру YARN:
- Разделение областей ответственности: RM** - глобальное планирование; NM - локальное управление ресурсами; AM - управление приложением и задачами внутри.
- Обеспечение масштабируемости: горизонтальная линейная масштабируемость за счет репликаций NM и балансировки нагрузки RM.
- Гибкость и многофреймворковость: поддержка MapReduce, Tez, Spark и других исполнителей на одной инфраструктуре благодаря единообразному интерфейсу взаимодействия через YARN.
Контейнеры и ресурсная модель
Контейнер представляет собой конкретное сочетание ресурсов: память (обычно в мегабайтах) и виртуальные ядра CPU, плюс набор локальных ресурсов и контекст выполнения. Ресурсная модель YARN оперирует абстракциями Resource и Container. Resource задаёт параметры памяти и CPU, которые может потребовать приложение. Контейнер - это запущенный процесс или набор процессов, имеющих выделенное окружение, доступ к локальным ресурсам и ограниченный набор прав. Контейнеры запускаются на узлах NodeManager по запросу RM, и их жизненный цикл тщательно контролируется, чтобы обеспечить предсказуемость кластера.
Жизненный цикл контейнера начинается с запроса AM или RM на создание контейнера с заданными ресурсами. NM подготавливает окружение, разворачивает локальные ресурсы и запускает команду из ContainerLaunchContext. В ходе выполнения контейнер может обмениваться статусами с RM и AM, сообщать об использовании ресурсов и завершается по инициативе AM, RM или из-за сбоев внутри контейнера. При этом изоляция гарантируется не на уровне виртуальных машин, а через механизмы ОС и средства управления ресурсами (в том числе cgroups, namespaces, ограничение доступа к сети и дисковому вводу-выводy).
С точки зрения практики управления ресурсами, ключевые параметры следующие:
- memory и vCPU для каждого контейнера; RM использует эти параметры для планирования и балансировки нагрузки на узлы.
- лимиты и квоты: кластер может поддерживать разные политики QoS и очередей (через Capacity или Fair Scheduler), чтобы обеспечить приоритеты для критически важных задач.
- локальные ресурсы и передача контекстов: AM предоставляет список локальных ресурсов (jar-файлы, конфигурации) через ContainerLaunchContext, чтобы все необходимые артефакты были доступны внутри контейнера.
Изоляционные механизмы в контейнерах YARN обеспечивают безопасность и отказоустойчивость. Один из стандартов - использование cgroups для ограничения потребления CPU и памяти, а также ограничение конкурентного доступа к файловой системе и сети. Это не только снижает риск перегрузки узла, но и повышает предсказуемость исполнения, что особенно важно в многопользовательских кластерах.
Примеры приложений, которые работают на YARN и используют контейнерную модель, включают MRv2, Apache Tez и Apache Spark. Они могут запускаться внутри контейнеров, предоставленных RM и NM, и эффективно делить ресурсы в рамках единого кластера. Встроенная поддержка таких фреймворков делает YARN универсальной платформой для обработки больших данных, где различным задачам требуется различная степень параллелизма и временных ограничений.
Взаимодействия и протоколы: как компоненты договариваются
Коммуникация между компонентами YARN строится на наборах RPC-операций и обновления статусов, обеспечивающих координацию между RM, NM и AM. Рассмотрим основные паттерны взаимодействия:
-
Регистрация и инициализация AM: ApplicationMaster регистрируется в RM через протокол регистрации, после чего RM возвращает информацию о согласованной квоте и ближайших узлах, на которых можно разместить контейнеры для приложения. Это обеспечивает единый стартовый контекст для AM и позволяет RM учитывать текущую загрузку кластера.
-
Запрос ресурсов: AM (или сам RM в рамках координации) отправляет запросы на ресурсы через вызов allocate. В ответ RM возвращает список доступных и выделенных контейнеров на разных узлах. Этот обмен включает метаданные о запрашеемых ресурсах: память, CPU, локальные ресурсы и т. д.
-
Планирование и распределение контейнеров: RM решает, на каких узлах запустить новые контейнеры, исходя из политики планирования (Capacity, Fair), текущей загрузки и очередей. По принятию решения RM инициирует запуск контейнеров через NM.
-
Heartbeat и мониторинг: NM регулярно посылает heartbeats в RM, сообщая об уровне загрузки, состоянии узла и запущенных контейнеров. RM использует эту информацию для актуализации каталога ресурсов и принятия решений о перераспределении ресурсов в случае сбоев или перегрузки.
-
Обслуживание сбоев: при сбое AM RM может перезапустить AM на другом узле, а также повторно распределить контейнеры, привязанные к сбойному узлу. NM сообщает RM об ошибках контейнеров, что позволяет RM заново распределять задачи согласно текущему состоянию кластера.
-
Передача контекстов и локальных ресурсов: AM и контейнеры обмениваются контекстами запуска (ContainerLaunchContext), которые включают окружение, пути к локальным ресурсам и команды запуска. Это обеспечивает однородность исполнения вне зависимости от конкретного приложения.
Чтобы понять логику взаимодействия, полезно рассмотреть упрощенную схему потока:
- Клиент подает приложение в RM.
- RM создаёт запись приложения и выделение для AM.
- RM выбирает узел и запускает контейнер AM через NM.
- AM регистрируется в RM и запрашивает контейнеры для задач.
- RM планирует и запускает требуемые контейнеры на узлах NM.
- AM отслеживает прогресс, завершение задач и, по завершении, сообщает об окончании.
- RM и AM завершают приложение, освобождая ресурсы.
Протоколы взаимодействия поддерживают не только базовый обмен сообщениями, но и метрики производительности, статус выполнения задач, а также механизмы авторизации и аудита.
Жизненный цикл приложения и алгоритмы планирования
Жизненный цикл любого приложения в YARN начинается с подачи заявки и заканчивается ее завершением. Он включает следующие ключевые этапы:
-
Подготовка и регистрация: клиент подает заявку в RM, который инициирует ApplicationMaster и выделяет контейнер для AM. AM регистрируется в RM, устанавливая контекст выполнения и договорённости по ресурсам.
-
Запрос ресурсов и запуск задач: AM начинает запросы ресурсов через RM для целевого числа и типа контейнеров. RM распределяет ресурсы по узлам и инициирует запуск контейнеров на NM через соответствующие вызовы.
-
Планирование задач внутри AM: AM (для каждого конкретного типа приложения) реализует внутреннюю логику планирования задач внутри выделенного набора контейнеров. Для MapReduce или Tez это включает разбиение работы на мапперы, редюсеры и прочие фазы; для Spark - распределение симметричной обработки данных между executors.
-
Мониторинг и коррекция: RM и AM следят за прогрессом выполнения и производительностью. При необходимости AM может запрашивать перераспределение ресурсов (например, увеличение числа контейнеров или перераспределение их на другие узлы).
-
Завершение приложения: AM выполняет финализацию, сообщает RM о завершении, RM закрывает ресурсы и освобождает занятые контейнеры. В случае ошибок AM может перезапуститься или завершиться с возвратом ошибок, после чего RM инициирует восстановление в рамках политики кластера.
Что касается планирования ресурсов, YARN поддерживает несколько реальных реализаций планировщиков, которые формируют поведение кластера:
-
Capacity Scheduler: ориентирован на многоуровневую структуру очередей и гарантированное выделение пропускной способности для каждого пула и приложения. Он подходит для организаций с жесткими требованиями к сервисам и уровню приоритета между бизнес-подразделениями.
-
Fair Scheduler: нацелен на справедливое распределение ресурсов между активными приложениями. Он старается обеспечить баланс между задачами разных приложений, минимизируя периоды «голодания» и перераспределяя ресурсы в пользу менее обслуживаемых служб.
Важна роль предиктивной устойчивости: RM может инициировать предохранительное высвобождение ресурсов (preemption), чтобы обеспечить возможность выполнения критичных задач. Это особенно важно в условиях пиковых нагрузок и многоарендной эксплуатации, когда несколько приложений соревнуются за ограниченные ресурсы.
Жизненный цикл также включает обработку сбоев-AM-сбои или узловых сбоев. RM и AM имеют стратегии повторного запуска и перемещают выполнение на другие узлы. Это обеспечивает отказоустойчивость и высокую доступность обработки, что критично в продукционных кластерах.
Безопасность, мониторинг и интеграции
Безопасность YARN базируется на наборе механизмов аутентификации, авторизации и защиты передачи данных. Основной подход - Kerberos для аутентификации между компонентами и сервисами. Делегируемые токены используются AM как механизм аутентификации в доступе к HDFS и другим сервисам в рамках времени жизни приложения. TLS поддерживает шифрование RPC между компонентами, снижая риск перехвата данных и подмены сообщений.
Для управления безопасностью и доступом используются дополнительные инструменты, такие как Apache Ranger, обеспечивающий централизованную политику доступа и аудит, и инфраструктура мониторинга и управления, например Apache Ambari или коммерческие решения на базе Hadoop-дистрибутивов. В рамках интеграции с экосистемой YARN следует учитывать совместимость версий и зависимости между компонентами, чтобы обеспечить корректное функционирование политик безопасности.
Мониторинг и управление областью YARN осуществляются через:
- Метрики JMX и внешние панели мониторинга, которые собирают данные о загрузке узлов, использовании памяти, количестве запущенных контейнеров и задержках в обработке запросов.
- Логи контейнеров и приложений, собираемые в Kafka/Elastic или локально на HDFS для последующего анализа и трассировки.
- Инструменты управления кластерами (Ambari, Cloudera Manager) - упрощают развертывание, настройку и мониторинг целевых компонентов.
Интеграции в экосистему Hadoop-коверя включают:
- HDFS как источник/приемник данных для приложений, запущенных на YARN.
- MRv2 (MapReduce на YARN), Tez и Spark как потребители YARN в качестве фреймворков обработки данных.
- В контексте открытого ПО можно упомянуть Tez и Spark как одни из самых популярных примеров приложений, работающих на YARN. Это демонстрирует гибкость YARN в работе с различными стилями выполнения и динамическим планированием ресурсов.
В данном разделе следует отметить, что открытые решения (например, Apache Hadoop) и инструменты (Apache Tez, Apache Spark) добавляют конкретные реализации и примеры сценариев внедрения, но архитектура YARN остается универсальной основой для многопоточности и многопользовательской обработки данных. Российские продукты и решения, как и любые open-source, в рамках этой главы можно упомянуть лишь для иллюстрации конкретных интеграций, не перегружая текст. При этом предпочтение отдается концептуальному объяснению и практическим выводам, которые применимы независимо от выбранного поставщика решений.
Key takeaways
- YARN разделяет ответственность между ResourceManager, NodeManager и ApplicationMaster, что обеспечивает масштабируемость и гибкость кластера.
- Контейнеры служат единицами планирования и изоляции ресурсов, обеспечивая одновременную работу разных приложений на одной инфраструктуре.
- Протоколы взаимодействия RM-AM, RM-NM и NM-контейнеров критически важны для корректной маршрутизации запросов на ресурсы, мониторинга и управления жизненным циклом.
- Планировка ресурсов реализуется через различные schedulers (Capacity, Fair), поддерживаются предиктивные и реактивные механизмы перераспределения ресурсов и учет приоритетов приложений.
- Безопасность, мониторинг и интеграции с HDFS, Tez и Spark обеспечивают производительность, управляемость и устойчивость кластера в продакшене.
FAQ
- Что такое ApplicationMaster и как он связан с конкретным приложением?
- ApplicationMaster - это управляющий агент, привязанный к конкретному приложению. Он отвечает за планирование внутри приложения, запросы ресурсов у ResourceManager и координацию задач, разворачиваемых в контейнерах NodeManager. AM не управляет кластером в целом, а действует как локальный менеджер исполнения внутри выделенной квоты RM. Если AM завершается сбоем, RM может перезапустить его на другом узле, чтобы обеспечить продолжение обработки.
- Как работает планирование ресурсов в YARN и какие есть альтернативы?
- Планирование в YARN реализуется через Scheduler в RM. Основные подходы: Capacity Scheduler - обеспечивает очереди и гарантированное выделение для подразделений; Fair Scheduler - стремится обеспечить равное распределение ресурсов между активными приложениями. Выбор планировщика зависит от требований к квотам, SLA и профиля нагрузки. В реальном кластере часто применяется гибридная конфигурация, где ядро - Capacity, а отдельные бизнес-подразделения получают справедливый доступ между собой через настройки очередей.
- Чем отличается контейнер от виртуальной машины в контексте YARN?
- Контейнер в YARN - это легковесная единица ресурсообеспечения, базирующаяся на ОС-изоляции (cgroups, namespaces) и локально предоставляемой среде исполнения. В отличие от полных виртуальных машин, контейнеры запускаются значительно быстрее, потребляют меньше ресурсов и позволяют динамически масштабировать выполнение приложений внутри кластера без накладных расходов виртуализации.
- Как обеспечивается устойчивость к сбоям и что происходит при выходе AM?
- При сбое AM RM может запустить новый AM на другом узле и перераспределить выделенные контейнеры. NodeManager сообщает RM о статусе контейнеров, что позволяет RM перераспределить ресурсы и перезапустить задачи. Это обеспечивает устойчивость к сбоям и минимизирует время простоя.
- Какие чтения и политики безопасности применяются в YARN?
- Основной механизм безопасности - Kerberos для аутентификации между компонентами и делегируемые токены для доступа к другим сервисам (например, к HDFS). В конфигурациях можно включить TLS для защиты RPC, использовать политики доступа через инструменты вроде Apache Ranger. В рамках этого микро-подразделения рекомендуется ограничивать привилегии AM и обеспечить детальный аудит действий.
- Какие фреймворки обычно запускаются на YARN?
- Часто встречаются MapReduce ( MRv2 ), Apache Tez, Apache Spark. Эти фреймворки используют единый интерфейс ресурсообеспечения YARN для запросов контейнеров и выполнения задач. Tez и Spark особенно демонстрируют гибкость YARN как платформы обработки данных, где можно подстроить разные парадигмы выполнения.
- Каковы практические шаги для внедрения YARN в существующий кластер?
- Определить требуемые политики планирования (какие очереди, приоритеты, квоты).
- Выбрать планировщик (Capacity или Fair) и настроить параметры RM и NM (heartbeat, timeouts, ресурсные лимиты).
- Обеспечить безопасный доступ к HDFS и сервисам через Kerberos/Token и TLS, настройку аудита.
- Выбрать и внедрить мониторинг: метрики, логи, панели управления, интеграцию с инструментами управления (Ambari/Cloudera Manager).
- Включить поддержку фреймворков (Spark, Tez) и обеспечить корректную интеграцию с существующим пайплайном данных.
