Introduction
Avant la migration
Prérequis
Ce guide présuppose qu'on dispose de:
- Une installation Shinken fonctionnelle (potentiellement sur plusieurs machines): Il s'agit de l'installation qu'on veut migrer
- Une nouvelle installation "vide": les machines qui vont recevoir la nouvelle architecture sont disponibles et ont une installation Shinken Entreprise avec la configuration par défaut
- La version de Shinken sur la nouvelle plateforme est identique ou plus récent que la version de la plateforme courante (on ne peut par migrer une installation V02.05.00 vers une V02.04.00 par exemple)
Le point de départ de l'opération de migration se présente comme sur le schéma suivant:
Ce qui est couvert par ce guide
Ce guide présente une procédure de migration pour la configuration et les données collectées par Shinken Entreprise. Cela comprend:
- La configuration Shinken (hôtes, checks, clusters, modèles...)
- Architecture Shinken et configuration des démons
- Données SLA des éléments supervisés
- Données de métrologie
- Logs Shinken
Ce qui n'est pas couvert par ce guide
Puisque chaque environnement possède ses caractéristiques particulières, ce guide ne couvre pas la migration des éléments externes à l'architecture Shinken et à sa configuration, comme par exemple:
- La configuration système spécifique (configuration des serveurs, montage des disques, SELinux, clusters Mongo et Graphite)
- Les réglages réseaux (firewall, routage)
Procédure de migration
Configuration des démons
Copie de la configuration
La première partie de la migration est la copie des données Shinken de chaque machine vers son homologue de la nouvelle plateforme.
Pour chaque machine de l'architecture courante avec un démon Synchronizer, Arbiter ou Broker:
Effectuer une sauvegarde de toutes les données Shinken de la machine
shinken-backup
- Faire une archive du dossier créé par la commande de sauvegarde et copier cette archive sur la nouvelle machine
Sur la nouvelle machine, extraire l'archive puis restaurer la sauvegarde
shinken-restore /path/to/backup/folder
Si le besoin est de ne pas migrer l'intégralité des données de Shinken Entreprise, il est possible de selectionner uniquement les données voulues en passant les paramètres correspondants aux commandes shinken-backup et shinken-restore. Ces options sont décrites en détail sur la page de documentation suivante: Commande de Backup et de Restauration.
Ca peut être utile par exemple dans le cas ou certains données comme les métriques sont sauvegardées sur des disques réseau. Il peut être bien plus rapide et efficace de monter ces disques sur les nouvelles machines au lieu de faire des copies inutiles.
Ajuster la configuration de la nouvelle plateforme si besoin
La restauration des données de configuration restaure les données de l'ancienne machine vers la nouvelle machine telle quelle. Cela signifie notamment que les adresses des différents démons référent surement encore aux anciens démons.
Si la nouvelle plateforme est sur un réseau différent avec des adresses différentes, il faudra changer ces adresses pour faire correspondre aux nouvelles machines.
De même, si les démons utilisent le HTTPS et/ou des ports autres que les ports par défaut, il faut mettre à jour les fichiers .ini des démons concernés pour que les options de ports et de communication SSL soient bien configurées. Le fonctionnement des fichiers .ini des démons est expliqué en détail sur la page de documentation suivante: Les 7 Démons.
Les pages de documentation de chaque démon contiennent également une sous page qui détaille le procédé de configuration pour l'utilisation du SSL. Par exemple, pour le Poller: Sécuriser les communications vers le Poller
Copie des données de rétention
Pour conserver l'état des hôtes et checks, Shinken utilise la rétention faite par les démons Schedule. Lorsqu'on redémarre un Scheduler, les statuts des hôtes et checks sont chargés depuis les données de rétention au lieu d'être positionnées en "Unknown". C'est important dans le cas ou des notifications et escalades sont configurées, puisque les états "Unknown" déclenchent par défaut l'envoi de notifications. Sans rétention, un redémarrage d'un Scheduler pourrait envoyer une notification pour chaque hôte géré par ce Scheduler.
Lors de la migration, il est alors possible de vouloir migrer également ces données de rétention. Si le module de rétention utilisé sur les Schedulers est le module PickleRetentionFile, les données de rétention peuvent être migrées en copiant le fichier /var/lib/shinken/retention.dat sur chaque Scheduler vers sont homologue dans la nouvelle infrastructure. Si le module de rétention est MongodbRetention, les données de rétention sont sauvegardées et restaurées via les commandes shinken-backup et shinken-restore.
Sondes personnalisées
Les sondes personnalisées présentes dans /var/lib/shinken-user/libexec ne sont pas sauvegardées ni restaurées par les commandes shinken-backup et shinken-restore. Si ce dossier contient des sondes personnalisées, il faudra les copier et les restaurer manuellement sur la nouvelle machine.
Cette opération de sauvegarde et restauration pour les sondes doit être effectuée sur toutes les machines contenant des Pollers et Reactionners.
Données des addons
Les addons nagvis et nagvis-shinken-architecture ont chacun leurs données et fichiers de configuration. Les utilitaires de sauvegarde shinken-backup et shinken-restore ne sauvegardent et ne restaurent pas ces données.
La sauvegarde et restauration des données des addons doit être réalisée manuellement en copiant les dossiers suivants:
- Addon nagvis: /opt/nagvis
- Addon nagvis-shinken-architecture: /var/lib/shinken-nagvis