Introduction

La possibilité d'effectuer des sauvegardes et restaurations de différents composants de Shinken Entreprise fournit à l'administrateur Shinken un moyen rapide de restaurer un état fonctionnel de Shinken en cas de crash ou erreur sur la plateforme.

Ces outils de sauvegardes et restauration permettent également d'effectuer des migrations d'une plateforme Shinken Entreprise vers des nouvelles machines (changement de fournisseur, mise à niveau des machines vers des équipements plus performants).


Ce guide fournit des étapes rapides permettant d'effectuer une migration d'architecture Shinken.



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