Запросы о ПРЯЖИ (режимы отказа, размер контейнера, практический пример)

Question

Я хочу задать несколько вопросов, чтобы понять работу ПРЯЖИ:

1. Любой человек может объяснить или дать ссылку на какой-либо документ, который может легко о режимах сбоя в YARN (например, сбой задачи, сбой мастер-приложения, сбой диспетчера узлов, отказ менеджера ресурсов)
2. Что такое размер контейнера в YARN? это то же самое, что слот в Map уменьшить 1?
3. Любой практический/рабочий пример YARN? Спасибо

Answer 1

Обратитесь к учебному пособию Hadoop Definitive Guide ... Кроме того, на веб-сайте Apache есть много информации.

Размер контейнера не фиксирован, он динамически распределяется на основе требований диспетчера ресурсов.

С точки зрения разработчика та же самая старая карта-сокращение будет работать на YARN.

отказы ResourceManager

В начальных версиях рамках ПРЯЖИ, неудачи ResourceManager означает полный отказ кластера, как это было единственной точкой отказа. ResourceManager сохраняет состояние кластера, например метаданные представленного приложения, информацию о контейнерах ресурсов кластера , информацию о общих конфигурациях кластера и т. Д. Следовательно, если ResourceManager отключается из-за какого-либо сбоя оборудования, то не существует способа избежать ручной отладки кластера и перезапуска утилиты ResourceManager . За время, пока ResourceManager не работает, кластер недоступен, и после его перезапуска все задания потребуют перезагрузки, поэтому полузаполненные задания теряют любые данные и их необходимо снова перезапустить. Короче говоря, перезапуск ResourceManager, используемый для перезапуска всех запущенных ApplicationMasters. Последние версии YARN адресуют эту проблему двумя способами. Одним из способов является создание активной пассивной архитектуры ResourceManager, так что когда кто-то идет вниз, другой становится активным и берет на себя ответственность за кластер. Другим способом является использование кворума Zookeeper ResourceManager, так что состояние ResourceManager хранится снаружи над Zookeeper, а один ResourceManager находится в активном состоянии, и один или несколько диспетчеров ресурсов находятся в пассивном режиме, ожидая чего-то, что приведет их к активное состояние.

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

NodeManager Неудача Если Node Manager не удается, ResourceManager обнаруживает эту ошибку, используя тайм-аут (то есть прекращает прием сердечных сокращений от NodeManager). Затем ResourceManager удаляет NodeManager из своего пула доступных NodeManagers. Он также убивает все контейнеры, запущенные на этом узле &, сообщает о сбое всех запущенных AM.Затем AMs отвечают за реакцию на отказы узлов, переделывая работу, выполняемую любыми контейнерами, запущенными на этом узле во время сбоя.

контейнеров Неудачи

Контейнерные отказы будут передаваться диспетчеру узла с Resource Manager и менеджер ресурсов информирует таки Application Master. Теперь приложение перезапустит контейнер.