​Pourquoi mon cluster EMR s’est terminé ?

Lecture de 6 minute(s)
0

Mon cluster Amazon EMR s’est terminé de manière inattendue.

Résolution

Consultez les journaux de provisionnement Amazon EMR stockés dans Amazon S3

Les journaux du cluster Amazon EMR sont stockés dans un compartiment Amazon Simple Storage Service (Amazon S3) spécifié lors du lancement du cluster. Les journaux sont stockés sur s3://example-log-location/example-cluster-ID/node/example-EC2-instance-ID.

Remarque : Remplacez example-log-location, example-cluster-ID et example-EC2-instance-ID par le nom de votre système.

Voici la liste des erreurs les plus courantes :

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.

Remarque : Les erreurs de cessation les plus courantes sont décrites ci-dessus. Les clusters EMR peuvent se terminer en raison d'erreurs autres que celles répertoriées. Pour plus d'informations, consultez Erreurs de ressources.

SHUTDOWN_STEP_FAILED (USER_ERROR)

Lorsque vous soumettez une tâche par étapes dans votre cluster EMR, vous pouvez spécifier le comportement de défaillance de l'étape dans le paramètre ActionOnFailure. Le cluster EMR se termine si vous sélectionnez TERMINATE_CLUSTER ou TERMINATE_JOB_FLOW pour le paramètre ActionOnFailure. Pour en savoir plus, consultez StepConfig.

Voici un exemple de message d'erreur provenant d'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."
}

Pour éviter cette erreur, utilisez l'option CONTINUE ou CANCEL_AND_WAIT dans le paramètre ActionOnFailure lors de la soumission de la tâche par étape.

NO_SLAVES_LEFT (SYSTEM_ERROR)

Cette erreur se produit lorsque :

  • La protection contre la cessation est désactivée dans le cluster EMR.
  • Tous les nœuds principaux dépassent la capacité de stockage sur disque spécifiée par un seuil d'utilisation maximal dans la classification de configuration du site filaire. Le seuil d'utilisation maximale par défaut est de 90 %.
  • L'instance CORE est une instance Spot, et l'instance Spot est TERMINATED_BY_SPOT_DUE_TO_NO_CAPACITY.

Pour plus d'informations sur la cessation d'une instance Spot, consultez Pourquoi Amazon EC2 a mis fin à mon instance Spot ?

Pour plus d'informations sur l'erreur NO_SLAVE_LEFT, voir Cluster a pris fin avec NO_SLAVE_LEFT et les nœuds principaux FAILED_BY_MASTER.

Voici un exemple de message d'erreur provenant du contrôleur d'instance :

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% ]

Pour résoudre cette erreur, procédez comme suit :

502 mauvaise passerelle

L'erreur 502 mauvaise passerelle se produit lorsque les systèmes internes d'Amazon EMR ne peuvent pas atteindre le nœud principal pendant un certain temps. Amazon EMR se termine si la protection contre la cessation est désactivée. Consultez les derniers journaux du contrôleur d'instance et les journaux d'état de l'instance lorsque le service du contrôleur d'instance est en panne. La sortie standard du contrôleur d'instance indique que le service a pris fin car la mémoire est insuffisante. Cela indique que le nœud principal du cluster manque de mémoire.

Voici un exemple de message d'erreur extrait du journal d'état de l'instance :

# 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

Pour éviter l'erreur précédente, lancez un cluster EMR avec un type d'instance plus élevé afin d'obtenir plus de mémoire pour les besoins de votre cluster. Nettoyez également l'espace disque pour éviter les pannes de mémoire dans les clusters de longue durée. Pour plus d'informations, consultez Comment résoudre une défaillance du nœud principal associée à l'erreur « 502 mauvaise passerelle » ou « 504 expiration de la passerelle » dans Amazon EMR ?

KMS_ISSUE (USER_ERROR)

Lorsque vous utilisez une configuration de sécurité Amazon EMR pour chiffrer un appareil racine Amazon EBS et des volumes de stockage, le rôle doit disposer des autorisations appropriées. Si les autorisations nécessaires font défaut, l'erreur KMS_ISSUE s’affiche.

Voici un exemple de message d'erreur provenant d'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.

Pour éviter l'erreur précédente, assurez-vous que les configurations de sécurité utilisées pour chiffrer le périphérique racine et les volumes de stockage Amazon EBS disposent des autorisations nécessaires. Pour ces configurations, assurez-vous que la fonction de service Amazon EMR (EMR_DefaultRole_V2) est autorisée à utiliser la clé AWS Key Management Service (AWS KMS) spécifiée.

Terminé avec des erreurs, le nœud principal s’est terminé suite à une demande de l'utilisateur

Lorsque le nœud principal du cluster EMR s'arrête pour une raison quelconque, le cluster se termine avec l'erreur : Le nœud principal s’est terminé par un utilisateur.

Voici un exemple de message d'erreur provenant d'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
},

L'arrêt du nœud principal de l'EMR ou de tous les nœuds principaux entraînant la cessation du cluster, évitez d'arrêter ou de redémarrer les nœuds du cluster.


AWS OFFICIEL
AWS OFFICIELA mis à jour il y a un an