Déployer un jeu de réplicas à haute disponibilité dans MongoDB 3.4 à laide du fichier de clés pour le contrôle daccès sur Ubuntu 16.04

• A propos du jeu de répliques
• Conditions préalables
• Concevoir l'ensemble de répliques
• Instructions de déploiement
• Conclusion

Depuis sa conception en 2009, MongoDB est à la pointe de l'industrie NoSQL. L'un des concepts de base de MongoDB est le jeu de répliques, donc avant de travailler avec lui, examinons d'abord le concept.

A propos du jeu de répliques

Le modèle de communication le plus simple utilisé dans la réplication des bases de données est l'architecture maître-esclave. Comme son nom l'indique, ce modèle a 2 rôles qui sont répartis dans un maître unique et de nombreux esclaves, le rôle du maître est de traiter les opérations de lecture et d'écriture effectuées par les clients et les esclaves sont traités comme une réplique du maître.

L'avantage le plus important de ce modèle est que les performances du maître ne sont pas compromises par les opérations de sauvegarde, les opérations de sauvegarde sont effectuées de manière asynchrone et cela peut devenir un problème grave en cas de défaillance d'un nœud maître. Les nœuds esclaves sont en lecture seule et ils doivent être promus manuellement au nœud maître, donc dans ce temps, il y a la possibilité de perdre des données.

Une option pour résoudre le problème de disponibilité est d'avoir plus d'un maître dans l'architecture, mais cela peut entraîner un autre problème dans la cohérence des données entre ces instances et la complexité supplémentaire de la configuration.

Maintenant, dans un contexte donné, nous pouvons présenter la technologie Replica Set de MongoDB. Le jeu de répliques est le nom de l'architecture maître-esclave qui a un basculement automatique, donc au moment où un primarynœud maître (qui est maintenant nommé ) ne fonctionne pas correctement, un electiondéclencheur se déclenchera et un nouveau nœud principal sera choisi parmi les esclaves restants ( dénommé maintenant secondaries).

Noeud principal

Le nœud principal est le seul à effectuer des opérations d'écriture, par défaut, les opérations de lecture sont également gérées par le principal, mais ce comportement peut être modifié ultérieurement.

Les opérations sont enregistrées dans le oplog(journal des opérations), puis les nœuds secondaires mettent à jour leur contenu de manière asynchrone en fonction du contenu duoplog

Remarque: oplogest une collection plafonnée, cela signifie que la collection a une limite, avec local.oplog.rsvous pouvez vérifier le contenu de cette collection à l'intérieur d'un shell mongo dans n'importe quel membre de l'ensemble.

Noeud secondaire

En plus d'être ceux qui effectuent une sauvegarde correcte de la base de données, un nœud secondaire a ces rôles:

• Peut accepter des opérations de lecture si nécessaire.
• Peut déclencher une élection en cas de défaillance d'un nœud principal.
• Peut voter aux élections.
• Peut devenir la nouvelle primaire si nécessaire.

Grâce à ces caractéristiques, nous pouvons avoir différents types de nœuds secondaires:

• Priorité 0 : ces nœuds ne peuvent pas devenir un primaryet ne peuvent pas déclencher une élection, ils peuvent néanmoins voter aux élections, avoir une réplique complète et accepter les opérations de lecture. Ceux-ci peuvent être utiles dans le déploiement de plusieurs centres de données.
• Caché : ce sont des Priority 0membres, mais en plus ils ne peuvent pas traiter les opérations de lecture. Ils peuvent voter si nécessaire. Les tâches préférées de ces membres sont les rapports et les sauvegardes.
• Retardé : ces nœuds sont en charge des "données historiques" en étant retardés d'une unité dans le temps. Un membre retardé doit être un priority 0nœud, et il est recommandé qu'il soit hiddenégalement membre.

Conditions préalables

• La disponibilité pour exécuter au moins 3 instances d'Ubuntu 16.04 x64 avec la même taille de serveur.

Concevoir l'ensemble de répliques

Avant de déployer une infrastructure, il est important de la concevoir, et il y a des points à considérer dans cette conception.

Choix du nombre de membres

N'oubliez pas que le nombre minimum d'éléments pour créer un jeu de réplicas est de 3. Vous pouvez mélanger les trois types de nœuds avec au moins un nœud principal et un nœud secondaire.

Dans ce guide, nous déployons 3 membres, un primaire et deux secondaires standard.

Remarque: Il est recommandé d'avoir un nombre maximum de 7 membres votants avec un mélange d'arbitres et de membres secondaires.

Choisissez un nom

Le nom est juste pour référence mais vous l'utilisez dans la configuration de l'ensemble. Gardez à l'esprit que vous pouvez avoir plus d'un jeu de réplicas dans votre environnement de production, alors ne négligez pas le nom de votre jeu.

Ce didacticiel encourage l'utilisateur à sélectionner le nom de l'ensemble.

Répartition des membres dans différents centres de données

Ce didacticiel suggère de déployer sur le même centre de données afin d'éviter les problèmes de communication.

Remarque: En cas de déploiement dans différents centres de données, il est recommandé d'envelopper vos nœuds avec un VPN

Instructions de déploiement

Étape 1: déployer les nœuds minimum pour votre infrastructure

Lancez 3 nœuds d'Ubuntu 16.04 x64; dans la même région à partir de votre portail client, si possible. N'oubliez pas de les nommer en fonction du type de projet que vous traitez et assurez-vous d'avoir la même taille de serveur dans tous ces nœuds.

Après avoir déployé vos 3 nœuds, vous devrez vous assurer que chaque nœud peut parler avec les autres. Vous devez ssh en deux nœuds et atteindre les autres en utilisant ping -c 4 EXAMPLE_IP. Modifiez EXAMPLE_IPles adresses IP réelles de vos nœuds.

Ici, vous pouvez voir un exemple de communication réussie entre deux nœuds.

root@foo_node:~# ping -c 4 EXAMPLE_IP
PING EXAMPLE_IP (EXAMPLE_IP) 56(84) bytes of data.
64 bytes from EXAMPLE_IP: icmp_seq=1 ttl=59 time=0.594 ms
64 bytes from EXAMPLE_IP: icmp_seq=2 ttl=59 time=0.640 ms
64 bytes from EXAMPLE_IP: icmp_seq=3 ttl=59 time=0.477 ms
64 bytes from EXAMPLE_IP: icmp_seq=4 ttl=59 time=0.551 ms

--- EXAMPLE_IP ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3021ms
rtt min/avg/max/mdev = 0.477/0.565/0.640/0.064 ms

Étape 2: installez MongoDB dans chaque nœud de votre infrastructure

En général, vous pouvez utiliser le paquet MongoDB d'Ubuntu, mais il est préférable d'utiliser le dépôt officiel de la communauté car il est toujours à jour. Ce dépôt contient ces packages:

• mongodb-org , le package de groupe qui enveloppe les quatre composants.
• mongodb-org-server , il contient le mongoddémon (processus principal qui gère les demandes de données).
• mongodb-org-mongos , il contient le mongosdémon (service de routage pour les déploiements partagés).
• mongodb-org-shell , c'est l' mongo shellinterface JavaScript.
• mongodb-org-tools , quelques outils pour les activités d'administration.

Passez à l'installation des packages.

Importez la clé publique dans le système de gestion des packages.

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 0C49F3730359A14518585931BC711F9BA15703C6

Créez le fichier de liste pour MongoDB '/etc/apt/sources.list.d/mongodb-org-3.4.list'.

echo "deb [ arch=amd64,arm64 ] http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.4.list

Mettez à jour la base de données des packages.

sudo apt-get update

Installez le métapaquet MongoDB.

sudo apt-get install -y mongodb-org

Démarrez le service MongoDB.

sudo service mongod start

Vous pouvez maintenant ouvrir le mongo shelldans n'importe quelle session bash. Pour ce faire, vous devez utiliser la mongocommande. Vous serez accueilli par quelque chose de similaire à cela.

MongoDB shell version v3.4.7
connecting to: mongodb://127.0.0.1:27017
MongoDB server version: 3.4.7
Welcome to the MongoDB shell.
For interactive help, type "help".
For more comprehensive documentation, see http://docs.mongodb.org/
Questions? Try the support group
http://groups.google.com/group/mongodb-user
Server has startup warnings:
*Some extra logs are cut by the way*
>

N'oubliez pas de couper le service avec sudo service mongod stop, car plus tard nous mongodrecommencerons avec quelques paramètres. Répétez ce processus dans les 3 nœuds de l'ensemble.

Étape 3: configurer le fichier de clés d'accès

L'utilisation d'un fichier clé force deux concepts dans l'administration du jeu de réplicas. Le premier est Internal Authentication. Par défaut, vous pouvez démarrer une mongo shellsession sans utiliser d'utilisateur et cette session aura le contrôle total de la base de données, mais lorsque vous utilisez un fichier de clés pour l'authentification, votre mongo shellsession atteint un état appelé localhost exception. Cet état vous permet uniquement de créer l'utilisateur administrateur et le jeu de réplicas. Le deuxième concept est Role-Based Access Control, ou en d'autres termes, l'autorisation. Ceci est appliqué pour régir les niveaux administratifs du jeu de réplicas.

Créez votre fichier de clés

Le fichier de clés est le mot de passe à utiliser dans l'ensemble, ce mot de passe doit être le même pour tous les membres de l'ensemble. Pour augmenter la sécurité, il est important d'utiliser une clé aléatoire avec l'outil de votre choix.

Le contenu doit comporter entre 6 et 1064 caractères. Vous devez également définir l' read onlyautorisation pour le fichier de clés.

chmod 400 PATH_OF_YOUR_KEYFILE

Placer le fichier clé dans chaque membre du jeu

Copiez maintenant votre fichier de clés sur chaque membre de l'ensemble, veuillez utiliser un dossier cohérent pour référence future et ne le stockez pas sur un support amovible.

Utilisez également un dossier pour le fichier auquel vous mongodpouvez accéder.

Appliquer à l'aide du fichier de clés dans le jeu de réplicas

Dans cette étape, nous devons démarrer le mongod daemon dans chaque membre de l'ensemble . Il existe deux façons de démarrer le mongodprocessus: en utilisant un fichier de configuration ou en utilisant la ligne de commande. Les deux sont des méthodes assez simples, mais pour plus de simplicité, ce tutoriel utilise la version en ligne de commande.

Configuration de la ligne de commande

Utilisez le nom que vous avez choisi précédemment dans cette commande.

mongod --keyFile PATH_OF_YOUR_KEYFILE --replSet "YOUR_SET_NAME"

Par défaut, mongodne s'exécute pas en tant que démon. Vous devrez utiliser le --forkparamètre ou utiliser le upstartpour l'exécuter complètement en tant que démon. Dans ce didacticiel, nous n'encourageons pas l'exécution en mongodtant que démon afin que vous puissiez voir les journaux directement dans votre terminal.

Remarque: Tapez soigneusement le nom du jeu de réplicas, car une fois créé, vous ne pouvez pas le modifier.

Étape 4: Connectez-vous à l'interface localhost à partir de l'un des membres de l'ensemble

Remarque: Si vous exécutez en mongodtant que processus non démon, vous devrez alors ouvrir une autre connexion ssh pour continuer à travailler.

Vous devez utiliser la mongocommande pour ouvrir le fichier mongo shell. Cela peut être fait dans n'importe quel membre de l'ensemble.

En ce moment, nous sommes dans un état appelé localhost exception. Lorsqu'un fichier clé est utilisé pour configurer le mongodprocessus, vous êtes obligé de créer un administrateur de base de données avant de pouvoir appliquer des opérations de lecture-écriture, mais nous y reviendrons plus tard.

Étape 5: lancement du jeu de réplicas

C'est une partie délicate, nous utilisons la commande rs.initiate()à l'intérieur de l' mongo shellétape 4. Avant d'utiliser cette commande, examinons-la.

rs.initiate(
  {
    _id : <replicaSetName>,
    members: [
      { _id : 0, host : "example1.net:27017" },
      { _id : 1, host : "example2.net:27017" },
      { _id : 2, host : "example3.net:27017" }
    ]
  }
)

Le premier _idchamp est une chaîne et doit correspondre à celui --replSetqui a été transmis avant à mongod. En outre, chaque valeur de hostdoit être l'IP ou le nom de domaine de chaque membre du jeu de réplicas. N'oubliez pas d'ajouter le port que l'instance mongo utilise dans chaque membre.

Il est maintenant temps d'exécuter la commande avec vos données dessus, cela déclenchera un election, puis un primaire sera élu automatiquement.

Ici, vous devez noter que votre curseur shell a changé en YOUR_SET_NAME:PRIMARY>ou YOUR_SET_NAME:SECONDARY. Cela signifie que la création d'un ensemble a été un succès.

Pour continuer à travailler, vous devez trouver le primary, si vous n'y êtes pas bien sûr. Utilisez la rs.status()commande pour afficher les informations du jeu de réplicas et recherchez le fichier primary. Vous recherchez la propriété "stateStr" : "PRIMARY".

Étape 6: création de l'administrateur

Après avoir localisé le primary, entrez le mongo shellet exécutez la commande suivante à l'aide de vos données.

admin = db.getSiblingDB("admin")
admin.createUser(
  {
    user: "YOUR_USER",
    pwd: "YOU_PASSWORD",
    roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
  }
)

La admin = db.getSiblingDB("admin")partie nous permet d'écrire à adminpartir d'une base de données différente. Cela crée un alias appelé admin, afin que nous puissions exécuter des commandes à la place.

Si l'opération réussit, vous recevrez une notification indiquant que l'utilisateur a été ajouté.

Successfully added user: {
    "user" : "YOUR_USER",
    "roles" : [
        {
            "role" : "userAdminAnyDatabase",
            "db" : "admin"
        }
    ]
}

À ce stade, nous n'avons qu'un administrateur pour tous les serveurs, mais le fait d'avoir un jeu de réplicas nous oblige à avoir un utilisateur avec le clusterAdminrôle. Nous allons créer un autre utilisateur avec uniquement ce rôle pour séparer les préoccupations.

Étape 7: Authentification en tant qu'administrateur

Nous avons atteint la limite de la localhost exception, c'est pourquoi nous devons changer l'authentification à l'utilisateur créé une étape avant.

Vous pouvez changer les utilisateurs à l'intérieur du mongo shellavec ce qui suit.

db.getSiblingDB("admin").auth("YOUR_ADMIN", "YOUR_PASSWORD" )

Si vous n'êtes pas déjà connecté à la place, mongo shellutilisez cette commande.

mongo -u "YOUR_ADMIN" -p "YOUR_PASSWORD" --authenticationDatabase "admin"

Vous serez averti du changement d'un utilisateur et vous pourrez passer à l'étape suivante.

Étape 8: création du maître de cluster

Le clusterAdminrôle donne à l'utilisateur le contrôle total du jeu de réplicas. La création est aussi simple que la création de l'utilisateur administrateur.

db.getSiblingDB("admin").createUser(
  {
    "user" : "YOUR_USER",
    "pwd" : "YOUR_PASSWORD",
    roles: [ { "role" : "clusterAdmin", "db" : "admin" } ]
  }
)

Notez que cette fois le rôle est changé enclusterAdmin .

Étape 9: insertion de données dans le jeu de réplicas

En ce moment, nous avons 2 utilisateurs administrateurs: un qui a un contrôle total sur le serveur et un autre qui a accès aux tâches administratives au niveau du jeu de réplicas. Cependant, il nous manque un utilisateur qui a accès à "utiliser" une base de données, nous allons donc créer cet utilisateur maintenant.

admin = db.getSiblingDB("admin")
admin.createUser(
  {
    user: "YOUR_USER",
    pwd: "YOUR_PASSWORD",
    roles: [ { role: "userAdminAnyDatabase", db: "cars" } ]
  }
)

Remarquez que cette fois nous changeons de dbpièce, là nous mettons la base de données accessible à l'utilisateur, dans ce cas nous utilisons une base de données nommée cars.

La base de données n'est pas encore créée. Pour ce faire, vous devrez taper quelques commandes pour le créer implicitement. Basculez vers la carsbase de données.

use cars

Vous recevrez une notification: switched to db cars.

La base de données n'a toujours pas été créée, pour cela, vous devez y écrire quelque chose. Nous utilisons l'exemple suivant.

db.models.insert({ make: "Dodge", model: "Viper", year: 2010 })

Cette fois, vous en serez informé WriteResult({ "nInserted" : 1 }).

Si vous le souhaitez, vous pouvez récupérer tous les objets de la base de données, avec la find()méthode:

db.models.find()
{ "_id" : ObjectId("59acd8b55334882863541ff4"), "make" : "Dodge", "model" : "Viper", "year" : 2010 }

Notez que ce _idsera différent dans votre sortie, mais les autres données devraient être les mêmes. Avec suffisamment de temps, ces données seront répliquées vers les autres membres.

Conclusion

La création d'un jeu de répliques peut être difficile au début, car il y a beaucoup d'informations à comprendre, mais une fois que vous avez l'idée derrière vous, vous pouvez le déployer en un rien de temps, alors n'abandonnez pas si vous ne pouvez pas le saisir dans votre première fois. Gardez à l'esprit que le jeu de réplicas est important dans l'administration MongoDB car il ouvre la possibilité d'ajouter des fonctionnalités avancées telles que l'équilibrage de charge.