Description de la haute disponibilité et de la reprise après incident pour Databases for MongoDB
La haute disponibilitéLa capacité d'un service ou d'une charge de travail à résister aux défaillances et à continuer à fournir une capacité de traitement selon un niveau de service prédéfini. Pour les services, la disponibilité est définie dans l'accord de niveau de service. La disponibilité comprend à la fois les événements planifiés et non planifiés, tels que la maintenance, les pannes et les catastrophes. (HA) est la capacité d'un service à rester opérationnel et accessible en cas de défaillance inattendue. La reprise après sinistreCapacité d'un service ou d'une charge de travail à se remettre d'incidents rares, majeurs et de défaillances à grande échelle, tels que l'interruption d'un service. Il peut s'agir d'un désastre physique qui affecte une région entière, de la corruption d'une base de données ou de la perte d'un service contribuant à une charge de travail. L'impact dépasse la capacité de la conception haute disponibilité à le gérer. est le processus de rétablissement de l'instance de service dans un état opérationnel.
Databases for MongoDB est un service régional qui remplit les objectifs de niveau de service(SLO) définis avec les plans Standard et Enterprise. Pour plus d'informations, voir Accord de niveau de service(SLA). IBM Cloud Pour plus d'informations sur les régions et les centres de données disponibles pour Databases for MongoDB, voir Disponibilité des services et de l'infrastructure par emplacement.
Architecture à haute disponibilité
Databases for MongoDB offre des fonctions de réplication, de basculement et de haute disponibilité pour protéger vos bases de données et vos données de la maintenance de l'infrastructure, des mises à niveau et de certaines pannes. Les déploiements contiennent un cluster avec trois membres de données - un membre primaire et deux membres secondaires. L'ensemble de répliques à deux membres est maintenu à jour à l'aide d'une réplication asynchrone. Un mécanisme de consensus distribué est utilisé pour maintenir l'état de la grappe et gérer les basculements. Si le primaire n'est pas disponible, l'ensemble de répliques élit un secondaire comme primaire et continue à fonctionner normalement. L'ancien noeud principal rejoint l'ensemble lorsqu'il est disponible. Les membres principaux et secondaires se trouvent toujours dans des zones différentes d'une MZR. Si la défaillance d'une zone entraîne la défaillance d'un membre, la nouvelle réplique sera créée dans une zone survivante.
Fonctionnalités de haute disponibilité
Databases for MongoDB prend en charge les fonctions de haute disponibilité suivantes.
| Fonction | Description |
|---|---|
| Basculement automatique | Standard sur tous les clusters et résilient en cas de défaillance d'une zone ou d'un seul membre. |
| Nombre de membres | Minimum 3 membres. La valeur par défaut est un déploiement standard de trois membres. Un cluster de trois membres se rétablit automatiquement en cas de défaillance d'une seule instance ou d'une seule zone (avec une perte de données jusqu'au seuil de décalage). |
| Réplication asynchrone | Les secondaires répliquent les opérations du primaire et les appliquent à leurs ensembles de données de manière asynchrone. En faisant en sorte que les ensembles de données secondaires reflètent les ensembles de données primaires, l'ensemble de répliques peut continuer à fonctionner malgré la défaillance d'un ou de plusieurs membres. |
Architecture de reprise après sinistre
La stratégie générale de reprise après sinistre consiste à créer une nouvelle base de données, telle que la base de données suivante : MongoDB Restore. Le contenu de la nouvelle base de données peut être une sauvegarde de la base
de données source créée avant le sinistre. Une nouvelle base de données peut être créée à l'aide de la fonction point-in-time pour le plan Enterprise, si la base de données de production est disponible.
Fonctionnalités de reprise après sinistre
Databases for MongoDB prend en charge les fonctions de reprise après sinistre suivantes.
| Fonction | Description | Élément à prendre en compte |
|---|---|---|
| Restauration de la sauvegarde | Créer une base de données à partir d'une sauvegarde créée précédemment; voir Gestion des sauvegardes Cloud Databases. | Les nouvelles chaînes de connexion pour la base de données restaurée doivent être référencées dans l'ensemble de la charge de travail. |
| Restauration avec point de cohérence | Créer une base de données à partir de la production en direct à l'aide d'une récupération ponctuelle. | Cela n'est possible que pour le plan Entreprise et si la base de données active est disponible et que le RPO (sinistre) se situe dans la fenêtre prise en charge. Elle n'est pas utile si le cluster de production n'est pas disponible. Les nouvelles chaînes de connexion pour la base de données restaurée doivent être référencées dans l'ensemble de la charge de travail. |
Planification de la reprise après incident
Les étapes de la reprise après sinistre doivent être pratiquées régulièrement. Lors de l'élaboration de votre plan, envisagez les scénarios d'échec et les résolutions suivants.
| Echec | Résolution |
|---|---|
| Défaillance du matériel (point unique) | IBM fournit une base de données qui résiste à un seul point de défaillance matérielle au sein d'une zone - aucune configuration n'est requise. |
| défaillance de zone | Basculement automatique. Les membres de la base de données sont répartis entre les zones. La configuration de trois membres permet d'accroître la résilience en cas de défaillance de plusieurs zones. |
| Altération de données | Restauration de la sauvegarde. Utilisez la base de données restaurée en production ou comme source de données pour corriger la corruption dans la base de données restaurée.
Restauration ponctuelle. Utilisez la base de données restaurée en production ou comme source de données pour corriger la corruption dans la base de données restaurée. |
| Défaillance régionale | Restauration de la sauvegarde. Utiliser la base de données restaurée en production. |
Haute disponibilité au niveau de l'application
Les applications qui communiquent par le biais de réseaux et de services cloud sont sujettes à des pannes de connexion transitoires. Vous souhaitez concevoir vos applications de telle manière que les connexions soient relancées lorsque des erreurs se produisent à cause d'une perte temporaire de connectivité avec votre déploiement ou avec IBM Cloud.
Vos applications doivent être conçues pour gérer des interruptions temporaires de connexion à la base de données, implémenter le traitement d'erreurs pour les commandes de base de données qui échouent et implémenter une logique de relance pour effectuer une reprise après une interruption temporaire.
Une interruption de connexion ou une non-disponibilité de la base de données pendant plusieurs minutes n'est pas censée se produire. Ouvrez un dossier d'assistance avec des détails si vous avez des périodes de plus d'une minute sans connectivité afin que nous puissions enquêter.
Vos responsabilités en matière d'HA et de DR
Les informations suivantes peuvent vous aider à créer et à mettre en pratique en permanence votre plan pour l'AH et le DR.
Lors de la restauration d'une base de données à partir de sauvegardes ou d'une restauration ponctuelle, une nouvelle base de données est créée avec de nouvelles chaînes de connexion. Les charges de travail et les processus existants doivent être adaptés pour utiliser les nouvelles chaînes de connexion. La promotion d'un réplica en lecture dans un cluster aura un impact similaire, bien que les parties en lecture seule de la charge de travail ne soient pas affectées.
Une base de données restaurée peut également avoir besoin des mêmes dépendances créées par le client que la base de données sinistrée - assurez-vous que les services suivants et d'autres services existent dans la région restaurée :
- IBM® Key Protect for IBM Cloud®
N'oubliez pas que la suppression d'une base de données entraîne également la suppression des sauvegardes qui lui sont associées. Toutefois, les bases de données supprimées peuvent être récupérées dans un délai limité. Reportez-vous à la documentation sur les sauvegardes de la FAQ pour obtenir des détails spécifiques sur les procédures de récupération de la base de données.
Il n'est pas possible de copier des sauvegardes à partir du site IBM Cloud, il faut donc envisager d'utiliser les outils spécifiques à la base de données pour effectuer des sauvegardes supplémentaires. Il peut être nécessaire de récupérer une base de données malveillante supprimée, suivie d'une réclamation-suppression de la base de données. Une gestion rigoureuse de l'accès IAM aux bases de données peut contribuer à réduire l'exposition à ce problème.
La liste de contrôle suivante, associée à chaque caractéristique, peut vous aider à créer et à mettre en pratique votre plan.
- Restauration de la sauvegarde
- Vérifier que les sauvegardes sont disponibles à la fréquence souhaitée pour répondre aux exigences du RPO. La gestion des sauvegardes sur Cloud Databases documente la fréquence des sauvegardes. Envisagez un script utilisant IBM Cloud® Code Engine- Working with the Periodic timer(cron)event producer pour créer des sauvegardes supplémentaires à la demande afin d'améliorer le RPO si la criticité et la taille de la base de données le permettent.
- Il existe certaines restrictions sur les régions de restauration des bases de données - vérifiez que vos objectifs de restauration peuvent être atteints en lisant la rubrique gestion des sauvegardes du site Cloud Databases.
- Vérifiez que la durée de conservation des sauvegardes est conforme à vos exigences.
- Planifiez régulièrement des restaurations de test pour vérifier que les temps de restauration réels respectent le RTO défini. N'oubliez pas que la taille de la base de données a un impact significatif sur le temps de restauration. Envisagez des stratégies pour réduire les temps de restauration, par exemple en divisant les grandes bases de données en unités plus petites et plus faciles à gérer et en purgeant les données inutilisées.
- Vérifiez le service Key Protect.
- Restauration avec point de cohérence
- Vérifier les procédures décrites précédemment.
- Vérifier que la sauvegarde souhaitée se trouve dans la fenêtre.
Pour plus d'informations sur la répartition des responsabilités entre le client et IBM Cloud pour l'utilisation de Databases for MongoDB, voir Partage des responsabilités pour Cloud Databases.
Restez informé : IBM notifications
Les mises à jour affectant les charges de travail des clients sont communiquées par le biais de notifications à l'adresse IBM Cloud. Pour rester informé de la maintenance planifiée, des annonces et des notes de version relatives à ce service, reportez-vous à la rubrique Suivi des notifications et de l'état. En outre, il convient de consulter régulièrement la politique en matière de versions pour connaître les dernières mises à jour concernant les versions et les dates de fin de vie.