Таким образом, каждый сервер состоит из коллекции контейнеров.
Так, например, если сервер имеет 4 ядра и 4 гигабайта ОЗУ, в каждом контейнере есть одно ядро и 1 гигабайт ОЗУ, и у этого сервера есть 4 контейнера и, по существу, он может выполнять четыре задачи по одной в каждом контейнере.
YARN имеет три основных компонента.
Это менеджер ресурсов, администраторы узлов и мастера приложений.
И существует один глобальный менеджер ресурсов, который запускает планировщика.
Существует один менеджер узла на один сервер в системе.
Это Daemon, который отвечает за все специфическое управление сервером, а также отвечает за мониторинг сбоев задач, которые выполняются на этой конкретной машине.
Затем есть Application Master, или мастер приложения, который также работает на одном из серверов, и отвечает за согласование контейнеров с диспетчером ресурсов и менеджерами узлов.
Он также отвечает за взаимодействие с менеджерами узлов, чтобы выяснить, умер ли какой-либо из них, чтобы перенести с него запущенные задачи.
Теперь давайте посмотрим, как MapReduce разбирается с ошибками.
Наиболее частой ошибкой является отказ самого сервера, и отказ сервера может привести к сбою нескольких компонентов Hadoop планировщика YARN.
Серверы запускают менеджеров узлов, у них запущены задачи, на одном из серверов работает диспетчер ресурсов, а также может работать мастер приложений.
И для решения проблем с отказами серверов, есть пульсация.
Менеджер узла на каждом сервере отправляет пульсацию центральному менеджеру ресурсов.
И если сервер не работает, и эта пульсация останавливается, менеджер ресурсов знает, что менеджер узла не работает.
Он дает знать об этом всем мастерам приложений, и мастера приложений перенаправляют свои задачи.
Менеджер узлов отслеживает каждую задачу, запущенную на своем сервере, поэтому, если одна из задач выходит из строя, эта задача помечается как протаивающая, и, либо менеджер узла ее перезапускает, если это возможно, либо он сообщает диспетчеру ресурсов или мастеру приложения, что эта задача не выполнена.
И наконец, мастер приложения также периодически пульсирует менеджеру ресурсов.
Если, мастер приложения не работает, менеджер ресурсов перезапустит мастер приложения, и он затем синхронизируется с его запущенными задачами.
Далее сам менеджер ресурсов может перестать работать.
В этом случае, чтобы справиться с этим, поддерживается вторичное жесткое резервное копирование, чтобы вторичный менеджер ресурсов мог сразу заработать после отказа менеджера ресурсов.
Протокол Gossip
Далее мы рассмотрим класс протоколов, называемый gossip протоколами сплетен или эпидемическими протоколами.
Но сначала начнем с постановки задачи.
Задача, которую gossip пытается решить, называется