Com configurar el clúster Hadoop amb alta disponibilitat HDFS

Arquitectura de clúster d'alta disponibilitat HDFS 2.x.

En aquest bloc, parlaré sobre l'arquitectura de clúster d'alta disponibilitat HDFS 2.x i el procediment per configurar un clúster d'alta disponibilitat HDFS.Aquesta és una part important del . L'ordre en què s'han tractat els temes en aquest bloc és el següent:

• HDFS HA ​​Architecture
  • Introducció
  • Disponibilitat de NameNode
  • Arquitectura de HA
  • Implementació de HA (JournalNode i emmagatzematge compartit)
• Com es configura HA (Quorum Journal Nodes) en un clúster Hadoop?

Introducció:

El concepte de clúster d'alta disponibilitat es va introduir a Hadoop 2.x per resoldre el problema del punt únic de fallada a Hadoop 1.x. Com ja sabeu del meu bloc anterior que el segueix la topologia Màster / Esclau on NameNode actua com a dimoni mestre i és responsable de gestionar altres nodes esclaus anomenats DataNodes. Aquest sol dimoni mestre o NameNode es converteix en un coll d'ampolla. Tot i que la introducció del NameNode secundari ens va impedir la pèrdua de dades i descarregar part de la càrrega del NameNode, però no va resoldre el problema de disponibilitat del NameNode.

Disponibilitat de NameNode:

Si teniu en compte la configuració estàndard del clúster HDFS, el NameNode es convertirà en un punt únic de fracàs . Succeeix perquè en el moment en què el NameNode no està disponible, tot el clúster no està disponible fins que algú reinicia el NameNode o en porta un de nou.

Els motius de la indisponibilitat de NameNode poden ser:

• Un esdeveniment previst, com ara un treball de manteniment, té l'actualització de programari o maquinari.
• També pot ser degut a un esdeveniment no planificat en què el NameNode es bloqueja per alguns motius.

En qualsevol dels casos anteriors, tenim un temps d'inactivitat en què no podem utilitzar el clúster HDFS, cosa que es converteix en un repte.

HDFS HA ​​Architecture:

Comprenem que com HDFS HA ​​Architecture va solucionar aquest problema crític de la disponibilitat de NameNode:

L’arquitectura HA ha resolt aquest problema de disponibilitat de NameNode permetent-nos tenir dos NameNodes en una configuració activa / passiva. Per tant, tenim dos NameNodes en execució al mateix temps en un clúster d'alta disponibilitat:

• Nom actiu del nom
• Standby / Passive NameNode.

Si un NameNode cau, l’altre NameNode pot assumir la responsabilitat i, per tant, reduir el temps d’aturada del clúster. El NameNode d'espera serveix per al propòsit d'un NameNode de còpia de seguretat (a diferència del SecondName NameNode) que incorpora funcions de migració per error al clúster Hadoop. Per tant, amb el StandbyNode, podem tenir un canvi automàtic de fallades cada vegada que un NameNode es bloqueja (esdeveniment no planificat) o podem tenir un canvi de error elegant (iniciat manualment) durant el període de manteniment.

Hi ha dos problemes per mantenir la coherència al clúster d'alta disponibilitat HDFS:

• ActiveNode i Standby NameNode haurien d’estar sempre sincronitzats entre ells, és a dir, haurien de tenir les mateixes metadades. Això ens permetrà restaurar el clúster Hadoop al mateix estat de l'espai de noms on es va bloquejar i, per tant, ens proporcionarà una migració ràpida per error.
• Només hi hauria d’haver un NameNode actiu a la vegada perquè dos NameNode actius provocaran la corrupció de les dades. Aquest tipus d’escenari s’anomena un escenari de cervell dividit en què un clúster es divideix en un clúster més petit, creient cadascun que és l’únic cúmul actiu. Per evitar aquests escenaris, es fa esgrima. L’esgrima és un procés que garanteix que només un NomNode romangui actiu en un moment concret.

Implementació d'Arquitectura HA:

Ara, ja sabeu que a HDFS HA ​​Architecture, tenim dos NameNodes executats al mateix temps. Per tant, podem implementar la configuració ActiveName i Standby Name de dues maneres següents:

1. Utilitzant els nodes de la revista Quorum
2. Emmagatzematge compartit mitjançant NFS

Comprenguem aquestes dues formes d’implementació que es prenen d’una en una:

1. Ús dels nodes de la revista Quorum:

• El NameNode en espera i el NameNode actiu es mantenen sincronitzats entre si mitjançant un grup separat de nodes o dimonis anomenats JournalNodes .El JournalNodes segueix la topologia de l'anell on els nodes es connecten entre si per formar un anell.El JournalNode atén la sol·licitud que li arriba i copia la informació en altres nodes del ring.Això proporciona tolerància a fallades en cas de fallada de JournalNode.
• El NameNode actiu és responsable d’actualitzar els EditLogs (informació de metadades) presents als JournalNodes.
• El StandbyNode llegeix els canvis fets als EditLogs del JournalNode i els aplica al seu propi espai de noms de manera constant.
• Durant la migració per error, el StandbyNode s’assegura que ha actualitzat la seva informació de metadades del JournalNodes abans de convertir-se en el nou ActiveNodeNode. Això fa que l'estat actual de l'espai de noms se sincronitzi amb l'estat abans de la migració després d'un error.
• Les adreces IP de tots dos nodes de nom estan disponibles per a tots els nodes de dades i envien els seus batecs del cor i bloquegen la informació d’ubicació al nom de node. Això proporciona una migració per error ràpida (menys temps d'inactivitat) ja que el StandbyNode té informació actualitzada sobre la ubicació del bloc al clúster.

Tanca de NameNode:

Ara, com es va comentar anteriorment, és molt important assegurar-se que només hi hagi un nom de nom actiu a la vegada. Per tant, l’esgrima és un procés per garantir aquesta mateixa propietat en un clúster.

• El JournalNodes realitza aquesta esgrima en permetre que només un NameNode sigui l’escriptor alhora.
• El StandName NameNode assumeix la responsabilitat d’escriure al JournalNodes i prohibeix que qualsevol altre NameNode romangui actiu.
• Finalment, el nou Active NameNode pot realitzar les seves activitats amb seguretat.

2. Ús d'emmagatzematge compartit:

• El StandbyNode i el NameNode actiu es mantenen sincronitzats entre si mitjançant un dispositiu d'emmagatzematge compartit .El NameNode actiu registra el registre de qualsevol modificació feta al seu espai de noms en un EditLog present en aquest emmagatzematge compartit.El StandbyNode llegeix els canvis fets als EditLogs en aquest emmagatzematge compartit i els aplica al seu propi espai de noms.
• Ara, en cas de commutació per error, StandbyNode actualitza la informació de metadades utilitzant EditLogs a l’emmagatzematge compartit al principi. Aleshores, assumeix la responsabilitat del Active NameNode. Això fa que l'estat actual de l'espai de noms se sincronitzi amb l'estat abans de la migració després d'un error.
• L'administrador ha de configurar almenys un mètode d'esgrima per evitar un escenari de cervell dividit.
• El sistema pot utilitzar diversos mecanismes de tancament. Pot incloure la supressió del procés del NameNode i la revocació del seu accés al directori d'emmagatzematge compartit.
• Com a últim recurs, podem tancar el NameNode anteriorment actiu amb una tècnica coneguda com a STONITH, o 'disparar l'altre node al cap'. STONITH utilitza una unitat de distribució d’energia especialitzada per apagar per força la màquina NameNode.

Failover automàtic:

Failover és un procediment mitjançant el qual un sistema transfereix automàticament el control al sistema secundari quan detecta un error o fallada. Hi ha dos tipus de migració per error:

Failover gràfic: En aquest cas, iniciem manualment la migració per error per al manteniment rutinari.

Failover automàtic: En aquest cas, la migració per error s'inicia automàticament en cas d'error de NameNode (esdeveniment no planificat).

Apache Zookeeper és un servei que proporciona la capacitat de migració automàtica a fallades al clúster HDFS High Availability. Manté petites quantitats de dades de coordinació, informa els clients dels canvis en aquestes dades i supervisa els clients per si hi ha fallades. Zookeeper manté una sessió amb els NameNodes. En cas d'error, la sessió caducarà i el guardaespatlles informarà a altres NameNodes per iniciar el procés de migració després d'un error. En cas d'error de NameNode, un altre NameNode passiu pot bloquejar Zookeeper afirmant que vol convertir-se en el següent NameNode actiu.

El ZookeerFailoverController (ZKFC) és un client Zookeeper que també controla i gestiona l'estat NameNode. Cadascun dels NameNode també executa un ZKFC. ZKFC s’encarrega de controlar periòdicament la salut dels NameNodes.

Ara que heu entès què és Alta disponibilitat en un clúster Hadoop, és hora de configurar-lo. Per configurar l’alta disponibilitat al clúster Hadoop, heu d’utilitzar Zookeeper a tots els nodes.

Els dimonis de Active NameNode són:

• Guardià zoològic
• Zookeeper Fail Over controller
• JournalNode
• NomNode

Els dimonis del StandName NameNode són:

• Guardià zoològic
• Zookeeper Fail Over controller
• JournalNode
• NomNode

Els dimonis de DataNode són:

• Guardià zoològic
• JournalNode
• DataNode

Si voleu dominar HDFS i Hadoop, consulteu el curs especialitzat en Big Data i Hadoop d’Edureka. Feu clic al botó següent per començar.

Configuració i configuració del clúster d'alta disponibilitat a Hadoop:

Primer heu de configurar els noms de Java i d’amfitrió de cada node.

Baixeu-vos el fitxer tar binari de Hadoop i Zookeeper, extraieu-los per editar els fitxers de configuració.

Comandament : wget https://archive.apache.org/dist/zookeeper/zookeeper-3.4.6/zookeeper-3.4.6.tar.gz

Untar the Zookeeper-3.4.6.tar.gz

Comandament : tar –xvf zookeeper-3.4.6.tar.gz

Baixeu el quitrà binari estable de Hadoop des del lloc d'Apache Hadoop.

Comandament : wget https://archive.apache.org/dist/hadoop/core/hadoop-2.6.0/hadoop-2.6.0.tar.gz

Extraieu la bola de quitrà de Hadoop.

Comandament : tar –xvf hadoop-2.6.0.tar.gz

Untar Hadoop binary.

Afegiu Hadoop, Zookeeper i camins al fitxer .bashrc.

Obriu el fitxer .bashrc.

Comandament : sudo gedit ~ / .bashrc

Afegiu els camins següents:

exportació HADOOP_HOME = exportació HADOOP_MAPRED_HOME = $ HADOOP_HOME exportació HADOOP_COMMON_HOME = $ HADOOP_HOME exportació HADOOP_HDFS_HOME = $ HADOOP_HOME exportació YARN_HOME = $ HADOOP_HOME exportació HADOOP_CONF_DIR = $ HADOOP_HOME / etc / Hadoop exportació YARN_CONF_DIR = $ HADOOP_HOME / etc / exportació Hadoop JAVA_HOME = exportació ZOOKEEPER_HOME = export PATH = $ PATH: $ JAVA_HOME / bin: $ HADOOP_HOME / bin: $ HADOOP_HOME / sbin: $ ZOOKEEPER_HOME / bin

Editeu el fitxer .bashrc.

Activeu el SSH a tot el node.

Genereu la clau SSH a tots els nodes.

Comandament : ssh-keygen –t rsa (aquest pas en tots els nodes)

Configureu la clau SSH a tots els nodes.

No doneu cap camí al fitxer Retorn per desar la clau i no doneu cap contrasenya. Premeu el botó d'inici.

Genereu el procés de clau ssh a tots els nodes.

Un cop generada la clau ssh, obtindreu la clau pública i la clau privada.

El directori de claus .ssh ha de contenir el permís 700 i totes les claus del directori .ssh han de contenir els permisos 600.

Canvieu el permís del directori SSH.

Canvieu el directori a .ssh i canvieu el permís dels fitxers a 600

Canvieu el permís de clau pública i privada.

Heu de copiar la clau pública ssh Name nodes a tots els nodes.

A Active Namenode, copieu l’id_rsa.pub mitjançant l’ordre cat.

Comandament : cat ~ / .ssh / id_rsa.pub >> ~ / .ssh / author_keys

Copieu la clau ssh de Namenode a les claus autoritzades.

Copieu la clau pública NameNode a tots els nodes que utilitzeu ssh-copy-id comandament.

Comandament : ssh-copy-id –i .ssh / id_rsa.pub edureka@nn2.cluster.com

Copieu la clau de propòsit a Standby NameNode.

Copieu la clau pública NameNode al node de dades.

Comandament : ssh-copy-id –i .ssh / id_rsa.pub edureka@dn1.cluster.com

Copieu la clau pública Namenode al node de dades.

Reinicieu el servei sshd a tots els nodes.

Comandament : sudo service sshd restart (Feu-ho a tots els nodes)

Reinicieu el servei SSH.

Ara podeu iniciar sessió a qualsevol node des de Namenode sense cap autenticació.

Obriu el fitxer core-site.xml des del node Active Name i afegiu les propietats següents.

Editeu core-site.xml des del namenode actiu

Obriu el fitxer hdfs-site.xml a Active Namenode. Afegiu les Propietats següents.

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

Canvieu el directori al directori conf del zookeeper.

Comandament : cd zookeeper-3.4.6 / conf

Directori Zookeeper Conf.

En un directori conf teniu el fitxer zoo_sample.cfg, creeu el zoo.cfg mitjançant el fitxer zoo_sample.cfg.

Comandament : cp zoo_sample.cfg zoo.cfg

Creeu un fitxer zoo.cfg.

Creeu el directori en qualsevol ubicació i utilitzeu aquest directori per emmagatzemar les dades del guardaespatlles.

Comandament : mkdir

Creeu un directori per emmagatzemar les dades dels guardians.

Obriu el fitxer zoo.cfg.

Comandament : gedit zoo.cfg

Afegiu la ruta del directori que es crea al pas anterior a la propietat dataDir i afegiu els detalls següents sobre el node restant, al fitxer zoo.cfg.

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

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

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

Editeu el fitxer zoo.cfg.

Ara copieu els directoris Java i Hadoop-2.6.0, zookeeper-3.4.6 i el fitxer .bashrc a tots els nodes (node ​​de nom d'espera, node de dades) mitjançant l'ordre scp.

Comandament : scp –r edureka @:

Copieu el fitxer Hadoop, Zookeeper i .bashrc a tots els nodes.

De la mateixa manera, copieu el fitxer .bashrc i el directori zookeeper a tots els nodes i canvieu les variables d'entorn de cadascun segons el node respectiu.

En un node de dades, creeu qualsevol directori on necessiteu emmagatzemar els blocs HDFS.

En un node de dades, heu d'afegir les propietats dfs.datanode.data.dir.

En el meu cas, he creat datanode directori per emmagatzemar els blocs.

Creeu un directori Datanode.

Canvieu el permís al directori de nodes de dades.

Canvieu el permís del directori Datanode.

Obriu el fitxer HDFS-site.xml, afegiu aquest camí d'accés al directori Datanode a la propietat dfs.datanode.data.dir.

Nota: Mantingueu totes les propietats que es copien del namenode actiu afegiu dfs.datanode.data.dir una propietat d'extracte al namenode.

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

A Active namenode, canvieu el directori on voleu emmagatzemar el fitxer de configuració del guardaespatlles (ruta de la propietat dataDir).

Creeu el fitxer myid dins del directori i afegiu el número 1 al fitxer i deseu-lo.

Comandament : vi myid

Crea un fitxer myid.

En un namenode d'espera, canvieu el directori on voleu emmagatzemar el fitxer de configuració del zookeeper (ruta de propietat dataDir).

Creeu el fitxer myid dins del directori i afegiu el número 2 al fitxer i deseu-lo.

En un node de dades, canvieu el directori on voleu emmagatzemar el fitxer de configuració del guardaespatlles (ruta de la propietat dataDir).

Creeu el fitxer myid dins del directori i afegiu el número 3 al fitxer i deseu-lo.

Inicieu el Journalnode en els tres nodes.

Comandament : hadoop-daemon.sh start journalnode

Inicieu el Journalnode.

Quan introduïu l'ordre jps, veureu el dimoni JournalNode a tots els nodes.

Formateu el fitxerPropòsit actiu.

Comandament : Format HDFS previst

Format de nom actiu.

Inicieu el dimoni Namenode i Active Namedode.

Comandament : propòsit inicial de hadoop-daemon.sh

Inicieu Namenode.

Copieu les dades meta HDFS del node de nom actiu al namenode d'espera.

Comandament : HDFS previst -bootstrapStandby

Copieu les dades de meta HDFS del node de nom actiu a Namenode en espera.

Un cop executeu aquesta ordre, obtindreu la informació de quin node i ubicació copieu les metadades i si copieu amb èxit o no.

Informació de detalls de propòsit actiu.

Un cop copiades les meta dades del namenode actiu al namenode d’espera, obtindreu el missatge que es mostra a continuació a la captura de pantalla.

Informació sobre HDFS a Standby Namenode.

Inicieu el dimoni namenode a la màquina namenode Standby.

Comandament : propòsit inicial de hadoop-daemon.sh

Ara inicieu el servei Zookeeper en els tres nodes.

Comandament : zkServer.sh start (executeu aquesta ordre a tots els nodes)

Amb propòsit actiu:

Inicieu el zookeeper a Active NameNode.

Namenode en espera:

Inicieu el guardaespatlles en mode d'espera NameNode.

Al node de dades:

Inicieu el zookeeper a DataNode.

Després d'executar el servidor Zookeeper, introduïu l'ordre JPS. A tots els nodes veureu el servei QuorumPeerMain.

Inicieu el dimoni del node de dades a la màquina de nodes de dades.

Comandament : hadoop-daemon.sh start datanode

Inicieu la fallada del controlador Zookeeper al node de nom actiu i al node de nom d'espera.

Formateu la fallada del zookeeper sobre el controlador en el namenode actiu.

Comandament: HDFS zkfc -formatZK

Format ZKFC.

Inicieu el ZKFC al namenode actiu.

Comandament : hadoop-daemon.sh iniciar zkfc

Introduïu l'ordre jps per comprovar els dimonis DFSZkFailoverController.

Inicieu ZKFC.

Formateu la fallada del zookeeper sobre el controlador al namenode Standby.

Comandament : Hdfs zkfc -formatZK

Inicieu el ZKFC al namenode Standby.

Comandament : hadoop-daemon.sh iniciar zkfc

Introduïu l'ordre jps per comprovar els dimonis DFSZkFailoverController.

Ara comproveu l'estat de cada namenode, quin node és actiu o quin node està en espera mitjançant l'ordre següent.

Comandament : hdfs haadmin –getServiceState nn1

Comproveu l'estat de cada NameNode.

Ara comproveu l'estat de cada Namenode mitjançant el navegador web.

Obriu el navegador web i introduïu l'URL següent.

: 50070

Es mostrarà si el node de nom és actiu o està en espera.

Nom actiu del nom.

Obriu els detalls d’un altre node de nom mitjançant el navegador web.

Nom d'espera Node.

estructura bàsica del programa Java

Al namenode actiu, elimineu el dimoni namenode per canviar el node del nom d'espera a namenode actiu.

Introduïu jps a Active namenode i mateu el dimoni.

Comandament: sudo kill -9

Identificador de procés de dimonis.

L'identificador de procés Namenode és 7606, elimina el namenode.

Comandament : Sudo kill -9 7606

Mata el procés Name Node

Obriu els dos nodes a través del navegador web i comproveu-ne l'estat.

Detalls de Namenode.

Estat del nom del node.

Enhorabona, heu configurat correctament un clúster d'alta disponibilitat HDFS a Hadoop.

Ara que heu entès l'arquitectura de clúster d'alta disponibilitat Hadoop, consulteu el fitxer per Edureka, una empresa d'aprenentatge en línia de confiança amb una xarxa de més de 250.000 estudiants satisfets repartits per tot el món. El curs de formació en certificació Edureka Big Data Hadoop ajuda els estudiants a convertir-se en experts en HDFS, Yarn, MapReduce, Pig, Hive, HBase, Oozie, Flume i Sqoop mitjançant casos d’ús en temps real en dominis Retail, Social Media, Aviació, Turisme, Finances.

Tens alguna pregunta? Esmenta’l a la secció de comentaris i et respondrem.

window._LQ_ = window._LQ_ || {}

lqQuizModal (finestra, document, {quizId: 'XAIVp8 ′, baseUrl:' https: //quiz.leadquizzes.com/',trigger: 'exit'}, _LQ_)