Upgrading ClusterXL Deployments

In This Section:

Planning a Cluster Upgrade

Before you upgrade a ClusterXL, consider the available upgrade options.

Effort and time efficient upgrades with some loss of connectivity

Simple Upgrade (with downtime) - Select this option if you have a period of time during which network downtime is allowed. This method is the simplest, because each cluster member is upgraded as an independent Gateway.
Zero Downtime - Select this option if you cannot have any network downtime and need to complete the upgrade quickly, with a minimal number of dropped connections. During this type of upgrade, there is always at least one active member that handles traffic. Connections are not synchronized between cluster members running different Check Point software versions.
Note - Connections that were initiated on a cluster member running the old version get dropped when the cluster member is upgraded to a new version. Network connectivity, however, remains available during the upgrade, and connections initiated on an upgraded cluster member are not dropped.

Upgrades that guarantee minimal connectivity loss

Optimal Service Upgrade (OSU) - Select this option if security is of utmost concern. During this type of upgrade two cluster members process network traffic. Connections that are initiated during the upgrade stay up through the upgrade. A minimal number of connections that were initiated before the upgrade get dropped after the upgrade.
Connectivity Upgrade (CU) - Select this option, if you need to upgrade a Security Gateway or a VSX cluster to any version, and guarantee connection failover. Connections that were initiated before the upgrade are synchronized with the upgraded Security Gateways and cluster members so that no connections are dropped.
Note - Before you select the Connectivity Upgrade (CU) option, see sk107042 ClusterXL upgrade methods and paths for limitations.

An administrator can customize the Firewall, VPN, CoreXL, and SecureXL configuration on cluster members by configuring the relevant kernel parameters in special configuration files - $FWDIR/boot/modules/fwkern.conf, $FWDIR/boot/modules/vpnkern.conf, $PPKDIR/boot/modules/simkern.conf, $FWDIR/conf/fwaffinity.conf. For examples, see sk25977. During the upgrade, all customized configuration files are overwritten with the default configuration files.

If you upgrade the cluster through CLI, you can preserve the customized configuration. To do that, you must back up the configuration files before the upgrade and restore them manually immediately after upgrade, before the cluster members are rebooted. See sk42498 for details.

If you upgrade the cluster gateways through Portal, they are rebooted automatically immediately after the upgrade, and the customized configuration is lost.

Note - If configuration customizations are lost during the upgrade, different issues can occur in the upgraded cluster. Cluster members can stop detecting each other, cluster members can move to undesired state, and traffic can be dropped.

Ready State During Cluster Upgrade/Rollback Operations

When cluster members of different versions are on the same network, cluster members of the new (upgraded) version remain in state Ready, and cluster members of the previous version remain in state Active Attention. Cluster members in the state Ready do not process traffic for the cluster Virtual IP address and do not synchronize with other cluster members.

To prevent cluster members from being in Ready state:

Physically disconnect the cluster member
Shut down all interfaces:
- On Gaia/IPSO, run this Clish command: set interface <Interface_Name> state off
- On SecurePlatform, run this command in Expert mode: ifconfig <Interface_Name> down
- On Windows, disable the interface through Control Panel > Network and Sharing Center

Upgrading 32/64-bit Cluster Members

High Availability cluster deployments are supported on 32-bit and 64-bit kernel operating systems. Make sure that all cluster members are running the same 32-bit or the same 64-bit operating system. If the kernel versions are different among the cluster members, those that are running the 64-bit version will stay in the state Ready and will not synchronize with the other cluster members or process any traffic for the cluster Virtual IP address.

Upgrading Third-Party and OPSEC Certified Cluster Products

When upgrading clusters of IP appliances running IPSO operating system (VRRP and IP Clusters), use the Zero Downtime or the Minimal Effort procedure.
When upgrading other third-party clustering products, use the Minimal Effort procedure. If the third party vendor has an alternative for the Zero Downtime Upgrade, refer to their documentation for upgrading.