vCenter Reduced Downtime Update in vSphere 8 U2
About vCenter Reduced Downtime Update
vSphere 8 Update 2 introduces Reduced Downtime Update for on-premises vCenter instances.
Reduced Downtime Update (RDU) uses a migration-based approach for going from one build of vCenter to a newer build of vCenter. It’s not unlike the existing method to do a major vCenter upgrade, from version 7 to version 8 for example, but does have a significant difference.
Using a migration-based method, a new vCenter appliance is deployed and all vCenter data and configuration is copied from the current vCenter to the new vCenter, again similar to a major vCenter upgrade. The key difference is that during this data and configuration copy phase, the current vCenter and all its services remains online and vCenter can continue its productivity. The only vCenter service downtime that is incurred is a few short minutes when the current vCenter services are stopped, and the new vCenter services are started. This typically takes less than 5 minutes.
Check out this step-by-step video walkthrough using RDU to update a vCenter 8.0 U1 to version 8.0 U2
Important: vCenter reduced downtime upgrade is supported for single self-managed vCenter instances initially. It does not support vCenter instances enabled with vCenter HA or vCenter instances participating in Enhanced Linked Mode (ELM).
How does vCenter RDU work?
For a step-by-step guide with screenshots, see KB article 92659 or refer to the above video.
Major upgrades of vCenter (i.e. from 7.0 to 8.0) have been migration-based for many releases. A new vCenter VM is deployed and the data from the current running vCenter is copied to the the vCenter. We looked at that method and investigated how it could be applied to minor patches and updates, but also, looking at how we can streamline and orchestrate the process as much as possible and minimise to total downtime period of vCenter services.
First things first. Mount the vCenter 8.0 U2 (or later) ISO to the current vCenter VM. Ensure this is the full vCenter installation media (approximately 10GB) and not the smaller update ISO. Then navigate to the vCenter > Updates > Update section of the vSphere Client.
Figure shows the VMware vCenter Server Appliance ISO media used for RDU
The vCenter Lifecycle Manager service (not to be confused with the vSphere Lifecycle Manager service) is used to orchestrate the update. Essentially, vCenter uses vCenter to update vCenter. However, there is a chicken & egg caveat that needs solving first. A vCenter 8.0 or 8.0 U1 is not capable of orchestrating a vCenter 8.0 U2, so the first thing that needs to happen is that we update, in-place, the vCenter Lifecycle Manager service plugin to the version 8.0 U2. This allows the current vCenter to orchestrate the update to a new version of vCenter. The plugin update will automatically refresh the UI and may cause the UI to jump to a different section of the updates tab. Just navigate back to vCenter upgrade workflow to continue.
If you see an error "An error occurred while mounting the ISO file. Verify if the device attached to the CDROM is a vCenter Server ISO file." it might mean you have not mounted the ISO or mounted an incorrect ISO. The correct ISO should be named VMware-VCSA-all-8.0.2-XXXXXX.iso. You can leave the RDU workflow to mount the ISO and when you come back the UI will resume at the same point.
Once the plugin is updated, we then prepare the configuration of the new vCenter 8.0 U2 VM. You can simply inherit the VM location, name and sizing from the current vCenter or optionally customise these parameters. You must provide the new vCenter with a new temporary IP address. This allows both vCenter VMs to be online at the same time and for data replication to succeed.
In certain circumstances you may see a warning when configuring the temporary network settings stating "Mac Changes is set to 'Reject' on portgroups VM Network used by the vCenter. Forged Transmits is set to 'Reject' on portgroups VM Network used by the vCenter. This could prevent from a successful upgrade.". Change the policy of Mac Changes and Forged Transmits to Accept on the portgroup.
Note: The vCenter SSH service will be turned on automatically to allow for secure date replication. Ensure port 22 is open on the network between the current vCenter VM and the new vCenter VM.
The new vCenter VM is deployed, configured, and receives the necessary data from the current vCenter. This includes all contents of the vCenter database, configuration, TLS/SSL certificates and more. Some security hardening may not be replicated to the new vCenter and may need to be re-applied. At this point in time, both vCenter VMs are still online. The current vCenter has not been impacted and can continue productivity.
Figure shows both the current and new vCenter VMs are online and ready for the final phase to perform the switchover.
Once the replication of data is complete, you are now at the point where you can perform the final update step and switchover to the new vCenter. This is the only phase of brief downtime for vCenter. The current vCenter will be shutdown and the new vCenter will adopt the previous vCenter FQDN, IP, TLS/SSL certificates and begin starting the vCenter services. This process typically takes less than 5 minutes, but can vary depending on your own environment.
Figure shows the switchover in progress.
Once the switchover phase has completed, you can log into vCenter using the vSphere Client and verify that everything is expected. Like after any lifecycle event, now would be a good time to take a fresh vCenter file-based backup so you have a recovery point on the new version.
Figure shows the switchover is complete. This completes the update of vCenter using RDU.