Lancer des instances de manière synchrone - Amazon EC2 Auto Scaling
Provisionnement synchrone et dimensionnement asynchroneLimites et considérations

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.

Lancer des instances de manière synchrone

Amazon EC2 Auto Scaling propose deux méthodes pour lancer des instances dans votre groupe Auto Scaling : le comportement de dimensionnement asynchrone et le provisionnement synchrone à l'aide de l'API. LaunchInstances

Avec le provisionnement synchrone, vous utilisez l' LaunchInstances API pour demander un nombre spécifique d'instances dans une zone de disponibilité donnée. Le provisionnement synchrone offre les avantages suivants :

  • Feedback immédiat sur la disponibilité des capacités dans des zones de disponibilité spécifiques

  • Contrôle précis des instances de zone de disponibilité lancées dans

  • Instance déterministe IDs pour une utilisation immédiate dans les systèmes d'orchestration

  • Décisions de dimensionnement en temps réel basées sur les contraintes de capacité réelles

  • Mise à l'échelle plus rapide en éliminant les temps d'attente pour les lancements asynchrones d'Auto Scaling

Avec Auto Scaling asynchrone, lorsque vous modifiez la capacité souhaitée ou lorsqu'une politique de dimensionnement se déclenche, Amazon EC2 Auto Scaling traite la demande de dimensionnement et lance les instances en arrière-plan. Vous devez surveiller les activités de dimensionnement ou décrire votre groupe Auto Scaling pour déterminer à quel moment les instances sont lancées avec succès.

Note

  • L' LaunchInstances API fonctionne uniquement avec les groupes Auto Scaling qui utilisent des modèles de lancement. Les groupes Auto Scaling qui utilisent des configurations de lancement ne sont pas pris en charge. Si votre groupe Auto Scaling utilise une configuration de lancement, vous devez migrer vers un modèle de lancement avant d'utiliser le provisionnement synchrone.

  • L' LaunchInstances API prend en charge les politiques relatives aux instances mixtes avec des options d'achat entièrement à la demande ou entièrement ponctuelles uniquement. Les politiques mixtes combinant à la fois des instances à la demande et des instances ponctuelles ne sont pas prises en charge.

  • Pour les groupes Auto Scaling couvrant plusieurs zones de disponibilité, vous devez spécifier la zone de disponibilité ou le sous-réseau cible. Pour les groupes mono-AZ, ce paramètre est facultatif.

Provisionnement synchrone et dimensionnement asynchrone

Provisionnement synchrone

Lorsque vous utilisez l' LaunchInstances API, Amazon EC2 Auto Scaling :

  • Tente immédiatement de lancer les instances demandées en utilisant CreateFleet

  • Attend de renvoyer CreateFleet l'instance IDs avant de répondre

  • Renvoie les informations relatives à IDs l'instance, aux types d'instances et à la zone de disponibilité en cas de réussite

  • Renvoie des codes d'erreur spécifiques et des informations sur les défaillances

  • Fournit un feedback immédiat, permettant de prendre des décisions de dimensionnement en temps réel

Mise à l'échelle asynchrone

Lorsque vous utilisez des méthodes Auto Scaling asynchrones, telles que la modification de la capacité souhaitée ou l'utilisation de politiques de dimensionnement, Amazon EC2 Auto Scaling :

  • Met à jour la capacité souhaitée dans l'API mais ne renvoie pas les instances immédiatement

  • Planifie automatiquement les lancements d'instances dans les zones de disponibilité

  • Lance des instances via des flux de travail en arrière-plan

  • Répartit automatiquement la capacité entre plusieurs zones de disponibilité à des fins d'équilibre

  • Gère les échecs de lancement grâce à une logique de nouvelle tentative intégrée

Vous devez interroger les activités de dimensionnement ou décrire votre groupe Auto Scaling pour vérifier l'état des opérations de lancement.

Limites et considérations

Lorsque vous utilisez le provisionnement synchrone, gardez à l'esprit les remarques et limites suivantes :

  • État de l'instance après le lancement : les instances renvoyées par l'API sont en attente. Ils peuvent toujours échouer lors des processus de flux de travail ou des accrochages du cycle de vie ultérieurs. Une réponse d'API réussie signifie qu'EC2 a accepté la demande de lancement et renvoyé les ID d'instance. Les instances ne sont pas automatiquement considérées comme entièrement prêtes pour les charges de travail et doivent suivre les processus de cycle de vie standard EC2 et Auto Scaling.

  • Limitation des pools de chaleur — Les groupes Auto Scaling avec des pools de chaleur ne sont actuellement pas pris en charge. Si vous tentez d'appeler l' LaunchInstances API sur un groupe Auto Scaling sur lequel un pool de chaleur est configuré, l'API effectue un démarrage à froid au lieu d'utiliser des instances de pool de chauffage et renvoie une UnsupportedOperation erreur. Pour plus d'informations sur les démarrages à froid, consultez la section Limitations relatives aux piscines chaudes.

  • Expiration de l'API et nouvelles tentatives : si l' CreateFleet opération sous-jacente prend plus de temps que prévu, l'API peut expirer et renvoyer un jeton d'idempuissance. Vous pouvez réessayer de l'utiliser ClientToken pour suivre l'opération de lancement initiale ou utiliser describe-instances avec le jeton client pour vérifier les instances lancées.

  • Contraintes liées aux zones de disponibilité : si votre groupe Auto Scaling couvre plusieurs zones de disponibilité et que le rééquilibrage des zones de disponibilité est activé, le lancement synchrone des instances peut provoquer des conflits opérationnels :

    • Limitation d'une seule zone de disponibilité par appel : chaque appel d' LaunchInstances API ne peut cibler qu'une seule zone de disponibilité, même si votre groupe Auto Scaling couvre plusieurs zones.

    • Conflits de rééquilibrage AZ - Si le rééquilibrage AZ est activé dans votre groupe Auto Scaling, des appels séquentiels entre différents groupes AZs peuvent déclencher des lancements asynchrones supplémentaires, ce qui se traduit par un nombre d'instances supérieur à celui prévu. Envisagez de suspendre le rééquilibrage AZ pour un contrôle précis de la capacité. Pour de plus amples informations, veuillez consulter Suspendre et reprendre les processus Amazon EC2 Auto Scaling.

  • Scénarios de réussite partielle — L'LaunchInstancesAPI peut renvoyer un succès partiel si seule une partie de la capacité demandée est disponible, ce qui correspond au comportement normal d'EC2. L'API renvoie les instances lancées avec succès ainsi que les détails des erreurs en cas d'échec des lancements. Pour les cas d'utilisation nécessitant le lancement simultané de toutes les instances (comme les applications nécessitant toutes les instances dans la même zone de disponibilité pour une faible latence), vous devez mettre fin aux instances partiellement lancées et réessayer dans une autre zone de disponibilité. Tenez compte de ce comportement lors de la conception d'une logique de nouvelle tentative pour les charges de travail sensibles à la capacité.

  • Pondérations d'instance : si votre groupe Auto Scaling utilise des poids d'instance, le RequestedCapacity paramètre représente les unités de capacité pondérées, et non le nombre d'instances. Le nombre réel d'instances lancées dépend des types d'instances sélectionnés et de leurs poids configurés. EC2 Auto Scaling limite les lancements à 100 instances par appel d'API, quelle que soit la capacité pondérée demandée.

  • Types d'instances mixtes : l' LaunchInstances API utilise la politique d'instances mixtes existante de votre groupe Auto Scaling pour déterminer les types d'instances à lancer. L'API lance les instances conformément à la stratégie d'allocation et aux priorités des types d'instances de votre groupe.