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 pour les changements de zone sur la Route 53 ARC
Nous recommandons les meilleures pratiques suivantes pour utiliser les décalages de zone pour la restauration multi-AZ sur Route 53. ARC Les changements de zone réduisent généralement la capacité d'une application en ligne. Il est donc important de faire preuve de prudence lorsque vous les utilisez en production.
Rubriques
Limitez le temps pendant lequel les clients restent connectés à vos terminaux
Assurez-vous que toutes les zones de disponibilité sont saines et qu'elles accueillent du trafic
Utiliser les API opérations du plan de données pour la reprise après sinistre
Déplacez le trafic avec un changement de zone uniquement temporairement
- Planification des capacités et pré-dimensionnement
Assurez-vous d'avoir prévu une capacité suffisante, que vous l'avez prédimensionnée ou que vous pouvez la dimensionner automatiquement, pour faire face à la charge supplémentaire imposée aux zones de disponibilité lorsque vous commencez un changement de zone. Dans le cas d'une architecture axée sur la restauration, il est généralement recommandé de prédimensionner la capacité de calcul afin d'inclure une marge de manœuvre suffisante pour répondre aux pics de trafic lorsque l'une de vos trois répliques (généralement) est hors ligne.
Lorsque vous commencez un changement de zone pour une seule ressource d'équilibreur de charge, par exemple, la capacité d'une zone de disponibilité est temporairement supprimée derrière l'équilibreur de charge. En fonction des changements de zone que vous commencez et de la configuration de vos équilibreurs de charge, vous devez vous assurer d'avoir soigneusement planifié la gestion de la charge accrue sur les zones de disponibilité restantes.
- 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. Pour plus d'informations, consultez la durée de conservation HTTP du client dans le guide de l'utilisateur d'Application Load Balancer.Par défaut, les équilibreurs de charge d'application définissent la durée de conservation du HTTP client sur 3 600 secondes, soit 1 heure. Nous vous suggérons de réduire la valeur pour qu'elle corresponde à votre objectif de temps de restauration pour votre application, par exemple 300 secondes. Lorsque vous choisissez la durée de conservation d'un HTTP client, considérez que cette valeur représente un compromis entre une reconnexion plus fréquente en général, ce qui peut affecter la latence, et le fait de déplacer plus rapidement tous les clients loin d'une zone ou d'une région affectée.
- Testez à l'avance les décalages de zone de départ
Testez régulièrement le déplacement du trafic hors des zones de disponibilité pour votre application en commençant par des changements de zone. Planifiez et exécutez les changements de zone de départ, de préférence dans les environnements de test et de production, dans le cadre des tests de basculement réguliers visant à restaurer vos applications en cas de sinistre. Des tests réguliers sont essentiels pour garantir que vous êtes prêt et que vous avez la confiance nécessaire pour atténuer les problèmes lorsqu'un événement opérationnel se produit.
- Assurez-vous que toutes les zones de disponibilité sont saines et qu'elles accueillent du trafic
Les décalages zonaux fonctionnent en marquant une ressource, c'est-à-dire une réplique d'application, comme étant défectueuse dans une zone de disponibilité. Il est donc essentiel de s'assurer que les cibles des équilibreurs de charge pour vos applications sont généralement saines et qu'elles absorbent activement le trafic dans les zones de disponibilité d'une région. Nous vous recommandons de disposer de tableaux de bord pour suivre cela, y compris, par exemple, des métriques Elastic Load Balancing pour les cibles non conformes et bytesProcessed par zone de disponibilité.
Envisagez de surveiller l'état de vos ressources depuis une deuxième région adjacente. Les avantages de cette approche sont qu'elle peut être plus représentative de l'expérience de vos utilisateurs finaux et qu'elle réduit également le risque que votre application et votre surveillance soient touchées par le même sinistre en même temps (« destin partagé »).
- Utiliser les API opérations du plan de données pour la reprise après sinistre
Pour démarrer un changement de zone lorsque vous devez restaurer une application rapidement, avec peu de dépendances, nous vous recommandons d'utiliser les actions AWS Command Line Interface ou API avec changement de zone, avec des informations d'identification préenregistrées, si possible. Vous pouvez également commencer à changer de zone dans le AWS Management Console, pour faciliter l'utilisation. Mais lorsqu'une restauration rapide et fiable est essentielle, les opérations sur le plan de données constituent un meilleur choix. Pour plus d'informations, consultez le Guide de API référence Zonal Shift.
- Déplacez le trafic avec un changement de zone uniquement temporairement
Un changement de zone déplace le trafic hors d'une zone de disponibilité de façon temporaire, afin d'atténuer une détérioration. Vous devez restaurer la ressource pour la mise en service de l'application dès que vous avez pris des mesures pour corriger un problème. Cela garantit que l'ensemble de votre application est restauré dans son état d'origine entièrement redondant et résilient.