Solved: MVC Upgrade

Moudar · ‎2024-02-01

Hi,

As I read the CCSE course book, I could notice this:

So, how to test on a cluster if you do not install the policy?

Say I would upgrade from 81.10 to 81.20 and start the process by installing the new image on the standby gateway. What is the point of MVC if you cannot install the policy?

If not to install the policy on different version gateways in a cluster, how then should I test the configuration, what should be tested? How to be sure that everything went good on the standby? Should I try to make a manual failover?

Oliver_Fink · ‎2024-02-01

Maybe the quoted text is a little bit misleading. What do I do through a MVC upgrade?

Installing one node (eg. Node B - R81.20, Node A still has R81.10).
After reboot Node B has no policy.
Activate MVC on Node B.
Upgrade version for cluster object in SmartConsole.
Install policy on Node B
1. Select Install on each selected gateway independently.
2. Clear For gateway clusters, if installation on a cluster member fails, do not install on that cluster.
Now Node B will take part in the cluster with Node A.
You can switch with clusterXL_admin between nodes. (Have the limitations in mind!) Do testing with Node B as ACTIVE node.
Upgrade Node A.
Install policy on both nodes
1. Select Install on each selected gateway independently.
2. Select For gateway clusters, if installation on a cluster member fails, do not install on that cluster.
Deactivate MVC on Node B.

You can install policies with MVC. But you have to install it separately on both nodes and you have to change Version for the cluster in SmartConsole for both nodes each time. So, MVC is not meant for permanent use, but only to get a non-interruptive upgrade and the possibility to test the new version on one node before upgrading the whole cluster.

View solution in original post

Oliver_Fink · ‎2024-02-01

Maybe the quoted text is a little bit misleading. What do I do through a MVC upgrade?

Installing one node (eg. Node B - R81.20, Node A still has R81.10).
After reboot Node B has no policy.
Activate MVC on Node B.
Upgrade version for cluster object in SmartConsole.
Install policy on Node B
1. Select Install on each selected gateway independently.
2. Clear For gateway clusters, if installation on a cluster member fails, do not install on that cluster.
Now Node B will take part in the cluster with Node A.
You can switch with clusterXL_admin between nodes. (Have the limitations in mind!) Do testing with Node B as ACTIVE node.
Upgrade Node A.
Install policy on both nodes
1. Select Install on each selected gateway independently.
2. Select For gateway clusters, if installation on a cluster member fails, do not install on that cluster.
Deactivate MVC on Node B.

You can install policies with MVC. But you have to install it separately on both nodes and you have to change Version for the cluster in SmartConsole for both nodes each time. So, MVC is not meant for permanent use, but only to get a non-interruptive upgrade and the possibility to test the new version on one node before upgrading the whole cluster.

Moudar · ‎2024-02-03

Your text contains more logical reasoning than what I have encountered in the book. I will strive to enhance my understanding and adhere to that approach.

the_rock · ‎2024-02-03

I can tell you from my experience, activating MVC did not sadly help much compared to say zero downtime upgrade. There was always at least 30 seconds period where connections would drop. Maybe others had better success, not sure.

Best,

Andy

Are you a member of CheckMates?

MVC Upgrade