Как да настроите Hadoop клъстер с HDFS висока наличност

HDFS 2.x Архитектура на клъстери с висока наличност

В този блог ще говоря за HDFS 2.x Архитектура на клъстери с висока наличност и процедурата за създаване на клъстер с висока наличност HDFS.Това е важна част от . Редът, в който темите бяха обхванати в този блог, е както следва:

• HDFS HA ​​архитектура
  • Въведение
  • Наличност на NameNode
  • Архитектура на HA
  • Внедряване на HA (JournalNode и споделено съхранение)
• Как да настроите HA (Quorum Journal Nodes) в клъстер Hadoop?

Въведение:

Концепцията за клъстер с висока наличност е въведена в Hadoop 2.x за решаване на проблема с единичната точка на отказ в Hadoop 1.x. Както знаете от предишния ми блог, че следва главната / подчинената топология, където NameNode действа като главен демон и е отговорен за управлението на други подчинени възли, наречени DataNodes. Този единичен Master Daemon или NameNode се превръща в пречка. Въпреки че въвеждането на Secondary NameNode ни попречи да загубим данни и да разтоварим част от тежестта на NameNode, но не разреши проблема с наличността на NameNode.

Наличност на NameNode:

Ако разгледате стандартната конфигурация на HDFS клъстера, NameNode става единична точка на отказ . Това се случва, защото в момента, в който NameNode стане недостъпен, целият клъстер става недостъпен, докато някой не рестартира NameNode или не донесе нов.

Причините за липсата на NameNode могат да бъдат:

• Планирано събитие като работа по поддръжка, като такова има надстройка на софтуера или хардуера.
• Това може да се дължи и на непланирано събитие, при което NameNode се срива поради някои причини.

Във всеки от горните случаи имаме престой, при който не сме в състояние да използваме HDFS клъстера, което се превръща в предизвикателство.

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

Нека разберем, че как HDFS HA ​​Architecture решава този критичен проблем с наличността на NameNode:

Архитектурата на HA реши този проблем с наличието на NameNode, като ни позволи да имаме два NameNodes в активна / пасивна конфигурация. И така, имаме две работещи NameNodes едновременно в клъстер с висока наличност:

• Active NameNode
• Готов / Пасивен NameNode.

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

Има два проблема при поддържането на последователност в клъстера за висока наличност HDFS:

• Active и Standby NameNode винаги трябва да са синхронизирани помежду си, т.е.Те трябва да имат едни и същи метаданни. Това ще ни позволи да възстановим клъстера Hadoop в същото състояние на пространството от имена, където се е сринал, и следователно ще ни осигури бърз отказ.
• Трябва да има само един активен NameNode наведнъж, защото два активни NameNode ще доведат до повреда на данните. Този сценарий се нарича сценарий с разделен мозък, при който клъстерът се разделя на по-малки клъстери, като всеки вярва, че е единственият активен клъстер. За да се избегнат подобни сценарии се прави фехтовка. Фехтовката е процес за гарантиране, че само един NameNode остава активен в определен момент.

Внедряване на HA архитектура:

Сега знаете, че в HDFS HA ​​Architecture имаме два NameNodes, работещи едновременно. И така, можем да приложим конфигурацията Active и Standby 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:

Сега, както беше обсъдено по-рано, е много важно да се гарантира, че има само един Active NameNode наведнъж. Така че, фехтовката е процес за осигуряване на точно това свойство в клъстер.

• JournalNodes изпълнява това ограждане, като позволява само един NameNode да бъде писател наведнъж.
• Режимът на готовност NameNode поема отговорността да пише в JournalNodes и забранява на други NameNode да останат активни.
• И накрая, новият ActiveNameNode може да изпълнява своите дейности безопасно.

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

• StandbyNode и активният NameNode поддържат синхрон помежду си, като използват споделено устройство за съхранение .Активният NameNode регистрира записа на всяка промяна, направена в неговото пространство от имена, в EditLog, присъстващ в това споделено хранилище.StandbyNode чете промените, направени в EditLogs в това споделено хранилище, и го прилага към собственото си пространство от имена.
• Сега, в случай на отказ, StandbyNode първо актуализира информацията за метаданните си с помощта на EditLogs в споделеното хранилище. След това той поема отговорността на Active NameNode. Това прави текущото състояние на пространството от имена синхронизирано със състоянието преди срив.
• Администраторът трябва да конфигурира поне един метод на фехтовка, за да се избегне сценарий с разделен мозък.
• Системата може да използва набор от оградни механизми. Това може да включва убиване на процеса на NameNode и отмяна на достъпа му до споделената директория за съхранение.
• В краен случай можем да оградим предишния активен NameNode с техника, известна като STONITH, или да „застреляме другия възел в главата“. STONITH използва специализиран блок за разпределение на енергия, за да принудително изключи машината NameNode.

Автоматично прехвърляне:

Failover е процедура, при която системата автоматично прехвърля управлението към вторичната система, когато открие повреда или повреда. Има два вида отказоустойчивост:

Грациозен отказ: В този случай ръчно инициираме отказа за рутинна поддръжка.

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

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

ZookeerFailoverController (ZKFC) е клиент на Zookeeper, който също наблюдава и управлява състоянието на NameNode. Всеки от NameNode също изпълнява ZKFC. ZKFC е отговорен за периодичното наблюдение на здравето на NameNodes.

След като разбрахте какво е висока наличност в клъстер Hadoop, е време да го настроите. За да настроите висока наличност в клъстера Hadoop, трябва да използвате Zookeeper във всички възли.

Демоните в Active NameNode са:

• Зоопарк
• Контролер за отказ на Zookeeper
• JournalNode
• NameNode

Демоните в Standby NameNode са:

• Зоопарк
• Контролер за отказ на Zookeeper
• JournalNode
• NameNode

Демоните в DataNode са:

• Зоопарк
• JournalNode
• DataNode

Ако искате да овладеете HDFS и Hadoop, разгледайте специално подготвения курс за големи данни и Hadoop от Edureka. Щракнете върху бутона по-долу, за да започнете.

Настройване и конфигуриране на клъстер с висока наличност в Hadoop:

Първо трябва да настроите имената на Java и хоста на всеки възел.

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

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

Разпространете зоопарка-3.4.6.tar.gz

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

Изтеглете стабилния двоичен катран на Hadoop от сайта на Apache Hadoop.

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

Извадете катранената топка Hadoop.

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

Разпространете хадооп двоичен файл.

Добавете 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 на възлите за имена във всички възли.

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

Команда : cat ~ / .ssh / id_rsa.pub >> ~ / .ssh / дозволени_клавиши

Копирайте Namenode ssh ключ в оторизираните ключове.

Копирайте публичния ключ NameNode във всички използвани възли ssh-copy-id команда.

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

php mysql_fetch_array

Копирайте целевия ключ в режим на готовност 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 от Active 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

Променете директорията на zookeeper's conf директория.

Команда : 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.

Сървър.1 = nn1.cluster.com: 2888: 3888

Сървър.2 = nn2.cluster.com: 2888: 3888

Сървър.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.

Забележка: Запазете всички свойства, които се копират от Active namenode, добавете dfs.datanode.data.dir едно свойство за извличане в namenode.

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 към файла и запазете файла.

Стартирайте Journalnode във всичките три възела.

Команда : hadoop-daemon.sh стартиране на journalnode

Стартирайте Journalnode.

Когато въведете jps команда, ще видите демона JournalNode във всички възли.

ФорматирайтеАктивна цел.

Команда : HDFS предназначен -формат

Формат на Active NameNode.

Стартирайте демона Namenode и Active Namedode.

Команда : hadoop-daemon.sh начална цел

Стартирайте Namenode.

Копирайте метаданните HDFS от активния възел на име в готов режим.

Команда : HDFS предназначен -bootstrapStandby

Копирайте HDFS метаданните от възел Active name в режим на готовност Namenode.

След като изпълните тази команда, ще получите информация от кой възел и местоположение мета данните копират и дали копират успешно или не.

Информация за подробни данни за активна цел.

След като Meta данните бъдат копирани от Active 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 над контролера във възел Active name и възел в режим на готовност.

Форматирайте отказа на zookeeper над контролера в Active namenode.

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

Форматирайте ZKFC.

Стартирайте ZKFC в Active 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

Той ще покаже дали възелът с име е активен или в режим на готовност.

Active NameNode.

Отворете подробности за друг възел с име, като използвате уеб браузъра.

Име на възел в режим на готовност.

какво прави init в python

В Active namenode, убийте демона namenode, за да промените възела в режим на готовност на активен namenode.

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

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

Идентификационен номер на процеса на демони.

Идентификационният номер на процеса Namenode е 7606, убийте namenode.

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

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

Отворете двата възела чрез уеб браузър и проверете състоянието.

Подробности за Namenode.

Състояние на NameNode.

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

След като разбрахте архитектурата на клъстерите с висока наличност на Hadoop, разгледайте от Edureka, доверена компания за онлайн обучение с мрежа от над 250 000 доволни учащи, разпространени по целия свят. Курсът за обучение по сертифициране на големи данни Hadoop на Edureka помага на обучаващите се да станат експерти в HDFS, прежди, MapReduce, Pig, Hive, HBase, Oozie, Flume и Sqoop, като използват случаи в реално време за търговия на дребно, социални медии, авиация, туризъм, финанси.

Имате въпрос към нас? Моля, споменете го в раздела за коментари и ние ще се свържем с вас.

window._LQ_ = window._LQ_ || {}

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