Maintenir les ensembles de répliques MongoDB dans le cloud à l'aide d'Ansible

La réplication a été largement appliquée dans les systèmes de bases de données pour assurer une haute disponibilité des données en créant une redondance. Il s'agit essentiellement d'une stratégie consistant à faire une copie des mêmes données sur différents serveurs en cours d'exécution pouvant se trouver sur différentes machines afin qu'en cas de panne du serveur principal, un autre puisse être amené à continuer le service.

Un jeu de répliques est un groupe d'instances MongoDB qui conservent le même ensemble de données. Ils sont à la base des déploiements en production. La réplication est avantageuse par le fait que les données sont toujours disponibles à partir d'un serveur différent au cas où le système du serveur principal tomberait en panne. En outre, il améliore le débit de lecture en permettant à un client d'envoyer une demande de lecture à différents serveurs et d'obtenir une réponse du plus proche.

Un jeu de répliques constitue plusieurs nœuds porteurs de données qui pourraient être hébergés dans différentes machines et un nœud arbitre. L'un de ces nœuds porteurs de données est étiqueté comme nœud principal tandis que les autres sont des nœuds secondaires. Le nœud principal reçoit toutes les opérations d'écriture, puis réplique les données sur les autres nœuds une fois l'opération d'écriture terminée et les modifications enregistrées dans un oplog.

Un arbitre est une instance supplémentaire qui ne maintient pas un jeu de données mais fournit un quorum dans un jeu de répliques en répondant aux demandes de pulsation et d'élection par d'autres membres du jeu de répliques. Ils réduisent ainsi le coût de maintenance d'un jeu de répliques plutôt qu'un ensemble entièrement fonctionnel. membre du jeu de répliques avec un jeu de données.

Basculement automatique

Un nœud principal peut tomber en panne pour certaines raisons telles que des pannes de courant ou une déconnexion du réseau, ce qui l'empêche de communiquer avec les autres membres. Si la communication est coupée pendant plus que la période configurée electionsTimeoutMillis, l'un des secondaires appelle à une élection pour se désigner comme nouveau primaire. Si l'élection est terminée et réussie, le cluster poursuit son fonctionnement normal. Pendant cette période, aucune opération d'écriture ne peut être effectuée. Cependant, les requêtes de lecture peuvent être configurées pour se dérouler normalement sur les secondaires pendant que le principal est hors ligne.

Pour un processus de réplication optimal, le temps médian avant que le cluster élise un nouveau primaire au maximum doit être de 12 secondes avec les paramètres de configuration de réplication par défaut. Cela peut être affecté par des facteurs tels que la latence du réseau qui peut prolonger le temps, il faut donc tenir compte de l'architecture du cluster pour s'assurer que ce temps n'est pas trop élevé.

La valeur de electionsTimeoutMillis peut être abaissée par rapport à la valeur par défaut de 10 000 (10 secondes), de sorte que le primaire peut être détecté en premier pendant très rapidement. Cependant, cela peut entraîner des élections fréquentes, même pour des facteurs mineurs tels que la latence temporaire du réseau, même si le nœud principal est sain. Cela entraînera des problèmes tels que des restaurations pour les opérations d'écriture.

Ansible pour les ensembles de répliques

Comme mentionné, un jeu de répliques peut avoir des membres provenant de différentes machines hôtes, ce qui rend plus complexe la maintenance du cluster. Nous avons besoin d'une plate-forme unique à partir de laquelle cet ensemble de réplicas peut être maintenu facilement. Ansible est l'un des outils qui offre une meilleure vue d'ensemble pour la configuration et la gestion d'un jeu de répliques. Si vous êtes nouveau sur ansible, veuillez lire un bref récapitulatif de cet article pour comprendre les bases telles que la création d'un playbook.

Paramètres de configuration

arbitre_at_index : cela définit la position de l'arbitre dans la liste des membres du jeu de répliques. Un rappel d'arbitre n'a pas de données comme les autres membres et ne peut pas être utilisé comme nœud principal. Il n'est disponible que pour créer un quorum pendant l'élection. Par exemple si vous avez un nombre pair de membres, il est bon d'ajouter un arbitre tel que si les votes sont égaux, il ajoute un 1 pour faire un membre gagnant. La valeur à attribuer doit être un entier.
chaining_allowed : Cela prend une valeur booléenne et définit si les autres membres secondaires doivent répliquer à partir des autres membres secondaires si le chaînage _allowed =true. Sinon, si le chaînage _allowed =false, les autres membres secondaires ne peuvent répliquer qu'à partir du primaire. La valeur par défaut est true.
election_timeout_secs : par défaut la valeur est 10000 (prend une valeur entière). C'est le temps en millisecondes pour détecter quand le nœud principal n'est pas joignable ou plutôt ne communique pas avec les autres membres et déclenche donc une élection. Réglez-le sur une valeur médiane de 12 secondes. S'il est réglé trop haut, il faudra beaucoup de temps avant de détecter la panne primaire et donc plus de temps pour faire une élection. Comme cela affecte l'opération d'écriture, vous risquez de perdre beaucoup de données pendant cette période. En revanche s'il est fixé trop bas, il y aura des déclenchements fréquents d'élections même lorsque l'affaire n'est pas si grave et que la primaire reste accessible. Par conséquent, vous aurez tellement de retours en arrière pour les opérations d'écriture qui peuvent, à un moment donné, entraîner une mauvaise intégrité ou une incohérence des données.
heartbeat_timeout_secs : Les ensembles de répliques doivent communiquer entre eux avant une élection en envoyant un signal appelé battement de cœur. Les membres doivent alors répondre à cette signalisation dans un délai déterminé qui est fixé par défaut à 10 secondes. Heartbeat_timeout_secs est le nombre de secondes pendant lesquelles les membres du jeu de répliques attendent une pulsation réussie les uns des autres et si un membre ne répond pas, il est marqué comme inaccessible. Cependant, cela n'est applicable que pour la version 0 du protocole. La valeur de ceci est donc un entier.
login_host : Il s'agit de l'hôte qui héberge la base de données de connexion. Par défaut pour MongoDB est localhost.
login_database : la valeur par défaut est l'administrateur et c'est là que les identifiants de connexion sont stockés. (prend une valeur de chaîne)
login_user : le nom d'utilisateur avec lequel l'authentification doit être effectuée.(prend une valeur de chaîne)
login_password : le mot de passe pour authentifier l'utilisateur. (prend une valeur de chaîne)
login_port : Il s'agit du port MongoDB auquel l'hôte doit se connecter. (prend une valeur entière)
membres : définit une liste de membres du jeu de répliques. Il s'agit d'une chaîne séparée par une virgule ou une liste yaml, c'est-à-dire mongodb0:27017, mongodb2:27018, mongodb3:27019… S'il n'y a pas de numéro de port, alors le 27017 est supposé.
protocol_version : prend un entier qui définit la version du processus de réplication. Soit 0 soit 1
plica_set : il s'agit d'une valeur de chaîne qui définit le nom du jeu de réplicas.
SSL : valeur booléenne qui définit s'il faut utiliser ou non la connexion SSL lors de la connexion à la base de données.
ssl_certs_reqs : cela spécifie si un certificat est requis de l'autre côté de la connexion et s'il sera nécessaire de le valider s'il est fourni. Les choix pour cela sont CERT_NONE, CERT_OPTIONAL et CERT_REQUIRED. La valeur par défaut est CERT_REQUIRED.
valider : prend une valeur booléenne qui définit s'il faut effectuer une validation de base sur la configuration de jeu de répliques fournie. La valeur par défaut est true.

Création d'un ensemble de répliques MongoDB à l'aide d'Ansible

Voici un exemple simple de tâches pour configurer un jeu de réplicas dans ansible. Appelons ce fichier tasks.yaml

# Create a replicaset called 'replica0' with the 3 provided members
- name: Ensure replicaset replica0 exists
  mongodb_replicaset:
    login_host: localhost
    login_user: admin
    login_password: root
    replica_set: replica0
    arbiter_at_index:2
    election_timeout_secs:12000
    members:
    - mongodb1:27017
    - mongodb2:27018
    - mongodb3:27019
  when: groups.mongod.index(inventory_hostname) == 0

# Create two single-node replicasets on the localhost for testing
- name: Ensure replicaset replica0 exists
  mongodb_replicaset:
    login_host: localhost
    login_port: 3001
    login_user: admin
    login_password: root
    login_database: admin
    replica_set: replica0
    members: localhost:3000
    validate: yes

- name: Ensure replicaset replica1 exists
  mongodb_replicaset:
    login_host: localhost
    login_port: 3002
    login_user: admin
    login_password: secret
    login_database: root
    replica_set: replica1
    members: localhost:3001
    validate: yes

Dans notre playbook, nous pouvons appeler les tâches comme

---
- hosts: ansible-test
  remote_user: root
  become: yes
  Tasks:
- include: tasks.yml

Si vous l'exécutez dans votre playbook, ansible-playbook -i inventor.txt -c ssh mongodbcreateReplcaSet.yaml, une réponse vous sera présentée si le jeu de répliques a été créé ou non. Si la clé mongodb_replicaset est renvoyée avec une valeur de succès et une description du jeu de réplicas qui a été créé, alors vous êtes prêt à partir.

Conclusion

Dans MongoDB, il est généralement fastidieux de configurer un jeu de répliques pour les instances mongod qui peuvent être hébergées par différentes machines. Cependant, Ansible fournit une plate-forme simple pour faire de même en définissant simplement quelques paramètres, comme indiqué ci-dessus. La réplication est l'un des processus qui assure le fonctionnement continu de l'application et doit donc être bien configuré en définissant un nombre multiple de membres dans le monde de la production. Un arbitre est utilisé pour créer un quorum pendant le processus d'élection et doit donc être inclus dans le fichier de configuration en définissant sa position.