Create a Post
Showing results for 
Search instead for 
Did you mean: 

multi-version cluster upgrade

Hi Team,

We are planning to upgrade a firewall cluster to r80.40 . We have referred the installation manual as would plan for "Multi-Version Cluster (MVC) Upgrade"

Previously, we have upgrade cluster to r80.30 using the connectivity upgrade method which seem to be replaced by Multi-Version Cluster (MVC) Upgrade. We have a few queries related to that
1.Can we still use connectivity upgrade for r80.40 or its not possible as it have been replaced with MVC
2.In connectivity upgrade method we perform a controlled failover from the gateway on older version (that is active) to the upgraded gateway (in ready state) by stopping the services on the gateway with older version. But nothing such has been mentioned for MVC method . How does the failover take place ?
3.In MCV once we upgrade the gateway to r80.40 and enabled MCV followed by a policy push . Does the policy push shift traffic to upgraded gateway.

4. Is controlled failover required ?




0 Kudos
1 Reply

1. Just use the new MVC approach (cphaconf mvc on), instead of the old one (cphacu start no_dr). I do not know, if the old one s still usable, never tried it. MVC was working fine for use with every cluster.

2. With MVC set to on (on the upgraded gateway), the cluster sync feature just ignores the version missmatch and syncs normally. So after you have checked, that cluster is really in sync, just do a controlled failover using clusterXL_admin down on the active node. This will let the cluster failover (if there are no problems on the upgraded node).

3. Normally the answer is no. Details: It depends on your cluster preempt settings, node priorities and which node you upgrade first. If you have set ClusterXL to "Upon cluster member recovery: Maintain current active cluster member" nothing will happen automatically. You will have to shift traffic manually by using clusterXL_admin down on the current active node. If you use the other setting "Switch to higher priority cluster member" and do not want to change it (even temporary), using "clusterXL_admin down -p" might come in handy to have control over the exact time when the failover occures, because it makes the artificial problem "admin_down" persistent across reboots.

4. It is not required, but I would strongly recommend it.

0 Kudos