Что такое Unmanaged Application Master и его роль в Hadoop федерации пряжи?

Question

Что такое Unmanaged Application Master и его роль в Hadoop федерации пряжи?

Я не получаю много информации о работе Unmanaged AM. Я просто знаю базовое определение об этом, но все еще не уверен, как осуществляется их управление и кем оно осуществляется?

Также в документе apache упоминается (пункт 8 в потоке выполнения задания): "На основе политики AMRMProxy может олицетворять AM в других субкластерах, отправляя неуправляемый AM и перенаправляя тактовые импульсы AM соответствующим суб-кластерам. кластеры. a. Федерация поддерживает несколько попыток приложения с помощью AMRMProxy HA. Контейнеры AM будут иметь разные идентификаторы попыток в домашнем субкластере, но один и тот же Неуправляемый AM во вторичных серверах будет использоваться при попытках. б. Когда включен AMRMProxy HA, токен UAM будет храниться в реестре Yarn. При вызове registerApplicationMaster каждой попытки приложения AMRMProxy будет извлекать существующие маркеры UAM из реестра (если таковые имеются) и повторно присоединяться к существующим UAM."

Заранее спасибо за подробное объяснение.

1

yarn resource-management hadoop3

Источник

user2907609 08 сен '18 в 10:55

0 ответов

Другие вопросы по тегам yarn resource-management hadoop3

user2676994 02 мар '19 в 21:44 2019-03-02 21:44 · Answer 1 · 2019-03-02 21:44

UAM был представлен в https://issues.apache.org/jira/browse/YARN-420. Первоначальная цель была

Было бы полезным улучшить эту модель, позволив клиенту независимо запускать AM, не требуя RM. Эти AM будут запущены на компьютере шлюза, который может общаться с кластером. Это откроет новые варианты использования, такие как следующие
1) Простая отладка AM, особенно при начальной разработке. Запуск AM на произвольном узле кластера затрудняет просмотр журналов или присоединение отладчика к AM. Если он может быть запущен локально, тогда эти задачи будут проще.
2) Запуск AM, которым требуются специальные привилегии, которые могут быть недоступны на машинах, управляемых NodeManager

Теперь UAM также играет важную роль в разработке федерации пряжи. По тому, как вы цитировали.

AMRMProxy может олицетворять AM в других подкластерах, отправляя неуправляемый AM и перенаправляя тактовые импульсы AM соответствующим субкластерам.

Идея проста. В федерации только один "настоящий" AM создается после подачи заявки (в домашнем подкластере). Однако для того, чтобы распределить контейнеры задач в других (вторичных) подкластерах, приложению необходимы AM в вторичных подкластерах, чтобы общаться с их RM. Федерация пряжи решает эту проблему, регистрируя UAM в подкластере, задачей которого является только пересылка allocate стук сердца.

Вы можете взглянуть на код

FederationInterceptor
    sendRequestsToResourceManagers()

UnmanagedAMPoolManager
UnmanagedApplicationManager