Zero Downtime Upgrade on a Cluster

Zero Downtime Upgrade is supported on all Check Point clusters and third-party clustering products.

During a Zero Downtime Upgrade, one cluster member remains Active, while the other cluster members get upgraded. The Active cluster member is upgraded last.

The procedure below describes a cluster with three members. However, it can be used for clusters with two or more members.

• In High Availability mode, cluster member M1 is the Active member and is upgraded last. Cluster members M2 and M3 are Standby.
• In Load Sharing mode, all members are Active. Randomly choose one of the cluster members to upgrade last. Call it M1.

To upgrade a cluster with the Zero Downtime method:

1. Upgrade the licenses of all cluster members. A convenient time to do this is during the upgrade of the Security Management Server.

   To avoid possible problems with switches around the cluster, we recommend changing the CCP protocol to Broadcast mode on all cluster members. Run cphaconf set_ccp broadcast on all cluster members.

   Note - cphaconf set_ccp starts working immediately. It does not require a reboot, and it will survive the reboot. If you want to switch the CCP protocol back to Multicast mode on all cluster members after the upgrade, then run cphaconf set_ccp multicast on all cluster members.

2. Attach the upgraded licenses to all cluster members:
   1. Connect to the Security Management Server through SmartUpdate. The updated licenses are displayed as Assigned.
   2. Use the Attach assigned licenses option to attach the assigned licenses to the cluster members.
3. Upgrade M2.

   After the upgrade, reboot M2.

4. Upgrade M3.

   After the upgrade, reboot M3

5. In SmartConsole:
   1. In the Gateway Cluster General Properties window, change the Cluster version to R80.10.
   2. In the Install Policy window, clear these options: For Gateway Clusters, install on all the members, Install on each selected Module independently > if it fails do not install at all.
   3. Install the security policy on the cluster.

   The policy successfully installs on M2 and M3. Policy installation fails on M1 and generates a warning. You can safely ignore the warning.

6. On M1, run: cphaprob state

   Verify that the status of cluster M1 is Active or Active Attention.

   Active Attention means that the outbound status of the synchronization interface on M1 s down. This is because M1 stopped communicating with other cluster members.

7. On M1, run: cpstop

   This forces a failover to M2 or M3 (in High Availability mode) or to M2 and M3 (in Load Sharing mode).

   Make sure that one member is Active (in High Availability) or that all members are Active (in Load Sharing).

8. On M2 and M3, run: cphaprob state
9. Upgrade M1.
10. Reboot M1.
11. Optional: To return the cluster control protocol to multicast (instead of broadcast), run cphaconf set_ccp multicast on all cluster members.