:FAQ about images used with ECS instances

• Que faire si un message indique que le système d'exploitation Windows Server de mon instance n'est pas authentique ?

  Vous devez activer le système d'exploitation. Pour plus d'informations, consultez Comment utiliser le nom de domaine KMS pour activer une instance Windows dans un VPC ?

• Comment résoudre un problème de délai d'expiration de la résolution DNS sous CentOS ?

  Cause

  Le mécanisme de résolution DNS de CentOS 6 et CentOS 7 a évolué. Une erreur de délai d'expiration de la résolution DNS peut survenir sur les instances CentOS 6 ou CentOS 7 créées avant le 22 février 2017, ou utilisant des images personnalisées créées avant cette date.

  Solution

  Pour résoudre ce problème, procédez comme suit :

  1. Téléchargez le script fix_dns.sh.

  2. Placez le script téléchargé dans le répertoire /tmp du système d'exploitation CentOS.

  3. Exécutez la commande bash /tmp/fix_dns.sh pour lancer le script.

  Prenez note des points suivants concernant le script :

  • Rôle du script

    Le script vérifie si le fichier /etc/resolv.conf contient la configuration options > single-request-reopen. Pour plus d'informations, consultez resolv.conf.

    Le mécanisme de résolution DNS de CentOS 6 et CentOS 7 utilise le même quintuplet pour envoyer les requêtes DNS IPv4 et IPv6, ce qui nécessite l'ajout de l'option single-request-reopen. Lorsque deux requêtes provenant du même port doivent être traitées après l'ajout de l'option, le résolveur ferme le socket après l'envoi de la première requête, puis ouvre un nouveau socket avant d'envoyer la seconde. L'option prend effet immédiatement après son ajout. Aucun redémarrage de l'instance n'est nécessaire.

  • Logique du script

    1. Le script détermine si le système d'exploitation de l'instance est CentOS.

       • Si le système d'exploitation n'est pas CentOS (par exemple Ubuntu ou Debian), le script s'arrête.

       • Si le système d'exploitation est CentOS, le script continue son exécution.

    2. Le script recherche la configuration options dans le fichier /etc/resolv.conf.

       • Si la configuration options est absente, le script effectue l'opération suivante :

         Utilisez la configuration options Alibaba Cloud (options timeout:2 attempts:3 rotate single-request-reopen).

       • Si la configuration options est présente, le script vérifie si l'option single-request-reopen existe.

         • Si l'option single-request-reopen est absente, le script l'ajoute à la configuration options.

         • Si l'option single-request-reopen est présente, le script s'arrête sans modifier la configuration du serveur DNS.

• Après une utilisation prolongée d'une instance CentOS 7 ou Windows sans redémarrage, l'instance perd sa connectivité réseau, le réseau devient indisponible ou l'adresse IP publique ou privée de l'instance ne répond plus au ping. Que faire ?

  Pour connaître la cause et la solution à ce problème, consultez Vérifier et corriger le problème d'adresses IP manquantes sur les instances CentOS 7 et Windows.

• Que faire si un système d'exploitation CentOS 7.9 pour Arm ne génère pas de fichiers de vidage ?

  Description du problème

  Lorsque le système d'exploitation CentOS 7.9 pour Arm tombe en panne et que vous exécutez la commande ls /var/crash pour rechercher des fichiers de vidage, aucun fichier vmcore n'est généré.

  

  Cause

  Le système d'exploitation CentOS 7.9 pour Arm possède un noyau dans lequel l'option CONFIG_ARM64_USER_VA_BITS_52 est définie sur y pour activer l'adressage virtuel 52 bits pour l'espace utilisateur. La version du logiciel makedumpfile fournie avec le système d'exploitation ne correspond pas à la version du noyau. Par conséquent, les fichiers de vidage ne peuvent pas être générés.

  Solution

  Important

  Cette solution s'applique uniquement aux systèmes d'exploitation dont le service kdump est activé. Si le service kdump est désactivé et que vous résolvez le problème précédent comme décrit dans cette rubrique, configurez le paramètre crashkernel dans le fichier proc/cmdline.

  1. Exécutez la commande suivante pour télécharger le package kexec-tools :

     wget http://mirrors.aliyun.com/centos-vault/7.9.2009/os/Source/SPackages/kexec-tools-2.0.15-51.el7.src.rpm

  2. Exécutez la commande suivante pour installer le package RPM (RPM Package Manager) :

     rpm -ivh kexec-tools-2.0.15-51.el7.src.rpm

  3. Exécutez les commandes suivantes pour télécharger un fichier de correctif :

     cd /root/rpmbuild/SOURCES
     wget https://ecs-image-tools.oss-cn-hangzhou.aliyuncs.com/patch/rhelonly-kexec-tools-2.0.20-makedumpfile-arm64-Add-support-for-ARMv8.2-LVA-52-bi.patch

  4. Modifiez le fichier kexec-tools.spec.

     1. Exécutez les commandes suivantes pour ouvrir le fichier kexec-tools.spec :

        cd /root/rpmbuild/SPECS/
        vi kexec-tools.spec

     2. Appuyez sur la touche I pour passer en mode Insertion et ajoutez les lignes suivantes à l'emplacement approprié dans le fichier :

        Patch999: rhelonly-kexec-tools-2.0.20-makedumpfile-arm64-Add-support-for-ARMv8.2-LVA-52-bi.patch
        %patch999 -p1

        Ajoutez les lignes comme illustré dans la figure ci-dessous.

        

        

     3. Appuyez sur la touche Esc pour quitter le mode Insertion, puis saisissez :wq pour enregistrer et fermer le fichier.

  5. Exécutez la commande suivante pour vérifier les dépendances d'installation :

     yum-builddep kexec-tools.spec 

  6. Exécutez les commandes suivantes pour construire un package RPM :

     yum -y install rpm-build
     rpmbuild -ba kexec-tools.spec

  7. Exécutez les commandes suivantes pour installer le package RPM modifié :

     cd /root/rpmbuild/RPMS/aarch64
     rpm -ivh kexec-tools-2.0.15-51.el7.aarch64.rpm

  En cas de nouvelle interruption de service, vous pouvez rechercher les fichiers de vidage en exécutant la commande ls -lh /var/crash. Si un fichier vmcore a été généré, cela signifie que le problème est résolu.

  

• Comment convertir CentOS 7 en RHEL 7 ?

  CentOS 7 atteindra sa fin de vie (EOL) le 30 juin 2024. Alibaba Cloud ne fournira plus de support pour ce système d'exploitation à partir de cette date. Pour éviter les impacts de la fin de vie de CentOS 7, vous pouvez convertir CentOS 7 en RHEL 7. La section suivante décrit comment effectuer cette conversion sur Alibaba Cloud. Pour plus d'informations, consultez Converting from an RPM-based Linux distribution to RHEL.

  Important

  Pour éviter toute perte de données ou exception due à des manipulations accidentelles, nous vous recommandons d'arrêter les applications importantes, les services de base de données et les services de stockage de données, et de créer des snapshots de disque pour sauvegarder les données critiques avant la conversion.

  1. (Si nécessaire) Si vous utilisez des instances ECS sur lesquelles Server Guard est installé, désinstallez d'abord Server Guard.

     Pour plus d'informations, consultez Désinstaller l'agent.

     Remarque

     Server Guard est l'outil de renforcement de la sécurité par défaut pour CentOS. RHEL 7 utilise les outils de renforcement de la sécurité fournis par Red Hat. Server Guard peut être incompatible et entrer en conflit avec les outils de RHEL 7. Désinstallez Server Guard pendant le processus de conversion afin de garantir la stabilité et la compatibilité du système.

  2. Exécutez les commandes suivantes pour mettre à niveau les packages logiciels système vers leurs dernières versions :

     sudo wget -O /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo
     sudo wget -O /etc/yum.repos.d/epel.repo https://mirrors.aliyun.com/repo/epel-7.repo

  3. Exécutez les commandes suivantes pour mettre à jour les packages logiciels système et redémarrer le système :

     sudo yum -y update
     sudo reboot

  4. Exécutez les commandes suivantes pour télécharger l'outil convert2rhel depuis le site officiel de Red Hat et l'installer :

     sudo curl -o /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release https://www.redhat.com/security/data/fd431d51.txt
     sudo curl --create-dirs -o /etc/rhsm/ca/redhat-uep.pem https://ftp.redhat.com/redhat/convert2rhel/redhat-uep.pem
     sudo curl -o /etc/yum.repos.d/convert2rhel.repo https://ftp.redhat.com/redhat/convert2rhel/7/convert2rhel.repo
     sudo yum -y install convert2rhel

  5. Achetez un abonnement RHEL sur Alibaba Cloud et obtenez l'adresse du dépôt RPM RHEL 7.

     Pour plus d'informations, submit a ticket.

  6. Exécutez les commandes suivantes pour installer le dépôt RPM RHEL 7 :

     sudo rpm -ivh --replacefiles <RPM repository address> 
     sudo sed -i 's/enabled=1/enabled=0/g' /etc/yum.repos.d/rh-cloud.repo

     Remplacez <RPM repository address> par l'adresse réelle du dépôt RPM RHEL 7. Vous pouvez obtenir cette adresse lors de l'achat de l'abonnement RHEL.

  7. Exécutez la commande suivante pour convertir CentOS 7 en RHEL 7 :

     sudo convert2rhel -y  --no-rhsm --enablerepo rhui-rhel-7-server-rhui-rpms --enablerepo rhui-rhel-7-server-rhui-extras-rpms --enablerepo rhui-rhel-7-server-rhui-optional-rpms

     Le processus de conversion prend un certain temps. La sortie de commande suivante indique que la conversion est terminée.

     

  8. Exécutez la commande suivante pour redémarrer le système :

     Une fois la conversion terminée, un message vous invite à redémarrer le système. Redémarrez le système pour démarrer le nouveau noyau RHEL. Vérifiez ensuite si la conversion du système d'exploitation a réussi.

     sudo reboot

     Remarque

     Après avoir converti CentOS 7 en RHEL 7, si vous souhaitez mettre à niveau RHEL 7 vers RHEL 8, consultez Comment mettre à niveau Red Hat Enterprise Linux (RHEL) 7 vers RHEL 8 ?

• Les images Red Hat 8.1 et Red Hat 8.2 démarrent lentement sur les instances bare metal ECS. Que faire ?

  Lorsqu'une image Red Hat 8.1 ou Red Hat 8.2 est utilisée sur une instance bare metal ECS, le démarrage de l'image prend jusqu'à 2 minutes de plus que celui d'une image Red Hat 7. Pour résoudre ce problème, vous pouvez modifier les paramètres de démarrage du noyau de console=ttyS0 console=ttyS0,115200n8 à console=tty0 console=ttyS0,115200n8 dans le fichier /boot/grub2/grubenv de l'image Red Hat 8.1 ou Red Hat 8.2, puis redémarrer l'instance pour que la modification prenne effet.

Pourquoi la charge moyenne augmente-t-elle après le démarrage du processus Server Guard (AliYunDun) sur les instances ECS exécutant certaines versions d'Ubuntu ?

Après le démarrage du processus Server Guard sur les instances ECS exécutant certaines versions d'Ubuntu, telles qu'Ubuntu 18.04, la charge moyenne des instances augmente.

• Comment installer des correctifs et compiler le noyau sur FreeBSD ?

  Les noyaux des images publiques FreeBSD d'Alibaba Cloud sont déjà corrigés pour répondre aux exigences de démarrage des familles d'instances de série V ou ultérieures. Vous pouvez appeler l'opération DescribeInstanceTypeFamilies en spécifiant le paramètre Generation pour interroger les familles d'instances.

  Dans les scénarios suivants, vous pouvez utiliser le code source du noyau FreeBSD pour installer des correctifs et compiler le noyau afin de résoudre et prévenir l'impossibilité de démarrer l'instance :

  • Si vous utilisez une image FreeBSD non fournie par Alibaba Cloud, ou une image personnalisée dérivée d'une telle image, pour créer une instance d'une famille de série V ou ultérieure, l'instance risque de ne pas démarrer.

  • Si vous utilisez une image publique FreeBSD pour créer une instance d'une famille de série V ou ultérieure et que vous mettez à jour le noyau avec de nouveaux correctifs via freebsd-update, l'instance risque de ne pas démarrer.

  Il n'est pas nécessaire d'installer des correctifs pour FreeBSD 13 ou versions ultérieures. Dans cet exemple, FreeBSD 12.3 est utilisé pour décrire comment utiliser le code source du noyau FreeBSD pour installer des correctifs de noyau et le compiler.

  1. Téléchargez et décompressez le package de code source du noyau FreeBSD.

     wget https://mirrors.aliyun.com/freebsd/releases/amd64/12.3-RELEASE/src.txz -O /src.txz
     cd /
     tar -zxvf /src.txz

  2. Téléchargez les correctifs.

     Dans cet exemple, le correctif 0001-virtio.patch est téléchargé.

     cd /usr/src/sys/dev/virtio/
     wget https://ecs-image-tools.oss-cn-hangzhou.aliyuncs.com/0001-virtio.patch
     patch -p4 < 0001-virtio.patch

  3. Copiez les fichiers du noyau, compilez et installez le noyau.

     N dans la commande make -j<N> indique le nombre de tâches exécutées en parallèle. Définissez N en fonction de votre environnement de compilation. Par exemple, pour un environnement à un seul vCPU, nous vous recommandons de définir -j<N> sur -j2. Cela indique que le rapport entre le nombre de vCPUs et la valeur N est de 1:2.

     cd /usr/src/
     cp ./sys/amd64/conf/GENERIC .
     make -j2 buildworld KERNCONF=GENERIC
     make -j2 buildkernel KERNCONF=GENERIC
     make -j2 installkernel KERNCONF=GENERIC

  4. Après la compilation du noyau, supprimez le code source.

     rm -rf /usr/src/*
     rm -rf /usr/src/.*

• Le disque système d'une instance ECS exécutant un système d'exploitation FreeBSD est introuvable dans l'environnement KVM. Que faire ?

  Description du problème

  Lorsque vous vous connectez à une instance ECS exécutant un système d'exploitation FreeBSD dans l'environnement Kernel-based Virtual Machine (KVM) via Virtual Network Computing (VNC), le disque système de l'instance est introuvable et la connexion échoue, comme illustré dans la figure ci-dessous.

  Solution

  1. Saisissez un point d'interrogation (?) dans l'interface VNC pour afficher l'ufsid du système de fichiers racine.

  2. Saisissez ufs:/dev/ufsid/5565b5a09045**** et appuyez sur la touche Entrée pour accéder au système d'exploitation.

  3. Saisissez un nom d'utilisateur et un mot de passe pour vous connecter au système.

  4. Exécutez la commande suivante pour vérifier les configurations dans le fichier /etc/fstab :

     cat /etc/fstab

     La sortie de commande illustrée dans la figure ci-dessous indique que le système de fichiers racine est configuré pour être monté en fonction d'un UUID dans le fichier /etc/fstab. Cependant, les systèmes d'exploitation FreeBSD ne prennent pas en charge le montage des périphériques basé sur les UUID. Vous devez configurer le système de fichiers racine pour qu'il soit monté en fonction de l'ufsid.

  5. Configurez le système de fichiers racine pour qu'il soit monté en fonction de l'ufsid.

     1. Exécutez la commande suivante pour ouvrir le fichier /etc/fstab :

        vi /etc/fstab

     2. Appuyez sur la touche I pour passer en mode Insertion.

     3. Remplacez UUID=5565b5a09045**** par /dev/ufsid/5565b5a09045****.

     4. Appuyez sur la touche Esc, saisissez :wq, puis appuyez sur la touche Entrée pour enregistrer la modification et quitter.

  6. Exécutez la commande suivante pour redémarrer le système et appliquer la modification :

     reboot 

• Pourquoi ne puis-je pas utiliser une paire de clés SSH utilisant l'algorithme de signature ssh-rsa pour me connecter à une instance ECS exécutant Fedora 33 64 bits ?

  Lorsque vous utilisez une paire de clés SSH basée sur l'algorithme de signature ssh-rsa pour vous connecter à une instance ECS exécutant Fedora 33 64 bits, la connexion peut échouer. Vous pouvez utiliser l'une des méthodes suivantes pour résoudre ce problème :

  • Remplacez la paire de clés SSH utilisant l'algorithme de signature ssh-rsa par une paire utilisant un autre algorithme de signature, tel que l'Elliptic Curve Digital Signature Algorithm (ECDSA).

  • Exécutez la commande update-crypto-policies --set LEGACY sur le système pour définir POLICY sur LEGACY. Vous pourrez alors continuer à utiliser la paire de clés SSH basée sur l'algorithme de signature ssh-rsa.

• Après avoir créé une instance d'une certaine famille à l'aide d'une image Fedora CoreOS, j'ai constaté que le nombre de processeurs indiqué par la commande lscpu n'est que la moitié du nombre de vCPUs du type d'instance sélectionné. Pourquoi ?

  Après avoir utilisé une image Fedora CoreOS pour créer une instance d'une famille spécifique, telle que g5, vous avez exécuté la commande lscpu sur l'instance pour afficher les informations CPU. Dans la sortie de commande, le nombre total de vCPUs indiqué par la valeur On-line CPU(s) list ne représente que la moitié du nombre de vCPUs du type d'instance sélectionné. Par exemple, si un type d'instance disposant de deux vCPUs est utilisé pour créer une instance, la valeur On-line CPU(s) list n'indique qu'un seul vCPU, comme illustré dans la figure ci-dessous.

  Remarque

  La valeur On-line CPU(s) list indique les numéros de série des vCPUs. Dans la figure précédente, seul un vCPU dont le numéro de série est 0 est disponible.

  Cela s'explique par le fait que, dans le noyau Fedora CoreOS, le paramètre de démarrage mitigations est défini par défaut sur auto,nosmt pour désactiver le multithreading simultané (SMT) sur les systèmes vulnérables. Pour afficher le paramètre mitigations défini sur auto,nosmt, vous pouvez exécuter la commande cat /proc/cmdline.

  Pour plus d'informations sur le SMT, consultez Automatically disable SMT when needed to address vulnerabilities et Policy for disabling SMT.

• Que faire si le service kdump ne parvient pas à générer des fichiers de vidage de plantage sur une instance bare metal ECS ?

  Pour connaître la cause et la solution à ce problème, consultez Que faire si la génération de fichiers de vidage de plantage échoue sur certaines instances ECS ?

• Une erreur softlockup se produit lors du processus de writeback du noyau du système d'exploitation Linux. Que faire ?

  Une erreur softlockup survient lorsque certaines versions antérieures du noyau Linux écrivent des données dans les caches de fichiers. Pour savoir comment résoudre ce problème, consultez Solution au problème de softlockup lors du processus de writeback du noyau du système d'exploitation Linux.

• Une erreur softlockup se produit lorsque je supprime des cgroups d'une instance ECS. Que faire ?

  Pour savoir comment résoudre ce problème, consultez Une erreur softlockup se produit lorsque je supprime des cgroups dans une instance ECS. Que faire ?

• Une instance ECS tombe en panne. Que faire ?

  • Une instance ECS tombe en panne et le message d'erreur « Out of memory and no killable processes » s'affiche. Que faire ?

  • Une instance ECS tombe en panne et le message « Objects remaining in kmalloc » apparaît dans un journal d'alerte. Que faire ?

  • Une instance ECS tombe en panne et le message d'erreur « RIP:get_target_pstate_use_performance » apparaît dans un journal. Que faire ?

  • Une instance ECS tombe en panne et le message « VFS: Unable to mount root fs on unknown-block » apparaît dans un journal. Que faire ?

• Le service FTP est-il inclus dans les images publiques ?

  Non, le service FTP n'est pas inclus dans les images publiques. Vous devez configurer le service FTP vous-même. Pour plus d'informations, consultez Créer manuellement un site FTP sur une instance Windows et Créer manuellement un site FTP sur une instance CentOS 7.

• Pourquoi ECS désactive-t-il la mémoire virtuelle et laisse-t-il les partitions swap non configurées par défaut ?

  Lorsque la mémoire physique est insuffisante, le gestionnaire de mémoire enregistre les données mémoire inactives depuis longtemps dans une partition swap ou un fichier de mémoire virtuelle. Ce mécanisme permet d'augmenter la quantité de mémoire disponible.

  Toutefois, si l'utilisation de la mémoire est déjà élevée et que les performances d'E/S sont faibles, ce mécanisme réduit au contraire la quantité de mémoire disponible. Les disques cloud ECS utilisent des systèmes de fichiers distribués pour le stockage et fournissent plusieurs répliques fortement cohérentes pour chaque donnée. Ce mécanisme garantit la sécurité des données utilisateur, mais détériore les performances de stockage et d'E/S des disques locaux en triplant le nombre d'opérations d'E/S.

  Par conséquent, la mémoire virtuelle est désactivée sous Windows et les partitions swap ne sont pas configurées sous Linux par défaut, afin d'éviter une nouvelle diminution des performances d'E/S lorsque les ressources système sont insuffisantes.

• Comment activer le service kdump dans une image publique ?

  Par défaut, le service kdump est désactivé dans les images publiques. Si vous souhaitez qu'une instance génère un fichier core lors d'une panne afin d'analyser la cause de la défaillance, vous pouvez activer le service kdump en suivant les étapes ci-dessous. Dans l'exemple suivant, l'image publique CentOS 7.2 est utilisée. Les opérations peuvent varier selon la version de votre système d'exploitation.

  1. Configurez le répertoire dans lequel générer le fichier core.

     1. Run the vim /etc/kdump.conf command to open the kdump configuration file.

     2. Exécutez la commande path pour configurer le répertoire dans lequel générer le fichier core. Dans cet exemple, le répertoire est /var/crash, et la commande path suivante est utilisée :

        path /var/crash

     3. Enregistrez et fermez le fichier /etc/kdump.conf.

  2. Activez le service kdump.

     Utilisez l'une des méthodes suivantes selon le système d'exploitation pour activer le service kdump :

     • Méthode 1 : Exécutez les commandes suivantes pour activer le service kdump :

       systemctl enable kdump.service

       systemctlstartkdump.service

     • Méthode 2 : Exécutez les commandes suivantes pour activer le service kdump :

       chkconfig kdump on

       service kdump start

     • Méthode 3 : Si Cloud Assistant est installé sur votre instance, activez le service kdump en suivant les instructions de Comment résoudre les problèmes de temps d'arrêt des instances migrées ? Activez le service kdump.

• Après l'attribution d'une adresse IPv6 à une instance Linux sur laquelle le service NTP est installé, l'heure de l'instance ne peut pas être synchronisée avec l'heure UTC. Que faire ?

  Description du problème

  Après avoir exécuté la commande ntpq -p sur l'instance Linux pour synchroniser l'heure, une erreur de délai d'expiration se produit, comme illustré dans la figure ci-dessous.

  Solution

  Remarque

  Cette solution s'applique aux instances exécutant les systèmes d'exploitation suivants : CentOS 7 et versions antérieures, Ubuntu 20.04 et versions antérieures, Anolis OS RHCK, Anolis OS ANCK, Alibaba Cloud Linux et Debian.

  1. Connectez-vous à l'instance Linux.

     Pour plus d'informations, consultez Se connecter à une instance Linux à l'aide d'un mot de passe ou d'une clé.

  2. Exécutez la commande suivante pour modifier le fichier de configuration /etc/ntp.conf :

     vi /etc/ntp.conf

  3. Appuyez sur la touche I pour passer en mode Insertion.

  4. Ajoutez restrict -6 ::1 au fichier, comme illustré dans la figure ci-dessous.

  5. Appuyez sur la touche Esc. Saisissez ensuite :wq et appuyez sur la touche Entrée pour enregistrer la modification et quitter.

  6. Exécutez la commande suivante pour redémarrer le service NTP :

     systemctl restart ntp 

• Je ne peux pas remplacer à chaud les disques ou les ENI pour une instance en cours d'exécution utilisant une image personnalisée. Pourquoi ?

  Description du problème

  Le remplacement à chaud de disques ou d'interfaces réseau élastiques (ENI) implique les actions d'attacher des disques, de détacher des disques, de lier des ENI et de dissocier des ENI d'une instance dont l'état est Running. Vous ne pouvez pas effectuer de remplacement à chaud de disques ou d'ENI pour une instance Running utilisant une image personnalisée.

  Vous pouvez effectuer un remplacement à chaud de disques et d'ENI pour les instances sur Alibaba Cloud. Toutefois, une opération de remplacement à chaud peut échouer si le noyau du système d'exploitation de l'instance ne prend pas en charge cette opération. Si le noyau du système d'exploitation de l'instance ne prend pas en charge l'opération, les problèmes suivants peuvent survenir :

  • Après avoir attaché un disque ou lié une ENI à une instance, le disque ou l'ENI est introuvable dans le système d'exploitation.

  • Vous ne pouvez pas détacher un disque ou dissocier une ENI d'une instance.

  Solution

  Les noyaux des systèmes d'exploitation des instances ECS et des instances bare metal ECS prennent en charge différentes fonctionnalités pour permettre le remplacement à chaud. Nous vous recommandons d'activer les fonctionnalités de remplacement à chaud Peripheral Component Interconnect (PCI) et Advanced Configuration and Power Management Interface (ACPI) dans les noyaux des systèmes d'exploitation de toutes vos instances. Par défaut, le remplacement à chaud PCI et ACPI est activé dans tous les systèmes d'exploitation, à l'exception des versions anciennes telles que CentOS 5. Procédez comme suit pour vérifier si le remplacement à chaud PCI ou ACPI est activé dans le noyau :

  1. Connectez-vous à l'instance Linux.

     Pour plus d'informations, consultez Se connecter à une instance Linux à l'aide d'un mot de passe ou d'une clé.

  2. Exécutez la commande suivante pour afficher la version du noyau de l'instance :

     uname -r

     La sortie de commande illustrée dans la figure ci-dessous indique que la version du noyau est 3.10.0-1127.19.1.el7.x86_64.

     

  3. Exécutez la commande suivante pour vérifier les fichiers dans le répertoire /boot :

     ll /boot

     L'information config-3.10.0-1127.19.1.el7.x86_64 affichée dans la sortie de commande indique que le fichier config-3.10.0-1127.19.1.el7.x86_64 est le fichier de configuration du noyau système.

     

  4. Exécutez la commande suivante pour vérifier la configuration du noyau système :

     cat /boot/config-3.10.0-1127.19.1.el7.x86_64

     • Si les éléments de configuration suivants sont définis sur y, le système d'exploitation prend en charge les fonctionnalités de remplacement à chaud :

       CONFIG_HOTPLUG_PCI_PCIE=y
       CONFIG_HOTPLUG_PCI=y
       CONFIG_HOTPLUG_PCI_ACPI=y

     • Si l'un des éléments de configuration suivants est défini sur is not set, la fonctionnalité de remplacement à chaud correspondante n'est pas prise en charge par le noyau et vous devez modifier la configuration du noyau.

     • Si l'un des éléments de configuration suivants est défini sur m, l'élément de configuration est compilé en tant que module. Par exemple, l'élément de configuration CONFIG_HOTPLUG_PCI_ACPI est défini sur m, comme illustré dans la figure ci-dessous. Cela indique que CONFIG_HOTPLUG_PCI_ACPI est compilé en tant que module. Vous devez charger le module pour utiliser la fonctionnalité correspondante.

       CONFIG_HOTPLUG_PCI_PCIE=y
       CONFIG_HOTPLUG_PCI=y
       CONFIG_HOTPLUG_PCI_ACPI=m

       Par exemple, si vous utilisez un système d'exploitation CentOS 5.x avec un noyau de version 2.6, le module correspondant à l'élément de configuration CONFIG_HOTPLUG_PCI_ACPI est acpiphp.ko. Pour charger le module, vous devez exécuter la commande modprobe acpiphp. Si le chargement du module échoue, effectuez une mise à niveau vers une version de noyau ultérieure ou arrêtez l'instance, puis effectuez les opérations de remplacement à chaud.

       Important

       Nous vous recommandons de ne pas modifier arbitrairement les versions du noyau ou du système d'exploitation des instances. Pour savoir comment mettre à niveau la version du noyau, consultez Comment éviter les échecs de démarrage lors de la mise à niveau du noyau d'une instance Linux.

• Que faire si une instance s'arrête après une erreur du noyau du système d'exploitation ?

  Description du problème

  Lorsqu'une erreur inattendue du noyau (kernel panic) se produit au sein du système d'exploitation d'une instance, un second noyau (capture kernel) est chargé pour effectuer un vidage mémoire et générer un fichier journal Kdump. En raison de problèmes de compatibilité avec le type d'instance Bare Metal ECS, l'identification du disque échoue lors du démarrage du second noyau. Par conséquent, la collecte des journaux Kdump échoue et le second noyau ne parvient pas à démarrer. L'instance passe à l'état Stopped. Vous devez redémarrer l'instance dans la console ECS.

  Pour plus d'informations sur les types d'instances Bare Metal ECS, consultez Présentation des familles d'instances.

  Cause

  Les instances bare metal ECS peuvent ne pas parvenir à générer des fichiers de vidage à l'aide du service Kdump fourni avec les systèmes d'exploitation.

  • Ce problème survient lorsque vous utilisez les images suivantes pour les instances bare metal ECS de 6e génération.

    • CentOS 8.3 ou version antérieure

    • Ubuntu 16 ou 18

    • Debian 10

    • Alibaba Cloud Linux 2 avec des versions de noyau antérieures à 4.19.91-24.al7 (Ce problème est corrigé dans Alibaba Cloud Linux 2 à partir de la version de noyau 4.19.91-24.al7.)

  • Ce problème survient lorsque vous sélectionnez une image Debian 10 pour les instances bare metal ECS de 7e génération.

  Solution

  • Images CentOS

    Nous vous recommandons de remplacer le système d'exploitation par une version ultérieure. Pour plus d'informations, consultez Remplacer le système d'exploitation (remplacer le disque système).

  • Images Alibaba Cloud Linux 2

    Nous vous recommandons d'effectuer les étapes suivantes pour mettre à niveau la version du noyau vers 4.19.91-24.al7 ou une version ultérieure :

    1. Connectez-vous à l'instance.

       Pour plus d'informations, consultez Se connecter à une instance Linux à l'aide d'un mot de passe ou d'une clé.

    2. Exécutez la commande suivante pour interroger la version du noyau :

       uname -r

    3. Exécutez la commande suivante pour mettre à niveau la version du noyau :

       sudo yum update kernel

    4. Exécutez la commande suivante pour redémarrer l'instance ECS afin que la nouvelle version du noyau prenne effet :

       sudo reboot