Quelles étapes dois-je suivre avant de modifier le type de mon instance EC2 Linux ?

Dernière mise à jour : 13/09/2021

Mon système nécessite plus de CPU ou de mémoire que ce qui est disponible sur mon instance Amazon Elastic Compute Cloud (Amazon EC2) actuelle. Quelles étapes dois-je suivre avant de redimensionner mon instance pour m'assurer que la transition soit réussie ?

Brève description

La modification du type d'instance de votre instance EC2 Linux vous permet de modifier les éléments suivants :

  • Nombre de cœurs de processeur
  • Quantité de mémoire RAM
  • Quantité d'espace de stockage d'instance affecté
  • Optimisation d'Amazon Elastic Block Store (Amazon EBS)
  • Réseaux améliorés
  • Cœurs GPU
  • FPGA
  • Accélérateurs de Machine Learning

Remarque : une bonne pratique consiste à conserver des sauvegardes de vos instances et de vos données. Envisagez de créer une image AMI ou des instantanés des volumes EBS avant de modifier votre infrastructure.

Solution

Avant de modifier les types d'instances ou les familles d'instances, vérifiez que le type d'instance actuel et le nouveau type d'instance sont compatibles. Les problèmes courants suivants entraînent des problèmes de compatibilité lors de la modification des types d'instances. Pour obtenir la liste complète des problèmes de compatibilité, consultez Compatibilité pour le changement de type d'instance.

Après avoir vérifié la compatibilité, vous pouvez modifier le type de votre instance basée sur Amazon EBS.

Arrêter votre instance

Vous devez arrêter l'instance avant de modifier les types d'instance. Avant d'arrêter votre instance, assurez-vous de bien comprendre les informations suivantes :

  • Les données sont perdues lorsque vous arrêtez l'instance si votre instance est basée sur le stockage d'instance ou dispose de volumes de stockage d'instance contenant des données. Si vous passez d'une instance basée sur le stockage d'instance à une autre instance basée sur le stockage d'instance, vous devez migrer votre instance basée sur le stockage d'instance. Pour en savoir plus, consultez Migration d'une instance basée sur le stockage d'instance.
  • L'arrêt de l'instance peut mettre l'instance hors service si celle-ci fait partie d'un groupe Amazon EC2 Auto Scaling. Votre instance peut faire partie d'un groupe Auto Scaling d'AWS si vous l'avez lancée avec Amazon EMR, AWS CloudFormation ou AWS Elastic Beanstalk. Dans ce cas, sa hors service dépend des paramètres de protection de mise à l’échelle horizontale définis pour votre groupe Auto Scaling. Si votre instance fait partie d'un groupe Auto Scaling, supprimez-la temporairement du groupe avant d'exécuter les étapes de résolution.
  • Si vous n'utilisez pas d'adresse IP Elastic, l'arrêt et le démarrage de l'instance modifient son adresse IP publique. Il est recommandé d'utiliser une adresse IP Elastic, et non publique pour l'acheminement du trafic externe vers votre instance. Si vous utilisez Route 53, il peut être nécessaire de mettre à jour les enregistrements DNS Route 53 lorsque l'adresse IP publique change.

Réseaux améliorés

Si vous convertissez vers une instance qui prend en charge les réseaux améliorés, installez tous les pilotes requis et activez les réseaux améliorés sur votre instance actuelle. Pour en savoir plus, consultez Réseaux améliorés sur Linux.

Types d'instances basés sur Nitro

Si vous envisagez de remplacer votre instance par un type d'instance Nitro, procédez comme suit :

  • Vérifiez que les modules NVMe et ENA sont installés sur votre instance.
  • Vérifiez que tous les périphériques de stockage en mode bloc répertoriés dans /etc/fstab sont compatibles avec les noms de périphériques de stockage en mode bloc NVMe (/dev/nvme1, /dev/nvme2, etc.).
  • Les volumes Amazon Elastic Block Store (Amazon EBS) sont présentés comme périphériques NVMe à ces types d'instances, et les noms de périphériques sont modifiés. Pour éviter les erreurs de correspondance des volumes, montez les systèmes de fichiers à l'aide des UUID ou des étiquettes du système de fichiers.

Pour automatiser ces vérifications, exécutez le script NitroInstanceChecks. Pourquoi l'instance Linux ne démarre-t-elle pas après que j'ai remplacé son type par un type d'instance basé sur Nitro ? Suivez les instructions de la section Exécuter le script NitroInstanceChecks.

Après avoir exécuté et effectué toutes les mises à jour nécessaires, vérifiez que l'entrée DRIVERS dans /etc/udev/rules.d/70-persistent-net.rules a la valeur ? ou ENA.

Utilisez un éditeur de texte pour accéder au fichier. L'exemple suivant utilise l'éditeur vi.

vi /etc/udev/rules.d/70-persistent-net.rules

L'entrée correcte s'affiche comme suit :

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="01:23:45:67:89:ab", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0

Réseaux sur les instances de la génération actuelle

Les instances de la génération actuelle sont lancées uniquement dans un Virtual Private Cloud (VPC). Si votre instance actuelle est une instance EC2-Classic, migrez l'instance vers une instance Linux dans un VPC.

Combinaison des architectures EC2

Si l'AMI source de votre instance est conçue pour une architecture spécifique, vous êtes limité à la création de types d'instances de la même architecture. Des exemples d'AMI conçues pour une architecture spécifique peuvent inclure ARM 32 bits (i386), 64 bits (x86_64) ou 64 bits (arm64). C'est également le cas si votre instance exécute une AMI créée pour le type d'instance mac1. Vous ne pouvez pas déplacer ces images entre les types d'instances.