Bonnes pratiques lors de la configuration de l'autoshift zonal

Tenez compte des meilleures pratiques et considérations suivantes lorsque vous activez le changement automatique de zone dans Amazon Route 53 Application Recovery Controller.

Le changement automatique de zone comprend deux types de changements de circulation : les changements automatiques et les changements de zone pour entraînement.

• Le transfert automatique AWS permet de réduire le délai de restauration en transférant le trafic des ressources applicatives depuis une zone de disponibilité lors d'événements, en votre nom.

• Avec les courses d'entraînement, la Route 53 ARC amorce un changement de zone en votre nom. Le changement de zone déplace le trafic hors d'une zone de disponibilité pour une ressource, et inversement, selon une cadence hebdomadaire. Les essais pratiques vous aident à vous assurer que vous avez suffisamment augmenté la capacité des zones de disponibilité d'une région pour 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 de vitesse automatiques et les essais d'entraînement. Consultez les rubriques suivantes avant d'activer le changement automatique par zone ou de configurer des essais pratiques pour une ressource.

Rubriques

• Limitez le temps pendant lequel les clients restent connectés à vos terminaux

• Prédimensionnez la capacité de vos ressources et testez l'évolution du trafic

• Soyez conscient des types de ressources et des restrictions

• Spécifiez les alarmes pour les essais

• Évaluer les résultats des séances d'entraînement

Limitez le temps pendant lequel les clients restent connectés à vos terminaux

Lorsqu'Amazon Route 53 Application Recovery Controller déplace le trafic pour éviter une perturbation, par exemple en utilisant le décalage de zone ou le décalage automatique de zone, le mécanisme ARC utilisé par Route 53 pour déplacer le trafic de votre application est une mise à jour. DNS Une DNS mise à jour entraîne le renvoi 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 l'emplacement altéré jusqu'à ce qu'ils se reconnectent. Pour garantir un rétablissement rapide, nous vous recommandons de limiter la durée pendant laquelle les clients restent connectés à vos terminaux.

Si vous utilisez un Application Load Balancer, vous pouvez utiliser keepalive cette option pour configurer la durée des connexions. Nous vous suggérons de réduire la keepalive valeur pour qu'elle corresponde à votre objectif de temps de restauration pour votre application, par exemple 300 secondes. Lorsque vous choisissez une keepalive heure, considérez que cette valeur représente un compromis entre une reconnexion plus fréquente en général, ce qui peut affecter le temps de latence, et le fait de déplacer plus rapidement tous les clients d'une zone ou d'une région affectée.

Pour plus d'informations sur la définition de l'keepaliveoption pour Application Load Balancer, consultez la durée de conservation du HTTP client dans le Guide de l'utilisateur de l'Application Load Balancer.

Prédimensionnez la capacité de vos ressources et testez l'évolution du trafic

Lorsque AWS vous déplacez 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 demandes 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 a besoin de 30 instances pour servir ses clients, vous devez en fournir 15 dans trois zones de disponibilité, pour un total de 45 instances. Ce faisant, when AWS déplace le trafic d'une zone de disponibilité (avec un transfert automatique ou lors d'un entraînement)AWS peut toujours servir les clients de votre application avec le total de 30 instances restantes, réparties dans deux zones de disponibilité.

La fonctionnalité de transfert automatique zonal de Route 53 vous ARC aide à vous remettre 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 transfert automatique zonal pour une ressource, augmentez la capacité de votre ressource dans toutes les zones de disponibilité configurées dans un. Région AWS Commencez ensuite les changements de zone pour 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 testé avec des décalages de zone, activez le décalage automatique zonal et configurez les essais pratiques pour les ressources de l'application. Des séances d'entraînement régulières avec changement automatique par zone vous aident à vous assurer, sur une base continue, que votre capacité est toujours adaptée. Avec une capacité suffisante dans toutes les zones de disponibilité, votre application peut continuer à servir les clients, sans interruption, pendant un transfert automatique.

Pour plus d'informations sur le lancement d'un changement de zone pour une ressource, consultezChangement de zone dans Amazon Route 53 Application Recovery Controller.

Soyez conscient des types de ressources et des restrictions

L'autoshift zonal prend en charge le transfert du trafic hors d'une zone de disponibilité pour toutes les ressources prises en charge par le transfert zonal. En général, les équilibreurs de charge réseau et les équilibreurs de charge d'application dont l'équilibrage de charge entre zones est désactivé sont pris en charge. Dans certains scénarios de ressources spécifiques, le transfert automatique zonal ne déplace pas le trafic depuis une zone de disponibilité pour un transfert automatique.

Par exemple, si les groupes cibles de l'équilibreur de charge dans les zones de disponibilité ne possèdent aucune instance, ou si toutes les instances ne fonctionnent pas correctement, l'équilibreur de charge est dans un état d'ouverture défaillante. Dans ce scénario, si AWS un autoshift est lancé pour un équilibreur de charge, celui-ci ne modifie pas les zones de disponibilité utilisées par l'équilibreur de charge, car celui-ci est déjà dans un état ouvert en cas de défaillance. Ce comportement est normal. Le changement automatique ne peut pas rendre une zone de disponibilité défectueuse et déplacer le trafic vers les autres zones de disponibilité Région AWS si toutes les zones de disponibilité ne sont pas ouvertes (insalubres).

Un deuxième scénario est celui du AWS démarrage d'un autoshift pour un Application Load Balancer qui est le point de terminaison d'un accélérateur dans. AWS Global Accelerator Comme pour le changement de zone, le décalage automatique n'est pas pris en charge pour les équilibreurs de charge d'application qui sont les points de terminaison des accélérateurs dans Global Accelerator.

Pour en savoir plus sur les ressources prises en charge, y compris toutes les exigences et exceptions à connaître, consultezRessources et scénarios pris en charge pour le changement de zone et le changement automatique de zone.

Spécifiez les alarmes pour les essais

Vous configurez au moins une alarme, l'alarme de résultat, pour les essais avec changement automatique zonal. En option, vous pouvez également configurer une deuxième alarme, l'alarme de blocage.

Lorsque vous considérez les CloudWatch alarmes que vous configurez pour les entraînements de votre ressource, gardez à l'esprit les points suivants :

• Pour l'alarme de résultat, qui est requise, nous vous recommandons de configurer une CloudWatch alarme pour qu'elle passe à un ALARM état dans lequel les mesures relatives à la ressource ou à votre application indiquent que le fait de déplacer le trafic hors de la zone de disponibilité a un impact négatif sur les performances. Par exemple, vous pouvez déterminer un seuil pour les taux de demandes pour votre ressource, puis configurer une alarme pour qu'elle passe à un ALARM état lorsque le seuil est dépassé. Vous êtes responsable de la configuration d'une alarme appropriée qui AWS met fin à l'entraînement et renvoie un FAILED résultat.

• Nous vous recommandons de suivre le AWS Well Architected Framework, qui vous conseille de mettre en œuvre des indicateurs de performance clés (KPIs) sous forme d' 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 les essais de démarrer au cas où votre application risquerait d'en manquer uneKPI. Lorsque l'alarme n'est plus en ALARM état, Route 53 ARC lance des essais la prochaine fois qu'un entraînement est planifié pour la ressource.

• En ce qui concerne l'alarme de blocage des essais, si vous choisissez de la configurer, vous pouvez choisir de suivre une métrique spécifique que vous utilisez pour indiquer que vous ne souhaitez pas qu'un entraînement commence.

• Pour vous entraîner à exécuter des alarmes, vous devez spécifier le nom de ressource Amazon (ARN) pour chaque alarme, que vous devez d'abord configurer dans Amazon CloudWatch. Les CloudWatch alarmes que vous spécifiez peuvent être des alarmes composites, afin de vous permettre d'inclure plusieurs mesures et contrôles pour votre application et votre ressource susceptibles de déclencher le passage de l'alarme à un ALARM état. Pour plus d'informations, consultez 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 entraînement.

Évaluer les résultats des séances d'entraînement

Route 53 ARC indique un résultat pour chaque course d'entraînement. Après un entraînement, évaluez le résultat et déterminez si vous devez agir. Par exemple, vous devrez peut-être augmenter la capacité ou ajuster la configuration d'une alarme.

Les résultats possibles de l'entraînement sont les suivants :

• SUCCEEDED: L'alarme de résultat n'est pas entrée dans un ALARM état pendant la séance d'entraînement, qui a terminé la période de test complète de 30 minutes.

• FAILED: L'alarme de résultat est entrée dans un ALARM état pendant l'entraînement.

• INTERRUPTED: La course d'entraînement a pris fin pour une raison qui n'était pas le résultat de l'alarme qui a déclenché l'entrée dans un ALARM état. Un entraînement peut être interrompu pour diverses raisons, notamment les suivantes :

  • La séance d'entraînement a pris fin parce qu'un changement automatique avait AWS commencé Région AWS ou parce qu'une alarme s'était produite dans la région.

  • L'exécution d'entraînement a été interrompue car la configuration de l'exécution d'entraînement a été supprimée pour la ressource.

  • Le cycle d'entraînement a pris fin parce qu'un changement de zone initié par le client a été lancé pour la ressource de la zone de disponibilité à partir de laquelle le changement de zone d'entraînement détournait le trafic.

  • L'exercice d'entraînement a été interrompu car une CloudWatch alarme spécifiée pour la configuration de l'essai n'est plus accessible.

  • L'essai s'est terminé car l'alarme de blocage spécifiée pour l'essai est entrée dans un ALARM état.

  • La course d'entraînement a été interrompue pour une raison inconnue.

• PENDING: La séance d'entraînement est active (en cours). Il n'y a pas encore de résultat à obtenir.