Recursos que oferecem suporte à alta disponibilidade em um EMR cluster da Amazon e como eles funcionam com aplicativos de código aberto

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

Alta disponibilidade HDFS

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

Em um EMR cluster da Amazon, 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, a Amazon EMR inicia um processo de HDFS failover automático. Um nó standby NameNode se torna active e assume todas as operações do cliente no cluster. A Amazon EMR substitui o nó com falha por um novo, que então se junta novamente como um. standby

nota

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

Se precisar descobrir qual NameNode éactive, você pode usar 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

Alta disponibilidade YARN ResourceManager

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

Em um EMR cluster da Amazon com vários nós primários, 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, EMR a Amazon iniciará um processo de failover automático. Um nó primário com standby ResourceManager a assume todas as operações. A Amazon EMR substitui o nó primário que falhou por um novo, que então volta ao ResourceManager quórum como um. standby

Você pode se conectar a “http://master-public-dns-name:8088/cluster” para qualquer nó primário, que o direciona automaticamente para o gerenciador de recursos. active Para descobrir qual é o gerenciador de recursosactive, use 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

Aplicativos compatíveis em um EMR cluster da Amazon com vários nós primários

Você pode instalar e executar os seguintes aplicativos em um EMR cluster da Amazon com vários nós primários. Para cada aplicação, o processo de failover do nó primário varia.

Aplicativo	Disponibilidade durante failover do nó primário	Observações
Flink	Disponibilidade não afetada pelo failover do nó primário	Os trabalhos do Flink na Amazon EMR são executados como YARN aplicativos. O Flink JobManagers funciona da mesma forma YARN que ApplicationMasters nos nós principais. O não JobManager é afetado pelo processo de failover do nó primário. Se você usa a 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 Configurando o Flink em um EMR cluster da Amazon com vários nós primários. A partir da EMR versão 5.28.0 da Amazon, nenhuma configuração manual é necessária para permitir a JobManager alta disponibilidade.
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	HDFS NameNode e faça YARN ResourceManager o failover automaticamente para o nó em espera quando o nó primário ativo falhar.
HBase	Alta disponibilidade	HBaseo 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é construído sobre o metastore Hive, que existe fora do cluster. HCatalogpermanece 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	Todos os aplicativos Spark são executados em YARN contêineres e podem reagir ao failover do nó primário da mesma forma que os recursos de alta YARN disponibilidade.
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 os contêineres Tez funcionamYARN, o Tez se comporta da mesma forma que 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 do intérprete HDFS por padrão para evitar 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 HDFS automático. 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 failover HDFS automático.

Para executar os seguintes aplicativos em um EMR cluster da Amazon com vários nós primários, você deve 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.

Aplicativo	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. Essa deve ser uma metastore SQL externa My, pois o Postgre não SQL é compatível com clusters de vários mestres. 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 Usando o Hue com um banco de dados remoto na 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 Usando o Oozie com um banco de dados remoto na 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 Presto/Trino SQL	Alta disponibilidade somente para componentes de serviço	É necessário um metastore externo do Hive para o PrestoDB (Presto na Amazon EMR 6.1.0-6.3.0 ou SQL Trino na Amazon 6.4.0 e versões posteriores). EMR Você pode usar o Presto com o AWS Glue Data Catalog ou usar um SQL banco de dados externo My for Hive. O Presto CLI é instalado em todos os três nós primários para que você possa usá-lo para acessar o Coordenador do Presto a partir de qualquer um dos nós primários. O coordenador do Presto é instalado em apenas um nó primário. Você pode encontrar o DNS nome do nó primário em que o Presto Coordinator está instalado ligando para a Amazon EMR describe-cluster API e lendo o valor retornado do MasterPublicDnsName campo na resposta.

nota

Quando um nó primário falha, sua conectividade de banco de dados Java (JDBC) ou conectividade de banco de dados aberta (ODBC) encerra sua 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 EMR recursos da Amazon funcionam em um cluster com vários nós primários

Conectando-se aos nós primários usando SSH

Você pode se conectar a qualquer um dos três nós principais em um EMR cluster da Amazon usando SSH da mesma forma que se conecta a um único nó primário. Para obter mais informações, consulte Conectar-se ao nó primário usando SSH.

Se um nó primário falhar, sua SSH conexão com esse nó primário será encerrada. 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 depois que EMR a Amazon 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. Você pode recuperar os novos endereços IP no console ou usando o describe-cluster comando no AWS CLI.

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

Trabalhando com etapas em um EMR cluster da Amazon com vários nós primários

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

A seguir estão algumas considerações para trabalhar com etapas em um EMR cluster da Amazon com vários nós primários:

• Se um nó primário falhar, as etapas em execução no nó primário serão marcadas comoFAILED. 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 tiver iniciado um YARN aplicativo quando o nó primário falhar, a etapa poderá continuar e ser bem-sucedida 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 que você defina o ActionOnFailure parâmetro comoCONTINUE, ou CANCEL _ AND _WAIT, em vez de TERMINATE JOB _ _ FLOW ou TERMINATE _CLUSTER.

Proteção automática de término

A Amazon habilita EMR automaticamente a proteção contra terminação para todos os clusters com vários nós primários e substitui todas as configurações de execução de etapas que você fornece ao criar o 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 Encerrar um EMR cluster da Amazon com vários nós primários.

Para obter mais informações sobre proteção contra término, consulte Usando a proteção contra rescisão para proteger seus EMR clusters da Amazon contra o desligamento acidental.

Recursos não suportados em um EMR cluster da Amazon com vários nós primários

No momento, os seguintes EMR recursos da Amazon não estão disponíveis em um EMR cluster da Amazon com vários nós primários:

• EMRCadernos

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

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

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

nota

Para usar a autenticação Kerberos em seu cluster, você deve configurar uma externa. KDC

A partir da EMR versão 5.27.0 da Amazon, você pode configurar a criptografia HDFS transparente em um EMR cluster da Amazon com vários nós primários. Para obter mais informações, consulte Criptografia transparente HDFS na Amazon EMR.