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.

REL11-BP04 S'appuyer sur le plan de données et non sur le plan de contrôle lors de la restauration

Les plans de contrôle fournissent les outils administratifs APIs nécessaires pour créer, lire et décrire, mettre à jour, supprimer et répertorier (CRUDL) les ressources, tandis que les plans de données gèrent le trafic de day-to-day service. Lorsque vous mettez en œuvre des réponses de restauration ou d’atténuation en cas d’événements susceptibles d’avoir un impact sur la résilience, concentrez-vous sur l’utilisation d’un nombre minimal d’opérations du plan de contrôle pour récupérer, redimensionner, restaurer, réparer ou basculer le service. L’action du plan de données doit remplacer toute activité lors de ces événements de dégradation.

Par exemple, les actions suivantes font toutes partie du plan de contrôle : lancement d’une nouvelle instance de calcul, création d’un stockage par blocs et description des services de file d’attente. Lorsque vous lancez des instances de calcul, le plan de contrôle doit effectuer plusieurs tâches, telles que la recherche d’un hôte physique avec la capacité suffisante, l’allocation d’interfaces réseau, la préparation de volumes locaux de stockage par blocs, la génération d’informations d’identification et l’ajout de règles de sécurité. Les plans de contrôle relèvent souvent d’une orchestration complexe.

Résultat souhaité : lorsqu’une ressource passe à un état altéré, le système peut être rétabli automatiquement ou manuellement en transférant le trafic des ressources altérées vers des ressources saines.

Anti-modèles courants :

Avantages du respect de cette bonne pratique : l’augmentation du taux de réussite de la correction automatisée contribue à réduire le temps moyen de récupération et à améliorer la disponibilité de la charge de travail.

Niveau d’exposition au risque si cette bonne pratique n’est pas respectée : moyen : pour certains types de dégradations de service, les plans de contrôle sont affectés. Les dépendances liées à une utilisation intensive du plan de contrôle pour la correction peuvent augmenter le temps de restauration (RTO) et le temps moyen de restauration (MTTR).

Directives d’implémentation

Pour limiter les actions du plan de données, évaluez chaque service pour déterminer les actions nécessaires afin de restaurer le service.

Tirez parti d'Amazon Application Recovery Controller pour déplacer le DNS trafic. Ces fonctionnalités surveillent en permanence la capacité de votre application à se rétablir en cas de défaillance et vous permettent de contrôler la restauration de votre application dans plusieurs Régions AWS zones de disponibilité et sur site.

Les politiques de routage Route 53 utilisent le plan de contrôle. Ne vous fiez donc pas à celui-ci pour la récupération. Les plans de données Route 53 répondent aux DNS requêtes et effectuent et évaluent les bilans de santé. Ils sont distribués dans le monde entier et conçus pour un accord de niveau de service de disponibilité à 100 % (SLA).

La gestion de Route 53 APIs et les consoles dans lesquelles vous créez, mettez à jour et supprimez les ressources Route 53 s'exécutent sur des plans de contrôle conçus pour donner la priorité à la cohérence et à la durabilité dont vous avez besoin lors de la gestionDNS. Pour ce faire, les plans de contrôle sont situés dans une seule région : USA Est (Virginie du Nord). Bien que les deux systèmes soient conçus pour être très fiables, les plans de contrôle ne sont pas inclus dans leSLA. Dans de rares cas, la conception résiliente du plan de données permet de maintenir la disponibilité alors que les plans de contrôle ne le font pas. Pour les mécanismes de reprise après sinistre et de basculement, utilisez les fonctions du plan de données pour assurer la meilleure fiabilité possible.

Concevez votre infrastructure informatique de manière à ce qu'elle soit statiquement stable afin d'éviter d'utiliser le plan de contrôle lors d'un incident. Par exemple, si vous utilisez des EC2 instances Amazon, évitez de provisionner de nouvelles instances manuellement ou de demander à Auto Scaling Groups d'ajouter des instances en réponse. Pour obtenir les niveaux de résilience les plus élevés, allouez une capacité suffisante dans le cluster utilisé pour le basculement. Si ce seuil de capacité doit être limité, réglez l'ensemble du end-to-end système afin de limiter en toute sécurité le trafic total atteignant l'ensemble limité de ressources.

Pour les services tels qu'Amazon DynamoDB, API Amazon Gateway, les équilibreurs AWS Lambda de charge et les services sans serveur, l'utilisation de ces services permet de tirer parti du plan de données. Cependant, la création de nouvelles fonctions, d'équilibreurs de charge, de API passerelles ou de tables DynamoDB est une action du plan de contrôle qui doit être terminée avant la dégradation afin de préparer un événement et de répéter les actions de basculement. Pour AmazonRDS, les actions du plan de données permettent d'accéder aux données.

Pour plus d'informations sur les plans de données, les plans de contrôle et sur la manière dont les services AWS sont conçus pour atteindre les objectifs de haute disponibilité, consultez la section Stabilité statique à l'aide des zones de disponibilité.

Comprendre quelles opérations relèvent du plan de données et quelles opérations relèvent du plan de contrôle.

Étapes d’implémentation

Pour chaque charge de travail qui doit être restaurée après un événement de dégradation, évaluez le runbook de basculement, la conception de la haute disponibilité, la conception de la réparation automatique ou le plan de restauration des ressources haute disponibilité. Identifiez chaque action qui pourrait être considérée comme une action du plan de contrôle.

Envisagez de remplacer l’action du plan de contrôle par une action de plan de données :

Envisagez d’autres approches qui permettent aux actions du plan de données d’affecter les mêmes mesures correctives.

Envisagez certains services dans une région secondaire, s’ils sont critiques, afin de permettre davantage d’actions du plan de contrôle et du plan de données dans une région non affectée.

Ressources

Bonnes pratiques associées :

Documents connexes :

Vidéos connexes :

Exemples connexes :

Outils associés :