Who rated this post

OK, not to exaggerate now, but I had done this probably 50 times and every time I did it, below is what I followed and NEVER had an issue (forget about the versions, process was literally the same even 20 years ago lol)

I will list steps I do:

-generate backups on both cluster members (I dont bother with snapshots, but thats your choice)

-push policy before the upgrade, just to make sure all is good

-download say R81.20 (latest recommended jumbo) and verify it can be upgraded

-install R81.20 on BACKUP member and reboot

-once rebooted, change cluster version in dashboard to R81.20 and uncheck that option for cluster "dont install policy..." and once policy is done, it will ONLY apply on upgraded member

-current master is STILL master, one on R81.10

-issue failover by running clusterXL_admin down on R81.10 member, so everything goes to upgraded member and verify this by running cphaprob roles and cphaprob state commands

-if all good, upgrade R81.10 member to R81.20, install policy after reboot, just recheck option "dont install policy..." (its also indicated what option that is in zero downtime upgrade)

-once done, verify cluster state and if all good, you can fail back to original master member (just dont forget to run clusterXL_admin up) : - )

-once done, verify all...routing, nat, vpn etc

I am 100% POSITIVE in these steps, because they never failed for me.

Andy