Le déploiement de MongoDB en production ne peut vraiment fonctionner que si le bon modèle de déploiement est respecté. Le déploiement d'un jeu de répliques sur un seul hôte ne garantit pas la haute disponibilité des données. La gestion des mégadonnées nécessite des recherches approfondies et des implémentations optimales, soit en combinant les options disponibles, soit en choisissant celle qui présente les avantages les plus prometteurs.
Les modèles de déploiement pour MongoDB incluent :
- Ensembles de répliques à trois membres
- Ensembles de réplicas répartis sur deux centres de données ou plus
Ensembles de répliques à trois membres
La réplication est une stratégie de mise à l'échelle pour MongoDB qui améliore la haute disponibilité des données. Un jeu de réplicas implique :
- Un nœud principal :responsable de toutes les opérations de débit d'écriture et peut également être lu.
- Nœuds secondaires :ne peuvent être utilisés que pour les opérations de lecture, mais peuvent être élus comme nœuds principaux en cas d'échec du nœud existant. Ils obtiennent leurs mises à jour de données à partir d'un oplog généré par le membre principal de l'ensemble.
- Arbitre. Utilisé pour faciliter l'élection d'un primaire en cas de nombre pair de membres du jeu de réplicas. Il n'héberge aucune copie des données.
Les avantages d'un jeu de répliques ne peuvent être obtenus qu'avec un nombre minimum de trois membres avec l'architecture suivante :
Primaire-Secondaire-Secondaire
C'est le plus recommandé car il a une plus grande tolérance aux pannes et répond aux limitations de l'ajout d'un troisième membre porteur de données tel que le coût.
Ce déploiement fournira toujours deux copies complètes en plus des données principales, garantissant ainsi une haute disponibilité. L'échec du primaire déclenchera l'ensemble de réplicas pour élire un nouveau primaire et l'opération de service reprendra normalement. Si l'ancien membre principal devient actif, il sera classé comme membre secondaire.
Pendant le processus électoral, les membres se signalent par un battement de cœur et aucune opération d'écriture n'a lieu pendant ce temps
Après le processus électoral, nous supposons que l'architecture se réforme comme :
Arbitre-Primaire-Secondaire
Cela garantit que le jeu de répliques reste disponible même si le primaire ou le secondaire n'est pas disponible en facilitant le processus d'élection d'un secondaire à un primaire. Les arbitres n'ont aucune copie des données et nécessitent donc moins de ressources à gérer.
Une limitation avec ce déploiement est ; pas de redondance puisqu'il n'y a que deux membres porteurs de données :primaire et secondaire. Cela se traduit par une tolérance aux pannes inférieure.
La tolérance aux pannes doit pouvoir garantir :
- Disponibilité en écriture :la majorité des membres votants de l'ensemble de réplicas est nécessaire pour maintenir ou élire le principal responsable des opérations d'écriture.
- Redondance des données :l'écriture peut être acquittée par plusieurs membres pour éviter les retours en arrière
La configuration Primary-Secondary-Arbiter ne prend en charge que l'aspect de disponibilité en écriture, de sorte que si un seul membre de l'ensemble est indisponible, un primaire peut toujours être maintenu.
Cependant, l'absence de prise en charge du deuxième aspect entraîne certaines conséquences opérationnelles si le membre secondaire devient indisponible :
- Il n'y aura pas de réplication active, surtout si le secondaire est hors ligne pendant longtemps. Lorsque le secondaire est hors ligne pendant trop longtemps, il peut tomber de l'oplog, ce qui oblige à le resynchroniser lors du redémarrage.
- La redondance des données sera sabotée, forçant l'opération d'écriture à être acquittée uniquement par le principal actuel.
- L'option Majorité avec préoccupation ne fournira pas les données les plus récentes aux applications connectées et aux processus internes. C'est le cas lorsque votre configuration s'attend à ce que les écritures demandent un accusé de réception majoritaire et sont donc bloquées jusqu'à ce que la majorité des membres porteurs de données soient disponibles.
- La migration de fragments entre les fragments sera également compromise si le jeu de réplicas fait partie d'un cluster fragmenté.
- Pression sur le cache du moteur de stockage WiredTiger si des restaurations se produisent et que le point de validation majoritaire ne peut pas être avancé.
Pour éviter ces conséquences, on peut opter pour une configuration Primaire-Secondaire-Secondaire car elle augmente la tolérance aux pannes.
Remarque :la tolérance aux pannes n'intervient pas uniquement en cas de panne, mais certaines opérations système telles que la mise à niveau du logiciel et la maintenance normale peuvent obliger un membre à être brièvement indisponible.
Ensembles de répliques répartis sur deux centres de données ou plus
La haute disponibilité peut être élevée à un autre niveau en répartissant les membres du jeu de réplicas dans des centres de données géographiquement distincts. Cette approche augmentera la redondance en plus d'assurer une tolérance élevée aux pannes en cas d'indisponibilité d'un centre de données.
Si tous les membres sont situés dans un seul centre de données, le jeu de réplicas est sensible aux défaillances du centre de données telles que les transitoires du réseau et les pannes de courant.
Il est conseillé de conserver au moins un membre dans un autre centre de données, utilisez un nombre impair de centres de données et sélectionnez une répartition des membres qui offrira une majorité pour l'élection ou fournira au minimum une copie des données en cas d'échec.
La configuration doit garantir que si un centre de données tombe en panne, le jeu de répliques reste accessible en écriture puisque les membres restants peuvent organiser une élection.
Distribuez vos données au moins sur trois centres de données.
Les membres peuvent être limités aux ressources ou avoir des contraintes de réseau, ce qui les rend inaptes à devenir principaux en cas de basculement. Vous pouvez configurer ces membres pour qu'ils ne deviennent pas principaux en leur donnant la priorité 0.
Les membres d'un centre de données peuvent avoir une priorité plus élevée que les autres centres de données pour leur donner une priorité de vote afin qu'ils puissent élire le principal avant les membres des autres centres de données.
Tous les membres de l'ensemble de répliques doivent pouvoir communiquer entre eux.
Conclusion
Les avantages de la réplication peuvent être élevés à un statut plus prometteur en répartissant les membres sur un certain nombre de centres de données. Cela augmente essentiellement la tolérance aux pannes en plus d'assurer la redondance des données. Les membres de l'ensemble de répliques, lorsqu'ils sont répartis sur deux centres de données ou plus, offrent des avantages par rapport à un seul centre de données, tels que :
Si l'un des centres de données tombe en panne, les données sont toujours disponibles pour les lectures contrairement à une distribution de centre de données unique.
Les opérations d'écriture peuvent toujours être reconnues chaque fois qu'un centre de données avec des membres minoritaires tombe en panne.
Les opérations de lecture peuvent toujours être possibles si le centre de données avec les membres votants majoritaires tombe en panne, contrairement au cas d'un centre de données unique.
