Bonnes pratiques pour le contrôle du routage dans ARC

Dans un scénario de reprise après sinistre (DR), réduisez au minimum les dépendances du système en utilisant une approche simple pour accéder aux tâches de restauration AWS et les exécuter. Créez des informations IAM d'identification durables spécifiquement pour les tâches de reprise après sinistre, et conservez-les en toute sécurité dans un coffre-fort physique sur site ou un coffre-fort virtuel, pour y accéder en cas de besoin. Vous pouvez ainsi gérer de manière centralisée les informations de sécurité, telles que les clés d'accès et les autorisations d'accès aux AWS ressources. IAM Pour les tâches non liées à la reprise après sinistre, nous vous recommandons de continuer à utiliser l'accès fédéré, en utilisant AWS des services tels que l'authentification AWS unique.

Pour effectuer des tâches de basculement dans ARC le plan de données du cluster de restaurationAPI, vous pouvez associer une ARC IAM politique à votre utilisateur. Pour en savoir plus, consultez Exemples de politiques basées sur l'identité dans Amazon Application Recovery Controller () ARC.

Pour les DNS enregistrements que vous devrez peut-être modifier dans le cadre de votre mécanisme de basculement, en particulier les enregistrements dont l'état est vérifié, l'utilisation de TTL valeurs inférieures est appropriée. La définition TTL d'une valeur de 60 ou 120 secondes est un choix courant dans ce scénario.

Le paramètre DNS TTL (durée de vie) indique aux DNS résolveurs combien de temps ils doivent mettre en cache un enregistrement avant d'en demander un nouveau. Lorsque vous en choisissez unTTL, vous faites un compromis entre latence, fiabilité et réactivité face au changement. Avec un enregistrement plus court, TTL les DNS résolveurs remarquent les mises à jour de l'enregistrement plus rapidement, car cela TTL indique qu'ils doivent effectuer des requêtes plus fréquemment.

Pour plus d'informations, consultez Choisir TTL des valeurs pour DNS les enregistrements dans Meilleures pratiques pour Amazon Route 53 DNS.

Lorsque vous utilisez les contrôles de routage pour passer de l'un Région AWS à l'autre, le mécanisme utilisé par Amazon Application Recovery Controller (ARC) pour déplacer le trafic de votre application est une DNS mise à jour. Cette 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.

Nous vous recommandons de conserver une copie locale des points de terminaison de votre cluster ARC régional, dans des signets ou de l'enregistrer dans le code d'automatisation que vous utilisez pour réessayer vos points de terminaison. Lors d'une panne, il se peut que vous ne puissiez pas accéder à certaines API opérations, notamment celles ARC API qui ne sont pas hébergées sur le cluster de plans de données extrêmement fiable. Vous pouvez répertorier les points de terminaison de vos ARC clusters à l'aide de cette DescribeClusterAPIopération.

Les contrôles de routage fournissent cinq points de terminaison régionaux pour garantir une haute disponibilité, même en cas de panne. Pour atteindre leur résilience totale, il est important de disposer d'une logique de nouvelle tentative capable d'utiliser les cinq points de terminaison selon les besoins. Pour plus d'informations sur l'utilisation d'exemples de code avec le AWS SDK, y compris des exemples pour essayer des points de terminaison de cluster, consultezExemples de code pour Application Recovery Controller utilisant AWS SDKs.

À l'aide du plan de ARC donnéesAPI, visualisez vos contrôles et états de routage avec l'ListRoutingControlsopération et mettez à jour les états des contrôles de routage pour rediriger le trafic en vue d'un basculement avec l'UpdateRoutingControlStateopération. Vous pouvez utiliser le AWS CLI (comme dans ces exemples) ou le code que vous écrivez à l'aide de l'un des AWS SDKs. ARCoffre une fiabilité extrême grâce API au plan de données permettant de contourner le trafic. Nous vous recommandons d'utiliser le API plutôt que de modifier les états de contrôle de routage dans le AWS Management Console.

Connectez-vous à l'un des points de terminaison de votre cluster régional ARC pour utiliser le plan API de données. Si le point de terminaison n'est pas disponible, essayez de vous connecter à un autre point de terminaison du cluster.

Si une règle de sécurité bloque une mise à jour de l'état du contrôle de routage, vous pouvez la contourner pour effectuer la mise à jour et inverser le trafic. Pour de plus amples informations, veuillez consulter Dérogation aux règles de sécurité pour réacheminer le trafic.

Testez régulièrement le basculement avec le contrôle du ARC routage, afin de passer de votre pile d'applications principale à une pile d'applications secondaire. Il est important de vous assurer que les ARC structures que vous avez ajoutées sont alignées sur les bonnes ressources de votre pile et que tout fonctionne comme prévu. Vous devez le tester après avoir configuré ARC votre environnement, et continuer à le faire régulièrement, afin que votre environnement de basculement soit prêt, avant que vous ne subissiez une situation de défaillance dans laquelle vous auriez besoin que votre système secondaire soit rapidement opérationnel afin d'éviter les temps d'arrêt pour vos utilisateurs.