Продолжая обучение основам Apache Hadoop для начинающих администраторов, сегодня рассмотрим архитектуру и принципы работы YARN в кластере. Также разберем, какие отказы могут случиться на каждом из его компонентов и как Resource Manager системы YARN обеспечивает высокую доступность кластера Apache Hadoop.
Зачем Apache Hadoop нужен YARN и как он работает
Поскольку Hadoop работает в кластере, ему необходима система планирования заданий и управления распределенными приложениями. Эту роль выполняет один из 4-х основных модулей проекта, YARN – набор системных служб (демонов), которые обеспечивают совместное использование, масштабирование и надежность работы распределенных приложений. Таким образом, YARN является интерфейсом между аппаратными ресурсами кластера и распределенными приложениями, использующих его мощности для обработки и аналитики больших данных.
YARN разделяет функции управления ресурсами и планирования/мониторинга заданий на отдельные демоны, чтобы иметь глобальный диспетчер ресурсов (ResourceManager) и мастер приложения (ApplicationMaster) для каждого отдельного задания или их конвейера в виде направленного ациклического графа (DAG, Directed Acyclic Graph).
ResourceManager и диспетчер узлов (NodeManager) образуют структуру вычисления данных, где ResourceManager распределяет ресурсы между всеми приложениями в системе, а NodeManager является агентом инфраструктуры для каждой машины. Он отвечает за контейнеры, отслеживает использование ресурсов (ЦП, память, диск, сеть) и сообщает об этом планировщику (Scheduler) ResourceManager. Этот планировщик отвечает за распределение ресурсов между запущенными приложениями на основе требований приложений к ресурсам в виде контейнера, который включает память, процессор, диск, сеть и т. д., с учетом известных ограничений емкости, очередей и пр. Scheduler не отслеживает статус выполнения самих приложений и не дает гарантий перезапуска невыполненных задач из-за программного или аппаратного сбоя. ApplicationMaster для каждого приложения является специфической библиотекой платформы, которая согласовывает ресурсы с ResourceManager и работает с NodeManager для выполнения и мониторинга задач [1].
Таким образом, сбой в YARN может случиться из-за отказов на уровне мастера приложения, диспетчера ресурсов, диспетчера узлов и отдельных задач (Tasks) [2].
Отказы на уровне Application Master
ApplicationManager отвечает за прием отправок заданий, согласование первого контейнера для выполнения конкретного приложения ApplicationMaster и предоставляет службу для перезапуска его контейнера в случае сбоя. ApplicationMaster для каждого приложения отвечает за согласование с планировщиком соответствующих контейнеров ресурсов, отслеживание их статуса и мониторинг выполнения [2].
Если в Hadoop произойдет сбой мастера приложения, вся информация, связанная с выполнением этого конкретного задания, будет потеряна. По умолчанию максимальное количество попыток запуска ApplicationMaster равно 2: задание завершается ошибкой, если мастер приложения не сработал дважды. Управлять количеством повторных попыток запуска ApplicationMaster можно, задав значение свойства yarn.resourcemanager.am.max-plays.
Мастер приложения отправляет периодические heartbeat-сигналы в диспетчер ресурсов, который обнаружит сбой при отказе ApplicationMaster и запустит его новый экземпляр в новом контейнере, используя историю заданий для восстановления состояния, чтобы не запускать повторно уже запущенные задачи. Такое восстановление по умолчанию включено, но его можно отключить, установив для свойства yarn.app.mapreduce.am.job.recovery.enable значение false.
Клиент MapReduce опрашивает мастер приложения о ходе выполнения задания, поэтому при выходе мастера приложения из строя, клиенту необходимо найти новый экземпляр. Для этого во время инициализации задания клиент запрашивает у диспетчера ресурсов адрес мастера приложения, а затем кэширует его, чтобы не отправлять запросы каждый раз. Если мастер приложения выходит из строя, на клиенте возникает тайм-аут обновления статуса выполнения задания. Поэтому клиент снова отправит запрос диспетчеру ресурсов о новом адресе мастера приложения.
Что не так с менеджером узлов и при чем здесь мастер Hadoop-приложения
NodeManager будет отправлять контрольный сигнал (heartbeat) каждые 3 секунды диспетчеру ресурсов. Если диспетчер узлов выходит из строя из-за сбоя или работает очень медленно, ResourceManager будет ждать heartbeat-сигнала в течение 10 минут. Если он не будет получен, RM удалит узел из своего пула, чтобы запланировать контейнеры.
Если ApplicationMaster запущен в диспетчере отказавшего узла, то он будет перезапущен на другом узле, и это не будет засчитано в счетчике свойства yarn.resourcemanager.am.max-plays, т.к. было вызвано не ошибкой самого мастера приложения. На отказавших узлах даже завершенные задачи незавершенных полностью заданий, т.к. их промежуточный результат в локальной файловой системе отказавшего NodeManager, может быть недоступен для Reduce-шага задачи MapReduce.
NodeManager’ы могут быть занесены в черный список при большом количестве отказов приложения, даже если сам NodeManager не выходил из строя. Внесение в черный список выполняется мастером приложения, если на диспетчере узлов не удается выполнить более трех задач.
Менеджер ресурсов в YARN
До Hadoop 2.4 ResourceManager был единственной точкой отказа YARN в кластере Hadoop. Поэтому для обеспечения высокой доступности добавлена избыточность в виде пары Active/Standby диспетчеров ресурсов. В любой момент времени один ResourceManager находится в активном состоянии, а другие или находятся в режиме ожидания. Триггер перехода к активному состоянию поступает от администратора через CLI-интерфейс или через интегрированный контроллер аварийного переключения, если включено автоматическое переключение при сбое.
При включенном перезапуске ResourceManager, переведенный в активное состояние, загружает внутреннее состояние и продолжает работать с того места, где остановился предыдущий активный диспетчер ресурсов. Переход диспетчера ресурсов из режима ожидания в активный выполняется контроллером аварийного переключения. Контроллер аварийного переключения по умолчанию является автоматическим, который использует выборы лидера ZooKeeper, чтобы гарантировать активность только одного ResourceManager в один момент времени.
Информация обо всех запущенных приложениях хранится в высокодоступном хранилище состояний, так что резервный ResourceManager может восстановить состояние ядра отказавшего активного диспетчера ресурсов. Информация о менеджере узлов не сохраняется в хранилище состояний, поскольку она может быть относительно быстро восстановлена новым менеджером ресурсов, когда NodeManager отправят свои первые heartbeat-сигналы.
Существует две реализации хранилища состояний диспетчера ресурсов (RMStateStore) [2]:
- FileSystemRMStateStore на основе файловой системы HDFS. Используется по умолчанию.
- ZKRMStateStore на основе Zookeeper, которое неявно разрешает доступ на запись к одному ResourceManager в любой момент времени и, следовательно, является рекомендуемым хранилищем для использования в Hadoop-кластере высокой доступности. Не рекомендуется устанавливать свойство DigestAuthenticationProvider.superDigest в кластере Zookeeper, чтобы избежать несанкционированного доступа его администратора к учетным данным приложения или пользователя YARN.
- хранилище на базе высокопроизводительной NoSQL-СУБД LevelDB, которая поддерживает более совершенные атомарные операции, меньшее количество операций ввода-вывода на обновление состояния и гораздо меньшее количество файлов в файловой системе по сравнению с HDFS и ZKRMStateStore.
Задать нужное хранилище состояний для ResourceManager можно в свойстве yarn.resourcemanager.store.class, которое может принимать следующие значения, определяющее имя соответствующего класса [3]:
- apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore – реализация на основе ZooKeeper;
- apache.hadoop.yarn.server.resourcemanager.recovery.FileSystemRMStateStore — реализация на базе Hadoop HDFS или локальной файловой системы;
- apache.hadoop.yarn.server.resourcemanager.recovery.LeveldbRMStateStore — реализация на базе NoSQL-СУБД LevelDB.
Далее необходимо настроить свойства выбранного хранилища состояний согласно рекомендациям из официальной документации Apache Hadoop [3].
Сбой задачи в Apache Hadoop
Сбой задачи обычно происходит из-за исключений во время выполнения или из-за внезапного выхода из строя задачи JVM. Задача будет отправлять контрольный сигнал в мастер приложения каждые 3 секунды, но если он не получит обновлений в течение 10 минут, то будет считать задачу неудачной и повторит попытку ее выполнения.
Когда мастер приложения получает уведомление о неудачной попытке выполнения задачи, он перепланирует ее выполнение, пытаясь избежать узлов, на которых она завершилась неудачно. Но если задачу не удалось выполнить 4 раза, она не будет повторяться снова и задание вернет статус ошибки.
Выполнение некоторых задач может быть специально прервано, что отличается от неудачной попытки. Например, когда есть вероятность дублирования или отказа менеджера узла, на котором выполнялась задача. Как и в случае отказа NodeManager, эти попытки не будут учтены в счетчике свойства yarn.resourcemanager.am.max-plays, т.к. вызваны не ошибкой самого ApplicationMaster [2].
Об обновлениях YARN в свежем релизе Apache Hadoop 3.3.1, выпущенном в июне 2021 года, читайте в нашей новой статье. А практически освоить все тонкости администрирования и эксплуатации Apache Hadoop для хранения и аналитики больших данных вам помогут специализированные курсы в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
