Upgrade from 3.7.9 to 4.1.0

[IT_alien]

Hi,

We are currently running Omnistack 3.7.9, with firmware SVTSP-2019_0315.04.iso.

The SimpliVity federation consists of two clusters:
Production: 2x ProLiant DL380 Gen10
Backup: 1x ProLiant DL380 Gen10
running VMware ESXi 6.7.0 build 13004448 (ESXi 6.7 EP 07)

Our goal is to upgrade the infrastructure to Omnistack v.4.1.0, Firmware SVTSP-2021_0110.02.iso and ESXi v.6.7 P04.

We are not entirely sure whether a direct upgrade through Simplivity Upgrade Manager is supported or it is necessary to perform some intermediate step to the final version other then the final manual upgrade using ESXi670-202011002.zip.

Any advice?

[dhooley]

Hello @IT_alien 

In this instance you can do a straight upgrade from UM for all 3 components (i.e. OVC, ESXi & Firmware). The OVC will be upgrade first and then the node rebooted for ESXi & Firmware. It is a single upgrade hop from 3.7.9 to 4.1.0.

Interoperability guide linked for your reference - https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docId=a00099036en_us

David

[IT_alien]

Hi David,

Thanks for the quick answer.

Just another question I forgot to put in the original post: is upgrading the clusters at different time supported?

We have been asked to upgrade the 1-node cluster first and the other one or two days later, but the Interop Guide states that:

• All versions 3.7.10/3.7.10A and earlier require full federation commit.
• If you are upgrading from 3.7.10/3.7.10A or earlier, you must first upgrade all clusters in the federation and only then commit the clusters. Upgrading and committing a subset of the clusters in the federation while leaving the remaining at 3.7.10/3.7.10A or earlier can create interoperability issues. To achieve federation commit, perform the upgrade on all clusters and then commit the clusters.

Which sounds pretty much as a NO, but I would be extra sure before giving an answer that would impact our SLA and system stability.

[dhooley]

Hi @IT_alien 

Yes your understanding is correct. However, you can upgrade the single node cluster and leave it in an un-committed state until the second cluster i completed. As long as you are not leaving the node in an un-committed state for a lengthy period, then there is no issue.

Once you have upgraded to 4.1.0, all future upgrades will be able to be done one cluster at a time, including committing.

Hope this helps!

[IT_alien]

Hi @dhooley,

They would delay the second upgrade a couple of days to assess 4.1.0 on the Backup cluster and decide whether to upgrade the Production one. I am not 100% familiar with the upgrade commit concept, but it sounds that the cluster or the federation wouldn't be fully operational, right?

Alessandro

[ACA_RAY]

@IT_alienDo you use the file level restore in your environment often? If you do, just be aware it's basically broken in the 4.X.X releases and as yet it's still not fixed. There is a thread on it in this forum. I would hold off upgrading if it's something you use a lot. It's a pain to restore the whole VM, muck around with attaching disks to another VM, initlaizing them in disk managment and then reversing the process just to recover a single file. Very frustrating.

[dhooley]

@IT_alien"commit" basically activates the code of the newer version. So I guess that would not be an option for you. You will have to upgrade the entire federation and commit federation wide this time around. If you do not commit, the cluster will continue to be operational but will not activate the higher level of code.

@ACA_RAYthe FLR issues with spaces in the directory path should be resolved in 4.1.0 if this is what you are referring too.

Hope this helps!