Keep Calm and Don’t Panic – vSphere 5.5 End of General Support

VMware vSphere® 5.5 came to End of General Support on 19th September 2018. For those super, well-organised and forward-thinking kind of companies, you may have already completed your vSphere 5.5 eradication, upgrade or migration project. However, if you haven’t started for whatever reason be it bandwidth, time, budget, or inclination, there is no need to panic just yet. This article provides information to help you on your way with making an upgrade decision and creating a plan of action.

What does End of General Support (EoGS) actually mean?

As you’ve no doubt worked out your environment did not suddenly stop working on 20th September 2018 just because vSphere 5.5 moved out of General Support. It does mean however, that VMware® will no longer be providing maintenance updates and upgrades, bug and security fixes or technical assistance for this version of vSphere. In terms of VMware’s Support Lifecycle, on 19th September 2018, vSphere 5.5 entered what is known as VMware’s Technical Guidance phase which lasts until 19th September 2020 when all support will stop. During this Technical Guidance phase, you can still access existing patches and fixes, but no new ones will be released. The features available during each of the lifecycle phases are shown in Table 1 and more information can be found at https://www.vmware.com/support/policies/ lifecycle.html.

Resource

Deployment

Lifecycle

Configuration

Maintenance and upgrades

X

New Security Patches

X

New Bug Fixes

X

New Hardware support

X

Server, Client and Guest OS Updates

X

File a support request

Phone and Web

Web only

Existing security patches

X

X

Existing Bug Fixes

X

X

Workarounds for low security issues (severity 2, 3 and 4)

X

X

Self-help web-based support

X

X

Access to knowledge base

X

X

X

For customers who are still facing an uphill challenge to upgrade their potentially large and complex legacy vSphere 5.5 environment, all is not lost as it is possible to purchase an Extended Support contract with VMware (but only if the existing support and subscription contract is still active). The Extended Support contract can be purchased in one-year increments for a maximum of two years. However, be aware that this can be VERY expensive so should be one of the last options a customer should consider. Keep Calm and Don’t Panic – vSphere 5.5 End of General Support by Christopher Lewis 1 1 3 2 2 Upgrade is the term used when talking about moving from one version of something to another, without deploying a new environment. Migration is the term to describe the movement of workloads from one environment to another environment, either on-premises or in the cloud.

Should I Upgrade or Migrate?

What is the difference between upgrading and migrating? In the context of this article, upgrade is the term used when talking about moving from one version of vSphere to another, without deploying a new (greenfield) environment. This includes the deployment of a new vCenter Server onto existing infrastructure to enable an in-place upgrade of the vSphere environment. Migrate is used as a term to describe the movement of workloads from the legacy vSphere 5.5 environment to another environment, either on-premises or in the cloud.

Upgrade – is the term used when talking about moving from one version of something to another, without deploying a new environment.

Migration – is the term to describe the movement of workloads from one environment to another environment, either on-premises or in the cloud.

“Companies often under estimate the complexity of a vSphere upgrade, especially with all the interwoven dependencies”

Upgrading to a minor version (i.e. vSphere 6.0 to vSphere 6.5) can be very straightforward because the base architecture is unlikely to change significantly, however, upgrading to a major release (i.e. vSphere 5.5 to vSphere 6.x) can be extremely complicated. Quite often companies underestimate the complexity of a vSphere upgrade, especially with all the interwoven dependencies, so this may be the perfect time to re-evaluate the existing architecture, review the new features and enhancements available, and decide whether the existing architecture still meets the business needs. In the context of a vSphere 5.5 deployment, a decision to review and rearchitect a new vSphere solution will more than likely lend itself to a workload migration scenario.

What are the options?

So now we understand the difference between upgrade and migrate, the next question is “what are my options?” If you are currently running a vSphere 5.5 environment the main options to be considered are:

There is, of course, a combination of the options that enables the creation of a hybrid cloud environment, where the on premises infrastructure is upgraded to vSphere 6.x and applicable workloads/applications are migrated to one or more public cloud services.

Option 1 – Do Nothing

The “Do Nothing” approach indicates that you are not planning to do anything about upgrading your vSphere 5.5 environment. This approach is not ideal or advised, however it should be acknowledged that, depending on what service(s) or application(s) the vSphere 5.5 environment is hosting, it can be a valid approach to take. For example, some organisations may be of the view that if the environment is hosting a business application or service that was due to be decommissioned before September 2018, then why waste resource and money on planning and completing an upgrade? In this case the money and effort could be better spent on ensuring the replacement service is ready. Now, if the decommissioning of the application or service is already delayed, then there is obviously a risk that the vSphere 5.5 environment may be needed longer. This then becomes a discussion about the cost of Extended Support vs an upgrade project (or, indeed, a migration to a cloud service such as VMware Cloud on AWS) for the rest of the lifetime of the service. Whatever the reason for taking the “Do Nothing” approach, the management and business needs to understand and accept the risk that is associated with this decision. If the risk is unacceptable then it is important to quickly identify what “do something” should look like.

Option 2 – Upgrade to vSphere 6.0

Upgrading a vSphere 5.5 environment to vSphere 6.0, when vSphere 6.5 is already out, may seem sub-optimal. However, with vSphere 6.0, VMware made some significant (and positive) architectural changes to the vCenter management platform that may impede the ability to move directly to vSphere 6.5. In vSphere 6.0, whilst still supported, there is a significant shift away from the Windows and SQL-based vCenter Server towards an appliance-based model called the VMware vCenter® Server Appliance (VCSA). The Single-Sign On server has been re-designed from the ground up and replaced with the Platform Services Controller (PSC), which now also runs multiple new services as well as services that were once run on the vCenter Server.

“Upgrading to vSphere 6.0 is the right (and potentially only) decision if there are external dependencies that are not supported in vSphere 6.5 ”

So, why would a customer want to invest time, money and effort upgrading from vSphere 5.5 to vSphere 6.0 rather than upgrading directly to vSphere 6.5?

External Dependencies – A solution may be running software external to vSphere that interfaces with vSphere (or vCenter) that is running a version that isn’t supported in vSphere 6.5. Consider this scenario as an example, VMware Horizon® View™ 6 (EoGS 19th June 2019) is supported with vSphere 5.5 and vSphere 6.0 but not vSphere 6.5. Therefore, an upgrade to VMware Horizon View 7 (which is supported from vSphere 5.5) would need to be completed before moving to vSphere 6.5. However, it is not just VMware products that need to be considered, there may be numerous downstream dependencies that need reviewing such as backup software. These dependencies may need to be completed prior to, or at least as part of, the same upgrade project.

Hardware Support – Shockingly, the hardware originally deployed for vSphere 5.5 may not actually be supported with vSphere 6.5 because, like software vendors, hardware vendors stop supporting “legacy” systems too. The best place to check the compatibility of existing hardware is on the VMware Hardware Compatibility Guide https://www. vmware.com/resources/compatibility/

Strategic Planning – A company may have other vSphere 6.0 environments that are managed, and it may be beneficial to standardise on a consistent platform (or even consolidate management tools) before starting a strategic upgrade project to vSphere 6.5 across all environments. Note: You will need to be running the latest vSphere 5.5 patch level (U3) before attempting to migrate to vSphere 6.x. Upgrading to vSphere 6.0 is the right (and potentially only) decision if there are external dependencies that are not supported in vSphere 6.5. This is also the case if there is not enough time left to upgrade those dependencies and (in the case where the “do nothing” approach isn’t acceptable by the business) to ensure the environment will continue to be supported by VMware. When upgrading to vSphere 6.0, it is important to understand this should be considered as a short term tactical fix rather than strategic direction, as vSphere 6.0 goes EoGS on 3rd December 2020!

Option 3 – Upgrade to vSphere 6.5

In low complexity environments where existing hardware is both supported and suitable, all of the external dependencies are met and the existing vSphere 5.5 topology is supported, an upgrade to vSphere 6.5 would (likely) be the best approach and provide the quickest route to realising business benefits.

“In low complexity environments, an upgrade to vSphere 6.5 would provide the quickest route to realising business benefits’ ”

Whilst using a Windows-based vSphere management platform is no longer the recommended topology, an upgrade can be performed to move from vCenter 5.5 U3 to vCenter 6.5 (assuming the underlying operating system is a minimum of Microsoft Windows Server 2008 R2). In addition, in line with vSphere 6.0, the vSphere 5.5 SSO server is upgraded to become a Platform Services Controller which will either be embedded within the vCenter Server or remain a dedicated server. For customers who want to lessen their reliance on both Microsoft Windows Server and Microsoft SQL Server, and move towards the VMware vCenter Server Appliance (VCSA) (with embedded vPostgres), the Migrate-to-VCSA wizard can be used to upgrade whilst retaining all configuration and monitoring data.

Building on the foundations of vSphere 6.0, when deploying the VCSA, the reliance on multiple external SQL Servers and Windows based Virtual Machines has been completely removed as VMware Upgrade Manager (VUM) is now fully integrated. In addition, as well as security enhancements (such as VM Encryption and Secure Boot), vSphere 6.5 introduces vCenter High Availability (VCHA), which enables the vSphere Management software to have increased availability.

However, the upgrade of an environment from vSphere 5.5 to vSphere 6.5 should only be considered in the simplest of deployments or once a full environment analysis has been undertaken to assess the relative complexity. This has nothing to do with the difficulty of the actual upgrade task and everything to do with the fact that the environment (which could be anything up to 5 years old) may no longer be fit for the purpose it was originally designed for.

Option 4 – Migrate to vSphere 6.5

In large and more complex vSphere 5.5 environments (and especially where an environment requires a hardware refresh) it may be beneficial to re-architect and build a new vSphere 6.5 hosting platform and migrate the virtual machines to it.

The benefits of this approach include:

Smaller risk, lower impact – Designing and building a new VMware SDDC means that you minimise (if not remove) the impact to running services and applications within the existing vSphere 5.5 environment whilst the environment is being built.

Better performance at lower DC footprint – the vSphere 5.5 environment is more than likely running “legacy” hardware which means you could save money and increase performance by replacing the hardware with a hyperconverged infrastructure.

Reduce hosting cost – the legacy physical servers are more than likely consuming (rather inefficiently) lots of kW per hour, which all adds to the cost of running the services, especially in a co-location scenario.

Consideration for new options – rather than running often expensive, dedicated and complicated SAN storage and network infrastructure, consideration could be given to using software defined storage and network solutions such as VMware vSAN™ and VMware NSX®.

Even in low complexity environments, when a company wants to remain both on-premises and stay with VMware vSphere SDDC, this is by far the best option. On top of the benefits highlighted, this is because you have a solution reference point that can be used to inform the design and delivery of a new solution. Having run the environment for 5+ years, all of the underlying issues should have surfaced and, if they still exist, they can (and should) be addressed and minimised with the new solution.

Option 5 – Migrate to a VMware Cloud Verified Service Provider or VMware Cloud on AWS

At a high level, a VMware Cloud Verified Service Provider (CVSP) is a company that provides VMware-based cloud services that are consumed on a pay-as-you-go, pay-as-you-grow, or monthly subscription basis. VMware Cloud on AWS (VMConAWS) is a Cloud Service that has been jointly architected by VMware and AWS to provide a scalable and secure VMware SDDC located within the AWS Global Infrastructure.

One of the benefits of hosting with a CVSP or VMConAWS is that they provide VMware vSphere-based Infrastructureas-a-Service (IaaS) hosting. Therefore, the VMware SDDC can be recreated within the hosting environment and vSphere Virtual Machines can be migrated or moved ‘as is’ (assuming they are at a supported hardware virtualisation level). Not only does this allow a company to reduce their hosting datacentre footprint (and cost), they can take advantage of all the benefits of cloud such as, scalability, flexibility and agility. However, because the hosting solution is vSphere-based, there is minimal amount of additional training required for the teams to support the new solution. In VMware terms, this is delivering consistent infrastructure with consistent operations across multiple clouds.

“One of the benefits of hosting with a CVSP is that they provide VMware vSphere-based Infrastructure-as-a-Service (IaaS) hosting”

If the plan is to migrate the legacy vSphere 5.5 workloads to the cloud, rather than keep them on-premises, the best choice (i.e. least work for most gain) would be to use either VMConAWS or a CVSP. There are, of course, other cloud services that provide IaaS hosting, and consideration should be given to the relative merits of each before making a hosting decision.

Option 6 – Migrate to another Hypervisor

As discussed earlier, the situation where you are forced to upgrade a vSphere 5.5 environment to stay within support is, potentially, the right time to reflect on your organisation’s current solution architecture. That reflection could also include deciding if VMware vSphere is still the right on-premises hosting platform. Whilst VMware vSphere remains the market leader, the evolution of the SDDC has continued at pace since vSphere 5.5 was released and now there are numerous other options available to host on-premises. These include Microsoft Hyper-V™, Citrix® Hypervisor and OpenStack.

However, the argument to move away from an existing hypervisor (whether that be vSphere or any other) to a different hypervisor would need to be extremely well presented. After all, it would not be just a technology or architectural change, it would potentially initiate a holistic change program, with the need for resource up-skilling and numerous reviews of the external systems that interact or are dependent on the platform. Whilst this would be considered a highly complex and highly impacting change, it is possible and shouldn’t be completely discounted.

Option 7 – Migrate to the Public Cloud

In this context, as we have already covered IaaS hosting, we’re not only talking about migrating VMs as-is to the public cloud but transforming the way in which the application or services are architected, in order to run within the Public Cloud (such as AWS or Azure), using their native functionality. Now, migrating from applications or services that are residing on virtual machines, and hosted on a legacy vSphere 5.5 environment to the Public Cloud may seem like a quantum leap and that’s because it is, however, that doesn’t mean it is not possible.

“Migrating from applications or services residing on virtual machines to the public cloud may seem like a quantum leap – that’s because it is”

A last resort?

One final option, perhaps as a last resort, is migrating applications away from a virtual environment and back onto dedicated physical servers. Whilst, in principle, this is an option, if application(s) and service(s) have been successfully hosted virtually for up to the last 5+ years, there should be no need to take a step backward and move to physical hosting.

Final Thoughts

If you’ve read this article and are wondering “how do I even begin to work out what to do”, the most important thing to do is not panic. The world as you know it has continued after 19th September 2018 and so has your vSphere 5.5 environment. This article has hopefully helped you to assess your upgrade choices (if you haven’t already) and what to be considering for your plan of action.

Overall, moving from vSphere 5.5 to vSphere 6.5 is the easy decision, the complexity comes in whether this is a migration or an upgrade. It’s not often you see enterprise-scale organisations move wholeheartedly from an on premises infrastructure, to solely use cloud services, however hybrid cloud solutions are becoming more and more popular especially with specific functions moving to the cloud (such as development/test and cyclic capacity increases). Therefore, hosting some or all of the virtual machines with a CVSP or in VMConAWS, may provide the first step to moving to the cloud, but with less risk than adopting native cloud services. Choosing a cloud provider without a vSphere-based hosting solution will just add unnecessary complexity, and invariably, complexity adds cost, time and effort. In this context, migrating to another hypervisor when you have support and capability in your existing software stack, whilst valid, also adds additional, and unnecessary, complexity. The thing to remember is when you have a “deadline”, the last thing you need is unnecessary complexity.

Xtravirt is a leading VMware solution advisor and integrator. If you are considering a move from vSphere 5.5 but not sure where to get started or just want some further information around your upgrade options, contact us and we’ll be happy to use our wealth of knowledge and experience to assist you.