1.1.2.1 Active Upgrade(Quick Upgrade)
A quick upgrade is applicable to upgrade scenarios with the same host OS
kernel version and is commonly used for upgrading a minor version to another of the same series (for example, 6.7.0_R2 > 6.7.0_R3) or upgrading one version to another released within a short period of time (for example, 6.7.0 > 6.8.0).
Specifically, all physical nodes are directly upgraded without changing the run location and running status of VMs in the cluster. With the process active
restart technology, a quick upgrade will only cause a business system jitter which will last for 3 seconds or shorter and will not interrupt the business system. A quick upgrade of the cluster takes a shorter time to complete.
A quick upgrade is mainly applicable to the following versions (and is
commonly used for upgrading some of them):
| Current Version |
Target Version |
| HCI6.7.0_R1_EN/R2_EN |
HCI6.8.0 |
| HCI6.7.0_R1/R2/R3_EN |
HCI6.9.1 |
| HCI6.8.0/R1/R2 |
| HCI6.9.0 |
| HCI6.7.0_R1_EN/R2_EN |
HCI6.10.0R2 |
| HCI6.8.0/R1/R2 |
| HCI6.9.0/6.9.1 |
| HCI6.10.0/6.10.0_R1 |
| HCI6.8.0/R1/R2 |
HCI6.11.1 |
| HCI6.10.0/6.10.0_R1/6.10.0R2 |
1.1.2.2 Rolling Active Upgrade
In the event of host OS changes or kernel or driver version upgrades, all clustered nodes must be restarted, which will cause business service
interruption. With live migration technology, rolling active upgrades can significantly minimize the impacts on the services.
The rolling upgrade's functionality is migrating the VMs running on a node that needs to be upgraded to other nodes or clusters through live migration before restarting the node or cluster so that business services will not be interrupted. A rolling upgrade will not affect the business services, except that the live
migration of VMs during the upgrade can cause business service fluctuations for about 1 second, and the overall upgrade process can be arranged.
The rolling upgrade will migrate production VMs running on nodes that need to be upgraded to other nodes in the same cluster and then migrate them back
after the upgrade is complete and the upgraded nodes are restarted. The cluster to be upgraded must have sufficient resources.
1.1.2.3 Offline Upgrade
Offline upgrade requires all clustered nodes to be restarted. All clustered
nodes must be restarted in the event of host OS changes or kernel or driver
version upgrades. The cluster restart requires all business VMs to be shut
down, making the business system unavailable. The offline upgrade is mainly
applicable to the following versions (and is commonly used for upgrading some of them):
| Current Version |
Target Version |
| HCI6.0.0_R5_EN |
HCI6.8.0 |
| HCI6.3.0_R1/R2/R3_EN |
| HCI6.0.0_R5_EN |
HCI6.9.1 |
| HCI6.3.0_R1/R2/R3_EN |
| HCI6.0.0_R5_EN |
HCI6.10.0_R2 |
| HCI6.3.0_R1/R2/R3_EN |
| HCI6.3.0_R1/R2/R3_EN |
HCI6.11.1 |
{{ $t('index.defaultHeader.chromeBrowserTip') }}