Por que meu cluster do Amazon EMR foi encerrado com um erro de "application provisioning failed" (falha no provisionamento de aplicação)?

Resolução

Você pode ver um erro de "application provisioning failed" (falha no provisionamento de aplicação) quando o Amazon EMR não conseguir instalar, configurar ou iniciar o software especificado quando estiver iniciando um cluster do EMR. As seções a seguir mostram como encontrar e revisar os logs de provisionamento. Mostram também os diferentes tipos de erros e as etapas que você pode seguir para resolvê-los.

Analisar os logs de provisionamento do Amazon EMR armazenados no Amazon S3

Os logs de provisionamento do Amazon EMR são armazenados em um bucket do Amazon Simple Storage Service (Amazon S3) especificado na inicialização do cluster. O local de armazenamento dos logs usa a seguinte sintaxe de URI do Amazon S3:

s3://exemplo-local-log/exemplo-ID-cluster/node/exemplo-ID-nó-principal/provision-node/apps-phase/0/exemplo-UUID/puppet.log.gz

Observação: Substitua exemplo-local-log, exemplo-ID-cluster, exemplo-ID-nó-principal e exemplo-UUID pela nomenclatura do seu sistema.

1. Abra o console do Amazon EMR. No painel de navegação, escolha Clusters. Depois, escolha o cluster do EMR que apresentou a falha para ver os detalhes do cluster.
2. Na seção Summary (Resumo), escolha "Terminated with errors" (Encerrado com erros) e anote o ID do nó primário incluído na mensagem de erro.
3. Na seçãoCluster logs (Logs de cluster), escolha o URL do local do Amazon S3 para ser redirecionado aos logs de cluster no console do Amazon S3.
4. Navegue até pasta de UUID seguindo este caminho:node/exemplo-ID-nó-primário/provision-node/apps-phase/0/exemplo-UUID/.
   Observação: substituaexemplo-ID-nó-primário e exemplo-UUID pela nomenclatura do seu sistema.
5. Na lista resultante, selecione puppet.log.gz e escolha Open (Abrir) para ver o provisionamento em uma nova guia do navegador.

Identificar motivos de falhas nos logs de provisionamento

Parâmetros de configuração não compatíveis podem causar erros. Os erros também podem ser causados por nomes de host incorretos, senhas incorretas ou problemas gerais do sistema operacional. Pesquise nos logs palavras-chave relacionadas, incluindo "error" (erro) ou "fail" (falha).

Esta é uma lista de tipos de erro comuns:

• Problemas para conectar a um metastore externo com uma instância do Amazon Relational Database Service (Amazon RDS).
• Problemas para conectar a um centro de distribuição de chaves (KDC) externo.
• Problemas ao iniciar serviços, como o YARN ResourceManager e o Hadoop NameNode.
• Problemas ao baixar ou instalar aplicações.
• Os logs do S3 não estão disponíveis.

Problemas para conectar a um metastore externo com uma instância do Amazon RDS

Algumas aplicações do Amazon EMR, como Hive, Hue ou Oozie, podem ser configuradas para armazenar dados em um banco de dados externo, como o Amazon RDS. Quando há um problema com uma conexão, uma mensagem é exibida.

Este é um 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 resolver esse tipo de erro:

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

Problemas para conectar a um KDC externo

O Amazon EMR permite que você configure um KDC externo para adicionar mais uma camada de segurança. Você também pode criar uma relação de confiança com um servidor do Active Directory. Quando há um problema para estabelecer contato com o KDC ou ingressar em um domínio, uma mensagem é exibida.

Este é um 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 resolver esse tipo de erro:

• Verifique se o reino Kerberos está grafado corretamente.
• Verifique se a senha administrativa do KDC está grafada corretamente.
• Verifique se o usuário e a senha de ingresso do Active Directory estão grafados corretamente.
• Verifique se o usuário de ingresso do Active Directory existe no Active Directory e tem as permissões corretas.
• Verifique se os servidores do KDC e do Active Directory estão no Amazon EC2. Em seguida, verifique se as regras de entrada de grupo de segurança do KDC e do Active Directory permitem conexões do grupo de segurança do nó primário do Amazon EMR.
• Verifique se o KDC e o Active Directory não estão no Amazon EC2. Em seguida, verifique se o KDC e o Active Directory permitem conexões da nuvem privada virtual (VPC) e da sub-rede do cluster do EMR.

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

O Amazon EMR permite a configuração personalizada de todas as aplicações na inicialização de cluster do EMR. Mas, às vezes, essas configurações impedem que os serviços sejam iniciados. Quando há um problema impedindo que um serviço seja iniciado, uma mensagem é exibida.

Este é um exemplo de mensagem de erro do 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 resolver esse tipo de erro:

• Verifique o serviço em que houve falha na inicialização. Verifique se as configurações fornecidas estão grafadas corretamente.
• Navegue pelo caminho a seguir para ver o log do S3 e investigar o motivo da falha:s3://exemplo-local-log/exemplo-ID-cluster/node/exemplo-ID-nó-principal/applications/exemplo--aplicação-falhou/exemplo-serviço-falhou.gz.
  Observação: substitua exemplo-local-log, exemplo-ID-cluster, exemplo-ID-nó-principal, exemplo-aplicação-falhou e exemplo-serviço-falhou pela nomenclatura do seu sistema.

Problemas ao baixar ou instalar aplicações

O Amazon EMR pode instalar várias aplicações. Mas, às vezes, há um problema e uma aplicação não pode ser baixada ou instalada. Isso pode causar a falha no cluster do EMR. Quando essa falha acontece, os logs de provisionamento não são concluídos. Em vez disso, você deve revisar o log stderr.gz para encontrar mensagens semelhantes causadas por falhas nas instalações do yum.

Veja a seguir um exemplo de mensagem de erro de stderr.gz:

stderr.gz
Error 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) durante a inicialização do cluster do EMR.

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

O Amazon EMR não provisiona aplicações e não há nenhum log gerado no Amazon S3. Nesse cenário, é provável que um erro de rede tenha causado a falha do registro em log do S3.

Para resolver esse tipo de erro:

• Verifique se a opção Logging (Registrar em log) está ativada durante a inicialização do cluster do EMR. Para obter mais informações, consulte Configurar registro em log e depuração de clusters.
• Quando usar uma AMI personalizada, verifique se não há regras de firewall interferindo nas configurações de rede necessárias do Amazon EMR. Para obter mais informações, consulte Trabalhar com grupos de segurança gerenciados pelo Amazon EMR.
• Quando usar uma AMI personalizada, verifique se há algum nó primário com falha. Abra o console do Amazon EMR e, no painel de navegação, escolha Hardware para determinar se os clusters não conseguiram iniciar nenhum nó primário.
• Quando usar uma AMI personalizada, verifique se você está seguindo as práticas recomendadas. Para obter mais informações, consulte Usar uma AMI personalizada.

---

Informações relacionadas

Falha no provisionamento de cluster do EMR