Upgrade to 5.0

[Convergo]

I am reviewing the upgrade proces of 4.2 to 5.0. We currently have one federation with multiple clusters where clusters are located on different geographic locations.
In my understanding we are able to upgrade the OVC's from 4.2 to 5.0.

Just curious what's happening under the hood:
- Is the federation versionless, and not impacted with the upgrade of OVC's ?
- Can we commit/upgrade the clusters per location running the upgrade manager on the specific location ?
- What is the impact when we plan to upgrade the clusters in a time frame of 3 months. Are there any limitations when running 4.2 and 5.0 clusters in the same federation ?

I am curious about your experiences

[gustenar]

Hello @Convergo 

The federation won't be impacted during the upgrade as only one OVC per cluster runs the update at the same time. 

You can use ONE instance of Upgrade Manager, and you can choose to upgrade 1 OVC per cluster at the same time. 

Mixed versions between clusters is supported. All nodes in the cluster need to be at the same version before being able to commit. 

Please refer to the HPE Interoperability Guide for more information : 

https://support.hpe.com/hpesc/public/docDisplay?docId=a00117319en_us

[Convergo]

Thanks for your explanation. So basically commit activates the code for the upgraded 5.0 OVCs when the last cluster has been upgraded. To prevent updates being deployed over the WAN link between clusters, we update firmware and esxi with a local upgrade manager installed on the local cluster. When upgrading OVC, esxi and firmware of a cluster on location A plan is to exit the upgrade manager after the upgrades. Finally we start a new instance of upgrade manager that will be started in location Z. Will this new instance of upgrade manager notice that location A needs to be committed? In this way we update location A to Z, and finalize the upgrade in this last location Z by committing all clusters. Is this allowed and what would be the best approach. We want to avoid update manager on one location (for example location A) is interrupted during a 2 month update path (like windows update or a human error) / WAN utilization during upgrades.

[gustenar]

You could also commit location A as soon as you finish the updates of all nodes on that particular cluster, Upgrade Manager gives you the option to commit just that one cluster. Federation can live with one cluster running 5.0 and another cluster running 4.2.0. Once you commit, you could close Upgrade Manager and then run it from Location Z, update all nodes and commit that one. 

[Convergo]

Thanks! Documentation is quite limited on this specific case (or I missed it). To summarize; Basically a federation can mix 4.2 and 5.0 clusters within the same federation, and therefore an upgraded 5.0 cluster can be commited, while other clusters within the federation are on a lower code level (respecting the interoperability guidelines within the federation). Makes sense ?

[gustenar · Accepted solution]

Yes, that's correct. All this information and more is available in the HPE SimpliVity Interoperability Guide and also the HPE Upgrade Guide. 

https://www.hpe.com/us/en/collaterals/collateral.a50005929enw.html