Best Practise for installing Hotfixes on ClusterXL in HA mode

[Oleg_Pekar1]

Hello colleagues,

Is there any kind of best practice procedure for installing Hotfixes on ClusterXL in HA mode without downtime?

I used to perform it in the following way:

1. Installing the HF on the Standby member

2. Performing the manual cluster switchover by issuing "clusterXL_admin down" on the Active cluster member

3. Installing the HF on the  current Standby member and issuing "clusterXL_admin up" on it to push it back to the cluster

This procedure leads to the small drop of traffic during the switchover.

So, is there a better way to perform the installation on both member without, or with minimal, downtime?

I run into the following SK - sk107042 - ClusterXL upgrade methods and paths, and Connectivity Upgrade R77.x and R80.x Versions Best Practices document, but I'm not sure whether they are applicable for Hotfixes installation, or only for major/minor version upgrades.

Thanks.

[Kaspars_Zibarts]

Can you elaborate on "This procedure leads to the small drop of traffic during the switchover"?

Cluster admin down should not cause any downtime if configured correctly. 

Those SK are the best articles you can have, follow connectivity upgrade process.

[Oleg_Pekar1]

The drop of traffic may be connected with our traffic pattern - lots of short HTTP session are in place. I believe default synchronisation settings have some delay configured - need to revise that, thanks for pointing out.

Do you use the connectivity upgrade process during your upgrades? Is it smooth? 

[G_W_Albrecht · Accepted solution]

That is easy - look into sk106162: Jumbo Hotfix Accumulator for R77.30 (R77_30_jumbo_hf) 

In cluster environment:
Jumbo Hotfix Accumulator must be installed on all members of the cluster. To assure synchronization without losing connectivity, cluster administrator should use either Optimal Service Upgrade (OSU) method, or Connectivity Upgrade (CU) method. For additional information and limitations, refer to sk107042 - ClusterXL upgrade methods and paths.

[Oleg_Pekar1]

Nice remark!

That's what I wanted to see in the docs - a clear indication of the recommended procedure.

But I only missed it due to the fact it is not mentioned for the newer versions of CheckPoint software:

Jumbo Hotfix Accumulator for R80.10 (R80_10_jumbo_hf)

Jumbo Hotfix Accumulator for R80.20 (R80_20_jumbo_hf)

Do you think it's still a thing?

[G_W_Albrecht]

I do know that - and you did cite the important documentation yourself 😉 You can use the Comment field in Give us feedback at the end of the page to suggest changes to the sk, i just did that...

[KennyManrique]

AFAIK OSU and CU are methods to use when you are upgrading from a lower version, not for Jumbo Hotfix upgrade since your base version it's still the same. Maybe an error of documentation on sk106162???

Here are the upgrade paths of CU showing only base versions and nothing related to Jumbo Hotfix upgrades.

Your cluster is configured as "Highest priority member is always active"??

Your approach of Standby first its correct, for this scenarios I prefer to check the option "Maintain current active member" to aviod failovers other than those manually executed through clusterXL_admin; always verifying that the state is Active/Standby before start any operation.

Regards.

[G_W_Albrecht]

This is ClusterXL - if you install an update it follows the same procedure as a Jumbo HF, so you have to use OSU or CU or schedule a maintenance window...

[Oleg_Pekar1]

Yeah, "Maintain current active member" option lets perform only one failover, so I use this mode.

I lived happily following the procedure described in my opening post, until started preparing for CCSE exam and encountering the OSU and CU ways of upgrade. Unfortunately, there's no info whether these procedures are acceptable for installing Jumbos, so I went here to clarify it with the community 😃

I believe Gunther is right, and CheckPoint just needs to update the relevant SKs.

If understand it correct, the CU procedure will just make an additional sync of the connections and routing tables between the members, which is no harm for cluster at all.