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.
Configurer les politiques de résiliation pour Amazon EC2 Auto Scaling
Une politique de résiliation fournit les critères qu'Amazon EC2 Auto Scaling suit pour mettre fin aux instances dans un ordre spécifique. Par défaut, Amazon EC2 Auto Scaling utilise une politique de résiliation conçue pour mettre fin d'abord aux instances qui utilisent des configurations obsolètes. Vous pouvez modifier la politique de résiliation afin de contrôler les instances les plus importantes à résilier en premier.
Lorsqu'Amazon EC2 Auto Scaling met fin à des instances, il essaie de maintenir l'équilibre entre les zones de disponibilité activées pour votre groupe Auto Scaling. Le maintien de l'équilibre zonal prime sur la politique de résiliation. Si une zone de disponibilité comporte plus d'instances que d'autres, Amazon EC2 Auto Scaling applique d'abord la politique de résiliation à la zone déséquilibrée. Si les zones de disponibilité sont équilibrées, la politique de résiliation s'applique à toutes les zones.
Rubriques
Comment fonctionne la politique de résiliation par défaut
Lorsqu'Amazon EC2 Auto Scaling doit mettre fin à une instance, il identifie d'abord la zone de disponibilité (ou les zones) qui possède le plus grand nombre d'instances et au moins une instance qui n'est pas protégée contre le scaling in. Il procède ensuite à l'évaluation des instances non protégées au sein de la zone de disponibilité identifiée comme suit :
Instances utilisant des configurations obsolètes
-
Pour les groupes qui utilisent un modèle de lancement : déterminez si l'une des instances utilise des configurations obsolètes, en hiérarchisant dans cet ordre :
-
Vérifiez d'abord les instances lancées avec une configuration de lancement.
-
Vérifiez ensuite si les instances ont été lancées à l'aide d'un modèle de lancement différent du modèle de lancement actuel.
-
Enfin, vérifiez les instances utilisant la version la plus ancienne du modèle de lancement actuel.
-
-
Pour les groupes utilisant une configuration de lancement : déterminez si l'une des instances utilise la configuration de lancement la plus ancienne.
Si aucune instance avec des configurations obsolètes n'est trouvée, ou s'il existe plusieurs instances parmi lesquelles choisir, Amazon EC2 Auto Scaling prend en compte le prochain critère selon lequel les instances approchent de leur prochaine heure de facturation.
Instances approchant de l'heure de facturation suivante
Déterminez si l'une des instances répondant aux critères précédents est la plus proche de l'heure de facturation suivante. Si plusieurs instances sont également proches, arrêtez-en une au hasard. Cela vous permet d'optimiser l'utilisation de vos instances facturées à l'heure. Cependant, la majeure partie de EC2 l'utilisation est désormais facturée à la seconde, de sorte que cette optimisation offre moins d'avantages. Pour plus d'informations, consultez les EC2tarifs Amazon
L'organigramme suivant illustre le fonctionnement de la politique de résiliation par défaut pour les groupes qui utilisent un modèle de lancement.
Politique de résiliation par défaut et groupes d'instances mixtes
Amazon EC2 Auto Scaling applique des critères supplémentaires lors de la résiliation d'instances dans des groupes d'instances mixtes.
Lorsqu'Amazon EC2 Auto Scaling doit mettre fin à une instance, il identifie d'abord quelle option d'achat (spot ou On-Demand) doit être résiliée en fonction des paramètres du groupe. Cela garantit que le groupe évolue vers le ratio spécifié d'instances ponctuelles et à la demande au fil du temps.
Il applique ensuite la politique de résiliation indépendamment au sein de chaque zone de disponibilité. Il détermine quelle instance ponctuelle ou à la demande dans quelle zone de disponibilité mettre fin afin de maintenir l'équilibre des zones de disponibilité. La même logique s'applique à un groupe d'instances mixte avec des pondérations définies pour les types d'instances.
Dans chaque zone, la politique de résiliation par défaut fonctionne comme suit pour déterminer quelle instance non protégée peut être résiliée dans le cadre de l'option d'achat identifiée :
-
Déterminez si l'une des instances peut être interrompue afin d'améliorer l'alignement avec la stratégie d'allocation spécifiée pour le groupe Auto Scaling. Si aucune instance n'est identifiée pour l'optimisation, ou s'il existe plusieurs instances parmi lesquelles choisir, l'évaluation se poursuit.
-
Déterminez si l'une des instances utilise des configurations obsolètes, en hiérarchisant dans cet ordre :
-
Vérifiez d'abord les instances lancées avec une configuration de lancement.
-
Vérifiez ensuite si les instances ont été lancées à l'aide d'un modèle de lancement différent du modèle de lancement actuel.
-
Enfin, vérifiez les instances utilisant la version la plus ancienne du modèle de lancement actuel.
Si aucune instance avec des configurations obsolètes n'est trouvée, ou s'il existe plusieurs instances parmi lesquelles choisir, l'évaluation se poursuit.
-
-
Déterminez si l'une des instances est la plus proche de l'heure de facturation suivante. Si plusieurs instances sont également proches, choisissez-en une au hasard.
Politiques de résiliation prédéfinies
Vous avez le choix entre les politiques de résiliation prédéfinies suivantes :
-
Default— Mettez fin aux instances conformément à la politique de résiliation par défaut. -
AllocationStrategy— Mettez fin aux instances du groupe Auto Scaling pour aligner les instances restantes sur la stratégie d'allocation pour le type d'instance en cours de résiliation (instance ponctuelle ou instance à la demande). Cette politique est utile lorsque vous préférez les types d'instances ayant changé. Si la politique d'allocation Spot estlowest-price, vous pouvez progressivement rééquilibrer la distribution d'instances Spot entre vos groupes Spot ayant le prix le plus bas. Si la politique d'allocation Spot estcapacity-optimized, vous pouvez progressivement rééquilibrer la distribution d'instances Spot entre vos groupes Spot ayant la capacité Spot disponible.la plus élevée. Vous pouvez également remplacer progressivement les instances à la demande ayant un type de priorité inférieur par les instances à la demande ayant un type de priorité supérieur. -
OldestLaunchTemplate— Mettez fin aux instances dont le modèle de lancement est le plus ancien. Avec cette politique, les instances qui utilisent le modèle de lancement non courant sont mises hors service en premier, suivies des instances qui utilisent la plus ancienne version du modèle de lancement actuel. Cette politique est utile lorsque vous mettez à jour un groupe et supprimez les instances d'une configuration précédente. -
OldestLaunchConfiguration— Mettez fin aux instances dont la configuration de lancement est la plus ancienne. Cette politique est utile lorsque vous mettez à jour un groupe et supprimez les instances d’une configuration précédente. Avec cette politique, les instances qui utilisent la configuration de lancement non courant sont mises hors service en premier. -
ClosestToNextInstanceHour— Résiliez les instances les plus proches de l'heure de facturation suivante. Cette politique vous permet d'optimiser l'utilisation de vos instances qui ont un tarif horaire. -
NewestInstance— Mettez fin à l'instance la plus récente du groupe. Cette politique est utile lorsque vous testez une nouvelle configuration de lancement mais ne souhaitez pas la garder en production. -
OldestInstance— Mettez fin à la plus ancienne instance du groupe. Cette option est utile lorsque vous mettez à niveau les instances du groupe Auto Scaling vers un nouveau type d'EC2instance. Vous pouvez petit à petit remplacer les anciennes instances par des nouvelles.Note
Amazon EC2 Auto Scaling équilibre toujours d'abord les instances entre les zones de disponibilité, quelle que soit la politique de résiliation utilisée. Par conséquent, vous pouvez rencontrer des situations dans lesquelles certaines instances plus récentes sont résiliées avant les instances plus anciennes. Par exemple, lorsqu'une zone de disponibilité est ajoutée plus récemment ou lorsqu'une zone de disponibilité possède plus d'instances que celles qui sont utilisées par le groupe.
