Migrate your Shinken Enterprise architecture

Introduction

Before starting the migration

Prerequisites

This guide will suppose you already have the following:

• A Shinken architecture (the one  you want to migrate)
• A new "empty architecture": the machines for the new architecture are available and have Shinken installed with the default configuration.
• The Shinken version of the new Shinken platform must be equal or more recent that the current platform (cannot migrate from V02.06.00 to V02.05.00 for instance).

The starting point of the migration guide is an architecture such as the following:

What this guide covers

This guide covers the migration of Shinken configuration and data collected by Shinken. This includes:

• Shinken configuration (hosts, checks, templates)
• Shinken architecture and daemons configuration
• SLA data
• Metrology
• Shinken logs

What this guide does not cover

Because each environment has its own characteristics, this guide does not cover the migration of elements other than the Shinken architecture and configuration, meaning:

• Specific system configuration (machine setups, disks mounts, SELinux, ...)
• Network configuration (firewall, routing)

Migration steps

Daemons configuration

Copy configuration

The first step of the migration is to copy the Shinken data of each machine to its counterpart in the new platform.

For each machine in the current plateform with Synchronizer, Arbiter or Broker daemons:

• Create a backup of all the data in the  machine:

  shinken-backup

• Create an archive of the created backup folder and copy it to the new machine

• Extract the archive and restore the backup on the new machine:

  shinken-restore /path/to/backup/folder

  
  

Adapt configuration to the new platform if needed

Restoring the configuration copies the configuration from the old machine as is on the new machine. This means the addresses of the different daemons still refer to the old daemons.

If the new platform is on another network with different addresses, you will have to change these addresses in the configuration to refer to the new daemons addresses.

If daemons use HTTPS and/or ports other than the default ports, the .ini files of the concerned daemons must be updated so that the communication ports and SSL communication options are properly configured. The inner workings of the daemons .ini files are explained in detail on the following documentation page: The Seven Demons.

The documentation pages for each daemon also contains a subpage that details the configuration process for using SSL. For example, for the Poller: Secure communications to the Poller

Copy retention data

To keep hosts and checks status, Shinken uses retention on the Scheduler. When restarting a Scheduler, status are loaded from the retention instead of being "Unknown". This is important if you have notifications enabled, because by default an "Unknown" status on an host or check sends a notification. Without any retention, restarting your Scheduler might send a notification for each host of your monitoring configuration.

When migrating, you might want to also copy your retention data. If the retention module on the Schedulers is PickeRetentionFile, you can migrate your retention data by copying the /var/lib/shinken/retention.dat on the associated Scheduler in the new infrastructure.

Checks scripts

The custom probes present in /var/lib/shinken-user/libexec are saved and restored by the shinken-backup and shinken-restore commands. If this folder contains custom probes, saving the configuration saves the entire /var/lib/shinken-user/libexec folder and restores it with shinken-restore.

This backup and restore operation for probes must be performed on all machines containing Pollers and Reactioners.

Addons data

The nagvis and nagvis-shinken-architecture addons each have their data and configuration files. The shinken-backup et and shinken-restore utilities can saved these data and configurations by using them with the "--addon" parameter.