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.
Meilleures pratiques lors de la configuration du décalage automatique zonal
Tenez compte des bonnes pratiques et considérations suivantes lorsque vous activez le décalage automatique zonal dans Amazon Application Recovery Controller (ARC).
Le décalage automatique zonal comprend deux types de changements de trafic : les décalages automatiques et les décalages zonaux d'entraînement.
Grâce à un changement automatique, vous AWS pouvez réduire le temps nécessaire à la restauration en déplaçant le trafic des ressources applicatives depuis une zone de disponibilité lors d'événements organisés en votre nom.
Avec les séances d'entraînement, l'ARC commence un changement de zone en votre nom ou vous commencez une course d'entraînement par décalage de zone. La AWS pratique du décalage zonal permet de déplacer le trafic d'une zone de disponibilité pour une ressource, et inversement, selon une cadence hebdomadaire. Les essais pratiques vous aident à vous assurer que vous avez augmenté une capacité suffisante pour les zones de disponibilité d'une région afin que votre application puisse tolérer la perte d'une zone de disponibilité.
Il existe plusieurs bonnes pratiques et considérations à prendre en compte en ce qui concerne les changements automatiques et les essais. Consultez les rubriques suivantes avant d'activer le décalage automatique zonal ou de configurer des essais pratiques pour une ressource.
Rubriques
- Limitez la durée pendant laquelle les clients restent connectés à vos terminaux
-
Lorsqu'Amazon Application Recovery Controller (ARC) déplace le trafic pour éviter qu'il ne soit perturbé, par exemple en utilisant le décalage zonal ou le décalage automatique zonal, le mécanisme utilisé par ARC pour déplacer le trafic de votre application est une mise à jour DNS. Une mise à jour du DNS entraîne la redirection de toutes les nouvelles connexions hors de la zone affectée. Cependant, les clients disposant de connexions ouvertes préexistantes peuvent continuer à faire des demandes concernant la localisation altérée jusqu'à ce que les clients se reconnectent. Pour garantir une restauration rapide, nous vous recommandons de limiter la durée pendant laquelle les clients restent connectés à vos terminaux.
Si vous utilisez un équilibreur de charge d'application, vous pouvez utiliser
keepalivecette option pour configurer la durée des connexions. Nous vous suggérons de réduire lakeepalivevaleur pour l'aligner sur votre objectif de temps de restauration pour votre application, par exemple 300 secondes. Lorsque vous choisissez unekeepaliveheure, considérez que cette valeur est un compromis entre une reconnexion plus fréquente en général, ce qui peut affecter la latence, et un éloignement plus rapide de tous les clients d'une zone Z ou d'une région altérée.Pour plus d'informations sur la définition de l'
keepaliveoption Application Load Balancer, consultez la durée de conservation du client HTTP dans le Guide de l'utilisateur de l'équilibreur de charge des applications. - Prédimensionnez la capacité de vos ressources et testez le trafic changeant
-
Lorsque AWS vous éloignez le trafic d'une zone de disponibilité pour un changement de zone ou un transfert automatique, il est important que les zones de disponibilité restantes puissent répondre aux taux de demande accrus pour votre ressource. Ce modèle est connu sous le nom de stabilité statique. Pour plus d'informations, consultez le livre blanc sur la stabilité statique à l'aide des zones de disponibilité
dans la bibliothèque Amazon Builder. Par exemple, si votre application nécessite 30 instances pour servir ses clients, vous devez provisionner 15 instances dans trois zones de disponibilité, pour un total de 45 instances. Ainsi, lorsque le trafic est AWS déplacé hors d'une zone de disponibilité (avec un décalage automatique ou lors d'une exécution d'entraînement),AWS vous pouvez toujours servir les clients de votre application avec les 30 instances restantes, réparties dans deux zones de disponibilité.
La fonction de décalage automatique zonal d'ARC vous permet de récupérer rapidement des AWS événements survenus dans une zone de disponibilité lorsque vous disposez d'une application dont les ressources sont prédimensionnées pour fonctionner normalement en cas de perte d'une zone de disponibilité. Avant d'activer le décalage automatique par zone pour une ressource, augmentez la capacité de vos ressources dans toutes les zones de disponibilité configurées dans un. Région AWS Commencez ensuite à modifier les zones de la ressource, afin de vérifier que votre application fonctionne toujours normalement lorsque le trafic est déplacé hors d'une zone de disponibilité.
Après avoir effectué un test avec des décalages de zone, activez le décalage automatique de zone et configurez les essais pratiques pour les ressources de l'application. Effectuez vos propres essais pratiques à la demande pour vous assurer que votre configuration est correctement dimensionnée. Des séances d'entraînement régulières avec changement automatique de zone vous aident à vous assurer, en permanence, que votre capacité est toujours adaptée de manière appropriée. Avec une capacité suffisante dans toutes les zones de disponibilité, votre application peut continuer à servir les clients, sans interruption, pendant un changement automatique.
Pour plus d'informations sur le démarrage d'un changement de zone pour une ressource, consultezChangement de zone dans ARC.
- Soyez conscient des types de ressources et des restrictions
Le décalage automatique zonal prend en charge le transfert du trafic hors d'une zone de disponibilité pour toutes les ressources prises en charge par le décalage zonal. Dans certains scénarios de ressources spécifiques, le décalage automatique zonal ne déplace pas le trafic d'une zone de disponibilité vers un transfert automatique.
Par exemple, si les groupes cibles de l'équilibreur de charge situés dans les zones de disponibilité ne possèdent aucune instance, ou si toutes les instances sont défectueuses, l'équilibreur de charge est en état d'échec d'ouverture. Dans ce scénario, si un décalage automatique AWS démarre pour un équilibreur de charge, un décalage automatique ne modifie pas les zones de disponibilité utilisées par l'équilibreur de charge, car l'équilibreur de charge est déjà dans un état d'ouverture en cas d'échec. Ce comportement est normal. Autoshift ne peut pas provoquer l'insalubrité d'une zone de disponibilité et déplacer le trafic vers les autres zones de disponibilité en Région AWS cas d'échec de l'ouverture de toutes les zones de disponibilité (mauvaise santé).
Pour en savoir plus sur les ressources prises en charge, y compris toutes les exigences et exceptions à prendre en compte, consultezRessources prises en charge.
- Spécifiez les alarmes pour les séances d'entraînement
-
Vous devez configurer au moins un type d'alarme (une alarme de résultat) pour les essais avec décalage automatique zonal. En option, vous pouvez également configurer un deuxième type d'alarme (alarmes de blocage).
Lorsque vous considérez les CloudWatch alarmes que vous configurez pour les essais de votre ressource, tenez compte des points suivants :
Vous devez configurer au moins une alarme de résultat pour une configuration d'exécution d'entraînement. Pour les alarmes de résultat, nous vous recommandons de configurer les CloudWatch alarmes pour qu'elles passent à un
ALARMétat lorsque les mesures relatives à la ressource ou à votre application indiquent que le fait de déplacer le trafic hors de la zone de disponibilité a une incidence négative sur les performances. Par exemple, vous pouvez déterminer un seuil pour les taux de demande pour votre ressource, puis configurer une alarme pour qu'elle passe à unALARMétat lorsque le seuil est dépassé. Vous êtes responsable de la configuration des alarmes appropriées qui mettent fin AWS à l'exécution de l'entraînement et renvoient unFAILEDrésultat.Nous vous recommandons de suivre le AWS Well Architected Framework, qui vous conseille de mettre en œuvre des indicateurs de performance clés (KPI) en tant qu' CloudWatchalarmes. Dans ce cas, vous pouvez utiliser ces alarmes pour créer une alarme composite à utiliser comme déclencheur de sécurité, afin d'empêcher le démarrage des exercices d'entraînement s'ils risquent de faire manquer un KPI à votre application. Lorsque l'alarme n'est plus en
ALARMétat, ARC lance les essais d'entraînement la prochaine fois qu'un essai d'entraînement est planifié pour la ressource.Pour les alarmes bloquant les séances d'entraînement, si vous choisissez d'en configurer une (ou plusieurs), vous pouvez choisir de suivre des mesures spécifiques que vous utilisez pour indiquer que vous ne souhaitez pas qu'une séance d' AWS entraînement démarre, par exemple lorsqu'une alarme indique qu'un incident est en cours.
Pour vous entraîner à exécuter des alarmes, vous spécifiez le nom de ressource Amazon (ARN) pour chaque alarme. Vous devez donc d'abord configurer l'alarme dans Amazon CloudWatch. Les CloudWatch alarmes que vous spécifiez peuvent être des alarmes composites, afin de vous permettre d'inclure plusieurs mesures et vérifications pour votre application et votre ressource, qui peuvent déclencher l'
ALARMétat de l'alarme. Vous pouvez également configurer des alarmes distinctes, puis spécifier plusieurs alarmes de chaque type pour la configuration de votre entraînement. Pour plus d'informations, consultez la section Combiner des alarmes dans le Guide de CloudWatch l'utilisateur Amazon.Assurez-vous que les CloudWatch alarmes que vous spécifiez pour les essais se trouvent dans la même région que la ressource pour laquelle vous configurez un exercice d'entraînement.
- Évaluer les résultats des séances d'entraînement
L'ARC publie un résultat pour chaque séance d'entraînement. Après une séance d'entraînement, évaluez les résultats et déterminez si vous devez prendre des mesures. Par exemple, vous devrez peut-être augmenter la capacité ou ajuster la configuration d'une alarme.
Les résultats possibles des tests pratiques sont les suivants :
RÉUSSITE : Aucune alarme de résultat n'est entrée en
ALARMétat pendant la course d'entraînement, et la course d'entraînement a terminé la période de test complète de 30 minutes.ÉCHEC : Au moins une alarme de résultat est entrée en
ALARMétat pendant la course d'entraînement.INTERROMPU : La course d'entraînement s'est terminée pour une raison qui n'était pas le résultat de l'entrée d'une alarme dans un
ALARMétat. Une séance d'entraînement peut être interrompue pour diverses raisons, notamment les suivantes :La séance d'entraînement s'est terminée parce qu'un changement automatique a été AWS déclenché dans la région Région AWS ou qu'une alarme s'est produite dans la région.
L'exécution d'entraînement a été interrompue car la configuration d'exécution d'entraînement a été supprimée pour la ressource.
L'essai d'entraînement a pris fin car un changement de zone initié par le client a été lancé pour la ressource de la zone de disponibilité à partir de laquelle le décalage de zone d'entraînement détournait le trafic.
L'exécution des essais a été interrompue car il n'était plus possible d'accéder à une CloudWatch alarme spécifiée pour la configuration de l'exécution des essais.
La course d'entraînement a été interrompue car une alarme de blocage spécifiée pour la course d'entraînement est entrée dans un
ALARMétat.La course d'entraînement a été interrompue pour une raison inconnue.
-
L'essai d'entraînement a été interrompu car un changement automatique de zone avec priorité a été lancé. Voir Priorité pour les changements de zone.
ÉCHEC DE LA VÉRIFICATION DE CAPACITÉ : la vérification de l’équilibre de capacité entre les zones de disponibilité pour vos ressources de répartition de charge et de groupe Auto Scaling a échoué.
EN ATTENTE : La course d'entraînement est active (en cours). Il n’y a pas encore de résultat à transmettre.
