Chapter 6: High Availability Clusters

This chapter looks at the case where one of the peers in a High Availability (HA) cluster needs to be replaced with another, identical hardware unit. No reassignment of the interfaces is required.

It is assumed that one of the hardware units in the cluster is still functioning correctly and that unit will be referred to as FW1. The hardware unit that is being removed from the cluster will be referred to as FW2_Old and the new, replacement unit will be referred to as FW2_New.

The replacement procedure is as follows:

  1. Using the Web Interface, login to FW1.

  2. Select the menu option Maintenance > Backup and download a configuration backup to the local management workstation disk.

  3. Assuming that FW2_Old has been disconnected and removed, reconnect FW2_New to the same cables in the same way.

  4. Apply power to FW2_New and wait for cOS Core to start.

  5. The new unit FW2_New will have the default IP address on its default management Ethernet interface. If required, change this to the address used in SWG_Old. This is described in:

    Appendix C, Management Interface Setup.

  6. Login to FW2_New using the Web Interface. The default username and password is always admin and admin.

  7. On the first page of the Web Interface check the version of cOS Core that is running. Verify that this is the same version that is running on FW1.

    If the cOS Core versions are different, they must be made the same. This is done by downloading the correct upgrade package from the Clavister website and applying it by selecting the Web Interface menu option Maintenance > Upgrade.

    Do not try to upload a full system backup (configuration plus cOS Core) to dissimilar hardware. This will cause the configuration to be automatically activated and the hardware restarted, with the possibility that cOS Core becomes unreachable.

  8. In the Web Interface for FW2_New, select the menu option Maintenance > Backup and select the Restore option. Upload the configuration backup created previously from FW1.

    Note: DO NOT ACTIVATE THIS CONFIGURATION YET.

  9. Since the uploaded configuration is a mirror of FW1, its status of master or slave must be reversed so that FW2_New becomes correspondingly either slave or master.

    This is done in the Web Interface by selecting the navigation tree option System > High Availability and changing the setting Node Type.

  10. At this point the FW2_New can be activated and committed. In the Web Interface this is done by selecting the menu option Configuration > Save.

  11. Since the configuration from FW1 has been uploaded to FW2_New, the device name for both will now be the same. This must be changed for FW2_New using the CLI. For example, if the correct device name should be cluster_slave, the CLI command would be:

    Device:/> set Device Name=cluster_slave

  12. The MAC addresses of the Ethernet interfaces on the new hardware will be different from the old unit so the cOS Core license from the old hardware will no longer be valid. A new license from the Clavister must be installed. This can be done in one of the following ways:

    • Automatically through the Web Interface by going to Status > Maintenance > License.

    • Automatically through the CLI with the command:

      Device:/> license -activate -request -username=myname -password=pswd

    • Manually by first downloading a new license from the Clavister website then uploading it either through the Web Interface or with SCP. This will require the information written on the label attached to the hardware. With some older Clavister hardware models, this is the only option.

    Note that for hardware released from the 4th quarter of 2021 (for example, the 100, 500 and 6000 Series) licenses will be a subscription based Security as a Service (SECaaS) licenses. Installation of a SECaaS license requires that cOS Core is configured with both Internet access and a public DNS server.

Connectivity checks should now be made to confirm that the cluster is functioning correctly.

Cluster Replacement with Non-identical Hardware

It is recommended to never try to replace a peer in a high availability cluster with hardware that is not the same as the other peer.

Although such replacement could be done in extreme circumstances, there are many technical problems involved in configuring the replacement hardware plus complex operational issues. For this reason, such replacement is not discussed further in this document.