Recursos que oferecem suporte à alta disponibilidade em um cluster do Amazon EMR e como eles funcionam com aplicações de código aberto

Este tópico fornece informações sobre os recursos de alta disponibilidade do Hadoop do HDFS NameNode e do YARN em ResourceManager um cluster do Amazon EMR e como os recursos de alta disponibilidade funcionam com aplicativos de código aberto e outros recursos do Amazon EMR.

Alta disponibilidade do HDFS

Um cluster do Amazon EMR com vários nós primários permite que HDFS NameNode recurso de alta disponibilidade no Hadoop. Para obter mais informações, consulte HDFS high availability.

Em um cluster do Amazon EMR, dois ou mais nós separados são configurados como. NameNodes Um NameNode está em um active estado e os outros estão em um standby estado. Se o nó com active NameNode falha, o Amazon EMR inicia um processo automático de failover do HDFS. Um nó standby NameNode se torna active e assume todas as operações do cliente no cluster. O Amazon EMR substitui o nó que falhou por um novo, que, por sua vez, reintegra-se como standby.

nota

Nas versões 5.23.0 do Amazon EMR até 5.30.1, inclusive, apenas dois dos três nós principais executam o HDFS. NameNode

Se precisar descobrir qual NameNode éactive, você pode usar o SSH para se conectar a qualquer nó primário no cluster e executar o seguinte comando:

hdfs haadmin -getAllServiceState

A saída lista os nós em que NameNode está instalado e seu status. Por exemplo,

ip-##-#-#-##1.ec2.internal:8020 active
ip-##-#-#-##2.ec2.internal:8020 standby
ip-##-#-#-##3.ec2.internal:8020 standby

YARN de alta disponibilidade ResourceManager

Um cluster do Amazon EMR com vários nós primários habilita o recurso de ResourceManager alta disponibilidade do YARN no Hadoop. Para obter mais informações, consulte ResourceManager Alta disponibilidade.

Em um cluster do Amazon EMR com vários nós primários, o YARN ResourceManager é executado em todos os três nós primários. Um ResourceManager está no active estado e os outros dois estão no standby estado. Se o nó primário active ResourceManager falhar, o Amazon EMR iniciará um processo de failover automático. Um nó primário com standby ResourceManager a assume todas as operações. O Amazon EMR substitui o nó primário que falhou por um novo, que então volta ao quórum como um. ResourceManager standby

Você pode se conectar a “http: //:8088/clustermaster-public-dns-name” para qualquer nó primário, o que o direciona automaticamente para o gerenciador de recursos. active Para descobrir qual gerenciador de recursos está active, use o SSH para se conectar a qualquer nó primário no cluster. Depois, execute o seguinte comando para obter uma lista com os três nós primários e os status deles:

yarn rmadmin -getAllServiceState

Aplicações compatíveis com um cluster do Amazon EMR com múltiplos nós primários

Você pode instalar e executar as aplicações a seguir em um cluster do Amazon EMR com múltiplos nós primários. Para cada aplicação, o processo de failover do nó primário varia.

Aplicação	Disponibilidade durante failover do nó primário	Observações
Flink	Disponibilidade não afetada pelo failover do nó primário	Os trabalhos do Flink no Amazon EMR são executados como aplicações YARN. O Flink é JobManagers executado como YARN ApplicationMasters nos nós principais. O não JobManager é afetado pelo processo de failover do nó primário. Se você usa o Amazon EMR versão 5.27.0 ou anterior, esse JobManager é um único ponto de falha. Quando o JobManager falha, ele perde todos os estados de trabalho e não retoma os trabalhos em execução. Você pode habilitar a JobManager alta disponibilidade configurando a contagem de tentativas de aplicativos, o checkpoint e ativando o armazenamento ZooKeeper como estado para o Flink. Para obter mais informações, consulte Configuring Flink on an Amazon EMR Cluster with multiple primary nodes. A partir da versão 5.28.0 do Amazon EMR, nenhuma configuração manual é necessária para permitir a alta disponibilidade. JobManager
Ganglia	Disponibilidade não afetada pelo failover do nó primário	O Ganglia está disponível em todos os nós primários e, portanto, continua em execução durante o processo de failover do nó primário.
Hadoop	Alta disponibilidade	O HDFS NameNode e o YARN ResourceManager passam automaticamente para o nó em espera quando o nó primário ativo falha.
HBase	Alta disponibilidade	HBase o failover automático para o nó em espera quando o nó primário ativo falha. Se você estiver se conectando HBase por meio de um servidor REST ou Thrift, deverá alternar para um nó primário diferente quando o nó primário ativo falhar.
HCatalog	Disponibilidade não afetada pelo failover do nó primário	HCatalog é baseado no metastore Hive, que existe fora do cluster. HCatalog permanece disponível durante o processo de failover do nó primário.
JupyterHub	Alta disponibilidade	JupyterHub está instalado em todas as três instâncias principais. É altamente recomendável configurar a persistência do caderno para evitar a perda do caderno após uma falha do nó primário. Para obter mais informações, consulte Configuring persistence for notebooks in Amazon S3.
Livy	Alta disponibilidade	O Livy é instalado em todos os três nós primários. Quando o nó primário ativo falha, você perde o acesso à sessão Livy atual e precisa criar uma nova sessão em outro nó primário ou no novo nó de substituição.
Mahout	Disponibilidade não afetada pelo failover do nó primário	Como o Mahout não tem daemons, ele não é afetado pelo processo de failover do nó primário.
MXNet	Disponibilidade não afetada pelo failover do nó primário	Como não MXNet tem daemon, ele não é afetado pelo processo de failover do nó primário.
Phoenix	Alta disponibilidade	Phoenix QueryServer funciona apenas em um dos três nós primários. O Phoenix em todos os três mestres está configurado para conectar o Phoenix QueryServer. É possível encontrar o IP privado do servidor de consulta do Phoenix usando o arquivo /etc/phoenix/conf/phoenix-env.sh
Pig	Disponibilidade não afetada pelo failover do nó primário	Como o Pig não tem daemons, ele não é afetado pelo processo de failover do nó primário.
Spark	Alta disponibilidade	Todas as aplicações do Spark são executadas em contêineres do YARN e podem reagir ao failover do nó primário do mesmo modo que os recursos de alta disponibilidade do YARN.
Sqoop	Alta disponibilidade	Por padrão, sqoop-job e sqoop-metastore armazenam dados (descrições de trabalhos) no disco local do mestre que executa o comando. Se você deseja salvar dados do metastore no banco de dados externo, consulte a documentação do Apache Sqoop.
Tez	Alta disponibilidade	Como o contêineres do Tez são executados no YARN, o Tez se comporta da mesma forma que o YARN durante o processo de failover do nó primário.
TensorFlow	Disponibilidade não afetada pelo failover do nó primário	Como não TensorFlow tem daemon, ele não é afetado pelo processo de failover do nó primário.
Zeppelin	Alta disponibilidade	O Zeppelin é instalado em todos os três nós primários. O Zeppelin armazena notas e configurações de intérprete no HDFS por padrão para evitar a perda de dados. As sessões de intérprete são completamente isoladas em todas as três instâncias primárias. Os dados da sessão serão perdidos após uma falha da instância mestra. Recomenda-se não modificar a mesma nota simultaneamente em instâncias primárias diferentes.
ZooKeeper	Alta disponibilidade	ZooKeeper é a base do recurso de failover automático do HDFS. ZooKeeper fornece um serviço altamente disponível para manter os dados de coordenação, notificar os clientes sobre alterações nesses dados e monitorar os clientes em busca de falhas. Para obter mais informações, consulte HDFS automatic failover.

Para executar as seguintes aplicações em um cluster do Amazon EMR com múltiplos nós primários, é necessário configurar um banco de dados externo. O banco de dados externo existe fora do cluster e torna os dados persistentes durante o processo de failover do nó primário. Para as aplicações a seguir, os componentes de serviço serão recuperados automaticamente durante o processo de failover do nó primário, mas os trabalhos ativos podem falhar e precisam ser repetidos.

Aplicação	Disponibilidade durante failover do nó primário	Observações
Hive	Alta disponibilidade somente para componentes de serviço	É necessário um metastore externo para o Hive. Deve ser um metastore externo do MySQL, pois o PostgreSQL não é compatível com clusters multiprincipais. Para obter mais informações, consulte Configuring an external metastore for Hive.
Hue	Alta disponibilidade somente para componentes de serviço	É necessário um banco de dados externo para o Hue. Para obter mais informações, consulte Using Hue with a remote database in Amazon RDS.
Oozie	Alta disponibilidade somente para componentes de serviço	É necessário um banco de dados externo para o Oozie. Para obter mais informações, consulte Using Oozie with a remote database in Amazon RDS. O Oozie-server e o oozie-client são instalados nos três nós primários. Os oozie-clients são configurados para se conectar ao oozie-server correto por padrão.
PrestoDB ou PrestoSQL/Trino	Alta disponibilidade somente para componentes de serviço	É necessário ter um metastore externo do Hive para PrestoDB (PrestoSQL no Amazon EMR 6.1.0-6.3.0 ou Trino no Amazon EMR 6.4.0 e versões posteriores). Você pode usar o Presto com o AWS Glue Data Catalog ou usar um banco de dados MySQL externo para o Hive. A CLI do Presto está instalada nos três nós primários, e assim você pode usá-la para acessar o coordenador do Presto por qualquer um dos nós primários. O coordenador do Presto é instalado em apenas um nó primário. Você encontra o nome DNS do nó primário em que o coordenador do Presto está instalado chamando a API describe-cluster do Amazon EMR e lendo o valor retornado do campo MasterPublicDnsName na resposta.

nota

Quando um nó primário falha, o Java Database Connectivity (JDBC) ou o Open Database Connectivity (ODBC) termina a conexão com o nó primário. Você pode se conectar a qualquer um dos nós primários restantes para continuar o trabalho, pois o daemon do Hive Metastore é executado em todos os nós primários. Ou você pode esperar a substituição do nó primário com falha.

Como os atributos do Amazon EMR funcionam em um cluster com múltiplos nós principais

Conectar aos nós primários usando SSH

Você pode se conectar a qualquer um dos três nós primários de um cluster do Amazon EMR usando o SSH da mesma maneira que conecta a um único nó primário. Para obter mais informações, consulte Connect to the primary node using SSH.

Se um nó primário falha, sua conexão SSH ao nó primário encerra. Para que ela continue funcionando, você pode se conectar a um dos outros dois nós primários. Como alternativa, você pode acessar o novo nó primário após o Amazon EMR substituir o que falhou por um novo.

nota

O endereço IP privado para o nó primário de substituição permanece o mesmo que o anterior. O endereço IP público para o nó primário de substituição pode mudar. É possível recuperar os novos endereços IP no console ou usando o comando describe-cluster na AWS CLI.

NameNode só é executado em dois dos nós primários. No entanto, você pode executar comandos hdfs da CLI e operar trabalhos para acessar o HDFS em todos os três nós primários.

Trabalhar com etapas em um cluster do Amazon EMR com múltiplos nós primários

Você pode enviar etapas a um cluster do Amazon EMR com múltiplos nós primários da mesma maneira que você trabalha com as etapas em um cluster com um único nó primário. Para obter mais informações, consulte Submit work to a cluster.

Veja aqui algumas considerações para trabalhar com etapas em um cluster do Amazon EMR com múltiplos nós primários:

• Se um nó primário falha, as etapas sendo executadas no nó primário são marcadas como FAILED. Todos os dados que foram gravados localmente são perdidos. No entanto, o status FAILED pode não refletir o estado real das etapas.

• Se uma etapa em execução iniciou uma aplicação do YARN antes da falha do nó primário, ela pode continuar e ter êxito devido ao failover automático do nó primário.

• Recomendamos que você verifique os status das etapas consultando a saída dos trabalhos. Por exemplo, os MapReduce trabalhos usam um _SUCCESS arquivo para determinar se o trabalho foi concluído com êxito.

• É recomendável definir o ActionOnFailure parâmetro como CONTINUE ou CANCEL_AND_WAIT, em vez de TERMINATE_JOB_FLOW ou TERMINATE_CLUSTER.

Proteção automática de término

O Amazon EMR habilita automaticamente a proteção contra término para todos os clusters com múltiplos nós primários e substitui as configurações de execução de etapas fornecidas na criação do cluster. É possível desabilitar a proteção contra término depois que o cluster é iniciado. Consulte Configurar a proteção contra término para clusters em execução. Para desligar um cluster com múltiplos nós primários, primeiro é necessário modificar os atributos do cluster para desabilitar a proteção contra término. Para obter instruções, consulte Terminar um cluster do Amazon EMR com múltiplos nós primários.

Para obter mais informações sobre proteção contra término, consulte Uso da proteção contra encerramento para proteger clusters do Amazon EMR do desligamento acidental.

Atributos incompatíveis em um cluster do Amazon EMR com múltiplos nós primários

No momento, os seguintes recursos do Amazon EMR não estão disponíveis em clusters do Amazon EMR com múltiplos nós primários:

• Cadernos do EMR

• Acesso com um clique ao servidor de histórico persistente do Spark

• Interfaces do usuário de aplicações persistentes

• No momento, o acesso com um clique às interfaces de usuário de aplicativos persistentes não está disponível para clusters do Amazon EMR com vários nós primários ou para clusters do Amazon EMR integrados ao Lake Formation. AWS

nota

Para usar a autenticação do Kerberos no seu cluster, é necessário configurar um KDC externo.

A partir do Amazon EMR 5.27.0, é possível configurar a criptografia transparente do HDFS em um cluster do Amazon EMR com múltiplos nós primários. Para obter mais informações, consulte Transparent encryption in HDFS on Amazon EMR.