Como configurar o cluster Hadoop com alta disponibilidade HDFS

Arquitetura de cluster de alta disponibilidade HDFS 2.x

Neste blog, vou falar sobre a arquitetura de cluster de alta disponibilidade HDFS 2.x e o procedimento para configurar um cluster de alta disponibilidade HDFS.Esta é uma parte importante do . A ordem em que os tópicos foram abordados neste blog é a seguinte:

• Arquitetura HDFS HA
  • Introdução
  • Disponibilidade de NameNode
  • Arquitetura de HA
  • Implementação de HA (JournalNode e armazenamento compartilhado)
• Como configurar HA (Quorum Journal Nodes) em um cluster Hadoop?

Introdução:

O conceito de cluster de alta disponibilidade foi introduzido no Hadoop 2.x para resolver o problema de ponto único de falha no Hadoop 1.x. Como você sabe do meu blog anterior que o segue a Topologia Mestre / Escravo, onde NameNode atua como um daemon mestre e é responsável por gerenciar outros nós escravos chamados DataNodes. Este único Master Daemon ou NameNode torna-se um gargalo. Embora, a introdução do NameNode Secundário tenha nos impedido de perder dados e descarregado parte da carga do NameNode, mas não resolveu o problema de disponibilidade do NameNode.

Disponibilidade de NameNode:

Se você considerar a configuração padrão do cluster HDFS, o NameNode se torna um ponto unico de falha . Isso acontece porque no momento em que o NameNode fica indisponível, todo o cluster fica indisponível até que alguém reinicie o NameNode ou traga um novo.

Os motivos para a indisponibilidade de NameNode podem ser:

• Um evento planejado, como trabalho de manutenção, como atualização de software ou hardware.
• Também pode ser devido a um evento não planejado onde o NameNode falha devido a alguns motivos.

Em qualquer um dos casos acima, temos um tempo de inatividade em que não podemos usar o cluster HDFS, o que se torna um desafio.

Arquitetura HDFS HA:

Vamos entender como a arquitetura HDFS HA ​​resolveu este problema crítico de disponibilidade de NameNode:

A arquitetura HA resolveu esse problema de disponibilidade de NameNode, permitindo-nos ter dois NameNodes em uma configuração ativa / passiva. Portanto, temos dois NameNodes em execução ao mesmo tempo em um cluster de alta disponibilidade:

• NameNode ativo
• NameNode em espera / passivo.

Se um NameNode ficar inativo, o outro NameNode pode assumir a responsabilidade e, portanto, reduzir o tempo de inatividade do cluster. O NameNode em espera serve ao propósito de um NameNode de backup (ao contrário do NameNode secundário), que incorpora recursos de failover ao cluster do Hadoop. Portanto, com o StandbyNode, podemos ter failover automático sempre que um NameNode travar (evento não planejado) ou podemos ter um failover normal (iniciado manualmente) durante o período de manutenção.

Existem dois problemas em manter a consistência no cluster de alta disponibilidade HDFS:

• NameNode ativo e em espera devem estar sempre sincronizados, ou seja, devem ter os mesmos metadados. Isso nos permitirá restaurar o cluster Hadoop para o mesmo estado de namespace em que travou e, portanto, nos fornecerá um failover rápido.
• Deve haver apenas um NameNode ativo por vez, porque dois NameNode ativos levarão à corrupção dos dados. Esse tipo de cenário é denominado como cenário de cérebro dividido, em que um cluster é dividido em um cluster menor, cada um acreditando ser o único cluster ativo. Para evitar tais cenários, a cerca é feita. Fencing é um processo que garante que apenas um NameNode permaneça ativo em um determinado momento.

Implementação da Arquitetura HA:

Agora, você sabe que na arquitetura HDFS HA, temos dois NameNodes em execução ao mesmo tempo. Portanto, podemos implementar a configuração NameNode ativa e em espera de duas maneiras:

1. Usando nós de diário de quorum
2. Armazenamento compartilhado usando NFS

Vamos entender essas duas formas de implementação, uma de cada vez:

1. Usando nós de diário de quorum:

• O NameNode em espera e o NameNode ativo mantêm-se em sincronia um com o outro por meio de um grupo separado de nós ou daemons -chamado JournalNodes .O JournalNodes segue a topologia de anel onde os nós são conectados uns aos outros para formar um anel.O JournalNode atende à solicitação que chega a ele e copia as informações para outros nós do anel.Isso fornece tolerância a falhas no caso de falha do JournalNode.
• O NameNode ativo é responsável por atualizar os EditLogs (informações de metadados) presentes no JournalNodes.
• O StandbyNode lê as alterações feitas nos EditLogs no JournalNode e as aplica ao seu próprio namespace de maneira constante.
• Durante o failover, o StandbyNode certifica-se de que atualizou suas informações de metadados do JournalNodes antes de se tornar o novo NameNode ativo. Isso faz com que o estado do namespace atual seja sincronizado com o estado antes do failover.
• Os endereços IP de ambos os NameNodes estão disponíveis para todos os DataNodes e eles enviam suas pulsações e informações de localização de bloco para ambos os NameNode. Isso fornece um failover rápido (menos tempo de inatividade), pois o StandbyNode tem informações atualizadas sobre o local do bloco no cluster.

Esgrima de NameNode:

Agora, como discutido anteriormente, é muito importante garantir que haja apenas um NameNode ativo por vez. Portanto, a vedação é um processo para garantir essa propriedade em um cluster.

• O JournalNodes executa esse isolamento permitindo que apenas um NameNode seja o gravador de cada vez.
• O Standby NameNode assume a responsabilidade de escrever no JournalNodes e proíbe qualquer outro NameNode de permanecer ativo.
• Finalmente, o novo Active NameNode pode realizar suas atividades com segurança.

2. Usando armazenamento compartilhado:

• O StandbyNode e o NameNode ativo mantêm-se em sincronia entre si usando um dispositivo de armazenamento compartilhado .O NameNode ativo registra o registro de qualquer modificação feita em seu namespace em um EditLog presente neste armazenamento compartilhado.O StandbyNode lê as alterações feitas nos EditLogs neste armazenamento compartilhado e as aplica ao seu próprio namespace.
• Agora, em caso de failover, o StandbyNode atualiza suas informações de metadados usando os EditLogs no armazenamento compartilhado primeiro. Em seguida, ele assume a responsabilidade do NameNode ativo. Isso faz com que o estado do namespace atual seja sincronizado com o estado antes do failover.
• O administrador deve configurar pelo menos um método de esgrima para evitar um cenário de divisão do cérebro.
• O sistema pode empregar uma variedade de mecanismos de esgrima. Pode incluir eliminar o processo do NameNode e revogar seu acesso ao diretório de armazenamento compartilhado.
• Como último recurso, podemos cercar o NameNode anteriormente ativo com uma técnica conhecida como STONITH, ou “atirar no outro nó na cabeça”. STONITH usa uma unidade de distribuição de energia especializada para desligar à força a máquina NameNode.

Failover automático:

Failover é um procedimento pelo qual um sistema transfere automaticamente o controle para o sistema secundário quando detecta uma falha ou falha. Existem dois tipos de failover:

Failover elegante: Nesse caso, iniciamos manualmente o failover para manutenção de rotina.

Failover automático: Nesse caso, o failover é iniciado automaticamente em caso de falha de NameNode (evento não planejado).

Apache Zookeeper é um serviço que fornece o recurso de failover automático no cluster de alta disponibilidade do HDFS. Ele mantém pequenas quantidades de dados de coordenação, informa os clientes sobre as mudanças nesses dados e monitora os clientes quanto a falhas. Zookeeper mantém uma sessão com os NameNodes. Em caso de falha, a sessão expirará e o Zookeeper informará outros NameNodes para iniciar o processo de failover. Em caso de falha de NameNode, outro NameNode passivo pode ser bloqueado no Zookeeper afirmando que deseja se tornar o próximo NameNode ativo.

O ZookeerFailoverController (ZKFC) é um cliente Zookeeper que também monitora e gerencia o status do NameNode. Cada um dos NameNode também executa um ZKFC. ZKFC é responsável por monitorar a integridade dos NameNodes periodicamente.

Agora que você entendeu o que é alta disponibilidade em um cluster Hadoop, é hora de configurá-lo. Para configurar a alta disponibilidade no cluster Hadoop, você deve usar o Zookeeper em todos os nós.

Os daemons em Active NameNode são:

• Funcionário do zoológico
• Controlador de falha do Zookeeper
• JournalNode
• NameNode

Os daemons em Standby NameNode são:

• Funcionário do zoológico
• Controlador de falha do Zookeeper
• JournalNode
• NameNode

Os daemons no DataNode são:

• Funcionário do zoológico
• JournalNode
• DataNode

Se você deseja dominar HDFS e Hadoop, confira o curso Big Data e Hadoop especialmente curado por Edureka. Clique no botão abaixo para começar.

Definindo e configurando o cluster de alta disponibilidade no Hadoop:

Você deve primeiro configurar o Java e os nomes do host de cada nó.

Baixe o arquivo tar binário do Hadoop e Zookeeper, extraia os arquivos para editar os arquivos de configuração.

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

Espalhe o zookeeper-3.4.6.tar.gz

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

Baixe o tar binário do Hadoop estável no site do Apache Hadoop.

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

Extraia o tarball do Hadoop.

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

Espalhe o binário hadoop.

Adicione o Hadoop, Zookeeper e caminhos ao arquivo .bashrc.

Abra o arquivo .bashrc.

Comando : sudo gedit ~ / .bashrc

Adicione os caminhos abaixo:

estrutura básica do programa java

exportação HADOOP_HOME = exportação HADOOP_MAPRED_HOME = $ HADOOP_HOME exportação HADOOP_COMMON_HOME = $ HADOOP_HOME exportação HADOOP_HDFS_HOME = $ HADOOP_HOME exportação YARN_HOME = $ HADOOP_HOME exportação HADOOP_CONF_DIR = $ HADOOP_HOME / etc / hadoop exportação YARN_CONF_DIR = $ HADOOP_HOME / etc / exportação hadoop exportação ZOOKEEPER_HOME JAVA_HOME = = export PATH = $ PATH: $ JAVA_HOME / bin: $ HADOOP_HOME / bin: $ HADOOP_HOME / sbin: $ ZOOKEEPER_HOME / bin

Edite o arquivo .bashrc.

Habilite o SSH em todos os nós.

Gere a chave SSH em todos os nós.

Comando : ssh-keygen –t rsa (esta etapa em todos os nós)

Configure a chave SSH em todos os nós.

Não forneça nenhum caminho para o arquivo Enter para salvar a chave e não forneça nenhuma senha longa. Pressione o botão Enter.

Gere o processo de chave ssh em todos os nós.

Assim que a chave ssh for gerada, você obterá a chave pública e a chave privada.

O diretório de chaves .ssh deve conter a permissão 700 e todas as chaves dentro do diretório .ssh devem conter as permissões 600.

Altere a permissão do diretório SSH.

Mude o diretório para .ssh e mude a permissão dos arquivos para 600

Altere a permissão da chave pública e privada.

Você deve copiar a chave pública ssh dos nós de nome para todos os nós.

No Active Namenode, copie o id_rsa.pub usando o comando cat.

Comando : cat ~ / .ssh / id_rsa.pub >> ~ / .ssh / authorized_keys

Copie a chave ssh do Namenode para suas chaves autorizadas.

Copie a chave pública NameNode para todos os nós usando ssh-copy-id comando.

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

Copie a chave de propósito para o Standby NameNode.

Copie a chave pública NameNode para o nó de dados.

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

Copie a chave pública Namenode para o nó de dados.

Reinicie o serviço sshd em todos os nós.

Comando : sudo service sshd restart (fazer em todos os nós)

Reinicie o serviço SSH.

Agora você pode fazer login em qualquer nó do Namenode sem qualquer autenticação.

Abra o arquivo core-site.xml no nó Active Name e adicione as propriedades abaixo.

Editar core-site.xml do Active namenode

Abra o arquivo hdfs-site.xml no Active Namenode. Adicione as propriedades abaixo.

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

Mude o diretório para o diretório conf do zookeeper.

Comando : cd zookeeper-3.4.6 / conf

Diretório Zookeeper Conf.

Em um diretório conf, você tem o arquivo zoo_sample.cfg, crie o zoo.cfg usando o arquivo zoo_sample.cfg.

Comando : cp zoo_sample.cfg zoo.cfg

Crie o arquivo zoo.cfg.

Crie o diretório em qualquer local e use-o para armazenar os dados do zookeeper.

Comando : mkdir

Crie um diretório para armazenar os dados do zookeeper.

Abra o arquivo zoo.cfg.

Comando : gedit zoo.cfg

Adicione o caminho do diretório que é criado na etapa acima à propriedade dataDir e adicione os detalhes abaixo sobre o nó restante, no arquivo zoo.cfg.

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

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

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

Edite o arquivo zoo.cfg.

Agora copie os diretórios Java e Hadoop-2.6.0, zookeeper-3.4.6 e o ​​arquivo .bashrc para todos os nós (nó de nome de espera, nó de dados) usando o comando scp.

Comando : scp –r edureka @:

Copie o arquivo Hadoop, Zookeeper e .bashrc para todos os nós.

Da mesma forma, copie o arquivo .bashrc e o diretório zookeeper para todos os nós e altere as variáveis ​​de ambiente em cada um de acordo com o respectivo nó.

Em um nó de dados, crie qualquer diretório onde você precise armazenar os blocos HDFS.

Em um nó de dados, você deve incluir as propriedades dfs.datanode.data.dir.

No meu caso, eu criei datanode diretório para armazenar os blocos.

Crie o diretório Datanode.

__init__ em python

Altere a permissão para o diretório do nó de dados.

Altere a permissão do diretório Datanode.

Abra o arquivo HDFS-site.xml, adicione este caminho do diretório Datanode na propriedade dfs.datanode.data.dir.

Nota: Mantenha todas as propriedades que são copiadas do namenode Ativo, adicione dfs.datanode.data.dir uma propriedade de extração em namenode.

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

Em namenode ativo, altere o diretório onde deseja armazenar o arquivo de configuração do zookeeper (caminho da propriedade dataDir).

Crie o arquivo myid dentro do diretório, adicione 1 numérico ao arquivo e salve o arquivo.

Comando : vi myid

Crie o arquivo myid.

Em um namenode em espera, altere o diretório onde deseja armazenar o arquivo de configuração do zookeeper (caminho da propriedade dataDir).

Crie o arquivo myid dentro do diretório e adicione numérico 2 ao arquivo e salve o arquivo.

Em um nó de dados, altere o diretório onde deseja armazenar o arquivo de configuração do zookeeper (caminho da propriedade dataDir).

Crie o arquivo myid dentro do diretório e adicione numérico 3 ao arquivo e salve o arquivo.

Inicie o Journalnode em todos os três nós.

Comando : hadoop-daemon.sh start journalnode

Inicie o Journalnode.

Ao inserir o comando jps, você verá o daemon JournalNode em todos os nós.

Formate oPropósito ativo.

Comando : HDFS pretendido - formato

Formato de NameNode ativo.

Inicie o daemon Namenode e o Namedode ativo.

Comando : hadoop-daemon.sh iniciar propósito

Inicie o Namenode.

Copie os metadados HDFS do nó do nome ativo para o namenode em espera.

Comando : HDFS pretendido -bootstrapStandby

Copie os metadados HDFS do nó do nome ativo para o Namenode em espera.

Depois de executar esse comando, você obterá as informações de qual nó e local os metadados estão copiando e se estão copiando com êxito ou não.

Informações de detalhes da finalidade ativa.

Assim que os metadados forem copiados do namenode ativo para o namenode em espera, você receberá a mensagem mostrada abaixo na imagem.

Informações sobre HDFS em Standby Namenode.

passar por valor e passar por referência em java

Inicie o daemon namenode na máquina namenode em espera.

Comando : hadoop-daemon.sh iniciar propósito

Agora inicie o serviço Zookeeper em todos os três nós.

Comando : zkServer.sh start (Execute este comando em todos os nós)

No objetivo ativo:

Inicie o zookeeper em Active NameNode.

Namenode em espera:

Inicie o zookeeper em NameNode em espera.

No nó de dados:

Inicie o zookeeper no DataNode.

Depois de executar o servidor Zookeeper, digite o comando JPS. Em todos os nós, você verá o serviço QuorumPeerMain.

Inicie o daemon do nó de dados na máquina do nó de dados.

Comando : hadoop-daemon.sh start datanode

Inicie o controlador de failover do Zookeeper no nó de nome ativo e no nó de nome de espera.

Formate o controlador de failover do zookeeper no namenode ativo.

Comando: HDFS zkfc –formatZK

Formato ZKFC.

Inicie o ZKFC no namenode ativo.

Comando : hadoop-daemon.sh start zkfc

Insira o comando jps para verificar os daemons DFSZkFailoverController.

Inicie o ZKFC.

Formate o controlador de failover do zookeeper no namenode em espera.

Comando : hdfs zkfc –formatZK

Inicie o ZKFC no namenode em espera.

Comando : hadoop-daemon.sh start zkfc

Insira o comando jps para verificar os daemons DFSZkFailoverController.

Agora verifique o status de cada Namenode, qual nó está ativo ou qual nó está em espera usando o comando abaixo.

Comando : hdfs haadmin –getServiceState nn1

Verifique o status de cada NameNode.

Agora verifique o status de cada Namenode usando o navegador da web.

Abra o navegador da Web e digite o URL abaixo.

: 50070

Ele mostrará se o nó de nome está Ativo ou em espera.

NameNode ativo.

Abra outros detalhes de nó de nome usando o navegador da web.

NameNode em espera.

No namenode ativo, elimine o daemon namenode para alterar o nó de nome em espera para namenode ativo.

Digite jps em Active namenode e mate o daemon.

Comando: sudo kill -9

ID do processo de Daemons.

O ID do processo Namenode é 7606, elimine o namenode.

Comando : Sudo kill -9 7606

Mate o processo de Nó de Nome

Abra os dois nós por meio do navegador da web e verifique o status.

Detalhes do Namenode.

Status de NameNode.

Parabéns, você configurou com êxito um cluster de alta disponibilidade HDFS no Hadoop.

Agora que você entendeu a arquitetura de cluster de alta disponibilidade do Hadoop, verifique o pela Edureka, uma empresa de aprendizagem online confiável com uma rede de mais de 250.000 alunos satisfeitos espalhados por todo o mundo. O curso Edureka Big Data Hadoop Certification Training ajuda os alunos a se tornarem especialistas em HDFS, Yarn, MapReduce, Pig, Hive, HBase, Oozie, Flume e Sqoop usando casos de uso em tempo real no varejo, mídia social, aviação, turismo, domínio financeiro.

Tem alguma questão para nós? Mencione isso na seção de comentários e entraremos em contato com você.

window._LQ_ = window._LQ_ || {}

lqQuizModal (janela, documento, {quizId: ’XAIVp8 ′, baseUrl:’ https: //quiz.leadquizzes.com/’,trigger: ’exit’}, _LQ_)