Overview
This section provides information related to upgrading a Cisco HyperFlex Stretched Cluster. The procedure for performing a Stretched Cluster upgrade is similar to the regular HyperFlex cluster upgrade procedure.
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This section provides information related to upgrading a Cisco HyperFlex Stretched Cluster. The procedure for performing a Stretched Cluster upgrade is similar to the regular HyperFlex cluster upgrade procedure.
Only split upgrade of the HX Data Platform is supported. Upgrade of UCS firmware is not supported.
Manual cluster bootstrap is required for upgrade from a pre-3.5 release to 3.5(1a).
Auto bootstrap is supported for upgrade from 3.5(1a) to later releases.
When upgrading to any release from 3.0.x to 3.5.x or later releases:
If you manually bootstrap only one node, the ESXi checkbox will not appear under the Select Upgrade Type section of the Cluster Upgrade page. The ESXi upgrade option appears only after upgrading HX Data Platform to release 3.5.x or later releases.
If you manually bootstrap all the nodes to 3.5.x or later release, the ESXi checkbox will appear under the Select Upgrade Type section of the Cluster Upgrade page. However, you cannot perform an ESXi only upgrade at this point. You can do a combined upgrade of HX Data platform + ESXi.
HyperFlex Witness node version 1.0.2 is supported from 3.5(1a) or later releases. An upgrade of the HyperFlex Witness node is not required when upgrading stretched clusters to 3.5(1a) or later releases.
HyperFlex Release |
Witness Node Version |
---|---|
4.0(2a) |
1.0.8 |
4.0(1b) |
1.0.4 |
4.0(1a) |
1.0.4 |
Follow these steps when upgrading a HyperFlex Stretched Cluster from a current HX Data Platform version of 3.0(1x) or later releases.
Note |
If the HyperFlex package update is interrupted due to power failure or reboot of the node that is being upgraded, the controller VM must be re-imaged or manual intervention is required to fix the issue depending on the state of the system. For more details, contact Cisco TAC. |
Complete pre-upgrade validation checks. See Upgrade Prerequisites for more details.
Download the latest Cisco HX Data Platform Upgrade Bundle for upgrading existing clusters from previous releases, from Software Download .
Complete steps 1 to 6 in the Online Upgrade Process Work flow. See Online Upgrade Process Workflow for more details.
Upgrade Cisco UCS Infrastructure.
Bootstrap to upgrade Cisco HX Data Platform plug-in.
Disable snapshot schedule, on the bootstrapped storage controller VM.
If DRS is Enabled, the VMs are automatically migrated to other hosts with vMotion.
Note |
If DRS is not enabled and the VMs of the node are not migrated with vMotion, all the VMs on the node will be automatically shutdown. For more information, see VMware Documentation for Migration with vMotion. |
Step 1 |
Log in to HX Connect.
|
||||||||||||
Step 2 |
In the Navigation pane, select Upgrade. |
||||||||||||
Step 3 |
On the Select Upgrade Type page, select HX Data Platform and complete the following fields:
|
||||||||||||
Step 4 |
Enter the vCenter credentials.
|
||||||||||||
Step 5 |
Click Upgrade to begin the cluster upgrade process. |
||||||||||||
Step 6 |
The Validation Screen on the Upgrade Progress page displays the progress of the checks performed. Fix validation errors, if any. Confirm that the upgrade is complete. |
Upgrade HyperFlex Stretched Cluster.
root@StCtlVM:~# stcli cluster info | grep healthy
Step 1 |
Log in to the witness VM using SSH and execute the following command to stop the service exhibitor.
|
||
Step 2 |
Copy the exhibitor.properties file available in the /usr/share/exhibitor/ path to a remote machine from where you can retrieve the exhibitor.properties file.
|
||
Step 3 |
Log out from the Witness VM. Power off and rename the Witness VM to WitnessVM.old.
|
||
Step 4 |
Deploy a new Witness VM and configure the same IP address as the old Witness VM.
|
||
Step 5 |
Log in to the new witness VM using SSH and execute the following command to stop the service exhibitor.
|
||
Step 6 |
Copy the exhibitor.properties file from the remote machine (copied in Step 2) to the /usr/share/exhibitor/ path of the new Witness VM.
|
||
Step 7 |
Verify if the following symlinks are preserved in the new Witness VM:
If the symlinks are not available, execute the following command:
|
||
Step 8 |
Start the service exhibitor by executing the following command:
|