Automatisation de votre stratégie de reprise après sinistre - AWS Conseils prescriptifs

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.

Automatisation de votre stratégie de reprise après sinistre

Vous pouvez éventuellement choisir d'implémenter une automatisation complète ou partielle afin de mieux contrôler la reprise après sinistre. Si vous utilisez l'option DR de sauvegarde et de restauration, vous pouvez automatiser vos sauvegardes en utilisant AWS Backup, qui prend en charge toutes les RDS bases de données Amazon ainsi que les tables DynamoDB, Amazon DocumentDB et Amazon Neptune.

Détection des sinistres

Pour réduire le temps de reprise, vous pouvez envisager d'automatiser la détection d'un événement régional, qui peut ensuite déclencher le basculement vers la région de reprise après sinistre. Pour mettre en œuvre une détection automatisée afin d'obtenir une approche agressiveRTO, vous pouvez créer une solution basée sur des bilans de santé. Ces surveillances de l'état ne s'arrêtent pas aux pulsations (qui vérifient si les modules du plan de contrôle et du plan de données d'un réseau peuvent communiquer entre eux), mais ils vont plus loin pour évaluer la nature interdépendante des composants de l'application afin de parvenir à une prédiction précise. Cependant, une solution automatisée peut comporter le risque de fausses alertes, ce qui peut entraîner des basculements inutiles. Vous devez faire preuve de prudence dans ce cas, car les basculements inutiles entraînent des problèmes de disponibilité pour votre activité. Vous pouvez également créer des remplacements manuels dans le flux de travail pour confirmer que le basculement a été effectué. Vous pouvez vous abonner au RSS fil Service Health Dashboard pour rester informé des interruptions de service. En outre, vous pouvez utiliser le AWS Health Dashboard(nécessite un AWS compte) dans votre région principale et votre compte pour rester au courant des événements susceptibles d'affecter votre compte. Ils peuvent vous aider à prendre une décision de basculement en connaissance de cause dans le cas d'un événement régional.

Basculement

Quelle que soit la stratégie de reprise après sinistre que vous choisissez, vous pouvez créer des solutions d'automatisation de reprise après sinistre personnalisées pour effectuer le basculement vers la région de reprise après sinistre. Cette automatisation peut réduire le besoin d'intervention manuelle et offrir un meilleur contrôle lors des tests de votre solution de reprise après sinistre. Vous pouvez choisir parmi le AWS service APIs, qui AWS est disponible dans plusieurs langages tels que Python JavaScript,PHP,. NET, Ruby, Java, Go, Node.js et C++, selon les préférences de votre organisation. Pour créer une automatisation utilisant ces AWS servicesAPIs, vous devez d'abord vous concentrer sur la transformation de l'infrastructure de base de données en code sous forme de AWS CloudFormation modèles Terraform. Ces modèles peuvent vous aider à automatiser le basculement de plusieurs bases de données, mais aussi à maintenir l'ordre dans lequel les composants de l'application et de la base de données sont réinstallés dans la région de reprise après sinistre.

À des fins de reprise après sinistre, nous vous recommandons de vous concentrer sur les deux objectifs suivants :

  • Les CloudFormation piles existantes doivent exporter des informations pertinentes sur vos bases de données, notamment les noms des instances et les points de terminaison. Vos processus d'automatisation peuvent faire référence à ces valeurs d'exportation au sein d'une région et effectuer des opérations qui vous aideront dans vos opérations de reprise après sinistre.

  • Si vous avez des ressources en production mais que vous n'avez pas de CloudFormation pile associée, vous devez vous concentrer sur la création de piles pour ces ressources. Assurez-vous également que ces piles couvrent les valeurs d'exportation adéquates, comme indiqué au point précédent.

Lorsque vous aurez atteint ces deux objectifs, vous pourrez créer des solutions d'automatisation dans la langue choisie par votre organisation afin de tirer parti des CloudFormation exportations et d'effectuer automatiquement les actions de transition requises en cas de sinistre. Par exemple, si vous avez une banque de données globale ElastiCache (RedisOSS) déployée sous forme de CloudFormation modèle, le code d'automatisation a accès aux CloudFormation exportations qui fournissent des détails sur la banque de données globale. En cas de sinistre, le code peut automatiquement promouvoir la banque de données secondaire vers la banque de données principale sans aucune intervention manuelle en utilisant le service ElastiCache (RedisOSS). APIs

Dans un scénario type, l'automatisation doit être évolutive pour plusieurs bases de données au sein de votre organisation. Vous pouvez mettre à l'échelle vos solutions d'automatisation pour plusieurs bases de données en utilisant AWS Step Functions ou AWS Batch.