MongoDB
 sql >> Base de données >  >> NoSQL >> MongoDB

Les bases du déploiement d'un ensemble de répliques MongoDB et de fragments à l'aide de Puppet

Le système de base de données fonctionne mieux lorsqu'il est intégré à des approches bien définies qui facilitent à la fois les opérations de débit de lecture et d'écriture. MongoDB a fait un effort supplémentaire en adoptant la réplication et le sharding dans le but de permettre la mise à l'échelle horizontale et verticale par opposition aux DBM relationnels dont le même concept améliore uniquement la mise à l'échelle verticale.

 Le partitionnement assure la répartition de la charge entre les membres du cluster de bases de données afin que les opérations de lecture soient effectuées avec peu de latence. Sans partitionnement, la capacité d'un serveur de base de données unique avec un grand ensemble de données et des opérations à haut débit peut être techniquement contestée et peut entraîner une défaillance de ce serveur si les mesures nécessaires ne sont pas prises en compte. Par exemple, si le taux de requêtes est très élevé, la capacité CPU du serveur sera dépassée.

La réplication, quant à elle, est un concept dans lequel différents serveurs de base de données hébergent les mêmes données. Il garantit une haute disponibilité des données en plus d'améliorer l'intégrité des données. Prenons l'exemple d'une application de médias sociaux très performante, si le système de base de données principal de service tombe en panne, comme en cas de panne de courant, nous devrions avoir un autre système pour servir les mêmes données. Un bon jeu de répliques doit avoir plus de 3 membres, un arbitre et une électionTimeoutMillis optimale. Dans la réplication, nous aurons un nœud maître/primaire où toutes les opérations d'écriture sont effectuées puis appliquées à un Oplog. Depuis l'Oplog, toutes les modifications apportées sont ensuite appliquées aux autres membres, qui dans ce cas sont appelés nœuds secondaires ou esclaves. Dans le cas où les nœuds primaires ne communiquent pas après un certain temps :electionsTimeoutMillis, les autres nœuds sont signalés à aller pour une élection. Le electionsTimeoutMillis ne doit être défini ni trop haut ni trop bas car les systèmes seront indisponibles pendant une longue période et perdront donc beaucoup de données ou d'élections fréquentes qui peuvent se produire même avec une latence temporaire du réseau, d'où une incohérence des données respectivement. Un arbitre est utilisé pour ajouter un vote à un membre gagnant pour devenir maître en cas d'égalité mais ne transporte aucune donnée comme les autres membres.

Pourquoi utiliser Puppet pour déployer un ensemble de répliques MongoDB

Plus souvent, le sharding est utilisé de concert avec la réplication. Le processus de configuration et de maintenance d'un jeu de répliques n'est pas facile en raison de :

  1. Risque élevé d'erreur humaine
  2. Incapacité à effectuer automatiquement des tâches répétitives
  3. Cela prend du temps, surtout lorsqu'un grand nombre de membres est impliqué
  4. Possibilité d'insatisfaction au travail
  5. Une complexité écrasante qui peut émerger.

Afin de surmonter les revers décrits, nous optons pour un système automatisé comme Puppet qui dispose de nombreuses ressources pour nous aider à travailler facilement.

Dans notre blog précédent, nous avons appris le processus d'installation et de configuration de MongoDB avec Puppet. Cependant, il est important de comprendre les ressources de base de Puppet puisque nous les utiliserons pour configurer notre jeu de répliques et nos fragments. Au cas où vous l'auriez manqué, voici le fichier manifeste du processus d'installation et d'exécution de votre MongoDB sur la machine que vous avez créée

​  package {'mongodb':

    ensure => 'installed',

  }

  service {'mongodb':

    ensure => 'running',

    enable => true

  }

Nous pouvons donc mettre le contenu ci-dessus dans un fichier appelé runMongoDB.pp et l'exécuter avec la commande 

$ sudo apply runMongoDB.pp

Sing le module et les fonctions 'mongodb', nous pouvons configurer notre jeu de réplicas avec les paramètres correspondants pour chaque ressource mongodb.

Connexion MongoDB

Nous devons établir une connexion mongodb entre un nœud et le serveur mongodb. L'objectif principal est d'empêcher l'application des modifications de configuration si le serveur mongodb n'est pas accessible, mais peut potentiellement être utilisé à d'autres fins, telles que la surveillance de la base de données. Nous utilisons le mongodb_conn_validator

mongodb_conn_validator{‘mongodb_validator’:

ensure => present,

     server: ‘127.0.0.1:27017’,

     timeout: 40,

     tcp_port:27017

    }

nom : dans ce cas, le nom mongodb_validator définit l'identité de la ressource. Il peut également être considéré comme une chaîne de connexion

serveur :il peut s'agir d'une chaîne ou d'un tableau de chaînes contenant les noms DNS/adresses IP du serveur sur lequel mongodb doit s'exécuter.

timeout :il s'agit du nombre maximal de secondes que le validateur doit attendre avant de décider que le puppetdb n'est pas en cours d'exécution.

tcp_port :  il s'agit d'un fournisseur pour la ressource qui valide la connexion mongodb en tentant la connexion https au serveur mongodb. La configuration du certificat SSL de la marionnette à partir de l'environnement local de la marionnette est utilisée dans l'authentification.

Création de la base de données

mongodb_database{‘databaseName’:

ensure => present,

     tries => 10

}

Cette fonction prend 3 paramètres soit :

name : dans ce cas, le nom databaseName définit le nom de la base de données que nous créons, qui aurait également été déclarée comme name => 'databaseName'.

essais :cela définit le nombre maximal d'essais de deux secondes pour attendre le démarrage de MongoDB

Création d'un utilisateur MongoDB

Le module mongodb_user permet de créer et de gérer des utilisateurs pour une base de données donnée dans le module puppet.

mongodb_user {userprod:

  username => ‘prodUser’,

  ensure => present,

  password_hash => mongodb_password(‘prodUser’, ‘passProdser’),

  database => prodUser,

  roles => [‘readWrite’, ‘dbAdmin’],

  tries  => 10

}

Propriétés

username :définit le nom de l'utilisateur.

password_hash :il s'agit du hachage du mot de passe de l'utilisateur. La fonction mongodb_password() disponible sur MongoDB 3.0 et versions ultérieures est utilisée pour créer le hachage.

rôles :cela définit les rôles que l'utilisateur est autorisé à exécuter sur la base de données cible.

mot de passe :il s'agit du texte brut du mot de passe de l'utilisateur.

base de données :définit la base de données cible de l'utilisateur.

Création d'un jeu de répliques

Nous utilisons le module mongodb_replset pour créer un jeu de répliques.

Mongodb_replset{'replicaset1':

   arbiter: 'host0:27017',

   ensure  => present,

   members => ['host0:27017','host1:27017', 'host2:27017', 'host3:27017'] 

   initialize_host: host1:27017

}

name :définit le nom du jeu de répliques.

membres :un tableau de membres que l'ensemble d'instances dupliquées contiendra.

initialize_host :hôte à utiliser lors de l'initialisation du jeu de répliques

arbitre :définit le membre du jeu de répliques qui sera utilisé comme arbitre.

Création d'un fragment MongoDB

mongodb_shard{'shard1':

   ensure  => present,

   members => ['shard1/host1:27017', 'shard1/host2:27017', 'shard1/host3:27017'] 

   keys: 'price'

}

name :définit le nom de la partition.

membres :il s'agit du tableau de membres que le fragment contiendra.

keys :définissez la clé à utiliser dans le sharding ou un tableau de clés pouvant être utilisé pour créer une clé de shard composée.