Как настроить кластер Hadoop с высокой доступностью HDFS

Кластерная архитектура высокой доступности HDFS 2.x

В этом блоге я расскажу об архитектуре кластера высокой доступности HDFS 2.x и о процедуре настройки кластера высокой доступности HDFS.Это важная часть . Порядок, в котором темы были затронуты в этом блоге, следующий:

• Архитектура HDFS HA
  • Введение
  • NameNode Доступность
  • Архитектура HA
  • Реализация HA (JournalNode и общее хранилище)
• Как настроить HA (узлы журнала кворума) в кластере Hadoop?

Введение:

Концепция кластера высокой доступности была представлена ​​в Hadoop 2..x для решения проблемы единой точки отказа в Hadoop 1.x. Как вы знаете из моего предыдущего блога, следует топологии Master / Slave, где NameNode действует как главный демон и отвечает за управление другими подчиненными узлами, называемыми DataNodes. Этот единственный главный демон или NameNode становится узким местом. Хотя введение Secondary NameNode действительно предотвратило потерю данных и сняло часть бремени NameNode, но не решило проблему доступности NameNode.

Доступность NameNode:

Если учесть стандартную конфигурацию кластера HDFS, NameNode становится единая точка отказа . Это происходит потому, что в тот момент, когда NameNode становится недоступным, весь кластер становится недоступным, пока кто-то не перезапустит NameNode или не принесет новый.

Причины недоступности NameNode могут быть:

• Планируемое мероприятие, такое как техническое обслуживание, например обновление программного или аппаратного обеспечения.
• Это также может быть связано с незапланированным событием, когда NameNode выходит из строя по некоторым причинам.

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

Архитектура HDFS HA:

Давайте разберемся, как архитектура HDFS HA ​​решила эту критическую проблему доступности NameNode:

Архитектура высокой доступности решила эту проблему доступности NameNode, позволив нам иметь два NameNode в активной / пассивной конфигурации. Итак, у нас есть два запущенных NameNodes одновременно в кластере High Availability:

• Активный узел имени
• Резервный / пассивный NameNode.

Если один NameNode выходит из строя, другой NameNode может взять на себя ответственность и, следовательно, сократить время простоя кластера. Резервный NameNode служит резервному NameNode (в отличие от Secondary NameNode), который включает в себя возможности переключения при отказе для кластера Hadoop. Следовательно, с помощью StandbyNode мы можем иметь автоматическое аварийное переключение всякий раз, когда происходит сбой NameNode (незапланированное событие), или мы можем иметь плавное переключение (инициированное вручную) в течение периода обслуживания.

Есть две проблемы при поддержании согласованности в кластере высокой доступности HDFS:

• Активный и резервный NameNode всегда должны быть синхронизированы друг с другом, т.е. они должны иметь одинаковые метаданные. Это позволит нам восстановить кластер Hadoop до того же состояния пространства имен, в котором произошел сбой, и, следовательно, обеспечит быстрое переключение при отказе.
• В каждый момент времени должен быть только один активный NameNode, потому что два активных NameNode приведут к повреждению данных. Этот вид сценария называется сценарием с разделением мозга, когда кластер делится на более мелкие кластеры, каждый из которых считает, что это единственный активный кластер. Чтобы избежать таких сценариев, делается ограждение. Ограждение - это процесс обеспечения того, чтобы только один NameNode оставался активным в определенное время.

Реализация архитектуры высокой доступности:

Теперь вы знаете, что в архитектуре высокой доступности HDFS у нас одновременно работают два NameNodes. Итак, мы можем реализовать конфигурацию активного и резервного NameNode двумя способами:

1. Использование узлов журнала кворума
2. Общее хранилище с использованием NFS

Давайте разберемся с этими двумя способами реализации по одному:

1. Использование узлов журнала кворума:

• Резервный NameNode и активный NameNode синхронизируются друг с другом через отдельную группу узлов или демонов, называемых JournalNodes .JournalNodes следует кольцевой топологии, в которой узлы соединяются друг с другом, образуя кольцо.JournalNode обслуживает поступающий к нему запрос и копирует информацию в другие узлы в кольце..Это обеспечивает отказоустойчивость в случае отказа JournalNode.
• Активный NameNode отвечает за обновление EditLogs (информации метаданных), присутствующих в JournalNodes.
• StandbyNode считывает изменения, внесенные в EditLogs в JournalNode, и постоянно применяет их к своему собственному пространству имен.
• Во время аварийного переключения StandbyNode проверяет, обновил ли он информацию о своих метаданных из JournalNodes, прежде чем стать новым Active NameNode. Это синхронизирует текущее состояние пространства имен с состоянием до отработки отказа.
• IP-адреса обоих NameNodes доступны для всех DataNodes, и они отправляют свои контрольные сообщения и информацию о местоположении блока на оба NameNode. Это обеспечивает быстрое переключение при отказе (меньшее время простоя), поскольку StandbyNode имеет обновленную информацию о расположении блока в кластере.

Ограждение NameNode:

Теперь, как обсуждалось ранее, очень важно убедиться, что одновременно существует только один активный NameNode. Итак, ограждение - это процесс обеспечения именно этого свойства в кластере.

• JournalNodes выполняет это ограждение, позволяя писать только одному NameNode за раз.
• Резервный NameNode берет на себя ответственность за запись в JournalNodes и запрещает любому другому NameNode оставаться активным.
• Наконец, новый Active NameNode может безопасно выполнять свои действия.

2. Использование общего хранилища:

• StandbyNode и активный NameNode синхронизируются друг с другом с помощью общее запоминающее устройство .Активный NameNode регистрирует запись о любых изменениях, сделанных в его пространстве имен, в EditLog, присутствующем в этом общем хранилище.StandbyNode считывает изменения, внесенные в EditLogs в этом общем хранилище, и применяет их к своему собственному пространству имен.
• Теперь, в случае аварийного переключения, StandbyNode сначала обновляет информацию о своих метаданных, используя журналы редактирования в общем хранилище. Затем за это отвечает Active NameNode. Это синхронизирует текущее состояние пространства имен с состоянием до отработки отказа.
• Администратор должен настроить хотя бы один метод ограждения, чтобы избежать сценария разделения мозга.
• В системе может использоваться ряд ограждающих механизмов. Это может включать остановку процесса NameNode и аннулирование его доступа к каталогу общего хранилища.
• В крайнем случае, мы можем изолировать ранее активный NameNode с помощью техники, известной как STONITH, или «выстрелить другому узлу в голову». STONITH использует специализированный блок распределения питания для принудительного отключения машины NameNode.

Автоматический переход на другой ресурс:

Отказоустойчивость - это процедура, с помощью которой система автоматически передает управление вторичной системе при обнаружении неисправности или отказа. Существует два типа аварийного переключения:

Изящный отказ: В этом случае мы вручную инициируем аварийное переключение для планового обслуживания.

Автоматический переход на другой ресурс: В этом случае аварийное переключение инициируется автоматически в случае отказа NameNode (незапланированное событие).

Apache Zookeeper - это служба, которая обеспечивает возможность автоматического переключения при отказе в кластере высокой доступности HDFS. Он поддерживает небольшие объемы данных координации, информирует клиентов об изменениях в этих данных и контролирует клиентов на предмет сбоев. Zookeeper поддерживает сеанс с NameNodes. В случае сбоя сеанс истечет, и Zookeeper проинформирует другие NameNodes о начале процесса переключения при отказе. В случае сбоя NameNode другой пассивный NameNode может заблокировать Zookeeper, заявив, что он хочет стать следующим активным NameNode.

ZookeerFailoverController (ZKFC) - это клиент Zookeeper, который также отслеживает статус NameNode и управляет им. Каждый из NameNode также запускает ZKFC. ZKFC несет ответственность за периодический мониторинг состояния NameNodes.

Теперь, когда вы поняли, что такое высокая доступность в кластере Hadoop, пора его настроить. Чтобы настроить высокую доступность в кластере Hadoop, вы должны использовать Zookeeper на всех узлах.

Демоны в Active NameNode:

• Работник зоопарка
• Контроллер Zookeeper Fail Over
• JournalNode
• Имя Узел

Демоны в Standby NameNode:

• Работник зоопарка
• Контроллер Zookeeper Fail Over
• JournalNode
• Имя Узел

Демоны в DataNode:

• Работник зоопарка
• JournalNode
• DataNode

Если вы хотите освоить HDFS и Hadoop, ознакомьтесь с специально разработанным Edureka курсом по Big Data и Hadoop. Нажмите кнопку ниже, чтобы начать.

Установка и настройка кластера высокой доступности в Hadoop:

Вы должны сначала настроить Java и имена хостов для каждого узла.

Загрузите двоичный tar-файл Hadoop и Zookeeper, извлеките файлы для редактирования файлов конфигурации.

Команда: wget https://archive.apache.org/dist/zookeeper/zookeeper-3.4.6/zookeeper-3.4.6.tar.gz

Выкладываю zookeeper-3.4.6.tar.gz

Команда : tar –xvf zookeeper-3.4.6.tar.gz

Загрузите стабильный двоичный файл tar Hadoop с сайта Apache Hadoop.

Команда : wget https://archive.apache.org/dist/hadoop/core/hadoop-2.6.0/hadoop-2.6.0.tar.gz

круглый двойной в int java

Извлеките tar-шар Hadoop.

Команда : tar –xvf hadoop-2.6.0.tar.gz

Распространение бинарного файла hadoop.

Добавьте Hadoop, Zookeeper и пути к файлу .bashrc.

Откройте файл .bashrc.

Команда : sudo gedit ~ / .bashrc

Добавьте следующие пути:

экспорт HADOOP_HOME = экспорт HADOOP_MAPRED_HOME = $ HADOOP_HOME экспорт HADOOP_COMMON_HOME = $ HADOOP_HOME экспорт HADOOP_HDFS_HOME = $ HADOOP_HOME экспорт YARN_HOME = $ HADOOP_HOME экспорт HADOOP_CONF_DIR = $ HADOOP_HOME / и т.д. / Hadoop экспорт YARN_CONF_DIR = $ HADOOP_HOME / и т.д. / экспорт Hadoop JAVA_HOME = экспорт ZOOKEEPER_HOME = экспорт PATH = $ PATH: $ JAVA_HOME / bin: $ HADOOP_HOME / bin: $ HADOOP_HOME / sbin: $ ZOOKEEPER_HOME / bin

Отредактируйте файл .bashrc.

Включите SSH на всех узлах.

Сгенерируйте ключ SSH на всех узлах.

Команда : ssh-keygen –t rsa (этот шаг на всех узлах)

Настройте SSH-ключ на всех узлах.

Не указывайте путь к файлу Enter, чтобы сохранить ключ, и не указывайте кодовую фразу. Нажмите кнопку ввода.

Сгенерируйте процесс ключа ssh на всех узлах.

Как только ключ ssh будет сгенерирован, вы получите открытый и закрытый ключи.

Каталог ключей .ssh должен содержать разрешение 700, а все ключи внутри каталога .ssh должны содержать разрешения 600.

Измените разрешение каталога SSH.

Измените каталог на .ssh и измените разрешение файлов на 600

Изменить разрешение открытого и закрытого ключей.

Вы должны скопировать открытый ключ SSH узлов Name на все узлы.

В Active Namenode скопируйте id_rsa.pub с помощью команды cat.

Команда : cat ~ / .ssh / id_rsa.pub >> ~ / .ssh / authorized_keys

Скопируйте SSH-ключ Namenode на его авторизованные ключи.

Скопируйте открытый ключ NameNode на все узлы, используя ssh-copy-id команда.

Команда : ssh-copy-id –i .ssh / id_rsa.pub edureka@nn2.cluster.com

Скопируйте целевой ключ в резервный NameNode.

Скопируйте открытый ключ NameNode в узел данных.

Команда : ssh-copy-id –i .ssh / id_rsa.pub edureka@dn1.cluster.com

Скопируйте открытый ключ Namenode в узел данных.

Перезапустите службу sshd на всех узлах.

Команда : sudo service sshd restart (Выполнить на всех узлах)

Перезапустите службу SSH.

Теперь вы можете войти в любой узел из Namenode без какой-либо аутентификации.

Откройте файл core-site.xml из узла Active Name и добавьте указанные ниже свойства.

Отредактируйте core-site.xml из активного namenode

Откройте файл hdfs-site.xml в Active Namenode. Добавьте указанные ниже свойства.

dfs.namenode.name.dir / home / edureka / HA / data / namenode dfs.replication 1 dfs.permissions false dfs.nameservices ha-cluster dfs.ha.namenodes.ha-cluster nn1, nn2 dfs.namenode.rpc-address .ha-cluster.nn1 nn1.cluster.com:9000 dfs.namenode.rpc-address.ha-cluster.nn2 nn2.cluster.com:9000 dfs.namenode.http-address.ha-cluster.nn1 nn1.cluster. com: 50070 dfs.namenode.http-address.ha-cluster.nn2 nn2.cluster.com:50070 dfs.namenode.shared.edits.dir qjournal: //nn1.cluster.com: 8485nn2.cluster.com: 8485dn1. cluster.com:8485/ha-cluster dfs.client.failover.proxy.provider.ha-cluster org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider dfs.ha.automatic-failover.enabled true ha.zookeeper .quorum nn1.cluster.com:2181,nn2.cluster.com:2181,dn1.cluster.com:2181 dfs.ha.fencing.methods sshfence dfs.ha.fencing.ssh.private-key-files / home / edureka /.ssh/id_rsa

Измените каталог на каталог conf zookeeper.

Команда : cd zookeeper-3.4.6 / conf

Каталог Zookeeper Conf.

В каталоге conf у вас есть файл zoo_sample.cfg, создайте zoo.cfg, используя файл zoo_sample.cfg.

Команда : cp zoo_sample.cfg zoo.cfg

Создайте файл zoo.cfg.

Создайте каталог в любом месте и используйте этот каталог для хранения данных zookeeper.

Команда : mkdir

Создайте каталог для хранения данных zookeeper.

Откройте файл zoo.cfg.

Команда : gedit zoo.cfg

Добавьте путь к каталогу, созданный на предыдущем шаге, в свойство dataDir и добавьте приведенную ниже информацию об оставшемся узле в файл zoo.cfg.

Server.1 = nn1.cluster.com: 2888: 3888

Server.2 = nn2.cluster.com: 2888: 3888

Server.3 = dn1.cluster.com: 2888: 3888

Отредактируйте файл zoo.cfg.

Теперь скопируйте каталоги Java и Hadoop-2.6.0, zookeeper-3.4.6 и файл .bashrc на все узлы (узел резервного имени, узел данных) с помощью команды scp.

Команда : scp –r edureka @:

Скопируйте файлы Hadoop, Zookeeper и .bashrc на все узлы.

Точно так же скопируйте файл .bashrc и каталог zookeeper на все узлы и измените переменные среды в каждом в соответствии с соответствующим узлом.

В узле данных создайте любой каталог, в котором вам нужно хранить блоки HDFS.

В узле данных вы должны добавить свойства dfs.datanode.data.dir.

В моем случае я создал датанод каталог для хранения блоков.

Создайте каталог Datanode.

Измените разрешение на каталог узла данных.

Измените разрешение каталога Datanode.

Откройте файл HDFS-site.xml, добавьте этот путь к каталогу Datanode в свойстве dfs.datanode.data.dir.

Примечание. Сохраните все свойства, скопированные из активного namenode, добавьте dfs.datanode.data.dir одно свойство extract в namenode.

что такое __init__ в Python

dfs.datanode.data.dir / home / edureka / HA / data / datanode

В Active namenode измените каталог, в котором вы хотите сохранить файл конфигурации zookeeper (путь к свойству dataDir).

Создайте файл myid внутри каталога, добавьте в него число 1 и сохраните файл.

Команда : vi myid

Создайте файл myid.

В резервном namenode измените каталог, в котором вы хотите сохранить файл конфигурации zookeeper (путь к свойству dataDir).

Создайте файл myid внутри каталога, добавьте в него число 2 и сохраните файл.

В узле данных измените каталог, в котором вы хотите сохранить файл конфигурации zookeeper (путь к свойству dataDir).

Создайте файл myid внутри каталога, добавьте к нему цифру 3 и сохраните файл.

Запустите узел журнала во всех трех узлах.

Команда : hadoop-daemon.sh запустить journalnode

Запустите узел журнала.

Когда вы вводите команду jps, вы увидите демон JournalNode во всех узлах.

ОтформатируйтеАктивная цель.

Команда : Формат HDFS

Формат активного NameNode.

Запустите демон Namenode и Active Namedode.

Команда : hadoop-daemon.sh цель запуска

Запустите Namenode.

Скопируйте метаданные HDFS из активного узла имени в резервный узел имени.

Команда : Предназначена для HDFS -bootstrapStandby

Скопируйте метаданные HDFS из узла активного имени в резервный узел имени.

После того, как вы запустите эту команду, вы получите информацию, с какого узла и местоположения копируются метаданные, и успешно ли они копируются.

Информация об активных целях.

Как только метаданные будут скопированы из активного namenode в резервный namenode, вы получите сообщение, показанное ниже на снимке экрана.

Информация о HDFS в резервном Namenode.

Запустите демон namenode на резервной машине namenode.

Команда : hadoop-daemon.sh цель запуска

Теперь запустите службу Zookeeper на всех трех узлах.

Команда : zkServer.sh start (Выполните эту команду на всех узлах)

В активной цели:

Запустите zookeeper в Active NameNode.

В режиме ожидания Namenode:

Запустите zookeeper в режиме ожидания NameNode.

В узле данных:

Запустите zookeeper в DataNode.

После запуска сервера Zookeeper введите команду JPS. Во всех узлах вы увидите службу QuorumPeerMain.

Запустите демон узла данных на компьютере узла данных.

Команда : hadoop-daemon.sh запустить узел данных

Запустите отказоустойчивый контроллер Zookeeper в узле активного имени и узле резервного имени.

Отформатируйте отказоустойчивый контроллер zookeeper в Active namenode.

Команда: HDFS zkfc –formatZK

Отформатируйте ZKFC.

Запустите ZKFC в активном namenode.

Команда : hadoop-daemon.sh запустить zkfc

Введите команду jps, чтобы проверить демоны DFSZkFailoverController.

Запустите ZKFC.

Отформатируйте отказоустойчивый контроллер zookeeper в ждущем namenode.

Команда : hdfs zkfc –formatZK

Запустите ZKFC в режиме ожидания namenode.

Команда : hadoop-daemon.sh запустить zkfc

Введите команду jps, чтобы проверить демоны DFSZkFailoverController.

Теперь проверьте состояние каждого Namenode, какой узел активен или какой узел находится в режиме ожидания, используя следующую команду.

Команда : hdfs haadmin –getServiceState nn1

Проверьте статус каждого NameNode.

Теперь проверьте статус каждого Namenode с помощью веб-браузера.

Откройте веб-браузер и введите указанный ниже URL-адрес.

: 50070

Он покажет, активен ли узел имени или находится в режиме ожидания.

Активный NameNode.

Откройте сведения о другом узле имени с помощью веб-браузера.

Резервный NameNode.

В активном namenode убейте демон namenode, чтобы изменить резервный узел имени на активный namenode.

Введите jps в Active namenode и убейте демона.

Команда: sudo kill -9

ID процесса демонов.

Идентификатор процесса Namenode - 7606, уничтожьте namenode.

Команда : Sudo kill -9 7606

Убейте процесс Name Node

Откройте два узла через веб-браузер и проверьте статус.

Детали Namenode.

Статус NameNode.

Поздравляем, вы успешно настроили кластер высокой доступности HDFS в Hadoop.

Теперь, когда вы разобрались с архитектурой кластера высокой доступности Hadoop, ознакомьтесь с от Edureka, надежной компании по онлайн-обучению с сетью из более чем 250 000 довольных учащихся по всему миру. Учебный курс Edureka Big Data Hadoop Certification Training помогает учащимся стать экспертами в области HDFS, Yarn, MapReduce, Pig, Hive, HBase, Oozie, Flume и Sqoop, используя примеры использования в реальном времени в области розничной торговли, социальных сетей, авиации, туризма, финансов.

Есть вопрос к нам? Пожалуйста, укажите это в комментариях, и мы свяжемся с вами.

window._LQ_ = window._LQ_ || {}

lqQuizModal (окно, документ, {quizId: ’XAIVp8 ′, baseUrl:’ https: //quiz.leadquizzes.com/’,trigger: ’exit’}, _LQ_)