E-MapReduce:FAQ sur la gestion des clusters

Puis-je mettre à niveau un cluster EMR ?

Non. Vous ne pouvez pas mettre à niveau un cluster EMR ni ses services. Pour utiliser une version plus récente, libérez le cluster existant et créez-en un nouveau.

Quels services les clusters EMR prennent-ils en charge ?

Les services pris en charge varient selon le type de cluster et la version. Pour plus d'informations, consultez la rubrique Présentation des versions.

Puis-je ajouter Zeppelin depuis la console ?

Non. Vous ne pouvez pas ajouter Zeppelin en tant que nouveau service depuis la console EMR. Pour ajouter Zeppelin, installez-le sur n'importe quelle instance ECS de nœud master. Vous pouvez également installer et maintenir manuellement d'autres composants sur les instances ECS. Pour obtenir des informations sur les services que vous pouvez ajouter aux différents types de clusters, consultez la rubrique Ajouter des services.

EMR prend-il en charge Oozie et ses alternatives ?

Le composant Oozie n'est pas inclus dans les clusters DataLake EMR exécutant EMR V5.8.0 ou ultérieure, ou EMR V3.42.0 ou ultérieure. Si vous avez besoin d'un service de planification de workflows, vous pouvez utiliser EMR Workflow. Pour plus d'informations, consultez la rubrique Qu'est-ce qu'EMR Workflow ?.

Raison de la présence de trois nœuds master dans les clusters haute disponibilité

Les nouveaux clusters haute disponibilité EMR utilisent trois nœuds master pour offrir une fiabilité supérieure à celle d'une configuration à deux nœuds master. Les configurations à deux nœuds master ne sont plus prises en charge et le groupe de nœuds master ne peut pas faire l'objet d'un scale-in. Pour ces clusters, EMR répartit les nœuds master sur différents hôtes physiques afin de réduire le risque de défaillance.

Activation du chiffrement des disques de données et ses effets

Une fois le chiffrement des disques de données activé, les données sont chiffrées aussi bien en transit qu'au repos. Cette fonctionnalité permet de répondre aux exigences de sécurité et de conformité. Le chiffrement des disques de données est transparent pour les applications au niveau du système d'exploitation des instances ECS et n'affecte pas l'exécution des tâches.

Comment nettoyer un cluster ayant échoué

Les échecs de création de cluster sont généralement causés par des configurations RDS incorrectes entraînant un échec de déploiement, ou par un stock insuffisant de certaines instances ECS.

Si certaines instances ECS ont été créées mais que l'état du cluster est Startup Failed, libérez les instances depuis la console ECS. Une fois toutes les instances libérées, le cluster EMR est automatiquement libéré.

Si le déploiement EMR échoue et que l'état du cluster est Unexpectedly Terminated, aucune ressource n'a été créée et aucun frais n'est facturé. Cliquez sur Delete dans la colonne Actions du cluster pour le supprimer.

Ajout de services à un cluster existant

Oui. Vous pouvez ajouter des services à un cluster après sa création. Pour plus d'informations, consultez la rubrique Ajouter des services.

Redémarrage du service après modification des configurations

Les modifications de configuration côté serveur pour des services tels que Spark, Hive et HDFS ne prennent effet qu'après le redémarrage des services. Les modifications de configuration côté client prennent effet après avoir cliqué sur Deploy Client Configuration, sans nécessiter de redémarrage du service. Pour plus d'informations sur la modification ou l'ajout d'éléments de configuration, consultez la rubrique Gérer les éléments de configuration.

Qu'est-ce qu'un redémarrage progressif ?

Le mécanisme de redémarrage progressif redémarre les instances ECS une par une. L'instance suivante ne redémarre qu'après que l'instance actuelle et tous ses services soient entièrement restaurés. Chaque redémarrage de nœud prend environ cinq minutes.

Association d'une adresse IP publique à un cluster existant

Vous pouvez demander une adresse IP élastique (EIP) et l'associer à une instance ECS dans un Virtual Private Cloud (VPC) qui ne dispose pas d'adresse IP publique. Cela permet à l'instance ECS d'être accessible via Internet. Pour plus d'informations, consultez la rubrique Associer une EIP.

Quand activer un deployment set

Un deployment set est une fonctionnalité ECS qui contrôle la stratégie de distribution des instances ECS. Nous vous recommandons d'activer la fonctionnalité de deployment set pour les groupes de nœuds core utilisant des types d'instance avec des disques locaux afin d'améliorer la sécurité des données. Un deployment set empêche le déploiement de plusieurs instances ECS sur le même hôte physique. Cela évite un point de défaillance unique et aide à prévenir la perte de données HDFS locales sur EMR en cas de défaillance d'un hôte physique.

En raison des limitations des deployment sets ECS, un maximum de 20 instances ECS peuvent être ajoutées à un deployment set. Pour plus d'informations, consultez la rubrique Activer un deployment set.

Spécification d'un deployment set lors du scale-out d'un cluster

Par défaut, les deployment sets sont activés pour les types d'instance avec des disques locaux et désactivés pour les autres types d'instance. Vous pouvez ajuster ce paramètre selon vos besoins. Pour obtenir des instructions sur l'activation d'un deployment set, consultez la rubrique Activer un deployment set.

Spécification de la taille du disque lors du scale-out d'un cluster

Lorsque vous effectuez un scale-out d'un cluster, les paramètres du groupe de nœuds déterminent la taille du disque pour les nouveaux nœuds. Cette taille ne peut pas être modifiée pendant le processus de scale-out. Si nécessaire, vous pouvez ajuster la taille du disque du groupe de nœuds. Pour obtenir des instructions sur l'extension d'un disque, consultez la rubrique Étendre un disque.

Puis-je augmenter ou réduire la taille des disques ?

Vous ne pouvez qu'augmenter la taille des disques de données. Vous ne pouvez pas réduire la taille des disques de données ni redimensionner les disques système.

Sur l'onglet Nodes du cluster cible, cliquez sur Expand Disk pour le groupe de nœuds cible afin d'augmenter la taille de ses disques de données. Pour des instructions spécifiques, consultez la rubrique Étendre un disque.

Scale-out et scale-in d'un cluster

Oui, mais les règles de mise à l'échelle varient selon le type de nœud :

• Scale-out : Vous ne pouvez effectuer un scale-out que pour les groupes de nœuds core et task. La configuration des nouveaux nœuds est identique à celle des nœuds existants par défaut. Avant d'effectuer un scale-out, assurez-vous que toutes les commandes associées sont payées. Une commande impayée entraînera l'échec de l'opération de scale-out. Pour des instructions spécifiques, consultez la rubrique Effectuer un scale-out d'un cluster.

• Scale-in : Le groupe de nœuds master ne prend pas en charge le scale-in. Les règles pour les autres groupes de nœuds varient selon le type :

  • Pour les groupes de nœuds task avec des instances à la demande ou préemptibles et les groupes de nœuds Gateway à la demande, consultez la rubrique Effectuer un scale-in d'un cluster.

  • Pour les groupes de nœuds core à la demande, les groupes de nœuds task par abonnement et les groupes de nœuds core par abonnement, consultez la rubrique Effectuer manuellement un scale-in d'un groupe de nœuds.

Erreur : « AddNumber is not valid » lors du scale-out

• Symptôme : Vous recevez le message d'erreur The specified parameter AddNumber is not valid. add instances number :xxx larger than deploymentSet availableAmount: xxx deploymentSetId: ds-uf6gwfou0a13kekupt14xxxx lors du scale-out d'un cluster.

• Cause : Cette erreur indique que la fonctionnalité de deployment set est activée pour votre cluster et que le nombre de nœuds dans le groupe de nœuds a atteint la limite du deployment set. Pour plus d'informations sur les deployment sets, consultez la rubrique Activer un deployment set.

• Solution : Contactez le support ECS pour demander une augmentation du quota de deployment set pour votre compte.

Comment arrêter la collecte des journaux de service ?

Si vous ne souhaitez pas qu'EMR collecte vos données, vous pouvez désactiver la collecte des journaux opérationnels des services.

Procédure :

1. Désactivez la collecte des journaux opérationnels des services.

   • Lors de la création du cluster : Dans l'étape de configuration logicielle, cliquez sur Collect Service Operational Logs.

   • Après la création du cluster : Sur la page Basic Information du cluster cible, dans la section Software Information, cliquez sur Collection Status of Service Operational Logs.

2. Vérifiez que la collecte est désactivée.

   Vérifiez si namenode-log existe dans /usr/local/ilogtail/user_log_config.json. S'il n'existe pas, la collecte des journaux de service est désactivée.

   Remarque

   Après avoir désactivé la collecte des journaux de service, la synchronisation de la configuration prend environ deux à trois minutes. Veuillez patienter.

Quelles informations les journaux opérationnels des services collectent-ils ?

Les journaux opérationnels des services incluent uniquement les journaux des composants de service en cours d'exécution du cluster. Vous pouvez activer ou désactiver la collecte de tous les journaux de service en un seul clic. Notez que si vous désactivez la collecte des journaux, la fonctionnalité de vérification de l'état de santé du cluster et le support technique seront limités.

Quels types de cluster prennent en charge EMR Doctor ?

Seuls les types de cluster DataLake et Hadoop prennent en charge la fonctionnalité de vérification de l'état de santé. Après la création d'un cluster, vous pouvez utiliser cette fonctionnalité dans l'onglet Monitoring and Diagnostics > Health Check du cluster cible dans la console EMR.

Si votre cluster Hadoop ne dispose pas de cette fonctionnalité, vous devez activer EMR Doctor. Pour plus d'informations, consultez la rubrique Activer EMR Doctor (pour les clusters Hadoop).

Impact de l'installation ou de la mise à niveau d'EMR Doctor

L'installation ou la mise à niveau d'EMR Doctor ne redémarre aucun service et n'affecte pas vos tâches existantes. Après l'installation, EMR Doctor configure automatiquement les paramètres nécessaires dans le cluster existant, de sorte que vous n'avez pas besoin d'effectuer de configurations manuelles.

Pendant l'installation ou la mise à niveau, EMR Doctor déploie les configurations pour les services YARN, Spark, Tez et Hive. Si vous avez modifié et enregistré certaines configurations sans les déployer, assurez-vous que le processus de déploiement n'affecte pas les services.

Quelles données EMR Doctor collecte-t-il ?

EMR Doctor ne collecte pas vos données réelles et n'analyse pas vos fichiers ni leur contenu.

EMR Doctor collecte uniquement les données d'événements nécessaires, telles que les heures de début et de fin des tâches, les métriques et les compteurs.

EMR Doctor est-il gratuit ?

Oui. EMR Doctor est actuellement gratuit.

Comment la collecte de données affecte-t-elle l'exécution des tâches ?

La collecte de métadonnées de stockage d'EMR Doctor ajuste dynamiquement les ressources utilisées pour la collecte en fonction des ressources de l'utilisateur et ne consomme pas de ressources excessives.

La collecte de tâches d'EMR Doctor utilise la technologie de sonde Java et ne démarre pas de processus Java distinct pour la surveillance. La collecte est effectuée de manière asynchrone et ne bloque pas le processus principal de la tâche. Si la surcharge de collecte devient trop élevée, EMR Doctor ignore automatiquement les données. Vous pouvez également ajuster des paramètres tels que la fréquence de collecte.

Quand les rapports de collecte sont-ils disponibles ?

Après l'installation ou la mise à niveau d'EMR Doctor, la fonctionnalité de rapport quotidien analyse les données en fonction des tâches que vous exécutez et de la collecte des métadonnées de stockage. Par conséquent, le cluster doit avoir une charge de travail active.

• Tâches de calcul : Après la collecte des tâches de calcul sur le cluster, le dernier rapport est disponible le lendemain. Le rapport fournit une évaluation du cluster et des recommandations basées sur une analyse de l'état d'exécution des tâches de la veille.

• Analyse du stockage : EMR Doctor n'active pas l'analyse du stockage par défaut. Vous pouvez l'activer manuellement. Après l'avoir activée, la collecte s'exécute généralement vers 10 h 00. Une fois la collecte terminée, l'analyse s'exécute et un rapport est généré tôt le matin du lendemain. Si vous activez la collecte dans l'après-midi, vous devrez attendre le troisième jour pour voir les résultats.

Valeurs spécifiques pour les configurations recommandées

EMR Doctor fournit des recommandations directionnelles, telles que la réduction de la configuration mémoire ou la modification des paramètres GC, mais ne fournit pas de valeurs de paramètres spécifiques. En effet, EMR Doctor utilise un échantillonnage ponctuel pour la collecte afin de minimiser l'impact sur votre programme. Vous devez tester et valider toutes les configurations recommandées pour vos charges de travail spécifiques.

Erreur : « Insufficient ECS inventory » lors du scale-out

• Symptôme : Le scale-out du cluster échoue, avec comme raison d'échec « Insufficient ECS inventory_OutofStock » ou « Insufficient ECS inventory_OperationDenied.NoStock ».

• Cause : Le stock du type d'instance ECS pour le groupe de nœuds que vous souhaitez étendre est insuffisant pour satisfaire votre demande.

• Solution : Attendez que le type d'instance ECS requis soit disponible en stock, puis réessayez le scale-out, ou effectuez un scale-out en créant un nouveau groupe de nœuds et en sélectionnant un autre type d'instance ECS. Pour plus d'informations, consultez la rubrique Créer un groupe de nœuds.

Erreur : « Insufficient ECS inventory » lors de la création d'un cluster

• Symptôme : La création d'un cluster ou l'ajout d'un groupe de nœuds échoue, avec comme raison d'échec « Insufficient ECS inventory_OutofStock » ou « Insufficient ECS inventory_OperationDenied.NoStock ».

• Cause : Le stock du type d'instance ECS que vous avez sélectionné pour le cluster ou le groupe de nœuds est insuffisant.

• Solution : Lors de la création du cluster, sélectionnez un autre type d'instance ECS disposant d'un stock suffisant et répondant à vos besoins métier.

Comment supprimer des services inutiles ?

Vous ne pouvez pas supprimer des services existants d'un cluster. Une fois qu'un service est démarré, vous ne pouvez pas le supprimer depuis la console ni via une API.

Comment se connecter à un nœud de cluster

Après la création d'un cluster EMR, vous pouvez vous connecter au nœud master en utilisant le mot de passe défini lors de la création du cluster. Pour savoir comment vous connecter aux autres nœuds, consultez la rubrique Se connecter aux autres nœuds d'un cluster.

Comment afficher le vSwitch d'une instance

Dans EMR sur ECS, les informations relatives au vSwitch sont associées aux groupes de nœuds et ne peuvent pas être consultées directement sur la page Basic Information. Accédez à la page Nodes et cliquez sur le nom du groupe de nœuds auquel l'instance appartient pour afficher les informations du vSwitch associé.

Sur la page Node Management du cluster EMR, sélectionnez le groupe de nœuds cible (par exemple emr-master) dans la liste des groupes de nœuds à gauche. Dans le panneau de détails à droite, vous pouvez afficher l'ID du vSwitch dans le champ vSwitch.

Résolution des pertes de paquets sur un cluster à grande échelle

• Symptôme : Des pertes fréquentes de paquets réseau se produisent dans le cluster et les journaux système peuvent afficher des messages d'erreur tels que neighbour: arp_cache: neighbor table overflow!. Cela indique que la table de cache ARP (Address Resolution Protocol) est pleine et ne peut plus gérer les mappages d'adresses IP vers MAC, ce qui entraîne des problèmes de performances réseau.

• Cause : Dans les systèmes distribués à grande échelle, en particulier lorsqu'un seul cluster dépasse 1 000 serveurs et exécute une version antérieure à EMR-5.18.0 ou EMR-3.52.0 (exclues), vous pouvez rencontrer une instabilité réseau et des pertes de paquets. Vous pouvez optimiser la gestion du cache ARP en ajustant les paramètres système.

  Le cache ARP stocke les mappages entre les adresses IP et les adresses MAC. Les paramètres clés sont les suivants :

  • net.ipv4.neigh.default.gc_thresh1 : Nombre minimal d'entrées à conserver dans le cache ARP. La garbage collection n'est pas effectuée si le nombre d'entrées est inférieur à cette valeur. La valeur par défaut est 128.

  • net.ipv4.neigh.default.gc_thresh2 : Limite souple du nombre d'entrées dans le cache ARP. La garbage collection est effectuée dans les 5 secondes si le nombre d'entrées dépasse cette valeur. La valeur par défaut est 512.

  • net.ipv4.neigh.default.gc_thresh3 : Limite stricte du nombre d'entrées dans le cache ARP. La valeur par défaut est 1024.

  Remarque

  Les valeurs par défaut sont trop faibles pour les clusters de plus de 1 000 nœuds et peuvent provoquer des pertes de paquets réseau et une instabilité. Par conséquent, les paramètres doivent être ajustés.

• Solution :

  1. Modifiez le fichier /etc/sysctl.conf et ajoutez le contenu suivant pour augmenter la limite de capacité du cache ARP et optimiser la valeur maximale de suivi des connexions.

     net.ipv4.neigh.default.gc_thresh1 = 512
     net.ipv4.neigh.default.gc_thresh2 = 2048
     net.ipv4.neigh.default.gc_thresh3 = 10240
     net.nf_conntrack_max = 524288

  2. Exécutez la commande sudo sysctl -p pour appliquer les nouveaux paramètres.

     Remarque

     Si vous rencontrez le message d'erreur sysctl: cannot stat /proc/sys/net/nf_conntrack_max: No such file or directory lors de l'exécution de la commande sysctl -p, commencez par exécuter la commande sudo modprobe nf_conntrack pour charger le module correspondant. Ensuite, exécutez à nouveau la commande sysctl -p pour mettre à jour la configuration.

Gestion d'un événement SystemMaintenance.Redeploy

Si vous recevez un événement système de type Redéploiement d'instance dû à la maintenance du système (SystemMaintenance.Redeploy) pour une instance à disque local, cela indique qu'Alibaba Cloud a détecté des risques potentiels de défaillance logicielle ou matérielle sur l'hôte sous-jacent de l'instance ECS. Ce risque nécessite le redéploiement de l'instance ECS. Ne cliquez pas directement sur Redeploy dans la console ECS afin d'éviter toute perte de données.

Solution :

1. Vérifiez les détails de l'événement pour identifier le nœud concerné.

2. Dans le groupe de nœuds contenant le nœud défectueux, effectuez un scale-out pour ajouter un nouveau nœud. Pour plus d'informations, consultez la rubrique Effectuer un scale-out d'un cluster.

3. Effectuez un scale-in du nœud défectueux.

   • Pour effectuer un scale-in d'un groupe de nœuds core ou d'un groupe de nœuds task par abonnement, consultez la rubrique Effectuer manuellement un scale-in d'un groupe de nœuds.

     Remarque

     Lorsque vous libérez une instance ECS par abonnement, ECS calcule et affiche le montant du remboursement. Si vous avez des questions, soumettez un ticket et sélectionnez Elastic Compute Service pour le champ Product.

   • Pour effectuer un scale-in d'un groupe de nœuds task à la demande, consultez la rubrique Effectuer un scale-in d'un cluster.

Ajout automatique de tags d'ID de cluster aux disques cloud

Pour taguer automatiquement les disques cloud des instances ECS de votre cluster EMR avec l'ID du cluster, activez l'héritage des tags dans la console Tag.

Procédure :

1. Connectez-vous à la console Tag.

2. Dans le volet de navigation de gauche, choisissez Tags > Tag inheritance.

3. Lisez les instructions pour activer la fonctionnalité et cochez la case pour créer un rôle lié au service.

   Lorsque vous activez l'héritage des tags, le système crée automatiquement un rôle lié au service nommé AliyunServiceRoleForTag pour effectuer les opérations liées à l'héritage des tags. Pour plus d'informations, consultez la rubrique Rôle lié au service pour Tag.

4. Cliquez sur Enable and set rules.

5. Configurez les règles d'héritage des tags.

   Pour les ressources prenant en charge l'héritage des tags, spécifiez les clés de tag à hériter. Vous pouvez choisir d'hériter de toutes les clés de tag ou uniquement de clés spécifiques.

   Dans Associated Resource Types, sélectionnez ECS Instance Disks, puis sélectionnez All Tag Keys dans les options développées ci-dessous.

6. Cliquez sur OK.

Pour plus d'informations sur les paramètres des tags, consultez la rubrique Héritage des tags.

Erreur : IdempotentParameterMismatch

• Symptôme : Vous pouvez rencontrer le message d'erreur suivant lors d'opérations telles que la libération d'un cluster ou la mise à niveau d'une configuration.

• Cause : Le même jeton client a été utilisé dans plusieurs requêtes.

  The request uses the same client token as a previous, but non-identical request. Do not reuse a client token with different requests, unless the requests are identical.

• Solution : Vérifiez si votre opération est déjà en cours. Si c'est le cas, ne la soumettez pas à nouveau. Sinon, actualisez la page de la console. La console EMR génère automatiquement un nouveau jeton client.

Erreur : QuotaExceeded.PrivateIpAddress

• Symptôme : Vous pouvez rencontrer le message d'erreur suivant lors de la création ou du scale-out d'un cluster.

  [QuotaExceeded.PrivateIpAddress] The specified VSwitch "vsw-xxxx" does not have enough IP addresses.

• Cause : Le vSwitch sélectionné ne dispose pas d'assez d'adresses IP privées disponibles pour satisfaire la demande de création ou de scale-out du cluster.

• Solution : Créez un nouveau groupe de nœuds et sélectionnez un vSwitch disposant d'un nombre suffisant d'adresses IP disponibles. Ensuite, réessayez l'opération de création ou de scale-out du cluster.

Erreur : LostProxy

• Symptôme : L'erreur « taihao-proxy disconnect » se produit lors de la création d'un cluster, du scale-out d'un cluster ou de la mise à jour d'une configuration de service.

• Cause : L'agent de gestion EMR (proxy) sur un nœud du cluster a perdu sa connexion.

• Solution :

  1. Vérifiez l'état du cluster et corrigez les problèmes des nœuds.

     • Si plusieurs nœuds sont déconnectés, vérifiez les métriques CPU et mémoire.

       • Si l'utilisation du processeur ou de la mémoire est élevée, le cluster est surchargé. Mettez à niveau la configuration ou effectuez un scale-out du cluster pour réduire la pression.

       • Si l'utilisation du processeur et de la mémoire est faible, vérifiez la configuration du groupe de sécurité pour vous assurer que la communication réseau est normale.

     • Si seuls quelques nœuds sont déconnectés, vérifiez la charge de ces nœuds pour déterminer si l'utilisation du processeur ou de la mémoire a atteint 100 %. Si la charge est trop élevée, recherchez des processus anormaux qui consomment des ressources. Si vous en trouvez, terminez-les et vérifiez si l'état du nœud revient à la normale. Si aucun processus anormal n'est trouvé, envisagez les solutions suivantes :

       • Pour un nœud master, examinez les processus qui consomment beaucoup de CPU. Vous pouvez mettre à niveau la spécification du nœud master ou ajouter des nœuds MASTER-EXTEND pour répartir la charge.

       • Pour un nœud non master, si une seule instance ECS est surchargée ou ne répond pas, vous pouvez retirer le nœud problématique ou ajouter un nouveau nœud.

         Connectez-vous au nœud et exécutez la commande suivante pour redémarrer le service.

         service taihao-proxy restart

  2. Après avoir effectué les vérifications et les opérations, réessayez de créer le cluster, de le mettre à l'échelle ou de mettre à jour la configuration du service.

Erreur : « Insufficient account balance »

• Symptôme : Vous rencontrez le message d'erreur suivant lors de la création, du scale-out ou de la mise à niveau d'un cluster.

  InvalidAccountStatus.NotEnoughBalance Message: Your account does not have enough balance to order pay-as-you-go products. 

• Cause : Votre compte dispose d'un solde insuffisant.

• Solution : Vérifiez le solde de votre compte et assurez-vous qu'il est suffisant pour couvrir le coût des ressources requises. Une fois votre solde suffisant, réessayez l'opération.

Erreur : QuotaExceed.DiskCapacity

• Symptôme : Vous pouvez rencontrer le message d'erreur suivant lors du scale-out d'un cluster ou de l'extension d'un disque.

  [QuotaExceed.DiskCapacity] The used capacity of disk type has exceeded the quota in the zone,  quota check fail.

• Cause : Le quota de disque pour l'instance a atteint sa limite.

• Solution : La capacité utilisée du type de disque spécifié a dépassé le quota dans la zone de disponibilité. Accédez au Quota Center pour consulter et demander une augmentation de votre quota de capacité de disque.

Erreur : QuotaExceed.ElasticQuota

• Symptôme : Vous pouvez rencontrer le message d'erreur suivant lors de la création ou du scale-out d'un cluster.

  QuotaExceed.ElasticQuota Message: The number of the specified ECS instances has exceeded the quota of the specified instance type. 

• Cause : Le quota d'instances ECS a été atteint.

• Solution : Sélectionnez un autre type d'instance ou réduisez le nombre d'instances et réessayez. Vous pouvez également demander une augmentation de quota dans la console ECS ou le Quota Center.

Gestion des échecs d'action bootstrap

Vérifiez le journal d'exécution de l'action bootstrap ayant échoué dans l'historique des opérations :

• Si le journal contient un message d'erreur clair, corrigez le script bootstrap en fonction du message d'erreur et réessayez l'opération.

• Si le journal contient le mot-clé exitCode mais aucun message d'erreur clair, ajoutez une journalisation plus détaillée au script bootstrap pour un meilleur débogage, puis réessayez l'opération.

• Si la tâche expire ou s'il n'y a aucune sortie dans le journal, vérifiez les points suivants :

  • Assurez-vous que l'utilisateur dispose des autorisations de lecture sur le bucket OSS où se trouve le script bootstrap.

  • Vérifiez la configuration réseau de l'ECS pour vous assurer qu'elle peut accéder au endpoint interne OSS, puis réessayez l'opération.