Moving an Icinga 2 master to a new machine requires careful preparation, especially in a master-to-master high availability setup. In production environments, such migrations are often part of broader infrastructure changes, platform standardization, or long-term monitoring strategy decisions. This guide walks you through the process step by step, ensuring a smooth migration without service interruption while keeping your monitoring platform stable and consistent across the environment.
Moving an Icinga 2 master to a new machine requires careful preparation, especially in a master-to-master setup. This guide walks you through the process step by step, ensuring a smooth migration without service interruption.
Prepare the New Master
Before starting the migration, prepare your new server by installing Icinga 2 with the desired version. Verify that the installation works as expected, including network connectivity to your database server and both existing master nodes. Once you verified everything is working, ensure that Icinga 2 is stopped on the new server. You will start Icinga 2 once all the data from the existing server is copied.
It’s best to migrate one master at a time. Start with the master that holds the Certificate Authority (CA). You can identify the CA master by checking for files in /var/lib/icinga2/ca on your current machines.
Copy Configuration and Data
Stop the Icinga 2 service on the Icinga server that will be migrated to avoid configuration changes during the migration. The second Icinga master continues the monitoring. Then copy the following directories from the old master to the new one:
/etc/icinga2 /var/lib/icinga2
Keep Icinga 2 stopped on the master that is being migrated. On the new master, verify if you need to make any adjustments in the /etc/icinga2/zones.conf. You may need to change
Handling the FQDN
If the Fully Qualified Domain Name (FQDN) of the new machine remains the same as the old one, the migration is straightforward. Depending on your configuration within /etc/icinga2/zones.conf you may need to adjust the settings, for example if you used IP addresses instead of DNS names. Simply start Icinga 2 on the new master, and it should automatically reconnect to the other master. You can verify this by checking the icinga2.log file. If you make changes to the zones.conf file
If the FQDN changes, you’ll need to create and sign a new certificate for the new master before starting Icinga 2.
Creating and Signing a New Certificate
When migrating to a new hostname, the master needs a fresh certificate signed by the CA master. Here’s how to do that:
1. On the new master, create a certificate signing request (CSR):
icinga2 pki new-cert \ --cn <new-master-fqdn> \ --key /var/lib/icinga2/certs/<new-master-fqdn>.key \ --csr /var/lib/icinga2/certs/<new-master-fqdn>.csr
2. Copy the CSR file from the new master to the CA master, for example using scp:
scp /var/lib/icinga2/certs/<new-master-fqdn>.csr <ca-master>:/var/lib/icinga2/ca/
3. On the CA master, sign the CSR:
icinga2 pki sign-csr \ --csr /var/lib/icinga2/ca/<new-master-fqdn>.csr \ --cert /var/lib/icinga2/ca/<new-master-fqdn>.crt
4. Copy the signed certificate back to the new master:
scp <ca-master>:/var/lib/icinga2/ca/<new-master-fqdn>.crt /var/lib/icinga2/certs/
5. Copy the CA certificate as well:
scp <ca-master>:/var/lib/icinga2/ca/ca.crt /var/lib/icinga2/certs/
Verify certificate permissions and ensure that the configuration in /etc/icinga2/constants.conf points to the correct certificate and key paths.
Update Configuration on Connected Nodes
After generating and signing the new certificate, update the zones.conf file on all nodes directly connected to the new master. This includes:
- The other master in the pair
- Satellites below the master zone
- Agents connected directly to the master zone
Ensure the new master’s FQDN and connection details are correctly reflected in each node’s configuration.
Verifying the Migration
Once everything is set up, start Icinga 2 on the new master. It should establish connections to the other master and satellites and resume normal monitoring operations. Check the icinga2.log to confirm successful connections and verify that no errors are reported.
Summary
Migrating an Icinga 2 master is a straightforward process when done carefully. Start with the CA master, move one node at a time, and verify each step along the way. Whether the hostname stays the same or changes, following these steps will help you achieve a smooth and reliable migration to your new infrastructure.
