Что такое Unmanaged Application Master и его роль в Hadoop федерации пряжи? - PullRequest
0 голосов
/ 08 сентября 2018

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

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

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

1 Ответ

0 голосов
/ 03 марта 2019

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

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

1) Простая отладка AM, особенно во время начальной разработки. Имея АМ запускается на произвольном узле кластера, поэтому на него трудно смотреть логи или прикрепить отладчик к АМ. Если он может быть запущен локально тогда эти задачи будут проще.

2) Запуск AM, которые нуждаются в специальных привилегии, которые могут быть недоступны на машинах, управляемых NodeManager

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

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

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

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

FederationInterceptor
    sendRequestsToResourceManagers()

UnmanagedAMPoolManager
UnmanagedApplicationManager
...