The first post in this series covered Phase 1 of the vSphere 6.5 upgrade process. Phase 1 consists of all the upfront work that one should do before starting an upgrade. This includes getting familiar with the new vSphere 6.5 features and the necessary documents. Hopefully, by now you’ve done your homework and are ready to move on to Phase 2 which is planning out the upgrade steps of all the components, scheduling meetings with the business owners to gather requirements, submitting the necessary change controls, and executing the upgrade.
Over the course of the next couple of blog posts, we will be going through a couple of scenarios that will help you see how to plan an upgrade to vSphere 6.5. Each scenario will also include a set of requirements and decisions used to determine the upgrade path. These examples may or may not relate to your current environment. The intent is to help familiarize you with the upgrade process and concepts and then apply them to your specific situation.
Scenario
The Amazing T-Shirt company currently has two datacenter sites, California and New York. The company recently acquired a third site that will help with their distributions located in Texas. Each site is running vSphere 5.5 using an embedded vCenter Server deployment on Windows. Other products in the environment include NSX, vRealize Automation (vRA), vRealize Operations (vROPS), and vRealize Log Insight (vRLI). vRA is using a separate vCenter Server endpoint from the previously mentioned vCenter Server. The example chart below represents the current version of each product and target (upgrade to) version. Accompanying each product are comments taken from the install or upgrade section found in its release notes. Also, do not forget to add any 3rd party products (ex. Backup) that are in use to determine if they support or have an upgrade path in order to be compatible with vSphere 6.5.
After reading about all the new vSphere 6.5 features, Adam, the company’s new lead virtualization architect has decided that it’s time to upgrade. Before starting the upgrade process he has compiled a list of business requirements and then will map out the associated upgrade path. The vSphere 6.5 upgrade project is estimated to take three months to complete. This includes planning, coordinating, submitting change controls, and validation. One of Adam’s main objectives is not to over complicate his design while meeting the business’s requirements. Here is a list of the requirements that Adam has compiled after his meeting with the business’s key stakeholders.
Requirements and Decisions
vSphere Single Sign-On Domain Consolidation
Having a single vSphere Single Sign-On (SSO) domain will simplify management after the upgrade process. Starting with vSphere 6.0, licensing, global permissions, custom roles, single sign-on, and certificates are replicated throughout the SSO domain and make it easier and more efficient to manage these shared services across multiple vCenter Servers.
Can only be done in vSphere 5.5
This will require an architecture change from embedded to external PSC deployment
Will need to be done prior to the upgrade process
A separate change control and validation are required
The outage will only affect IT management of the environment
Enhanced Linked Mode
Today each site is operating autonomously which means each site is managed separately. This is not efficient for Adam and his team. Their goal is to have visibility to all three sites no matter what vSphere Client they use.
Requires external deployment which will be completed with the vSphere SSO domain consolidation
Automatically inherited when new vCenter Servers are added to the same vSphere SSO domain; no action required
Migrate to the vCenter Server Appliance
The vCenter Server Appliance 6.5 surpasses its Windows counterpart when it comes to features and performance. The VCSA is VMware’s direction for vCenter Server and all new features starting with vSphere 6.5 will only be in the VCSA:
Native vCenter Server High Availability
Built-In File-Based Backup Restore
vSphere Update Manager no longer requires a separate Windows Server
Supported Migration Tool from Windows to VCSA
High Availability
To meet their current 10 minute RTO Adam has decided to leverage both vSphere HA and vCenter Server High Availability (VCHA). This will ensure the company is protected from host and vCenter Server (application) failure.
vSphere HA will protect again host failure
vCenter Server VM restart priority setting to highest
vCenter Server HA requires a load balancer for Platform Services Controller high availability
Load Balancers supported: F5, NetScaler, and NSX
VCHA provides 5 minute RTO
Centralized Logging per Site
Currently, there is no centralized logging within each site. The hosts and vCenter Server are using the default settings and logs are maintained on each individual node. VMware provides a 25-OSI pack with each vCenter Server license for free.
No additional cost for logging solution at each site (budget)
Content Packs available
Dashboard and Analytics of logging data helpful for troubleshooting
Not limited to vSphere products, Windows and Linux agents available
Limited feature set would need to be upgraded to the full version of Log Insight for additional features such as clustering, event forwarding, archiving, etc.
More hands on experience with Log Insight and can upgrade in the future as budget permits
Compatibility
Now that Adam has a set of upgrade requirements, the next step is validating the compatibility of each product. This can be achieved by using the VMware Product Interoperability Matrices which is one of the documents he is now familiar with as part of his upgrade preparation during Phase 1. Since all the products communicate with vCenter Server as an end point, it should be selected in step one, labeled “Select a Solution”. There is the option to list all versions or specify particular version numbers. vCenter Server will now be displayed in the main horizontal header of the table. The next step is to list other solutions that will also be upgraded under the “Add Platform/Solution” section. The example below illustrates both the current version of vCenter Server 5.5 and the version that Adam will be upgrading to 6.5. Each of the products show the version that Adam plans to upgrade to ensure they are compatible with vSphere 6.5. As a result, Adam learns that NSX is the only product which has a requirement of vCenter Server 6.5a (also noted in the release notes), which is the version Adam must download.
Upgrade Order
The final step before performing the upgrade is listing the order of operations. This order is listed in VMware vSphere upgrade documentation and has not changed over time.
vSphere SSO domain consolidation will be the first task that needs to be completed since it is one of Adam’s requirements. Keep in mind this can only be done on vSphere 5.5, once the first node is updated to vSphere 6.5 the ability to consolidate is no longer available. The other item to note is that this may not be a requirement for everyone. If it is not part of your requirements then move forward with the next step of upgrading the vCenter Server components. The following KB provides the details needed to consolidate a vSphere SSO domain in version 5.5. Also, don’t forget to look at the vSphere 6.5 maximums guide to ensure the supported number of Single Sign-On servers in a vSphere SSO domain.
If your deployment is embedded then proceed directly with your vCenter Server upgrade. In this example, there is an external deployment spanning multiple sites. One of the requirements is migrating from a Windows based vCenter Server to the vCenter Server Appliance. A migration also falls under the upgrade category since it is not only copying data (configuration/inventory by default) from one platform to another (Windows to Photon OS) but also going from version 5.5 to 6.5. The first step in an external deployment is upgrading or migrating all the Single Sign-On servers within the vSphere SSO domain first. This will leave the environment in mixed mode since the Single Sign-On Servers version 5.5 have been upgraded to Platform Services Controllers version 6.5 and vCenter Servers are still on version 5.5. The migration process provides an easy rollback plan since the original source machine is not being changed. This also satisfies the requirement of Enhanced Linked Mode (ELM) because ELM was enabled through the domain consolidation procedure performed in Step 1.
Note: If Linked Mode is configured in vSphere 5.5, you will have to break it before starting the migration process.
vCenter Server upgrade or migration is next. Now that the environment is in mixed mode it is important to upgrade or migrate all the vCenter Servers 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.
Note: The image above is related to the current scenario. The migration tool in vSphere 6.5 supports migrations from both vSphere 5.5 or 6.0.
Now that vCenter Server has been migrated to the vCenter Server Appliance 6.5 we can focus on upgrading the other products in the management plane. Referring back to the chart above we can determine that the other solutions currently in the environment (NSX, vRA, vROPS) will need to be upgraded to support vSphere 6.5. This should include any 3rd party products as well.
All ESXi hosts should be upgraded and not left for maximum uptime bragging rights. While vSphere 5.5 ESXi hosts are supported in a vSphere 6.5 environment, they should not be left as such. Upgrading the hosts provides support for the latest server hardware, an increase in scalability, vMotions enhancements, and security improvements. Host upgrades can be completed by using vSphere Update Manager (VUM) either at the cluster or host level. A vSphere Update Manager baseline applied at the cluster level can leverage DRS to automatically move the virtual machines from a host, then place a host in maintenance mode, and automatically start the upgrade process. Once the upgrade of a host has completed, it will exit maintenance mode and move to the next host in the cluster until all hosts are within compliance of the baseline.
Virtual Machines need love too!
Having VMware Tools up to date ensures the performance and management of a virtual machine are enhanced. Although a guest operating system can run without VMware Tools, failure to install or update a VMware Tools can result in poor operating system performance and lack of features.
Next is virtual machine hardware, which reflects the supported virtual machine hardware features. This includes the virtual machine BIOS, the number of supported CPUs and memory, and the other hardware related features for a virtual machine. The virtual machine hardware version can remain at the current version and upgraded if newer hardware capabilities are needed.
We can’t forget about storage! vSphere 6.5 introduces VMFS6 which includes many enhancements over the previous version of VMFS5. VMFS6 now includes automatic space reclamation at the datastore level as well as from the guest operating system. More information about all the VMFS enhancements in vSphere 6.5 can be found here. There are multiple approaches to getting a VMFS datastore to version 6. The first, if space is available, would be to create a new datastore and Storage vMotion the virtual machines from the existing datastore. If space is a constraint, then Storage vMotion all of the virtual machines from an existing datastore then, once empty, upgrade from VMFS5 to VMFS6, and repeat the process until all datastores have been upgraded.
Upgrade vSphere licensing from vSphere 5.x to vSphere 6.x. from the myvmware portal. Apply the new vSphere 6.x licenses to your vCenter Server and then to your ESXi hosts. There will be a 60 day grace period during the upgrade or migration to allow for the license upgrade.
Adam will be deploying vRLI to meet his centralized logging requirement at each site. Then we will configure VCHA to meet his vCenter Server high availability requirement. Any new VMware or 3rd party products or features can be deployed or configured after the entire upgrade has been completed.
Adam was able to satisfy the company’s requirements and upgrade successfully from vSphere version 5.5 to 6.5 because he did his due diligence. Keep in mind this is just an example scenario and may or may not cover your particular environment. Again the important key takeaway is understanding the upgrade process and concepts and applying them to your own environment. Reviewing the release notes for each product and knowing not only upgrading process but also known issues is valuable. Opening an SR with VMware support prior to starting the upgrade process can ensure you’ve validated the process them and if any issues occur this will expedite the support process. Don’t forget to ensure that you have a backup prior to starting the upgrade process and also a recovery plan in case you need to revert back. Making a schedule within the product upgrade chart will also be helpful to determine not only when a product will be upgraded but also how an upgrade of one product like vCenter Server will affect other products. In the next blog post, we will cover another upgrade scenario, this time covering vSphere 6.0 to 6.5.
