E-MapReduce:Cluster management FAQ

Puis-je mettre à niveau un cluster EMR ?

Non. Il n'est pas possible de mettre à niveau un cluster EMR ou 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 section Versions de publication.

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 maître. 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 à différents types de clusters, consultez la section 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érieur, ou EMR V3.42.0 ou ultérieur. Si vous avez besoin d'un service de planification de flux de travail, vous pouvez utiliser EMR Workflow. Pour plus d'informations, consultez la section Qu'est-ce qu'EMR Workflow ?.

Raison de la présence de trois nœuds maîtres dans les clusters HA

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

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 inventaire 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'a été facturé. Cliquez sur Delete dans la colonne Actions correspondant au 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 section Ajouter des services.

Redémarrage du service après modification de la configuration

Les modifications apportées à la configuration côté serveur des services tels que Spark, Hive et HDFS ne prennent effet qu'après le redémarrage des services. Les changements effectués sur les configurations côté client sont appliqués lorsque vous cliquez 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 section 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'une fois que l'instance actuelle et tous ses services sont entièrement rétablis. Le redémarrage de chaque 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 au sein d'un VPC qui ne dispose pas d'adresse IP publique. Cette opération permet d'accéder à l'instance ECS via Internet. Pour plus de détails, reportez-vous à la section Associer une EIP.

Quand activer un ensemble de déploiement

Un ensemble de déploiement est une fonctionnalité ECS qui contrôle la stratégie de distribution des instances ECS. Nous vous recommandons d'activer cette fonctionnalité pour les groupes de nœuds principaux utilisant des types d'instance avec disques locaux afin d'améliorer la sécurité des données. Un ensemble de déploiement 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 panne d'un hôte physique.

En raison des limitations des ensembles de déploiement ECS, un maximum de 20 instances ECS peut être ajouté à un ensemble de déploiement. Pour plus d'informations, consultez la rubrique Activer un ensemble de déploiement.

Spécification d'un ensemble de déploiement lors de la mise à l'échelle d'un cluster

Par défaut, les ensembles de déploiement sont activés pour les types d'instance dotés de 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 ensemble de déploiement, reportez-vous à la section Activer un ensemble de déploiement.

Spécification de la taille du disque lors de la mise à l'échelle d'un cluster

Lorsque vous augmentez la capacité d'un cluster, les paramètres du groupe de nœuds déterminent la taille des disques pour les nouveaux nœuds. Il est impossible de modifier cette taille pendant le processus de mise à l'échelle. Si nécessaire, vous pouvez ajuster la taille des disques du groupe de nœuds. Pour savoir comment étendre un disque, consultez la page Étendre un disque.

Puis-je étendre ou réduire les disques ?

Vous ne pouvez qu'étendre les disques de données. Il est impossible de réduire les disques de données ou de redimensionner les disques système.

Dans l'onglet Nodes du cluster cible, cliquez sur Expand Disk pour le groupe de nœuds concerné afin d'étendre ses disques de données. Pour des instructions détaillées, consultez la section Étendre un disque.

Mise à l'échelle horizontale et réduction d'un cluster

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

• Mise à l'échelle horizontale (scale-out) : vous ne pouvez augmenter la capacité que des groupes de nœuds principaux (core) et de tâches (task). Par défaut, la configuration des nouveaux nœuds est identique à celle des nœuds existants. Avant de procéder à la mise à l'échelle, assurez-vous que toutes les commandes associées sont payées. Une commande impayée entraînera l'échec de l'opération. Pour des instructions spécifiques, consultez la rubrique Mettre à l'échelle un cluster.

• Réduction de la capacité (scale-in) : le groupe de nœuds maîtres ne prend pas en charge la réduction de la capacité. Les règles applicables aux autres groupes de nœuds varient selon leur type :

  • Pour les groupes de nœuds de tâche avec facturation à l'utilisation ou instances préemptibles, ainsi que pour les groupes de nœuds Gateway avec facturation à l'utilisation, consultez la section Réduire la capacité d'un cluster.

  • Pour les groupes de nœuds principaux avec facturation à l'utilisation, les groupes de nœuds de tâche par abonnement et les groupes de nœuds principaux par abonnement, reportez-vous à la documentation sur Réduire manuellement la capacité d'un groupe de nœuds.

Erreur : « AddNumber is not valid » lors de la mise à l'échelle

• 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 de la mise à l'échelle d'un cluster.

• Cause : cette erreur indique que la fonctionnalité d'ensemble de déploiement est activée pour votre cluster et que le nombre de nœuds dans le groupe a atteint la limite de l'ensemble de déploiement. Pour plus d'informations sur les ensembles de déploiement, consultez la page Activer un ensemble de déploiement.

• Solution : contactez le support ECS pour demander une augmentation du quota d'ensembles de déploiement associé à votre compte.

Comment arrêter la collecte des journaux de service ?

Si vous souhaitez qu'EMR cesse de collecter 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 : à 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 la désactivation de la collecte des journaux de service, il faut environ deux à trois minutes pour que la configuration soit synchronisée. 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 au sein 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 fonction de vérification de l'intégrité 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 fonction de vérification de l'intégrité. Une fois le cluster créé, vous pouvez utiliser cette fonctionnalité sous 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 travaux existants. Après l'installation, EMR Doctor configure automatiquement les paramètres nécessaires dans le cluster existant, ce qui vous dispense d'effectuer des configurations manuelles.

Pendant l'installation ou la mise à niveau, EMR Doctor déploie des 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 ni 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 travaux, les métriques et les compteurs.

EMR Doctor est-il gratuit ?

Oui. EMR Doctor est actuellement gratuit.

Quel est l'impact de la collecte de données sur l'exécution des travaux ?

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

La collecte des travaux par 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 du travail. 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 fonction de rapport quotidien analyse les données en fonction des travaux 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.

• Travaux de calcul : une fois les travaux de calcul du cluster collectés, le dernier rapport est disponible le lendemain. Ce rapport fournit une évaluation du cluster et des recommandations basées sur l'analyse de l'état d'exécution des travaux de la veille.

• Analyse du stockage : EMR Doctor n'active pas l'analyse du stockage par défaut. Vous pouvez l'activer manuellement. Une fois activée, la collecte s'exécute généralement vers 10 h 00. Une fois la collecte terminée, l'analyse se lance et un rapport est généré tôt le lendemain matin. 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 donne 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 de la mise à l'échelle

• Symptôme : la mise à l'échelle du cluster échoue, avec comme motif 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 mettre à l'échelle est insuffisant pour satisfaire votre demande.

• Solution : attendez que le type d'instance ECS requis soit disponible, puis tentez à nouveau la mise à l'échelle, ou procédez à la mise à l'échelle 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 section 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 motif 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 professionnels.

Comment supprimer des services inutiles ?

Il est impossible de supprimer des services existants d’un cluster. Une fois un service démarré, vous ne pouvez pas le supprimer depuis la console ni via une API.

Comment se connecter à un nœud de cluster

Une fois le cluster EMR créé, connectez-vous au nœud maître à l’aide du 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 consulter le vSwitch d’une instance

Dans EMR on 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 située à gauche. Dans le panneau de détails à droite, vous pouvez consulter l’ID du vSwitch dans le champ vSwitch.

Résoudre la perte de paquets sur un cluster à grande échelle

• Symptôme : Le cluster subit des pertes fréquentes de paquets réseau et les journaux système affichent 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 entre adresses IP et adresses 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 compte plus de 1 000 serveurs et exécute une version antérieure à EMR-5.18.0 ou EMR-3.52.0 (exclusive), 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 principaux paramètres sont les suivants :

  • net.ipv4.neigh.default.gc_thresh1 : nombre minimal d’entrées à conserver dans le cache ARP. Aucune opération de garbage collection n’est 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. Une opération de garbage collection est effectuée dans un délai de 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 comptant plus de 1 000 nœuds et peuvent provoquer des pertes de paquets réseau ainsi qu’une instabilité. Il est donc nécessaire d’ajuster ces paramètres.

• Solution :

  1. Modifiez le fichier /etc/sysctl.conf et ajoutez le contenu suivant afin d’augmenter la limite de capacité du cache ARP et d’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. Exécutez ensuite à nouveau la commande sysctl -p pour mettre à jour la configuration.

Gérer 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 dotée de disques locaux, cela signifie 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. Consultez 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 une mise à l’échelle horizontale vers l’extérieur (scale out) pour ajouter un nouveau nœud. Pour plus d’informations, consultez la rubrique Mettre à l’échelle un cluster vers l’extérieur.

3. Effectuez une mise à l’échelle horizontale vers l’intérieur (scale in) du nœud défectueux.

   • Pour effectuer une mise à l’échelle vers l’intérieur d’un groupe de nœuds Core ou d’un groupe de nœuds Task en abonnement, consultez la rubrique Mettre manuellement à l’échelle un groupe de nœuds vers l’intérieur.

     Remarque

     Lorsque vous libérez une instance ECS en 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 une mise à l’échelle vers l’intérieur d’un groupe de nœuds Task en paiement à l’utilisation, consultez la rubrique Mettre à l’échelle un cluster vers l’intérieur.

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 d’activation de 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 choisissez All Tag Keys dans les options développées ci-dessous.

6. Cliquez sur OK.

Pour plus d’informations sur la configuration des tags, consultez la rubrique Héritage des tags.

Erreur : IdempotentParameterMismatch

• Symptôme : Le message d’erreur suivant peut s’afficher 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 : Le message d’erreur suivant peut s’afficher lors de la création ou de la mise à l’échelle vers l’extérieur 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 mise à l’échelle vers l’extérieur 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. Réessayez ensuite l’opération de création ou de mise à l’échelle vers l’extérieur du cluster.

Erreur : LostProxy

• Symptôme : L’erreur « taihao-proxy disconnect » se produit lors de la création d’un cluster, de sa mise à l’échelle vers l’extérieur 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 une mise à l’échelle vers l’extérieur du cluster pour réduire la charge.

       • 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 fonctionne correctement.

     • 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 les processus anormaux qui consomment des ressources. Si vous en trouvez, arrêtez-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 maître, examinez les processus présentant une consommation élevée de CPU. Vous pouvez mettre à niveau la spécification du nœud maître ou ajouter des nœuds MASTER-EXTEND pour répartir la charge.

       • Pour un nœud autre que le maître, si une seule instance ECS est surchargée ou ne répond pas, vous pouvez retirer le nœud problématique ou en ajouter un nouveau.

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

         service taihao-proxy restart

  2. Une fois les vérifications et les opérations terminées, réessayez de créer le cluster, de le mettre à l’échelle vers l’extérieur ou de mettre à jour la configuration du service.

Erreur : « Solde du compte insuffisant »

• Symptôme : Le message d’erreur suivant s’affiche lors de la création, de la mise à l’échelle vers l’extérieur 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 : Le solde de votre compte est 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 le solde suffisant, réessayez l’opération.

Erreur : QuotaExceed.DiskCapacity

• Symptôme : Le message d’erreur suivant peut s’afficher lors de la mise à l’échelle vers l’extérieur 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 : Le message d’erreur suivant peut s’afficher lors de la création ou de la mise à l’échelle vers l’extérieur 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, puis réessayez. Vous pouvez également demander une augmentation de quota dans la console ECS ou le Quota Center.

Gérer les échecs des actions bootstrap

Consultez 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 explicite, ajoutez des journaux plus détaillés au script bootstrap pour faciliter le débogage, puis réessayez l’opération.

• Si la tâche expire ou si le journal ne contient aucune sortie, 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 à l’endpoint interne OSS, puis réessayez l’opération.