Les déploiements de clusters sont d'une grande importance pour garantir la haute disponibilité des données ainsi que pour les protéger. MongoDB améliore cela grâce à la réplication et au sharding, la réplication assurant une mise à l'échelle verticale en supprimant la redondance, tandis que le sharding gonfle la mise à l'échelle horizontale.
En général, les deux approches tentent de répartir la charge de travail entre les membres et ainsi de réduire la charge de travail à laquelle un seul nœud pourrait être soumis. Les performances de la base de données peuvent alors être considérées comme rapides pour servir les utilisateurs avec des opérations de débit. Cependant, sans une architecture de cluster principale, vous ne verrez peut-être pas le même niveau de résultats, même si vous essayez le partitionnement et la réplication.
Si les membres du jeu de répliques sont pairs, il sera alors difficile pour les membres de voter et d'élire un nouveau primaire si celui existant échoue à un moment donné. Dans ce blog, nous allons discuter de l'architecture de déploiement standard que l'on peut utiliser, mais cela peut varier en fonction des exigences de l'application.
Stratégies de déploiement de MongoDB
L'architecture des jeux de répliques est très déterminante pour la capacité et les capacités de MongoDB.
Un jeu de répliques à trois nœuds est le déploiement de cluster standard pour MongoDB dans n'importe quel environnement de production, car il fournit la redondance des données et la tolérance aux pannes. La redondance est importante, en particulier dans la récupération de bases de données après un sinistre. Un jeu de répliques à trois nœuds peut constituer l'architecture de déploiement de base, mais cela peut varier en fonction des spécifications et des exigences de l'application. Cependant, ne le rendez pas trop complexe car cela pourrait vous conduire à des problèmes de configuration plus importants.
Stratégies de partitionnement MongoDB
Le partitionnement réduit la charge de travail sur laquelle la base de données doit travailler pour une requête donnée en réduisant le nombre de documents sur lesquels il faut agir. Il élève donc la mise à l'échelle horizontale permettant à la base de données de croître au-delà des limites matérielles d'un seul serveur. En fonction de la demande de charge de travail, des nœuds peuvent être ajoutés ou supprimés du cluster et MongoDB rééquilibrera les données de manière optimale sans intervention opérationnelle.
Certaines des meilleures stratégies de déploiement pour un cluster partitionné incluent :
S'assurer que les clés de partition sont distribuées uniformément
La raison du sharding est de redimensionner la base de données horizontalement et de réduire le nombre d'opérations de débit auxquelles une seule instance pourrait être soumise. Si vous ne distribuez pas les clés de partition uniformément, vous risquez de vous retrouver avec un petit nombre de partitions. Avec peu de partitions, les opérations peuvent être limitées par la capacité d'une seule partition, ce qui ralentit les opérations de lecture et d'écriture.
Les morceaux doivent être pré-divisés et distribués en premier
Les partitions ont des blocs de données qui sont regroupés selon certains critères de clé de partition. Lors de la création d'une nouvelle collection partitionnée, avant de la charger avec des données, vous devez créer des blocs vides et les répartir uniformément sur toutes les partitions. Lorsque vous remplirez MongoDB avec des données, il sera facile d'équilibrer la charge entre les fragments impliqués. L'option numInitialChunks peut être utilisée pour les effectuer automatiquement si vous utilisez le partitionnement basé sur le hachage. La valeur entière doit cependant être inférieure à 8192 par partition.
Nombre de fragments
Deux partitions sont souvent requises comme nombre minimum pour que la signification du partitionnement soit atteinte. Une seule partition n'est utile que si vous souhaitez jeter les bases de l'activation de la partition à l'avenir et que vous n'en avez pas besoin pendant la durée du déploiement.
Préférez le partage basé sur la plage au partage basé sur le hachage
Le partitionnement basé sur la plage est avantageux car il fournit plus de fragments, par conséquent, les opérations peuvent être acheminées vers le moins de fragments nécessaires et plus souvent un seul fragment. En pratique, cela peut être difficile, sauf si vous avez une bonne compréhension des modèles de données et de requêtes impliqués. Le partage haché améliore la distribution uniforme des opérations de débit au détriment de la fourniture d'opérations inférieures basées sur la plage.
Utiliser les requêtes Scatter-Gather uniquement pour les grandes requêtes d'agrégation
Les requêtes qui ne peuvent pas être acheminées en fonction d'une clé de partition doivent être diffusées à toutes les partitions pour évaluation et, comme elles impliquent plusieurs partitions pour chaque requête, elles ne s'échelonnent pas de manière linéaire à mesure que d'autres partitions sont ajoutées, ce qui entraîne une surcharge qui dégrade les performances de la base de données. Cette opération est connue sous le nom de scatter-gather et ne peut être évitée que si vous incluez la clé de partition dans votre requête.
L'approche n'est utile que lorsqu'il s'agit de requêtes d'agrégation volumineuses pour lesquelles chaque requête peut être autorisée à s'exécuter en parallèle sur toutes les partitions.
Stratégies de réplication MongoDB
La réplication améliore la mise à l'échelle verticale dans MongoDB de sorte que la charge de travail est répartie entre les membres impliqués. Dans l'environnement de production, voici quelques-unes des considérations à prendre en compte pour une architecture de cluster optimale.
Nombre de nœuds
Le nombre maximal de nœuds qu'un jeu d'instances dupliquées peut avoir est de 50 avec 7 membres votants. Tout membre après le 7 est considéré comme non votant. Un bon cluster devrait donc avoir 7 membres votants pour faciliter le processus d'élection.
Déployez un nombre impair de membres votants et si vous avez seulement moins de 7 mais un nombre pair de membres, alors vous devrez déployer un arbitre en tant qu'autre membre votant. Les arbitres ne stockent pas de copie des données et nécessiteront donc moins de ressources à gérer. De plus, on peut les soumettre à un environnement auquel vous ne pourriez pas soumettre les autres membres.
Considérations sur la tolérance aux pannes
Parfois, certains membres peuvent devenir indisponibles en raison de facteurs tels que des pannes de courant ou des transitoires et des déconnexions du réseau. Le nombre de membres qui restent dans l'ensemble et capables d'élire une primaire créent une situation connue sous le nom de tolérance aux pannes. C'est donc la différence entre le nombre total de membres du jeu de répliques et la majorité des membres votants nécessaires pour élire une primaire. L'absence d'un primaire signifie que les opérations d'écriture ne peuvent pas être exécutées.
Le tableau ci-dessous montre un exemple de relation entre les trois.
| Nombre total de membres du jeu de répliques | Majorité requise pour élire un nouveau primaire | Tolérance aux pannes |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
| 6 | 4 | 2 |
| 7 | 5 | 2 |
La relation n'est pas aussi directe dans la mesure où si vous ajoutez plus de membres à l'ensemble, il n'est pas donné que la tolérance aux pannes augmentera comme le montre le tableau. Des membres supplémentaires fournissent une assistance pour des fonctions dédiées telles que les sauvegardes et la création de rapports.
Planification des capacités et équilibrage de charge pour les lectures intensives
Vous devez disposer d'une capacité de réserve pour votre déploiement en ajoutant de nouveaux membres avant que la demande actuelle ne sature la capacité de l'ensemble existant.
Pour un trafic de lecture très élevé, distribuez les lectures de débit aux membres secondaires et chaque fois que le cluster se développe, ajoutez ou déplacez des membres vers d'autres centres de données afin d'obtenir une redondance et d'augmenter la disponibilité des données.
Vous pouvez également utiliser des opérations cibles avec des ensembles de balises pour cibler des opérations de lecture sur des membres spécifiques ou modifier une préoccupation d'écriture pour demander un accusé de réception à des membres spécifiques.
Les nœuds doivent être répartis géographiquement
Les centres de données peuvent également échouer en raison d'une catastrophe . Il est donc conseillé de garder au moins un ou deux membres dans un centre de données séparé à des fins de protection des données. Si possible, utilisez un nombre impair de centres de données et sélectionnez une distribution qui maximise la probabilité que même avec la perte d'un centre de données, les membres restants de l'ensemble de répliques puissent former une majorité ou au minimum fournir une copie des données.
Employer la journalisation pour les échecs inattendus
Par défaut, ceci est activé dans MongoDB. Vous devez vous assurer que cette option est activée afin de protéger la perte de données en cas d'interruptions de service telles que des redémarrages soudains et des pannes de courant.
Modèles de déploiement
Il existe principalement deux approches de déploiement :
- Trois jeux de répliques membres qui fournissent l'architecture minimale recommandée pour un jeu de répliques.
- Ensemble de réplicas distribué sur deux ou plusieurs centres de données pour se protéger contre les pannes spécifiques à l'installation, telles que les pannes de courant.
Les modèles dépendent cependant des exigences de l'application, mais si possible, vous pouvez combiner les fonctionnalités de ces deux dans votre architecture de déploiement.
Noms d'hôte et dénomination des ensembles de répliques
Utilisez un nom d'hôte DNS logique plutôt qu'une adresse IP lors de la configuration des membres du jeu de réplicas ou des membres du cluster partitionné. Ceci afin d'éviter la douleur liée aux modifications de configuration que vous devrez effectuer à la suite de la modification des adresses IP.
Dans le cas d'un nom de jeu de répliques, utilisez des noms distincts pour les jeux puisque certains pilotes regroupent les connexions de jeux de répliques par nom de jeu de répliques.
Conclusion
La disposition de l'architecture d'un jeu de réplicas détermine la capacité et les possibilités de votre déploiement. La protection des données et les performances du système sont au cœur des considérations lors de la configuration de l'architecture. Il convient de prendre en compte des facteurs vitaux tels que la tolérance aux pannes, le nombre de membres du jeu de répliques, la clé de partitionnement optimale et les modèles de déploiement pour une haute disponibilité et la protection des données. La distribution géographique des nœuds du jeu de répliques peut répondre à la plupart de ces facteurs en assurant la redondance et en offrant une tolérance aux pannes si l'un des centres de données est absent.
