Perché il mio cluster Amazon EMR è terminato con un errore "application provisioning failed" (errore di provisioning dell'applicazione)?

Risoluzione

Quando Amazon EMR non è in grado di installare, configurare o avviare il software specificato durante l'avvio di un cluster EMR, è possibile che venga visualizzato l'errore "application provisioning failed" (errore di provisioning dell'applicazione). Le sezioni seguenti illustrano come trovare ed esaminare i log relativi al provisioning. Mostrano anche diversi tipi di errori e i passaggi che puoi eseguire per risolverli.

Analisi dei log relativi al provisioning di Amazon EMR archiviati in Amazon S3

I log relativi al provisioning di Amazon EMR sono archiviati in un bucket Amazon Simple Storage Service (Amazon S3) specificato all'avvio del cluster. La posizione di archiviazione dei log utilizza la seguente sintassi URI di Amazon S3:

s3://example-log-location/example-cluster-ID/node/example-primary-node-ID/provision-node/apps-phase/0/example-UUID/puppet.log.gz

Nota: sostituisci example-log-location, example-cluster-ID, example-primary-node-ID e example-UUID con la denominazione del tuo sistema.

1. Apri la console Amazon EMR. Nel pannello di navigazione, scegli Cluster. Quindi, scegli il cluster EMR che ha riportato l'errore per visualizzare i dettagli del cluster.
2. Nella sezione Summary (Riepilogo), scegli "Terminato con errori" e annota l'ID del nodo primario incluso nel messaggio di errore.
3. Nella sezione Cluster logs (Log dei cluster), scegli l'URL della Amazon S3 location (Posizione Amazon S3) da reindirizzare ai log del cluster nella console Amazon S3.
4. Accedi alla tua cartella UUID seguendo questo percorso: node/example-primary-node-ID/provision-node/apps-phase/0/example-UUID/.
   Nota: sostituisci example-primary-node-ID e example-UUID con la denominazione del tuo sistema.
5. Nell'elenco che viene generato, seleziona puppet.log.gz e scegli Open (Apri) per visualizzare il provisioning in una nuova scheda del browser.

Identificazione dei motivi degli errori nei log di provisioning

I parametri di configurazione non supportati possono causare errori. Gli errori possono anche essere causati da nomi host errati, password errate o problemi generali del sistema operativo. Cerca nei log le parole chiave correlate agli errori, tra cui "error" o "fail".

Di seguito è riportato un elenco dei tipi di errore più comuni:

• Problemi di connessione a un metastore esterno con un'istanza Amazon Relational Database Service (Amazon RDS).
• Problemi di connessione a un centro di distribuzione delle chiavi (KDC) esterno.
• Problemi all'avvio di servizi, come YARN ResourceManager e Hadoop NameNode.
• Problemi durante il download o l'installazione di applicazioni.
• Mancanza di disponibilità dei log S3.

Problemi di connessione a un metastore esterno con un'istanza Amazon RDS

Alcune applicazioni Amazon EMR, come Hive, Hue o Oozie, possono essere configurate per archiviare dati in un database esterno, come Amazon RDS. Quando si verifica un problema con una connessione, viene visualizzato un messaggio.

Di seguito è riportato un esempio di messaggio di errore di 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

Per risolvere questo tipo di errore:

• Verifica che il nome host, l'utente, la password e il database dell'istanza RDS siano corretti.
• Verifica che le regole in entrata del gruppo di sicurezza dell'istanza RDS consentano le connessioni dal gruppo di sicurezza del nodo primario di Amazon EMR.

Problemi di connessione a un KDC esterno

Amazon EMR ti consente di configurare un KDC esterno per aggiungere un ulteriore livello di sicurezza. Inoltre, è possibile creare una relazione di attendibilità con un server Active Directory. Quando si verifica un problema nel contattare il KDC o nell'accedere a un dominio, viene visualizzato un messaggio.

Di seguito è riportato un esempio di messaggio di errore da 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]

Per risolvere questo tipo di errore:

• Verifica che l'area di Kerberos sia digitata correttamente.
• Verifica che la password amministrativa del KDC sia digitata correttamente.
• Verifica che il nome utente e la password per l'accesso ad Active Directory siano digitati correttamente.
• Verifica che il nome utente per l'accesso ad Active Directory esista in Active Directory e disponga delle autorizzazioni corrette.
• Verifica che i server KDC e Active Directory siano presenti su Amazon EC2. Quindi, verifica che le regole in entrata del gruppo di sicurezza KDC e Active Directory consentano le connessioni dal gruppo di sicurezza del nodo primario di Amazon EMR.
• Verifica che KDC e Active Directory non siano presenti su Amazon EC2. Quindi, verifica che KDC e Active Directory consentano le connessioni dal cloud privato virtuale (VPC) e dalla sottorete del cluster EMR.

Problemi all'avvio di servizi, come YARN ResourceManager, Hadoop NameNode o Spark History Server

Amazon EMR consente la configurazione personalizzata di tutte le applicazioni all'avvio del cluster EMR. Tuttavia, a volte queste configurazioni impediscono l'avvio dei servizi. Quando si verifica un problema che impedisce l'avvio di un servizio, viene visualizzato un messaggio di errore.

Di seguito è riportato un esempio di messaggio da 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:

Per risolvere questo tipo di errore:

• Verifica il servizio che non è stato avviato. Controlla se le configurazioni fornite sono state digitate correttamente.
• Naviga nel seguente percorso per visualizzare il log di S3 e per indagare sul motivo dell'errore: s3://example-log-location/example-cluster-ID/node/example-primary-node-ID/applications/example-failed-application/example-failed-service.gz.
  Nota: sostituisci example-log-location, example-cluster-ID, example-primary-node-ID, example-failed-application ed example-failed-service con la denominazione del tuo sistema.

Problemi durante il download o l'installazione di applicazioni

Amazon EMR può installare molte applicazioni. Tuttavia, a volte quando un'applicazione non può essere scaricata o installata si verifica un problema. Ciò può causare il malfunzionamento del cluster EMR. Quando si verifica questo errore, i log di provisioning non vengono completati. Pertanto, è necessario esaminare il log stderr.gz per trovare messaggi simili causati da installazioni di yum non riuscite.

Di seguito è riportato un esempio di messaggio di errore da 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.

Per risolvere questo tipo di errore, aumenta il volume root di Amazon Elastic Block Store (Amazon EBS) durante l'avvio del cluster EMR.

Mancanza di disponibilità dei log S3

Amazon EMR non riesce ad eseguire il provisioning delle applicazioni e non vi sono log generati in Amazon S3. In questo scenario, è probabile che un errore di rete abbia causato un errore con la registrazione di S3.

Per risolvere questo tipo di errore:

• Verifica che l'opzione Logging (Registrazione) sia attivata durante l'avvio del cluster EMR. Per ulteriori informazioni, consulta la pagina Configurazione della registrazione e del debug di cluster.
• Quando usi un'AMI personalizzata, verifica che non vi siano regole del firewall che interferiscano con le impostazioni di rete di Amazon EMR richieste. Per ulteriori informazioni, consulta la pagina Utilizzo dei gruppi di sicurezza gestiti da Amazon EMR.
• Quando usi un'AMI personalizzata, controlla se ci sono errori con i nodi primari. Apri la console Amazon EMR e, nel riquadro di navigazione, scegli Hardware per determinare se i cluster non sono in grado di avviare alcun nodo primario.
• Quando usi un'AMI personalizzata, verifica di seguire le best practice. Per ulteriori informazioni, consulta Utilizzo di un'AMI personalizzata.

---

Informazioni correlate

Insuccesso del provisioning del cluster EMR