La base Mongodb
La base Mongodb utilisé est la version 3.0.15. Elle est livrée avec deux moteurs de données:
- MMapv1: utilisé seulement si vous avez une installation initiale de Shinken en V02.06.03 ou antérieur, toutes les installations suivantes utilisent le moteur Wired Tiger
- Wired Tiger: moteur récent et performant, utilisé pour toutes les nouvelles installations de serveurs, présent par défaut pour les serveurs Shinken installés en V02.07.00 ou supérieur
Les points à surveiller
Fragmentation des fichiers de stockage
Pour stocker ses données, MongoDB alloue des pages par défaut de 512 Mo.
- Avec le temps, le stockage de donnée sur disque peut créer de la fragmentation car des données sont supprimés, mais mongoDB ne peut pas forcément utiliser des espaces libérés (si par exemples les entrées à écrire sont plus grandes que celles qui ont été supprimées).
- Il s'agit donc d'un point attention. Nous mettons à disposition :
- Un script pour vérifier cela ( cf MongoDB - surveillance du taux de fragmentation de la base )
- Ainsi que la procédure pour récupérer l'espace fragmenté ( cf MongoDB : maitriser l'espace utilisé )
La taille des logs
Les logs de mongo se trouvent par défaut dans le répertoire /var/log/mongodb/mongo.log
Par défaut, mongoDB ne limite pas la taille de ses logs.
- Il faut donc le mettre en place ( cf MongoDB - rotation des logs ).
Rotation des log
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
# A 3h01 on demande a mongo de rotationner son log
1 3 * * * root kill -USR1 `cat /var/run/mongodb/mongod.pid`
#A 3h02 on supprime les logs plus vieux de 7jours
2 3 * * * root find /var/log/mongodb/ -name "*.log.*" -type f -mtime +7 | xargs /bin/rm -f |
Et ensuite relancer le daemon crond:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
service crond reload |
Surveillance du taux de fragmentation de la base
La base de données va se fragmenter au fil des insertions/suppression d'éléments, et le volume des données va devenir plus faible que le volume sur disque (dans /var/lib/mongo): c'est la fragmentation.
Il est possible de surveiller ce taux de fragmentation et même le réduire.
Le script check_mongo_fragmentation.py est disponible afin d'avoir le calcul de ce taux, avec les volumes utilisés et les volumes sur disque.
Il se lance de la manière suivante:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
check_mongo_fragmentation.py -H IP_SERVEUR --connection-method=ssh --ssh-user=shinken --ssh-keyfile=~shinken/.ssh/id_rsa |
- -H: adresse publique du serveur à vérifier
- ou localhost si vous souhaitez vérifier le serveur sur lequel s'exécute le script
- --connection-method=ssh: à n'utiliser que pour les serveurs distants afin de créer un tunnel ssh vers le serveur et protéger les accès
- --ssh-user: utilisateur à utiliser pour les serveurs distants pour les connexions SSH
- --ssh-keyfile: clé SSH à utiliser pour les serveurs distants
Il va fournir les informations suivantes:
- Database: le nom de la base
- Disk-usage: la consommation disque de la base
- Data: le volume de données contenu dans la base
- Compression-save: espace disque économisé gracve à la compression de données (seulement pour Wired Tiger)
- Fragmented: espace non utilisé du à la fragmentation
- cet espace peux être réutilisé pour de nouvelles données, à la discrétion du moteur
- en cas de compactage ou migration, la majeur partie de cet espace pourra être récupéré
Exécution sur une base avec MMapV1
Sur une base avec MMapV1 l’exécution va donner un résultat suivant:
- Le script va conseiller de migrer de moteur de données, de MMapV1 vers Wired Tiger, en demandant à se référer à la documentation (cette page)
- Il fourni l'espace perdu à cause de la fragmentation, qui pourra être récupéré lors d'une migration
- l'espace sera probablement encore plus grand lors de la migration, car Wired Tiger compresse les données sur disque
Exécution sur une base avec Wired Tiger
Sur une base avec Wired Tiger, le résultat sera le suivant:
- Le script ne va conseiller un compactage de la base de données que si le pourcentage d'espace perdu est > 50%
- dans ce cas il conseille de se référer à la documentation, cette même page.
Compactage de la base: récupérer l'espace disque non utilisé
La base de données va se fragmenter au fil des insertions/suppression d'éléments, et le volume des données va devenir plus faible que le volume sur disque (dans /var/lib/mongo). Il est possible de surveiller cet écart de consommation, et même la réduire.
Récupérer l'espace disque
Deux méthodes options existent pour le compactage de la base :
- Compactage dans la base in-place
- Faire une sauvegarde la base et restauration dans une autre base
La 1ere option ne nécessite pas le montage d'une autre base ni de transfert de donnée c'est globalement plus simple mais pendant que la base se compacte elle est indisponible ce qui peux provoquer un long temps indisponibilité. De plus, suivant le moteur de base utilisé les contraintes et les résultats sont variables:
- MMapV1: le compactage sera efficace en terme de récupération d'espace, mais pendant le compactage, le double du volume de données sera utilisé, il faut donc prévoir assez d'espace disque
- Wired Tiger: le compactage est moins efficace, le moteur n'arrivant pas à récupérer tout l'espace perdu, mais par contre il se fait in-place sans consommer plus d'espace disque
Il est fortement recommandé de passer sur le moteur Wired Tiger, qui permet d'avoir de meilleures performances et un espace disque consommé plus faible (moins de fragmentation et compression de données). Le script de vérification de la fragmentation permet de donner le moteur de données utilisé.
Méthode 1 : Compactage dans la base
Il est important à noter que pendant que le script va fonctionner, la base se bloquée et les opérations ne pourront pas se faire. Nous vous conseillons de faire cette opération avec Shinken éteint.
Le script de compactage est launch_mongo_compaction.py
Il se lance de la manière suivante:
| Code Block | ||||
|---|---|---|---|---|
| ||||
launch_mongo_compaction.py -H IP_SERVER --ssh-user=shinken --connection-method=ssh --ssh-keyfile=~shinken/.ssh/id_rsa |
- -H: adresse publique du serveur à vérifier
- ou localhost si vous souhaitez vérifier le serveur sur lequel s'exécute le script
- --connection-method=ssh: à n'utiliser que pour les serveurs distants afin de créer un tunnel ssh vers le serveur et protéger les accès
- --ssh-user: utilisateur à utiliser pour les serveurs distants pour les connexions SSH
- --ssh-keyfile: clé SSH à utiliser pour les serveurs distants
| Info |
|---|
| ATTENTION: Pour rappel, lancer cette commande va bloquer la base pendant l'opération, qui va dépendre de la vitesse du serveur, notament de la vitesse de ses disques car toutes les données vont être lues/réécrites. Il faut que Shinken soit arrété pendant cette opération. |
Au lancement, il va parcourir les bases de données, et va les compacter. Voici une exécution du script:
Pour information la base de données de ce lancement faisait 600Mo sur disque pour un volume de données en base de 1.5Go.
Méthode 2: sauvegarde/restauration de la base dans une autre base de donnée, migration de MMapV1 vers Wired Tiger si nécessaire
| Info |
|---|
| Il est important de noter que pendant la restauration des données, il ne faut pas que Shinken fonctionne. Cette opération doit donc se faire à froid. |
C'est également la méthode pour migrer de moteur de données au sein d'un serveur: mongo ne supporte pas de changer de moteur in-place, il faut donc procéder à une restauration de données dans une nouvelle base avec le nouveau moteur.
Afin de sauvegarder la base, il faut prévoir suffisamment d'espace disque. Il faut ensuite lancer:
| Code Block | ||
|---|---|---|
| ||
shinken-backup --addons --configuration --sla --user |
Restauration sur un nouveau serveur:
Il faut ensuite transférer le backup sur le nouveau serveur et lancer la restauration:
| Code Block | ||
|---|---|---|
| ||
shinken-restore |
Restauration sur le même serveur:
Si vous souhaitez réutiliser le même serveur, il va falloir:
- arrêter mongo
- supprimer ses données
- s'assurer que le format de données est bien WiredTiger
- restaurer les données
Arrêter mongo:
| Code Block | ||
|---|---|---|
| ||
/etc/init.d/mongod stop |
Supprimer les données:
| Code Block | ||
|---|---|---|
| ||
rm -rf /var/lib/mongo/* |
Migration vers Wired Tiger (si nécessaire)
Pour s'assurer que le format de données est WiredTiger, il faut que l'entrée suivante soit dans le fichier /etc/mongod.conf:
| Code Block | ||||
|---|---|---|---|---|
| ||||
storage:
engine: wiredTiger |
Puis relancer la base:
| Code Block | ||||
|---|---|---|---|---|
| ||||
/etc/init.d/mongod start |
Ensuite il faut lancer l'import, qui va se faire avec le nouveau format de données, et avec un espace disque consommé minimal:
| language | bash |
|---|---|
| theme | Emacs |