Por que meu cluster do Amazon EMR foi encerrado com um erro "application provisioning failed"?

Resolução

Quando o Amazon EMR não consegue instalar, configurar ou iniciar um software específico ao iniciar um cluster do Amazon EMR, é possível que receba o erro "application provisioning failed".

Analisar os logs de provisionamento do Amazon EMR

O Amazon EMR armazena logs de provisionamento em um bucket do Amazon Simple Storage Service (Amazon S3) que você especifica ao iniciar o cluster.

Conclua as etapas a seguir:

1. Abra o console do Amazon EMR.
2. No painel de navegação, selecione Clusters. Em seguida, escolha o cluster do Amazon EMR que falhou para ver os detalhes do cluster.
3. Na seção Resumo, escolha Encerrado com erros e anote o ID do nó primário incluído na mensagem de erro.
4. Na seção Logs do cluster, escolha a URL de localização do Amazon S3.
5. Siga o caminho a seguir para navegar até sua pasta UUID:
   node/example-primary-node-ID/provision-node/apps-phase/0/example-UUID/.
   Observação: substitua example-primary-node-ID pelo ID do nó primário. Substitua example-UUID pelo seu UUID.
6. Na lista resultante, selecione puppet.log.gz e escolha Abrir para ver o provisionamento em uma nova guia do navegador.

Identificar os motivos das falhas nos logs de provisionamento

Parâmetros de configuração não suportados podem causar erros. Nomes de host incorretos, senhas incorretas ou problemas gerais do sistema operacional também podem causar erros. Pesquise nos logs palavras-chave relacionadas, incluindo "error", "err" ou "fail".

Problemas ao se conectar a uma metastore externa com uma instância do Amazon RDS

É possível configurar algumas aplicações do Amazon EMR, como Apache Hive, Hue ou Apache Oozie, para armazenar dados em um banco de dados externo, como o Amazon Relational Database Service (Amazon RDS). Quando você enfrenta problemas de conexão com o banco de dados externo, você recebe uma mensagem de erro.

Exemplo de mensagem de erro do Hive:

2022-11-26 02:59:36 +0000 /Stage[main]/Hadoop_hive::Init_metastore_schema/Exec[init hive-metastore schema]/returns (notice): org.apache.hadoop.hive.metastore.HiveMetaException: Failed to get schema version.
2022-11-26 02:59:36 +0000 /Stage[main]/Hadoop_hive::Init_metastore_schema/Exec[init hive-metastore schema]/returns (notice): Underlying cause: java.sql.SQLNonTransientConnectionException : Could not connect to address=(host=hostname)(port=3306)(type=master) : Socket fail to connect to host:hostname, port:3306. hostname
2022-11-26 02:59:36 +0000 /Stage[main]/Hadoop_hive::Init_metastore_schema/Exec[init hive-metastore schema]/returns (notice): SQL Error code: -1

Para solucionar esse tipo de erro, realize as seguintes ações:

• Verifique se o nome do host, o usuário, a senha e o banco de dados da instância do Amazon RDS estão corretos.
• Verifique se as regras de entrada do grupo de segurança da instância do Amazon RDS permitem conexões do grupo de segurança do nó primário do Amazon EMR.

Problemas ao se conectar a um KDC externo

O Amazon EMR permite configurar um KDC externo para adicionar uma camada extra de segurança. Além disso, também é possível criar uma relação de confiança com um servidor do Active Directory. Se houver um problema ao entrar em contato com o KDC ou tentar ingressar em um domínio, você receberá uma mensagem de erro.

Exemplo de mensagem de erro do Puppet:

2022-11-26 03:02:01 +0000 Puppet (err): 'echo "${AD_DOMAIN_JOIN_PASSWORD}" | realm join -v -U "${AD_DOMAIN_JOIN_USER}"@"${CROSS_REALM_TRUST_REALM}" "${CROSS_REALM_TRUST_DOMAIN}"' returned 1 instead of one of [0]
2022-11-26 03:02:01 +0000 /Stage[main]/Kerberos::Ad_joiner/Exec[realm_join]/returns (err): change from 'notrun' to ['0'] failed: 'echo "${AD_DOMAIN_JOIN_PASSWORD}" | realm join -v -U "${AD_DOMAIN_JOIN_USER}"@"${CROSS_REALM_TRUST_REALM}" "${CROSS_REALM_TRUST_DOMAIN}"' returned 1 instead of one of [0]

Para solucionar esse tipo de erro, realize as seguintes ações:

• Verifique se você digitou o domínio do Kerberos corretamente.
• Verifique se você digitou a senha administrativa do KDC corretamente.
• Verifique se você digitou corretamente o usuário e a senha de associação do Active Directory.
• Verifique se o Active Directory contém o usuário de associação e se o usuário tem as permissões corretas.
• Para o KDC e o Active Directory hospedados no Amazon Elastic Compute Cloud (Amazon EC2), verifique se as regras de entrada dos grupos de segurança do KDC e do Active Directory permitem conexões do grupo de segurança do nó primário do Amazon EMR.
• Para o KDC e o Active Directory hospedados fora do Amazon EC2, verifique se o KDC e o Active Directory permitem conexões da nuvem privada virtual (VPC) e da sub-rede do cluster do Amazon EMR.

Problemas ao iniciar serviços, como YARN ResourceManager, Hadoop NameNode ou Spark History Server

O Amazon EMR permite criar uma configuração personalizada de todas as aplicações ao iniciar um cluster do Amazon EMR. Mas, às vezes, essas configurações podem bloquear o processo inicial dos serviços. Quando o serviço não pode ser iniciado devido a um problema, você recebe uma mensagem de erro.

Exemplo de mensagem de erro do Apache Spark History Server:

2022-11-26 03:34:13 +0000 Puppet (err): Systemd start for spark-history-server failed!journalctl log for spark-history-server:
-- Logs begin at Sat 2022-11-26 03:27:57 UTC, end at Sat 2022-11-26 03:34:13 UTC. --
Nov 26 03:34:10 ip-192-168-1-32 systemd[1]: Starting Spark history-server...
Nov 26 03:34:10 ip-192-168-1-32 spark-history-server[1076]: Starting Spark history-server (spark-history-server):[OK]
Nov 26 03:34:10 ip-192-168-1-32 su[1112]: (to spark) root on none
Nov 26 03:34:13 ip-192-168-1-32 systemd[1]: spark-history-server.service: control process exited, code=exited status=1
Nov 26 03:34:13 ip-192-168-1-32 systemd[1]: Failed to start Spark history-server.
Nov 26 03:34:13 ip-192-168-1-32 systemd[1]: Unit spark-history-server.service entered failed state.  
Nov 26 03:34:13 ip-192-168-1-32 systemd[1]: spark-history-server.service failed.
2022-11-26 03:34:13 +0000 /Stage[main]/Spark::History_server/Service[spark-history-server]/ensure (err): change from 'stopped' to 'running' failed: Systemd start for spark-history-server failed!
journalctl log for spark-history-server:

Para solucionar esse tipo de erro, realize as seguintes ações:

• Verifique qual serviço falhou ao iniciar.
• Revise suas configurações em busca de erros de ortografia.
• Verifique o log do Amazon S3 no local especificado para descobrir a causa da falha. Por exemplo, s3://example-log-location/example-cluster-ID/node/example-primary-node-ID/applications/example-failed-application/example-failed-service.gz.

Problemas ao baixar ou instalar aplicações

Quando o Amazon EMR não consegue instalar ou baixar uma aplicação, o cluster do Amazon EMR falha e os logs de provisionamento não são concluídos. Analise o log stderr.gz para identificar o que causou o erro.
Exemplo de mensagem de erro:

stderr.gzError Summary
-------------
Disk Requirements:
  At least 2176MB more space needed on the / filesystem.

2022-11-26 03:18:44,662 ERROR Program: Encountered a problem while provisioning
java.lang.RuntimeException: Amazon-linux-extras topics enabling or yum packages installation failed.

Para resolver esse tipo de erro, aumente o volume raiz do Amazon Elastic Block Store (Amazon EBS) ao iniciar seu cluster do Amazon EMR.

Os logs do Amazon S3 não estão disponíveis

Quando o Amazon EMR falha ao provisionar aplicações e não há logs gerados no Amazon S3, você recebe uma mensagem de erro. Um erro de rede pode ter causado a falha no registro em log do Amazon S3.

Para solucionar esse tipo de erro, realize as seguintes ações:

• Verifique se você ativou a opção Registro em log ao iniciar o Amazon EMR. Para mais informações, consulte Configure Amazon EMR cluster logging and debugging (Configuração de registro em log e depuração do cluster do Amazon EMR).
• Se você usa uma AMI personalizada, verifique as regras de firewall que possam interferir nas configurações de rede necessárias do Amazon EMR. Para mais informações, consulte Working with Amazon EMR-managed security groups (Trabalhar com grupos de segurança gerenciados pelo Amazon EMR).
• Se você usa uma AMI personalizada, verifique se há nós primários com falha. Abra o console do Amazon EMR e, no painel de navegação, escolha Hardware para ver se os clusters podem iniciar qualquer nó primário.
• Se você usa uma AMI personalizada, certifique-se de seguir as práticas recomendadas. Para mais informações, consulte Using a custom AMI to provide more flexibility for Amazon EMR cluster configuration (Usar uma AMI personalizada para fornecer mais flexibilidade na configuração de clusters do Amazon EMR).

Informações relacionadas

Falha no provisionamento do cluster do EMR