Using Clusterxl_admin down/up on members with differnet versions

[Jonathan]

Hi,

I'm upgrading my active/standby cluster from R80.20 to R81.10.

I will be upgrading the standby member, and will then want to manually failover to the upgraded memebr.

Usually I use the 'ClusterXL_admin down' command for manual failovers, but I"m not sure how and if it will work when the two members are in different versions.

What will be the best way to failover to the upgraded member in such a case, with a minimum downtime, if any?

Thanks

[Swordfish]

After the first node is upgraded to R81.10 you need to activate the Multi-Version Cluster Mechanism.

"(MVC) mechanism synchronizes connections between Cluster Members that run different versions.

You can upgrade to a newer version without a loss in connectivity and test the new version on some of the Cluster Members before you decide to upgrade the rest of the Cluster Members."

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_ClusterXL_AdminGuide/Topics-CXLG/C...

You may also have a look at the R81.10 Upgrade Guide:  https://sc1.checkpoint.com/documents/R81.10/WebAdminGuides/EN/CP_R81.10_Installation_and_Upgrade_Gui... 

[_Val_]

As mentioned already, MVC is the answer. Follow the upgrade guide, this is your best option.

For any other version, where MVC is not available, run cpstop to bring down the active cluster member and to failover to the upgraded standby one.

[Jonathan]

Just to make it clear - I don't HAVE to use the MVC? It's just an option?

Also, I see in the guide that if using MVC I will have to install policy twice for every change I make until both members are in the same version. Is that the same case if I don't use the MVC?

In short, what are the benefits of using the mvc?

[Swordfish]

You will find different approaches more detailed in the guide. One option could be:

0) Backup your environment and dont make policy changes during the upgrade process of the cluster

1) Upgrade the first gateway and install the latest JHF

2) Change Cluster Object in SMS to R81.10 (you may also need to upgrade your SMS and Smart Event first)

3) Activate MVC

4) Install the policy from your SMS on your cluster and select the Install Mode "Install on each selected gateway independently". The installation will fail on the R80.20 gateway, but should be successful on your R81.10 gateway.

5) Now you can use clusterXL_admin down on your R80.20 node, because MVC in enabled. If you try to use it without MVC the command will not work (at least on R80.40 it did not work)

[Matlu]

Hello, @Swordfish 

Does this also apply to VSX Cluster?

Is it necessary to enable MVC when upgrading Gaia OS from R81 to R82?

I have an MDS + VSX environment, and I need to upgrade the boxes that make up the VSX Cluster, but I wonder if it is ‘mandatory’ to activate MVC in this process?

What happens if I don't enable MVC?

Could there be a “service outage”?

Thanks for your comments.

[emmap]

We recommend following the instructions in the upgrade and install admin guide, but:

Yes you should enable MVC on the upgraded member when indicated per the guide. If you don't enable it, there will be no sync of connections between members, so the failover step will be impacting as all currently open connections will be dropped out of state.

[the_rock]

Hey bro,

What Emma said is exactly how it works. Personally though, I never had an issue where both members have MVC enabled and its on by default since R80.40, which you can verify by running cphaconf mvc command (or cphaprob mvc, cant recall now)

Best,

Andy

[Matlu]

Broo 🙂

So, in versions such as R81, it is no longer necessary to worry about enabling MVC, correct?

Does the command you shared also apply to VSX Cluster environments?

Thank you.

[the_rock]

I dont have vsx to test in the lab, but worked last time I did. Correct, no need to worry about mvc in R81.

Buena noche 🙂

Andy

[emmap]

MVC is only on by default in R81.20 when the JHF is installed. It's certainly not on by default in R82, I've done a few upgrades and had to enable it.

[the_rock]

Hm, never really checked that on barebone R81.20, now you got me curious. But, considering I can tell you are true genius, I will take your word for it 🙂

Andy

[Matlu]

Hello, @emmap 

Does MVC need to be enabled before starting the upgrade on the boxes?

For example, you start the upgrade process from R81 to R82 on VSX Cluster:

As a “preliminary” activity, do you enable MVC on both members of the Cluster?

Or is this enabled on only one member after it has already been “upgraded” to the new version?

That confuses me a little.

If an administrator “forgets” to activate MVC, do they run the risk of encountering problems during the upgrade of their boxes?

[Bob_Zimmerman]

MVC is enabled on the newer member to allow it to synchronize with the older member. You don't do anything special with the old member at all. It's easy to tell if you need to enable MVC: if your new cluster member goes to the state Ready rather than Standby, you should enable MVC. I think on normal VSX, you just need to enable it in VS 0. Might be different on VSNext in the future. Check cluster member state, and if you see Ready, enable it.

Note that MVC only helps for different software versions. It does not help firewalls with different CoreXL topologies to sync. I've seen a box sync to a new box with more cores, but moving to a box with fewer cores will definitely involve a hard outage.

[Matlu]

Hello @Bob_Zimmerman 

The criteria you have detailed applies to any VSX Cluster mode, correct?

Because I have a VSLS mode

Member 1: Currently Active

Member 2: Currently Standby

So, if I start with Standby and perform the upgrade process with CPUSE, once this box is already in R82, would it only be necessary to enable MVC here?

When both members are already in R82, is MVC turned off?

Thanks 🙂

[Magnus-Holmberg]

MVC you enable on the upgraded node, so it can sync the data from the older member.
MVC allows you to have a smother failover, as the old member will see you as a standby nod instead of DOWN.
If you dont use MVC, all connections will need to be "reconnected" meaning you can get some application issues.
However MVC dosn´t work for all type of traffic, there is still limitations.

When upgrade is finished, turn mvc off.
The upgrade guide is OK, but there is room for improving the step by step 🙂

We uses MVC for all upgrades, it works great 🙂

So the status before MVC is added, it will be like this.
And on the node that is still running the traffic you will have Active / Lost.

[the_rock]

FWIW, I had done so many upgardes where MVC was on on both members, never had an issue.

Andy

[Bob_Zimmerman]

It doesn't hurt to enable it on the old systems, it's just a waste of time. MVC only matters on the upgraded member, and lets it go from Ready state to Standby (and from there to Active).

[the_rock]

Well, no time spent on it, at least in my work lol. I always find with jumbo fix installed, anything above R80.40 already has MVC enabled anyway.

Andy

[Bob_Zimmerman]

Yes. Exactly.

[emmap]

It's all in the install and upgrade admin guide. Follow the guide and enable it when it says to (after you've done the software upgrade on the gateway).

[the_rock]

Agree 100%.