Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Comment fonctionne la maintenance des hôtes Amazon EC2 Dedicated Hosts

Lorsqu'une dégradation est détectée sur un hôte dédié activé pour la maintenance de l'hôte, nous allouons automatiquement un hôte dédié de remplacement sur votre compte. L’Hôte dédié de remplacement reçoit un nouvel ID d’hôte, mais conserve les mêmes attributs que l’Hôte dédié d’origine, en particulier :

Une fois que l'hôte de remplacement a été attribué, nous migrons les instances en utilisant soit la maintenance de l'hôte de migration en direct, soit la maintenance de l'hôte basée sur le redémarrage, selon l'instance.

Une fois que l'hôte dégradé n'a plus d'instance en cours d'exécution, il est définitivement supprimé de votre compte.

Instances prenant en charge la maintenance de l'hôte de migration en direct

Les instances qui prennent en charge la maintenance de l'hôte de migration en direct sont automatiquement migrées vers l'hôte de remplacement dans les 24 heures, sans les arrêter ni les redémarrer. Les instances migrées conservent leurs attributs existants, notamment :

Une fois que les types d'instances pris en charge ont été automatiquement migrés vers l'hôte de remplacement, nous vous envoyons des notifications par e-mail et sur le tableau de AWS Health bord qui incluent les hôtes dégradés et IDs de remplacement, des informations sur les instances qui ont été migrées automatiquement à l'aide de la maintenance de l'hôte de migration en direct, ainsi que des informations sur les instances restantes.

Instances nécessitant une maintenance de l'hôte basée sur le redémarrage

Les instances qui nécessitent une maintenance de l'hôte basée sur le redémarrage sont planifiées pour les événements planifiés de redémarrage des instances pendant 14 jours à compter de la date de notification. Vous pouvez continuer à accéder à vos instances sur l'hôte dédié dégradé avant l'événement planifié.

Amazon réserve EC2 automatiquement de la capacité sur l'hôte de remplacement pour ces instances. Vous ne pouvez pas exécuter d'instances dans cette capacité réservée.

À la date et à l'heure de l'événement planifié, les instances sont automatiquement arrêtées et redémarrées dans la capacité réservée sur l'hôte de remplacement. Les instances migrées conservent leurs attributs existants, notamment :

Toutefois, étant donné que les instances sont arrêtées et redémarrées pendant la migration, elles ne conservent pas leur mémoire ni leur état réseau. CPU

Vous pouvez également arrêter et redémarrer manuellement ces instances à tout moment avant l'événement planifié pour les faire migrer vers l'hôte de remplacement ou vers un autre hôte. Vous devrez peut-être modifier l'affinité d'hôte de votre instance pour la redémarrer sur un autre hôte. Si vous arrêtez une instance avant l'événement planifié, la capacité réservée sur l'hôte de remplacement est libérée et peut être utilisée.

Instances non prises en charge

Certaines instances ne peuvent pas être migrées automatiquement vers l'hôte de remplacement.

Instances dotées de volumes racine sauvegardés par le stockage d'instances

Dans ces cas, nous programmons des événements de mise à la retraite pendant 28 jours à compter de la date de notification. À la date et à l'heure de l'événement planifié, les instances sont définitivement arrêtées. Nous vous recommandons de lancer manuellement les instances de remplacement sur l'hôte de remplacement, puis de migrer les données requises vers les instances de remplacement avant l'événement planifié.

Instances avec des EBS volumes racine sauvegardés

Dans ces cas, nous programmons des événements d'arrêt d'instance pendant 28 jours à compter de la date de notification. À la date et à l'heure de l'événement planifié, les instances sont arrêtées. Nous vous recommandons d'arrêter manuellement au redémarrage de l'instance sur l'hôte de remplacement ou sur un autre hôte. Vous devrez peut-être modifier l'affinité d'hôte de votre instance pour la redémarrer sur un autre hôte.

Vous pouvez continuer à accéder à vos instances sur l'hôte dédié dégradé avant l'événement planifié.

États de la maintenance de l’hôte

Lorsqu'un hôte se dégrade, il entre dans permanent-failure cet état. Vous ne pouvez pas lancer d'instances sur un hôte dédié qui est dans permanent-failure cet état.

Une fois que l'hôte de remplacement est alloué, il reste dans pending cet état jusqu'à ce que les instances prenant en charge la maintenance de l'hôte de migration en direct soient automatiquement migrées depuis l'hôte dégradé, et jusqu'à ce que les événements planifiés soient planifiés pour les instances restantes. Une fois cette opération terminée, l'hôte de remplacement entre dans l'availableétat.

Une fois que l'hôte de remplacement est entré dans available l'État, vous pouvez l'utiliser de la même manière que n'importe quel hôte de votre compte. Toutefois, une partie de la capacité d'instance de l'hôte de remplacement est réservée aux instances qui nécessitent une migration d'hôte basée sur le redémarrage. Vous ne pouvez pas lancer de nouvelles instances dans cette capacité réservée.

Lorsque l'hôte dégradé n'a plus d'instances en cours d'exécution, il entre dans l'released, permanent-failureétat et est définitivement supprimé de votre compte.