Planning a Cluster Upgrade

Important - Before you upgrade your Cluster members, you must upgrade your Security Management Server or Multi-Domain Server. You can also upgrade your High Availability system.

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

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.

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.

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 Gaia 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 the state Ready, and cluster members of the previous version remain in state Active Attention. Cluster members in the state Ready do not process traffic and do not synchronize with other cluster members.

To prevent cluster members from being in the state "Ready":

Option	Instructions
1	Connect over the console to the cluster member. Physically disconnect the cluster member from the network (unplug all cables).
2	Connect over the console to the cluster member. Log in to Gaia Clish. Shut down all interfaces: set interface <Interface_Name> state off

For more information, see sk42096: Cluster member is stuck in 'Ready' state.

Upgrading 32/64-bit Cluster Members

Cluster deployments are supported on 32-bit and 64-bit kernel Gaia 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 and will not process traffic sent to the cluster Virtual IP addresses.

Important - If you perform a major upgrade, first complete the upgrade of all cluster members and only then change the Gaia kernel edition to 64-bit.

Upgrading Third-Party and OPSEC Certified Cluster Products

• When upgrading 3rd party and OPSEC 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.

Upgrading Clusters on Appliances

Important - Before you upgrade your Cluster members, you must upgrade your Security Management Server or Multi-Domain Server. You can also upgrade your Management High Availability system.

If the appliance to upgrade was not the primary member of a cluster before, export its database before you upgrade. If it was the primary member before, you do not have to do this.

To upgrade an appliance and add it to a cluster:

1. If the appliance was not the primary member of a cluster, export the Security Management Server database.
2. Upgrade the Appliance.
3. If the appliance was not the primary member of a cluster, Import the database.
4. Using the Gaia Portal, on the Cluster page, configure the appliance to be the primary member of a new cluster.
5. Connect a second appliance to the network.
   • If the second appliance is based on an earlier version: get the relevant upgrade package from the Download Center, save it to a USB stick, and reinstall the appliance as a secondary cluster member.
   • If the second appliance is upgraded: run the first-time wizard and select Secondary Cluster Member.