Reprise après sinistre et clusters globaux Amazon DocumentDB

En utilisant un cluster mondial, vous pouvez vous remettre rapidement après des catastrophes telles que des défaillances régionales. La reprise après sinistre est généralement mesurée à l'aide de valeurs pour RTO etRPO.

• Objectif de temps de reprise (RTO) : temps nécessaire à un système pour revenir en état de fonctionnement après un sinistre. En d'autres termes, il RTO mesure les temps d'arrêt. Pour un cluster mondial, cela RTO peut être de l'ordre de quelques minutes.

• Objectif du point de récupération (RPO) : quantité de données pouvant être perdue (mesurée dans le temps). Pour un cluster mondial, RPO il est généralement mesuré en secondes.

• Pour vous remettre d'une panne imprévue, vous pouvez effectuer un basculement entre régions vers l'un des centres secondaires de votre cluster mondial. Lorsque votre cluster global comporte plusieurs régions secondaires, assurez-vous de détacher toutes les régions secondaires en cas de panne de Région AWS la principale. Ensuite, vous promouvez l'une de ces régions secondaires en tant que nouvelle région principale Région AWS. Enfin, vous créez de nouveaux clusters dans chacune des autres régions secondaires et vous attachez ces clusters à votre cluster global.

• Lorsque vous promouvez un cluster secondaire comme cluster principal, vous devez également mettre à jour les points de terminaison utilisés par vos applications pour se connecter au cluster global. Pour obtenir un nouveau point de terminaison de rédacteur à partir d'un cluster nouvellement promu, vous pouvez convertir un ancien point de terminaison de lecteur en supprimant -ro de la chaîne de point de terminaison. Par exemple, si un ancien point de terminaison de lecteur est global-16rr-test-cluster-1.cluster-ro-12345678901.us-west-2.docdb.amazonaws.com, le nouveau point de terminaison de rédacteur promu est global-16rr-test-cluster-1.cluster-cps2igpwyrwa.us-west-2.rds.amazonaws.com.

Basculement pour les clusters globaux Amazon DocumentDB

Si un cluster entier dans un cluster Région AWS devient indisponible, vous pouvez promouvoir un autre cluster du cluster global pour qu'il dispose d'une capacité de lecture/écriture.

Vous pouvez activer manuellement le mécanisme de basculement s'il Région AWS est préférable de choisir un cluster situé dans un autre cluster comme cluster principal. Par exemple, vous pouvez accroître la capacité de l'un des clusters secondaires, puis le promouvoir comme cluster principal. L'équilibre des activités entre eux Régions AWS peut également changer, de sorte que le fait de passer du cluster principal à un autre Région AWS peut réduire le temps de latence pour les opérations d'écriture.

La procédure suivante décrit la procédure à suivre pour promouvoir l'un des clusters secondaires d'un cluster global DocumentDB.

Pour promouvoir un cluster secondaire :

1. Arrêtez d'émettre DML des instructions et d'autres opérations d'écriture sur le Région AWS cluster principal en cas de panne.

2. Identifiez un cluster à partir d'un cluster secondaire Région AWS à utiliser comme nouveau cluster principal. Si vous en avez deux (ou plus) Régions AWS dans votre cluster global, choisissez le cluster secondaire qui présente le moins de temps de latence.

3. Détachez le cluster secondaire que vous avez choisi du cluster global.

   La suppression d'un cluster secondaire d'un cluster global arrête immédiatement la réplication du cluster principal vers ce cluster secondaire et en fait un cluster de cluster autonome provisionné doté de fonctionnalités de lecture/écriture complètes. Tout autre cluster secondaire associé au cluster principal dans la région touchée par la panne est toujours disponible et peut accepter les appels de votre application. Ils consomment également des ressources. Puisque vous recréez le cluster global, pour éviter les problèmes liés au split brain et à d'autres problèmes, supprimez les autres clusters secondaires avant de créer le nouveau cluster global en suivant les étapes ci-dessous.

   Afin d'obtenir les étapes détaillées du détachement, consultez Supprimer un cluster d'un cluster global Amazon DocumentDB.

4. Reconfigurez votre application pour envoyer toutes les opérations d'écriture à ce cluster désormais autonome à l'aide de son nouveau point de terminaison. Si vous avez accepté les noms fournis lors de la création du cluster global, vous pouvez modifier le point de terminaison en supprimant le -ro de la chaîne de point de terminaison du cluster dans votre application.

   Par exemple, le point de terminaison du cluster secondaire my-global.cluster-ro-aaaaaabbbbbb.us-west-1.docdb.amazonaws.com devient my-global.cluster-aaaaaabbbbbb.us-west-1.docdb.amazonaws.com lorsque ce cluster est détaché du cluster global.

   Ce cluster devient le cluster principal d'un nouveau cluster mondial lorsque vous commencez à y ajouter des régions, à l'étape suivante.

5. Ajoutez un Région AWS au cluster. Lorsque vous effectuez cette opération, le processus de réplication du cluster primaire vers le cluster secondaire commence.

6. Ajoutez-en Régions AWS d'autres si nécessaire pour recréer la topologie requise pour prendre en charge votre application. Assurez-vous que les écritures de l'application sont envoyées au cluster approprié avant, pendant et après de telles modifications, afin d'éviter les incohérences de données entre les clusters du cluster global (problèmes liés au split brain).

7. Lorsque la panne est résolue et que vous êtes prêt à réattribuer votre cluster d'origine Région AWS comme cluster principal, effectuez les mêmes étapes dans le sens inverse.

8. Supprimez l'un des clusters secondaires du cluster global. Cela lui permettra de desservir le trafic de lecture/écriture.

9. Redirigez tout le trafic d'écriture vers le cluster principal dans l'original Région AWS.

10. Ajoutez un Région AWS pour configurer un ou plusieurs clusters secondaires de la même manière Région AWS que précédemment.

Les clusters globaux Amazon DocumentDB peuvent être gérés à l'aide AWS SDKs de ce qui vous permet de créer des solutions pour automatiser le processus de basculement des clusters mondiaux pour les cas d'utilisation liés à la reprise après sinistre et à la planification de la continuité des activités. L'une de ces solutions est mise à la disposition de nos clients sous licence Apache 2.0 et est accessible depuis notre référentiel d'outils ici. Cette solution utilise Amazon Route53 pour la gestion des terminaux et fournit des fonctions AWS Lambda qui peuvent être déclenchées en fonction d'événements appropriés.