As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # 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 ResourceManager em 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. ## High-availability HDFS Um cluster do Amazon EMR com vários nós primários habilita o recurso de alta disponibilidade do HDFS NameNode no Hadoop. Para obter mais informações, consulte [HDFS high availability](https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithNFS.html). 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 até 5.36.2 do Amazon EMR, apenas dois dos três nós primários executam o HDFS. NameNode Nas versões 6.x e superiores do Amazon EMR, todos os três nós primários 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 onde 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 ``` ## High-availability YARN 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](https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/ResourceManagerHA.html). 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 inicia um processo automático de failover. Um nó primário com a `standby` ResourceManager assume todas as operações. O Amazon EMR substitui o nó primário que falhou por um novo, que então se junta novamente ao quórum como um. ResourceManager `standby` Você pode se conectar a “http://{{master-public-dns-name}}:8088/cluster" para qualquer nó primário, o que o direciona automaticamente para o gerenciador de `active` recursos. 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 o 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, o ponto de JobManager falha é único. Quando o JobManager falha, ele perde todos os estados do trabalho e não retomará os trabalhos em execução. Você pode ativar a JobManager alta disponibilidade configurando a contagem de tentativas de aplicativos, marcando pontos de verificação e ativando ZooKeeper como armazenamento de estado para o Flink. Para obter mais informações, consulte [Configuring Flink on an Amazon EMR Cluster with multiple primary nodes](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/flink-configure.html#flink-multi-master).
A partir da versão 5.28.0 do Amazon EMR, nenhuma configuração manual é necessária para permitir JobManager a 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 | O HDFS NameNode e o YARN ResourceManager são automaticamente transferidos para o nó em espera quando o nó primário ativo falha. | | HBase | Alta disponibilidade | O HBase faz o failover automático do nó em espera quando o nó primário ativo falha.
Se você estiver se conectando ao HBase pelo servidor Thrift ou REST, é necessário alternar para outro nó primário quando o nó primário ativo falha. | | HCatalog | Disponibilidade não afetada pelo failover do nó primário | O HCatalog é baseado no metastore do Hive, existente fora do cluster. O 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 primárias. É 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](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-jupyterhub-s3.html). | | 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 o MXNet não tem daemons, ele não é afetado pelo processo de failover do nó primário. | | Phoenix | Alta disponibilidade | O 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](https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithNFS.html#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](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-metastore-external-hive.html). | | 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](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/hue-rds.html). | | 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](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/oozie-rds.html).
Oozie-server e o oozie-client estão instalados em todos os 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 ](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-presto-glue.html) ou [ usar um banco de dados MySQL externo para o Hive. ](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive-metastore-external.html)
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](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-connect-master-node-ssh.html). 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 ou três 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](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-work-with-steps.html). 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](UsingEMR_TerminationProtection.md#emr-termination-protection-running-cluster). 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 instruções, consulte [Terminar um cluster do Amazon EMR com múltiplos nós primários](emr-plan-ha-launch.md#emr-plan-ha-launch-terminate). 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](UsingEMR_TerminationProtection.md). ### 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 + One-click acesso ao servidor de histórico persistente do Spark + Interfaces do usuário de aplicações persistentes + One-click Atualmente, o acesso a 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 AWS Lake Formation. + Controle de acesso baseado em funções em tempo de execução. Para obter mais informações, consulte [Considerações adicionais](emr-steps-runtime-roles.md#emr-steps-runtime-roles-considerations) em [Perfis de runtime para etapas ao Amazon EMR](emr-steps-runtime-roles.md). + Integração do Amazon EMR com Centro de Identidade do AWS IAM (propagação de identidade confiável). Para obter mais informações, consulte [Integre o Amazon EMR com Centro de Identidade do AWS IAM](emr-idc.md). **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](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-encryption-tdehdfs.html).