posted

3 Comments

In the previous post we covered a scenario demonstrating how to upgrade from vSphere 5.5 to 6.5. This post will cover another scenario but this time upgrading from vSphere 6.0 to 6.5 Update 1. Keep in mind this is an example scenario and may or may not cover your particular environment. The key take away is understanding the upgrade process and concepts so you can apply them to your own environment.

Scenario

The Awesome Sticker company has five datacenter sites, three in the US and two in Europe. Each site is running vSphere 6.0 using a vCenter Server Appliance with external Platform Services Controller deployment. There are three vSphere Single Sign-On domains (SSO), one for the US, one for Europe, and one for the Horizon VDI environment which is using a Windows vCenter Server with embedded Platform Services Controller. The goal is to get this Windows-based vCenter Sever migrated to the vCenter Server Appliance. The environment is using vSAN as their primary storage and is using SRM for Disaster recovery at its primary and secondary datacenters in both the US and Europe. Management has tasked Kyle, their systems engineer, with upgrading the entire environment to vSphere 6.5 Update 1. Kyle has already verified the current Dell servers are supported for vSphere 6.5 via the hardware compatibility list. The whiteboard below represents the current version of each product and target (upgrade to) version. Accompanying each product are notes taken from the install or upgrade section found in its release notes.

Environment Discovery

Since the current environment is on 6.0 Update 3, Kyle had to wait until vSphere 6.5 Update 1 was released before he could start the upgrade process. While looking through the environment he noticed the following items that needed to be addressed either before or after the upgrade process:

  • Each site only had one Platform Services Controller (PSC) which was a single point of failure and will need to add a secondary PSC at each site. Kyle verified the vSphere 6.5 Update 1 maximums which now support 10 PSCs and 15 vCenter Servers in a vSphere SSO domain. Now he will have a total of six external PSCs in the US and four in Europe.
  • The vCenter Servers are not being backed up at each site. Kyle is still waiting to hear back from the companies backup administrator but has decided to leverage the built-in file-based backup /restore in the VCSA 6.5.
  • There is a Nexus 1000v running in one of the European datacenters. Since Kyle knows that this will be the last release that will support a 3rd party switch such as the Cisco Nexus 1000v, he has decided to take the opportunity to migrate to the VMware Virtual Distributed Switch (VDS). He will use the Nexus 1000v to VDS migration tool to move this environment to a Virtual Distributed Switch (VDS).
  • Kyle opened an SR with VMware support getting ready for the upcoming upgrade.

Upgrade Order

Since there are three different vSphere SSO domains, Kyle has decided that he will tackle the smallest footprint and work his way up. His plan of attack is start with the VDI environment, then the European datacenters, and finally the US datacenters.

VDI Environment
Before staring the VDI environment upgrade Kyle took a backup prior to starting.

  1. The embedded vCenter Server 6.0 U3 will need to be migrated to 6.5 U1. All of the components (PSC, VC, VUM) reside on one virtual machine and will be migrated to a VCSA with embedded PSC. This will be done using the migration tool included in the VCSA 6.5 Update 1 ISO.
  2. Upgrade Horizon View server from 7.0 to 7.2. Make sure to upgrade the horizon view components in the correct order.
  3. Use VUM to upgrade the ESXi hosts for the VDI environment.
  4. Upgrade VM tools, then upgrade the horizon agent in the virtual desktops.
  5. Configure vCenter Server protocol (FTP, FTPS, HTTP, HTTPS, SCP) for backup. The native backup can be done manually or can be automated using the APIs.

European Datacenters

  1. Use the Nexus 1000v to VDS migration tool.
  2. Backup the PSCs and vCenter Servers prior to upgrading. Yes you can take a snapshot, but there is no need to shutdown all the PSCs to do so. Remember the PSCs are multi-master so all the information is replicated across the vSphere domain.
  3. Upgrade all the PSCs in the vSphere SSO domain from 6.0 U3 to 6.5 U1 first. In this case we only have two, but will be adding additional PSCs later. Mount the VCSA 6.5 U1 ISO and selecting the upgrade option from the installer menu and go through the wizard to upgrade the PSCs. Now that the environment is in mixed mode it is important to upgrade all the vCenter Servers appliances within the vSphere SSO domain as soon as possible. There is no enforced time limit on mixed mode, but it is better to get both vCenter Server Components (PSC and vCenter Server) on the same version from a troubleshooting perspective and to gain all the new functionality in vCenter Server 6.5.
  4. Upgrade all vCenter Server Appliances within the vSphere SSO domain from 6.0 U3 to 6.5 U1 by mounting the VCSA 6.5 U1 ISO and selecting the upgrade option from the installer menu.
  5. Since there are only two PSCs, one at each site we will have to make sure that we cleanup some replication agreements once we are done using vdcrepadmin. This will also give Kyle the ability to manually repoint within each site incase of a PSC failure. Although he liked the idea of the automated failover using the load balancer, he didn’t want the added complexity it brings.
    • Original PSC #1 in the London site connected to original PSC #2 in the Berlin site.
    • Deploy a new secondary PSC # 2 in the London site London, replication partner is the original PSC # 1 in the London site.
    • Deploy new a secondary PSC #2 in the Berlin site, replication partner is the original PSC # 1 in the Berlin site.
    • Use vdcrepadmin to create a new replication agreement from PSC # 2 in the Berlin site to PSC # 1 in the London site.
    • Clean up old replication agreement between original PSC #1 in the London site and original PSC #1 in the Berlin site.
  6. Upgrade vSAN.
  7. Upgrade SRM.
  8. Upgrade ESXi hosts using VUM.
  9. Upgrade VM tools / compatibility.
  10.  Upgrade VMFS.
  11.  Configure vCenter Server protocol (FTP, FTPS, HTTP, HTTPS, SCP) for backup. The native backup can be done manually or can be automated using the APIs. You only need to backup one of the PSCs in the vSphere SSO domain, but there is no harm in backing all of them up. The restore process of a PSC is only required if they all go down otherwise just deploy new.

US Datacenters

  1. Backup the PSCs and vCenter Servers prior to upgrading. Yes you can take a snapshot, but there is no need to shutdown all the PSCs to do so. Remember the PSCs are multi-master so all the information is replicated across the vSphere domain.
  2. Upgrade all the PSCs in the vSphere SSO domain from 6.0 U3 to 6.5 U1 first. In this case we only have two, but will be adding additional PSCs later. Mount the VCSA 6.5 U1 ISO and selecting the upgrade option from the installer menu and go through the wizard to upgrade the PSCs. Now that the environment is in mixed mode it is important to upgrade all the vCenter Servers appliances within the vSphere SSO domain as soon as possible. There is no enforced time limit on mixed mode, but it is better to get both vCenter Server Components (PSC and vCenter Server) on the same version from a troubleshooting perspective and to gain all the new functionality in vCenter Server 6.5.
  3.  Upgrade all vCenter Server Appliances within the vSphere SSO domain from 6.0 U3 to 6.5 U1 by mounting the VCSA 6.5 U1 ISO and selecting the upgrade option from the installer menu.
  4. Add a secondary PSC at each site, one at each site we will have to make sure that we cleanup some replication agreements once we are done using vdcrepadmin.
    • Original PSC #1 in the Seattle site connected to original PSC#2 in the Austin site.
    • Original PSC#2 in the Austin aite connected to the original PSC in the Tampa site.
    • Deploy a new secondary PSC # 2 in the Seattle site, replication partner is the original PSC # 1 in the Seattle site.
    • Deploy a new secondary PSC #2 in the Austin site, replication partner is the original PSC # 1 in the Austin site.
    • Deploy a new secondary PSC #2 in the Tampa site, replication partner is the original PSC # 1 in the Tampa site.
    • Use vdcrepadmin to create a new replication agreement from PSC # 2 in the Tampa site to PSC # 1 in the Seattle site for the ring.
    • Create a new replication agreement between newly deployed PSC #2 in the Seattle site with PSC #1 in the Austin site.
    • Create a new replication agreement between newly deployed PSC #2 in the Austin site with PSC #1 in the Tampa site.
    • Clean up the old replication agreement between original PSC #1 in the Seattle site and the original PSC #1 in the Austin site.
    • Clean up the old replication agreement between the original PSC #1 in the Austin site and the original PSC # 1 in the Tampa site.
    •  Use vdcrepadmin to make sure you have nice linear topology 
  5. Upgrade vSAN
  6. Upgrade SRM.
  7. Upgrade ESXi hosts using VUM.
  8. Upgrade VM tools / compatibility.
  9. Upgrade VMFS.
  10. Configure vCenter Server protocol (FTP, FTPS, HTTP, HTTPS, SCP) for backup. The native backup can be done manually or can be automated using the APIs. You only need to backup one of the PSCs in the vSphere SSO domain, but there is no harm in backing all of them up. The restore process of a PSC is only required if they all go down otherwise just deploy new.

Kyle was tasked with upgrading an environment from vSphere 6.0 U3 to vSphere 6.5 Update 1. Before starting he did his research getting up to speed on what’s new with vSphere 6.5 Update 1. He also watched the new vCenter Server light board videos to learn about vCenter Server architecture, deployment and availability as part of his upgrade process. Since vCenter High Availability was not a requirement, Kyle was able to add a secondary PSC at each site without the required load balancer reducing complexity. He backed up prior to starting the upgrade process and had a recovery/backout plan in case he needed to revert back. The important key takeaway is understanding the upgrade process and concepts and applying them to your own environment. Happy upgrading!

About the Author

Emad Younis

Emad Younis is a Senior Technical Marketing Engineer working in the Cloud Platform Business Unit at VMware. He currently focuses on the vCenter Server Appliance, vCenter Migrations, and VMware Cloud on AWS. Previous to VMware he worked as a virtualization architect designing and implementing large enterprise vSphere environments both as a customer and partner. Emad can be found blogging on the VMware vSphere blog, and his personal blog emadyounis.com. Get notifications of new blog posts and more by following Emad on Twitter @emad_younis.