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

Une introduction à Percona Server pour MongoDB 4.2

Lors du choix d'une technologie de base de données NoSQL, des considérations importantes doivent être prises en compte, telles que les performances, la résilience, la fiabilité et la sécurité. Ces facteurs clés doivent également être alignés sur la réalisation des objectifs commerciaux, du moins en ce qui concerne la base de données.

De nombreuses technologies sont entrées en jeu pour améliorer ces aspects, et il est conseillé à une organisation d'améliorer les options saillantes et d'essayer de les intégrer dans les systèmes de base de données.

Les nouvelles technologies doivent garantir des performances maximales pour améliorer la réalisation des objectifs commerciaux à un coût d'exploitation abordable, mais avec des fonctionnalités plus manipulatrices telles que la détection des erreurs et les systèmes d'alerte.

Dans ce blog, nous discuterons de la version Percona de MongoDB et de la manière dont elle étend la puissance de MongoDB de différentes manières.

Qu'est-ce que Percona Server pour MongoDB ?

Pour qu'une base de données fonctionne correctement, il doit y avoir un serveur sous-jacent établi de manière optimale pour améliorer les transactions de lecture et d'écriture. Percona Server pour MongoDB est un remplacement gratuit et open source de MongoDB Community Edition, mais avec des fonctionnalités supplémentaires de niveau entreprise. Il est conçu avec quelques améliorations majeures sur la configuration par défaut du serveur MongoDB.

Il offre des performances élevées, une sécurité et une fiabilité améliorées pour des performances optimales avec des dépenses réduites pour les relations avec les fournisseurs de logiciels propriétaires.

Serveur Percona pour les principales fonctionnalités de MongoDB

MongoDB Community Edition est au cœur du serveur Percona étant donné qu'il constitue déjà des fonctionnalités importantes telles que le schéma flexible, les transactions distribuées, la familiarité des documents JSON et la haute disponibilité native. En plus de cela, Percona Server pour MongoDB intègre les principales fonctionnalités suivantes qui lui permettent de satisfaire les aspects que nous avons mentionnés ci-dessus :

  • Sauvegardes à chaud
  • Cryptage des données au repos
  • Journal d'audit
  • Moteur de mémoire Percona
  • Authentification LDAP externe avec SASL
  • Intégration du coffre-fort HashiCorp
  • Profilage des requêtes amélioré

Sauvegardes à chaud 

Le serveur Percona pour MongoDB crée une sauvegarde physique des données sur un serveur en cours d'exécution en arrière-plan sans aucune dégradation notable du fonctionnement. Ceci est réalisable en exécutant la commande createBackup en tant qu'administrateur sur la base de données admin et en spécifiant le répertoire de sauvegarde. 

> use admin

switched to db admin

> db.runCommand({createBackup: 1, backupDir: "/my/backup/data/path"})

{ "ok" : 1 }

Lorsque vous recevez { "ok" :1 }, la sauvegarde a réussi. Sinon, si par exemple vous spécifiez un chemin de répertoire de sauvegarde vide, vous pouvez recevoir une réponse d'erreur, c'est-à-dire :

{ "ok" : 0, "errmsg" : "Destination path must be absolute" }

La restauration de la sauvegarde nécessite d'abord d'arrêter l'instance mongod, de nettoyer le répertoire de données, de copier les fichiers du répertoire, puis de redémarrer le service mongod. Cela peut être fait en exécutant la commande ci-dessous

$ service mongod stop && rm -rf /var/lib/mongodb/* && cp --recursive /my/backup/data/path /var/lib/mongodb/ && service mongod start

Vous pouvez également stocker la sauvegarde au format archive si vous utilisez le serveur Percona pour MongoDB 4.2.1-1 

> use admin

> db.runCommand({createBackup: 1, archive: "path/to/archive.tar" })

Vous pouvez également sauvegarder directement sur AWS S3 en utilisant les paramètres par défaut ou avec plus de configurations. Pour une sauvegarde de bucket S3 par défaut :

> db.runCommand({createBackup : 1,  s3 :{bucket :"backup", chemin :"newBackup"}})

Chiffrement des données au repos

MongoDB version 3.2 a introduit le chiffrement des données au repos pour le moteur de stockage WiredTiger afin de garantir que les fichiers de données peuvent être déchiffrés et lus par des parties avec une clé de déchiffrement uniquement. Le chiffrement des données au repos dans Percona Server pour MongoDB a été introduit dans la version 3.6 pour aller de pair avec le chiffrement des données au repos dans MongoDB. Cependant, la dernière version n'inclut pas la prise en charge des services de gestion de clés Amazon AWS et KIMP.

Le chiffrement peut également être appliqué aux fichiers de restauration lorsque les données au repos sont activées. Percona Server pour MongoDB utilise l'option de chiffrementCipherMode avec 2 modes de chiffrement sélectif :

  1. AES256-CBC (mode de chiffrement par défaut)
  2. AES256-GCM

Vous pouvez chiffrer les données avec la commande ci-dessous

$ mongod ... --encryptionCipherMode or 

$ mongod ... --encryptionCipherMode AES256-GCM

Nous utilisons l'option --ecryptionKeyFile pour spécifier le chemin d'accès à un fichier contenant la clé de chiffrement.

$ mongod ... --enableEncryption --encryptionKeyFile <fileName>

Journalisation d'audit

Pour chaque système de base de données, les administrateurs ont pour mandat de suivre les activités en cours. Dans Percona Server pour MongoDB, lorsque l'audit est activé, le serveur génère un fichier journal d'audit qui constitue des informations sur différents événements utilisateur tels que l'autorisation et l'authentification. Cependant, en démarrant le serveur avec l'audit activé, les journaux ne seront pas affichés dynamiquement pendant l'exécution.

La journalisation d'audit dans MongoDB Community Edition peut prendre deux formats de données, à savoir JSON et BSON. Cependant, pour Percona Server pour MongoDB, la journalisation d'audit est limitée au fichier JSON uniquement. Le serveur enregistre également uniquement les commandes importantes contrairement à MongoDB qui enregistre tout. Étant donné que la procédure de filtrage dans Percona est si peu claire en termes de syntaxe de filtrage, l'activation du journal d'audit sans filtrage offrirait plus d'entrées à partir desquelles on peut affiner ses propres spécifications.

Moteur de mémoire Percona

Il s'agit d'une configuration spéciale du moteur de stockage WiredTiger qui ne stocke pas les données utilisateur sur disque. Les données résident entièrement et sont facilement disponibles dans la mémoire principale, à l'exception des données de diagnostic qui sont écrites sur le disque. Cela rend le traitement des données beaucoup plus rapide, mais en tenant compte du fait que vous devez vous assurer qu'il y a suffisamment de mémoire pour contenir l'ensemble de données et que le serveur ne doit pas s'arrêter. Vous pouvez sélectionner un moteur de stockage à utiliser avec la commande --storageEngine. Les données créées pour un moteur de stockage ne peuvent pas être compatibles avec d'autres moteurs de stockage car chaque moteur de stockage possède son propre modèle de données. Par exemple pour sélectionner le moteur de stockage en mémoire. Vous arrêtez d'abord toute instance mongod en cours d'exécution, puis lancez les commandes :

$ service mongod stop

$ mongod --storageEngine inMemory --dbpath <newDataDir>

Si vous avez déjà des données avec votre édition communautaire MongoDB par défaut et que vous souhaitez migrer vers Percona Memory Engine, utilisez simplement les utilitaires mongodumb et mongorestore en lançant la commande :

$ mongodump --out <dumpDir>

$ service mongod stop

$ rm -rf /var/lib/mongodb/*

$ sed -i '/engine: .*inMemory/s/#//g' /etc/mongod.conf

$ service mongod start

$ mongorestore <dumpDir>

Authentification LDAP externe avec SASL

Chaque fois que les clients envoient une demande de lecture ou d'écriture à l'instance MongoDB mongod, ils doivent d'abord s'authentifier auprès de la base de données utilisateur du serveur MongoDB. L'authentification externe permet au serveur MongoDB de vérifier les informations d'identification du client (nom d'utilisateur et mot de passe) par rapport à un service distinct. L'architecture d'authentification externe implique :

  1. Serveur LDAP qui stocke à distance toutes les informations d'identification de l'utilisateur
  2. Démon SASL utilisé comme proxy local du serveur MongoDB pour le service LDAP distant.
  3. Bibliothèque SASL :crée les données d'authentification nécessaires pour le client et le serveur MongoDB.

Séquence de session d'authentification

  • Le client se connecte à une instance mongod en cours d'exécution et crée une demande d'authentification PLAIN à l'aide de la bibliothèque SASL.
  • La demande d'authentification est ensuite envoyée au serveur sous la forme d'une commande Mongo spéciale qui est ensuite reçue par le serveur mongod avec sa charge utile de demande.
  • Le serveur crée des sessions SASL dérivées des informations d'identification du client en utilisant sa propre référence à la bibliothèque SASL.
  • Le serveur mongod transmet la charge utile d'authentification à la bibliothèque SASL qui la transmet au démon saslauthd. Le démon le transmet au LDAP et attend une réponse OUI ou NON à la demande d'authentification en vérifiant si l'utilisateur existe et si le mot de passe soumis est correct.
  • Le saslauthd transmet cette réponse au serveur mongod via la bibliothèque SASL qui authentifie ou rejette ensuite la demande en conséquence.

 Voici une illustration de ce processus :

Pour ajouter un utilisateur externe à un serveur mongod :

> db.getSiblingDB("$external").createUser( {user : username, roles: [ {role: "read", db: "test"} ]} );

Cependant, les utilisateurs externes ne peuvent pas se voir attribuer de rôles dans la base de données d'administration.

Intégration du coffre-fort HashiCorp

HashCorp Vault est un produit conçu pour gérer les secrets et protéger les données sensibles en stockant en toute sécurité et en contrôlant étroitement l'accès aux informations confidentielles. Avec la version précédente de Percona, la clé de chiffrement des données au repos était stockée localement sur le serveur à l'intérieur du fichier de clé. L'intégration avec HashCorp Vault sécurise beaucoup mieux la clé de chiffrement.

Profilage de requête amélioré

Le profilage a un impact négatif sur les performances de la base de données, en particulier lorsque le nombre de requêtes émises est élevé. Le serveur Percona pour MongoDB permet de limiter le nombre de requêtes collectées par le profileur de base de données, ce qui diminue son impact sur les performances.

Conclusion

Percona Server pour MongoDB est une base de données open source améliorée et hautement évolutive qui peut servir de remplacement compatible pour MongoDB Community Edition, mais avec une syntaxe et une configuration similaires. Il améliore la sécurité des données étendues, en particulier celles au repos, et améliore les performances de la base de données grâce à la fourniture du moteur Percona Server, limitant le taux de profilage entre autres fonctionnalités.

Percona Server pour MongoDB est entièrement pris en charge par ClusterControl en tant qu'option de déploiement.