Usando AWS re:Post, accetti Termini di utilizzo
AWS re:Postre:Post

​Perché il mio cluster EMR è stato arrestato?

6 minuti di lettura
0

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:

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.

Argomenti
Analisi
Tag
Amazon Elastic MapReduce
Lingua
Italiano
AWS UFFICIALE
AWS UFFICIALEAggiornata 4 mesi fa

Contenuto pertinente