Perché il mio cluster EMR è stato arrestato?
Il mio cluster Amazon EMR è stato arrestato in modo imprevisto.
Risoluzione
Analisi dei log relativi al provisioning di Amazon EMR archiviati in Amazon S3
I log del cluster di Amazon EMR sono archiviati in un bucket Amazon Simple Storage Service (Amazon S3) specificato all'avvio del cluster. I log sono archiviati all'indirizzo s3://example-log-location/example-cluster-ID/node/example-EC2-instance-ID/.
Nota: sostituisci example-log-location, example-cluster-ID e example-EC2-instance-ID con la denominazione del tuo sistema.
Di seguito è riportato un elenco degli errori più comuni:
SHUTDOWN_STEP_FAILED (USER_ERROR)
NO_SLAVES_LEFT (SYSTEM_ERROR)
The master failed: Error occurred: <html>??<head><title>502 Bad Gateway</title></head>??<body>??<center><h1>502 Bad Gateway</h1></center>??<hr><center>nginx/1.16.1</center>??</body>??</html>??
KMS_ISSUE (USER_ERROR)Terminated with errors, The master node was terminated by user.
Nota: i precedenti sono gli errori di arresto più comuni. I cluster EMR potrebbero essere arrestati a causa di errori diversi da quelli elencati. Per ulteriori informazioni, consultare Errori nelle risorse.
SHUTDOWN_STEP_FAILED (USER_ERROR)
Quando si invia un processo di fase nel cluster EMR, è possibile specificare il comportamento di errore della fase nel parametro ActionOnFailure. Il cluster EMR si arresta se si seleziona TERMINATE_CLUSTER o TERMINATE_JOB_FLOW per il parametro ActionOnFailure. Per maggiori informazioni, consultare StepConfig.
Di seguito è riportato un esempio di messaggio di errore da AWS CloudTrail:
{ "severity": "ERROR", "actionOnFailure": "TERMINATE_JOB_FLOW", "stepId": "s-2I0GXXXXXXXX", "name": "Example Step", "clusterId": "j-2YJXXXXXXX", "state": "FAILED", "message": "Step s-2I0GXXXXXXXX (Example Step) in Amazon EMR cluster j-2YJXXXXXXX failed at 202X-1X-0X 0X:XX UTC." }
Per evitare questo errore, utilizzare l'opzione CONTINUE o CANCEL_AND_WAIT nel parametro ActionOnFailure quando si invia il processo della fase.
NO_SLAVES_LEFT (SYSTEM_ERROR)
Questo errore si verifica quando:
- La protezione dall'arresto è disattivata nel cluster EMR.
- Tutti i nodi principali superano la capacità di archiviazione su disco come specificato da una soglia massima di utilizzo nella classificazione di configurazione yarn-site. La soglia di utilizzo massima predefinita è del 90%.
- L'istanza CORE è un'istanza Spot e l'istanza Spot è TERMINATED_BY_SPOT_DUE_TO_NO_CAPACITY.
Per informazioni sull'arresto dell'istanza Spot, consultare Perché Amazon EC2 ha arrestato la mia istanza Spot?
Per ulteriori informazioni sull'errore NO_SLAVE_LEFT, consultare Cluster arrestato con NO_SLAVE_LEFT e nodi principali FAILED_BY_MASTER.
Di seguito è riportato un esempio di messaggio di errore dal controller di istanza:
202X-0X-0X 1X:5X:5X,968 INFO Poller: InstanceJointStatusMap contains X entries (DD:5 R:3): i-0e336xxxxxxxxxxxx 25d21h R 25d21h ig-22 ip-1x-2xx-xx-1xx.local.xxx.com I: 52s Y:U 98s c: 0 am: 0 H:R 1.1%Yarn unhealthy Reason : 1/4 local-dirs usable space is below configured utilization percentage/no more usable space [ /mnt/yarn : used space above threshold of 90.0% ] ; 1/1 log-dirs usable space is below configured utilization percentage/no more usable space [ /var/log/hadoop-yarn/containers : used space above threshold of 90.0% ]
Per risolvere questo errore:
- Mantenere la protezione di arresto ON per i cluster. Per ulteriori informazioni, consultare Protezione da arresto e nodi YARN non integri.
- Usare le politiche di scalabilità di Amazon EMR (scalabilità automatica e scalabilità gestita) per scalare i nodi principali in base alle esigenze. Per ulteriori informazioni, consultare Scalare le risorse del cluster.
- Aggiungere maggiore capacità di Amazon Elastic Block Storage (Amazon EBS) al cluster. Per ulteriori informazioni, consultare Come risolvere "Exit status: -100. Diagnostica: errori di container rilasciato su un nodo *smarrito" in Amazon EMR?
- Creare un allarme per il parametro MRUnhealthyNodes di Amazon CloudWatch. È possibile impostare una notifica per questo allarme per avvisarti della presenza di nodi non funzionanti prima che venga raggiunto il timeout di 45 minuti. Per ulteriori informazioni, consultare Creare un allarme CloudWatch basato su una soglia statica.
502 Bad Gateway
L'errore 502 Bad Gateway si verifica quando i sistemi interni Amazon EMR non riescono a raggiungere il nodo primario per un periodo di tempo. Amazon EMR viene arrestato se la protezione dall'arresto è disattivata. Controllare i log più recenti del controller di istanza e i log dello stato delle istanze quando il servizio del controller di istanza è inattivo. L'output standard del controller di istanza mostra che il servizio è arrestato perché la memoria è insufficiente. Ciò indica che il nodo primario del cluster ha poca memoria.
Di seguito è riportato un esempio di messaggio di errore dal log dello stato dell'istanza:
# dump instance controller stdout tail -n 100 /emr/instance-controller/log/instance-controller.out OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00007fb46c7c8000, 12288, 0) failed; error='Cannot allocate memory' (errno=12) # # There is insufficient memory for the Java Runtime Environment to continue. # Native memory allocation (mmap) failed to map 12288 bytes for committing reserved memory. # An error report file with more information is saved as: # /tmp/hs_err_pid16110.log # whats memory usage look like free -m total used free shared buff/cache available Mem: 15661 15346 147 0 167 69 Swap: 0 0 0
Per evitare l'errore precedente, avviare un cluster EMR con un tipo di istanza più elevato per sfruttare più memoria per i requisiti del cluster. Inoltre, ripulire lo spazio su disco per evitare interruzioni di memoria nei cluster a lunga esecuzione. Per ulteriori informazioni, consultare Come risolvere un errore del nodo primario con l'errore "502 Bad Gateway" o "504 Gateway Time-out" in Amazon EMR?
KMS_ISSUE (USER_ERROR)
Quando si utilizza una configurazione di sicurezza Amazon EMR per crittografare un dispositivo root Amazon EBS e i volumi di storage, il ruolo deve disporre delle autorizzazioni appropriate. Se mancano le autorizzazioni necessarie, viene visualizzato l'errore KMS_ISSUE.
Di seguito è riportato un esempio di messaggio di errore da AWS CloudTrail:
The EMR Service Role must have the kms:GenerateDataKey* and kms:ReEncrypt* permission for the KMS key configuration when you enabled EBS encryption by default. You can retrieve that KMS key's ID by using the ec2:GetEbsDefaultKmsKeyId API.
Per evitare l'errore precedente, assicurarsi che le configurazioni di sicurezza utilizzate per crittografare il dispositivo root e i volumi di storage Amazon EBS dispongano delle autorizzazioni necessarie. Per queste configurazioni, assicurarsi che il ruolo di servizio Amazon EMR (EMR_DefaultRole_V2) disponga delle autorizzazioni per utilizzare la chiave del Servizio di gestione delle chiavi AWS (AWS KMS) specificata.
Arrestato con errori, il nodo principale è stato arrestato dall'utente
Quando il nodo primario del cluster EMR si arresta per qualsiasi motivo, il cluster si arresta con Il nodo principale è stato arrestato per errore dell'utente.
Di seguito è riportato un esempio di messaggio di errore da AWS CloudTrail:
eventTime": "2023-01-18T08:07:02Z", "eventSource": "ec2.amazonaws.com", "eventName": "StopInstances", "awsRegion": "us-east-1", "sourceIPAddress": "52.xx.xx.xx", "userAgent": "AWS Internal", "requestParameters": { "instancesSet": { "items": [ { "instanceId": "i-xxf6c5xxxxxxxxxxx" } ] }, "force": false },
Poiché l'arresto dei nodi primari o di tutti i nodi principali EMR comporta la chiusura del cluster, evitare di arrestare o riavviare i nodi del cluster.

Contenuto pertinente
- AWS UFFICIALEAggiornata 4 mesi fa
- AWS UFFICIALEAggiornata 5 mesi fa