Смягчение ахиллова сухожилия Hadoop

Я только что прочитал это руководство по Hadoop, в котором говорится, что у Hadoop есть ахиллово сухожилие ( единая точка отказа) в JobTracker:

JobTracker — это единственная точка отказа для службы Hadoop MapReduce, что означает, что если JobTracker выйдет из строя, все запущенные задания будут остановлены.

А также эту статью, в которой говорится, что NameNode является SPOF:

Единственная точка отказа в кластере Hadoop — это NameNode.

Единичные точки отказа — это плохо, ладно? Какие стратегии/методы/инструменты/и т. д. можно ли обойти эти SPOF и сделать Hadoop избыточным, отказоустойчивым и отказоустойчивым (внимание, модное слово!)?


java hadoop fault-tolerance resiliency
person smeeb    schedule 25.06.2015    source источник

Ответы (2)


arrow_upward
1
arrow_downward

HDFS и Mapreduce являются основными компонентами Hadoop. В более ранних выпусках Apache Hadoop Namenode и Jobtracker были SPOF (можно настроить только один экземпляр). Эта проблема устранена в Hadoop 2.X.

Jobtracker HA.

HA Jobtracker HA можно достичь, настроив 2 Jobtracker(JT) экземпляра в режиме Active - Standby на двух узлах. Если один JT выйдет из строя, второй Jobtracker будет доступен для обслуживания запроса. Только один джобтрекер (активный) будет доступен для обслуживания запросов одновременно, второй JT (резервный) будет работать в режиме только для чтения. Для работы Jobtracker HA требуется экземпляр zookeeper. Переключение при сбое (переключение) можно настроить либо вручную, либо автоматически. Для автоматического перехода на другой ресурс требуется другой процесс с именем Failover Controller (FC). В текущем выпуске, если активный JT выходит из строя, все запущенные задания будут остановлены, однако новое задание будет автоматически отправлено на новый JT. Эта функция недоступна в текущей версии.

MR2 — это второе поколение mapreduce, использующее YARN, Resource Manager(RM) — основная служба в YARN, RM также можно настроить в режиме Active-Standby. Сбой RM не повлияет на выполнение заданий/приложений.

Namenode HA

Namenode HA — это нечто важное. Namenode HA также можно настроить в режиме Active-Standby (максимум 2 экземпляра namenode). Quorum based Journaling — широко распространенный метод, в котором используется Zookeeper. Одновременно будет активен только один namenode.

Secondary Namenode(SNN) не является Standby Namenode(SN) и наоборот, SNN имеет другую функциональность в конфигурации без высокой доступности, настройка Namenode HA не требует SNN, так как namenode SN выполняет контрольную точку (функциональность SNN)

Processes Namenode HA

  • Активный узел имени
  • Резервный узел имени
  • Отказоустойчивый контроллер: для ограждения, чтобы избежать сценария с разделенным мозгом.
  • Jounalnodes (требуется минимум 3 экземпляра): изменение пространства имен будет регистрироваться в узлах журнала, а резервный namenode считывается оттуда. Только одному namenode будет разрешено писать одновременно, чтобы избежать проблемы разделения мозга.
person SachinJ    schedule 01.07.2015

arrow_upward
1
arrow_downward

В Hadoop уже давно встроены High availability механизмы. 'Secondary NameNode', 'Backup JobTracker' будут служить в качестве горячей резервной копии своих соответствующих аналогов.

Большая часть прошлых «SPOF» была устранена с последними выпусками Hadoop.

Это подробно объясняется в следующих документах.

Надеюсь, поможет.

person Shyam    schedule 30.06.2015
comment
Спасибо @Shyam (+1) - я прочитаю ссылки, когда у меня будет возможность, но они кажутся довольно мускулистыми. В SO обычно не одобряют ответ на вопрос, просто ссылаясь на ссылку на документацию. Для полной награды, есть ли шанс, что вы сможете отредактировать свой ответ, чтобы он содержал краткое изложение основных стратегий высокой доступности, лежащих в основе Secondary NameNode и Backup JobTracker? Еще раз спасибо! - person smeeb; 30.06.2015
comment
На самом деле я не гнался за наградой. :) Но я понимаю вашу точку зрения, я обновлю свой ответ, когда у меня будет свободное время. - person Shyam; 01.07.2015