Considérations pour l'administration de MongoDB

Vous trouverez ci-dessous un extrait de notre livre blanc "MongoDB Management and Automation with ClusterControl" qui peut être téléchargé gratuitement.

Considérations pour l'administration de MongoDB

Redondance intégrée

Une caractéristique clé de MongoDB est sa redondance intégrée, sous forme de réplication. Si vous avez deux nœuds de données ou plus, ils peuvent être configurés comme un jeu de répliques, dans lequel toutes les données écrites sur le nœud principal sont répliquées en temps quasi réel sur les nœuds secondaires,

assurer plusieurs copies des données. Dans le cas d'un basculement principal, les nœuds restants du jeu de réplicas procèdent à une élection et promeuvent le gagnant comme principal, un processus qui prend généralement 2 à 3 secondes et les écritures dans le jeu de réplicas peuvent reprendre. MongoDB utilise également un journal pour des écritures plus rapides et plus sûres sur le serveur ou le jeu de réplicas, et emploie également une méthode de « préoccupation d'écriture » grâce à laquelle le niveau de redondance d'écriture est
configuré.

Pour déployer manuellement un jeu de répliques, les étapes de haut niveau sont les suivantes :

1. Allouez un seul hôte physique ou virtuel pour chaque nœud de base de données et installez le client de ligne de commande MongoDB sur votre bureau. Pour une configuration de jeu de réplicas redondants, un minimum de trois nœuds est requis, dont au moins deux seront des nœuds de données. Un nœud du jeu de répliques peut être configuré en tant qu'arbitre :il s'agit d'un processus mongod configuré uniquement pour constituer un quorum en fournissant un vote lors de l'élection d'un primaire si nécessaire. Les données ne sont pas répliquées dans les processus arbitres.
2. Installez MongoDB sur chaque nœud. Certaines distributions Linux incluent MongoDB Community Edition, mais sachez que celles-ci peuvent ne pas inclure les dernières versions. MongoDB Enterprise est disponible uniquement par téléchargement à partir du site Web de MongoDB. Des fonctionnalités similaires à MongoDB Enterprise sont également disponibles via Percona Server pour MongoDB, un remplacement direct de MongoDB Enterprise ou Community Edition.
3. Configurez les fichiers de configuration mongod.conf individuels pour votre jeu de répliques, à l'aide du "paramètre de réplication". Si vous comptez utiliser un fichier clé pour la sécurité, configurez-le également maintenant. Notez que l'utilisation de la sécurité des fichiers de clés permet également l'authentification basée sur les rôles, vous devrez donc également ajouter des utilisateurs et des rôles pour utiliser les serveurs. Redémarrez le processus mongod sur chaque serveur.
4. Assurez-vous de la connectivité entre les nœuds. Vous devez vous assurer que les nœuds du jeu de répliques MongoDB peuvent communiquer entre eux sur le port 27017, et également que vos clients peuvent se connecter à chacun des nœuds du jeu de répliques sur le même port.
5. À l'aide du client de ligne de commande MongoDB, connectez-vous à l'un des serveurs et exécutez rs.initiate() pour initialiser votre jeu de répliques, suivi de rs.add() pour chaque nœud supplémentaire. rs.conf() peut être utilisé pour afficher la configuration.

Bien que ces étapes ne soient pas aussi complexes que le déploiement et la configuration d'un cluster partitionné MongoDB, ou le partitionnement d'une base de données relationnelle, elles peuvent être onéreuses et sujettes aux erreurs, en particulier dans les environnements plus vastes.

Évolutivité

MongoDB est souvent qualifié de logiciel de base de données "à l'échelle du Web", en raison de sa capacité à évoluer horizontalement. Comme les bases de données relationnelles, il est possible de faire évoluer MongoDB verticalement, simplement en mettant à niveau l'hôte physique sur lequel il réside avec plus de cœurs de processeur, plus de RAM, des disques plus rapides ou même une vitesse de bus accrue. La mise à l'échelle verticale a cependant ses limites, à la fois en termes de rapport coût-bénéfice et de rendements décroissants, et de limitation technique. Pour résoudre ce problème, MongoDB dispose d'une fonctionnalité de "sharding automatique", qui permet aux bases de données d'être réparties sur plusieurs hôtes (ou jeux de réplicas, pour la redondance). Bien que le partitionnement soit également possible sur les plates-formes relationnelles, à moins qu'il ne soit conçu pour la création de la base de données, cela nécessite une refonte majeure du schéma et de l'application, ainsi qu'une refonte de l'application cliente, ce qui en fait un processus fastidieux, chronophage et sujet aux erreurs.

Le partitionnement MongoDB fonctionne en introduisant un processus de routeur, par lequel les clients se connectent au cluster partitionné, et des serveurs de configuration, qui stockent les métadonnées du cluster, l'emplacement dans le cluster de chaque document. Lorsqu'un client soumet une requête au processus du routeur, il se réfère d'abord aux serveurs de configuration pour obtenir les emplacements des documents, puis obtient les résultats de la requête directement à partir des serveurs individuels ou
des jeux de répliques (fragments). Le sharding est effectué par collection.

Un paramètre extrêmement important ici, à des fins de performances, est la "clé de partition", un champ indexé ou un champ composé qui existe dans chaque document d'une collection. C'est cela qui définit la distribution des écritures sur les fragments d'une collection. Ainsi, une clé de partition mal choisie peut avoir un effet très néfaste sur les performances. Par exemple, une clé de partition purement basée sur des séries chronologiques peut entraîner toutes les écritures sur un seul nœud pendant de longues périodes. Cependant, une clé de partition hachée, tout en répartissant uniformément les écritures sur les partitions, peut avoir un impact sur les performances de lecture car un ensemble de résultats est récupéré à partir de nombreux nœuds.

Arbitres

Un arbitre MongoDB est un processus mongod qui a été configuré pour ne pas agir comme un nœud de données, mais pour fournir uniquement la fonction de vote lorsqu'un jeu de réplicas primaire doit être élu, pour rompre les égalités et se prémunir contre un vote partagé. Un arbitre ne peut pas devenir principal, car il ne détient pas de copie des données ou n'accepte pas les écritures. Bien qu'il soit possible d'avoir plusieurs arbitres dans un jeu de répliques, cela n'est généralement pas recommandé.

Membres de l'ensemble de réplicas retardés

Les membres de jeu de réplicas retardés ajoutent un niveau supplémentaire de redondance, en maintenant un état qui est un nombre fixe de secondes derrière le primaire. Comme les membres retardés sont une "sauvegarde progressive" ou un instantané "historique" en cours d'exécution de l'ensemble de données, ils peuvent aider à récupérer de divers types d'erreurs humaines.

Les membres retardés sont des membres de jeux de réplicas "cachés", invisibles pour les applications clientes et ne peuvent donc pas être interrogés directement. Ils peuvent également ne pas devenir principaux pendant les opérations normales et doivent être reconfigurés manuellement dans le cas où ils doivent être utilisés pour récupérer d'une erreur.

Sauvegardes

La sauvegarde d'un jeu de répliques ou d'un cluster fragmenté est effectuée via l'utilitaire de ligne de commande "mongodump". Lorsqu'il est utilisé avec le paramètre --oplog, cela crée un vidage de la base de données qui inclut un oplog, pour créer un instantané à un instant donné de l'état d'une instance mongod. En utilisant mongorestore avec le paramètre --replayOplog, vous pouvez ensuite restaurer complètement l'état des données au moment où la sauvegarde est terminée, en évitant les incohérences.

Pour des exigences de sauvegarde plus avancées, un outil tiers appelé "mongodbconsistent-backup" - également basé sur la ligne de commande - est disponible et fournit des sauvegardes entièrement cohérentes des clusters partitionnés, une procédure complexe, étant donné que les bases de données partitionnées sont réparties sur plusieurs hôtes.

Surveillance

Il existe un certain nombre d'outils commerciaux, officiels et non officiels, disponibles sur le marché pour surveiller MongoDB. Ces outils, en général, sont des utilitaires de gestion de produit unique, se concentrant exclusivement sur MongoDB. Beaucoup se concentrent uniquement sur certains aspects spécifiques, comme la gestion des collections dans une architecture MongoDB existante, ou sur les sauvegardes, ou sur le déploiement. Sans une planification adéquate, cela peut conduire à une situation où une prolifération d'outils supplémentaires doivent être déployés et gérés dans votre environnement.

Les outils de ligne de commande fournis avec MongoDB, "mongotop" et "mongostat" peuvent fournir une vue détaillée des performances de votre environnement et peuvent être utilisés pour diagnostiquer les problèmes. De plus, le client de ligne de commande "mongo" de MongoDB peut également exécuter "rs.status()" - ou dans un cluster fragmenté "sh.status() - pour afficher l'état des jeux de réplicas ou des clusters et leurs hôtes membres. La commande "db.stats()" renvoie un document qui traite de l'utilisation du stockage et des volumes de données, et leurs équivalents pour les collections, ainsi que d'autres appels pour accéder à de nombreuses métriques internes.

Synopsis

Ceci a été un bref résumé des considérations pour l'administration de MongoDB. Même à un niveau aussi élevé, il devrait être immédiatement évident que s'il est possible d'administrer un jeu de répliques ou un cluster fragmenté à partir de la ligne de commande à l'aide des outils disponibles, cela ne s'adapte pas dans un environnement avec de nombreux jeux de répliques ou avec une grande production. cluster fragmenté. Dans les environnements moyens à grands comprenant de nombreux hôtes
et bases de données, il devient rapidement impossible de tout gérer avec des outils de ligne de commande et des scripts. Bien que des outils et des scripts internes puissent être développés pour déployer et maintenir l'environnement, cela ajoute la charge de la gestion des nouveaux développements, des systèmes de contrôle des révisions et des processus. Une simple mise à niveau d'un serveur de base de données peut devenir un processus complexe si des modifications d'outillage sont nécessaires pour prendre en charge de nouvelles
versions de serveur de base de données.

Mais sans outils et scripts internes, comment automatiser et gérer les clusters MongoDB ? Téléchargez le livre blanc pour savoir comment !