Отказоустойчивость в MapReduce - PullRequest
3 голосов
/ 28 апреля 2011

Я читал о Hadoop и о его отказоустойчивости. Я прочитал HDFS и прочитал, как можно обработать сбой главного и подчиненного узлов. Однако я не смог найти ни одного документа, в котором упоминается, как mapreduce выполняет отказоустойчивость. В частности, что происходит, когда мастер-узел, содержащий Job Tracker, выходит из строя или любой из подчиненных узлов выходит из строя?

Если кто-нибудь может указать мне некоторые ссылки и ссылки, которые объясняют это подробно.

Ответы [ 3 ]

4 голосов
/ 28 апреля 2011

Отказоустойчивость слоя MapReduce зависит от версии hadoop.Для версий, предшествующих hadoop.0.21, контрольные точки не выполнялись, и сбой JobTracker приводил к потере данных.

Однако в версиях, запускающих hadoop.0.21, была добавлена ​​контрольная точка, где JobTracker записывает свой прогресс в файл.Когда запускается JobTracker, он ищет такие данные, чтобы он мог возобновить работу с того места, где остановился.

4 голосов
/ 25 марта 2015

НЕДОПУСТИМОЙ ОТКАЗ В HADOOP

В случае, если JobTracker не получает пульса от TaskTracker в течение определенного периода время (по умолчанию оно установлено на 10 минут), JobTracker понимает, что работник, связанный с что TaskTracker не удалось. Когда происходит такая ситуация, JobTracker должен перенести все ожидающие и выполняющие задачи другому TaskTracker, поскольку промежуточные данные, принадлежащие сбойный TaskTracker может быть больше недоступен.

Все выполненные задачи на карте также должны быть перенесено, если они принадлежат незавершенным работам, потому что промежуточные результаты, находящиеся в неудавшейся Файловая система TaskTracker может быть недоступна для задачи сокращения.

TaskTracker также может быть в черном списке. В этом случае TaskTracker из черного списка остается в связь с JobTracker, но никакие задачи не назначены соответствующему работнику. Когда заданное количество задач (по умолчанию это число равно 4), принадлежащих к конкретной задаче, управляемой Сбой TaskTracker, система считает, что произошла ошибка.

Часть соответствующей информации в сердцебиении, которую TaskTracker отправляет в JobTracker: ● TaskTrackerStatus

● Перезагрузка

● Если это первое сердцебиение

● Если для выполнения узла требуется больше задач

TaskTrackerStatus содержит информацию о работнике, управляемом TaskTracker, например доступная виртуальная и физическая память и информация о процессоре. JobTracker хранит черный список с неисправным TaskTracker, а также последний полученный пульс из этого TaskTracker. Таким образом, при получении нового перезапущенного / первого пульса JobTracker, используя эта информация, может решить, перезапустить TaskTracker или удалить TaskTracker из черный список

После этого статус TaskTracker обновляется в JobTracker, и HeartbeatResponse имеет значение создано. Этот HeartbeatResponse содержит следующие действия, которые должен выполнить TaskTracker. Если есть задачи для выполнения, TaskTracker требует новых задач (это параметр Heartbeat) и его нет в черном списке, создаются задачи очистки и настройки ( механизмы очистки / настройки больше не исследовались). В случае, если нет очистки или Настройка задач для выполнения, JobTracker получает новые задачи. Когда задачи доступны, LunchTaskAction инкапсулируется в каждом из них, и затем JobTracker также ищет:

- Задачи быть убитыми

- Задания на убийство / очистку

-Задания, выходные данные которых еще не сохранены.

Все эти действия, если они применимы, добавляются в список действий, которые будут отправлены в HeartbeatResponse. Механизмы отказоустойчивости, реализованные в Hadoop, ограничиваются переназначением задач при заданном выполнение не удается. В этой ситуации поддерживаются два сценария: 1. В случае сбоя задания, назначенного данному TaskTracker, связь через Heartbeat используется для уведомления JobTracker, который по возможности переназначит задачу другому узлу. 2. Если TaskTracker не работает, JobTracker заметит неисправную ситуацию, потому что он не получит пульс от этого TaskTracker. Затем JobTracker назначит задачи, которые были у TaskTracker. в другой TaskTracker. Существует также единственная точка отказа в JobTracker, так как в случае сбоя происходит сбой всего выполнения.

Основные преимущества стандартного подхода к отказоустойчивости, реализованного в Hadoop, заключаются в его простоте и в том, что он хорошо работает в локальных кластерах. Однако стандартного подхода недостаточно для больших распределенных инфраструктур, расстояние между узлами может быть слишком большим и время, потраченное на переназначение задачи, может замедлить работу системы

2 голосов
/ 28 апреля 2011

Главный узел (NameNode) является единственной точкой отказа в Hadoop.Если он выйдет из строя, система будет недоступна.

Сбои ведомого (вычислительного) узла в порядке, и все, что работает на них во время сбоя, просто повторно запускается на другом узле.Фактически это может произойти, даже если узел работает медленно.

Некоторые проекты / компании стремятся устранить единую точку отказа.Погуглите «hadoop ha» (Высокая доступность), если вас это заинтересовало, вам по пути.

...