Migration Procedure to 5.0 for HA nodes

Version 3.0

Applies to platform: All 3.0 HA Cluster, software or hardware.
Last updated: 26th September 2017

This article guides you in the upgrade of a software or hardware HA cluster from the 3.0 to the 5.0 version.

Since the 5.0 version must be reinstalled over the 3.0, a downtime of the HA cluster and of the individual nodes must be scheduled, which in the best case would be a matter of a few minutes.

In a nutshell, the procedure requires to stop the HA on both nodes, to first reinstall the slave and import the backup on it, then reinstall the master and import the backup, and finally to restart HA on both nodes.


Read carefully the next section of this howto before actually starting the migration, in order to limit the downtime of your HA Cluster and be prepared to promptly react should something go wrong!

Before You Start

This is a list of task to be completed and points to focus on before actually start the upgrade procedure:

  • Both nodes must be up to date. Update both nodes by installing all the available packages for the 3.0.
  • Both nodes must be online on Endian Network.
  • Each node will be reinstalled individually, like explained in this howto.
  • Create a backup of both nodes (Master and Slave) with settings and database only and copy them away from the appliance, for example on a USB-stick, or even better, on a laptop, since you will need to import them into the each node after they are reinstalled with the 5.0. Make sure you really have one backup of the master node and one backup of the slave, and not two backups of the master node.
  • If you need a full backup (including log files and log archives) for archival purposes, create it and copy it to a safe place, but do not import it on the 5.0 appliance.
  • You have downloaded the correct 5.0 image for your appliance from Endian Network and verified its md5sum, and also verified that the burned CD or USB has a correct checksum. To burn an USB stick follow this howto.
  • You have a 3.0 disaster recovery image at hand, should anything go wrong.
  • Make sure that at any time you can connect at least via CLI (command line) to both nodes.
  • Read the articles mentioned before and have them at hand for all eventualities.

Hardware cluster

In case the cluster is composed of hardware appliances, two more points are important:

  • A PC or laptop with access to serial port of both appliances is necessary.
  • Someone must be physically present by them, since it will be necessary to change the boot order (explained in this howto), to be able to start the appliance from the CD or USB stick.


If your system contains special customisations made by Endian technician, let us know before you start the migration.
Moreover, if the GREEN IP of your cluster is the default one,, notice that right after the installation of the 5.0 on it, the Slave will also have that IP, since it is the default one for Endian devices, and this can lead to temporary routing issues due to the same IP address assigned to two different devices in the network. To prevent such issues, temporarily change the GREEN IP Address of the Slave.


Once you have completed the above mentioned tasks, it is time to start the actual procedure. At this point, you have two fully updated 3.0 appliances, you can access both of them and have the necessary CD or USB sticks with the images and the backup. 

To simplify access to the nodes during the procedure, you may want to change temporarily the passwords of the admin and root users to something like endian123$

First of all, make sure that the HA configuration is fully synchronised:

root@Master:~ # efw-ha --sync --verbose

then stop it

root@Master:~ # /etc/init.d/efw-ha stop

At this point it is necessary, on both the Master and the Slave, to stop rsync from working, in order to prevent the HA to try to synchronise the nodes before you migrated all the HA cluster:

root@endian:~ # chmod 0000 /usr/bin/rsync

At this point you can start the migration of the nodes, starting from the Slave.

Slave node

Power it off, then reinstall it with the 5.0. In case of hardware appliance, you might need to modify the boot order to allow boot from CD or USB. follow this howto for instruction. 

Once the installation is finished, reboot the slave and remove the USB key from it. You can also restore the boot order, removing the USB boot option from the BIOS.

Once you reboot the slave, log in as root and do the following:

  1. Like you did before the migration, stop rsync from working:
    root@endian:~ # chmod 0000 /usr/bin/rsync
  2. Import the backup of the Slave node in the slave. Make sure the backup contains only settings and database.
  3. If asked to reboot, do so.

Master Node

The procedure to migrate the Master is similar to the slave one.

Power the 3.0 Master off, then reinstall it with the 5.0, modifying the boot order if necessary.

Once the installation is finished, reboot the master, remove the USB key from it. You can also restore the boot order, removing the USB option from the BIOS.

Once you reboot the master, log in as root and do the following:

  1. Import the backup of the Master node. Make sure the backup contains only settings and database.
  2. If asked to reboot, do so.

At this point, both appliances have been migrated to the 5.0.

Restart HA

After you imported the backup on the Master unit, log in to the Slave unit, and restore the permissions on rsync to allow its execution:

root@endian:~ # chmod 0755 /usr/bin/rsync

At this point, the last operation to carry out is to check if the synchronisation between the two nodes has started.

Login to the Master and start HA from the GUI or from the CLI:

root@Master:~ # efw-ha --sync --verbose

Then log in to the Slave's GUI, go to Services > High availability and check that the Master Root Password (the password of the root user on the Master node) has been set:


Then click on Save: the GUI of the slave unit will change and after a few minutes you will have a working HA cluster. 

In order to verify that the HA indeed correctly works, try to reboot or poweroff the Master node and verify that the Slave correctly takes over.

If everything goes the right way and you do not find any problems during the various steps, the expected downtime of the cluster is a few minutes.

Questo articolo ti è stato utile?
Utenti che ritengono sia utile: 0 su 0
Altre domande? Invia una richiesta