Post by vExpert Vladan Seget
Expanding your virtual environment doesn’t always mean growing it in size with more VMs and more hosts. Expansion can also mean upgrading your environment from a previous release – a common fear for many users. This may be a fear of the unknown – the fear that something will break during the upgrade process and leave you with nothing, or the fear of having to adjust to a new environment. Many users (including myself) will choose to stay on an old environment until there is a hardware refresh cycle planned, because it’s often easier to plan the installation of a new environment instead of upgrading old hardware.
When a major upgrade of your virtual environment has been released, usually there are many questions you need to consider. I usually check compatibility with my existing environment and research whether other bloggers or the larger VMware vSphere community have reported any issues with the upgrade.
I also do a few installs and simulate the upgrade on non-production servers, just to see how it goes. If the upgrade involves a much older previous release (like vSphere 4.0 or 4.1), then usually the best approach is to do a fresh install on new hardware (as the old one won’t get much support from the vendor either).
It’s not simple, and sometimes the decision on which is the right approach can be hard to determine. If you’re thinking about upgrading your virtual environment, proper planning and thinking ahead is crucial. Below, I weigh the advantages and disadvantages to upgrading your environment through a fresh install (then moving workloads there) or through an existing environment (in-place upgrade of an existing virtual environment).
Two Ways to Upgrade
- Fresh Install – Installation on new hardware
- Upgrade existing environment – upgrade of existing virtual infrastructure on the same hardware
Fresh Install on New Hardware:
- Nice and clean – With a fresh installation (vCenter server, ESXi hosts), you can enjoy a clean environment, without potential misconfigurations from the old environment.
- Proper testing – With a fresh install, you have time to test if everything works and stress the environment with test VMs.
- It takes more time – As with all things, it takes time to create something from scratch vs. refreshing something that already exists as a framework.
- New hardware needs new configurations – New networking, new storage, and you also need to activate any functions you have licensed for (vMotion, HA, FT, sVMotion…)
- You need enough hardware – Usually when upgrading from very old infrastructure, this isn’t as much a problem, as there is usually a hardware refresh planned.
- New version of your current backup product – New major releases usually bring features that need a backup product to be upgraded first.
vCenter upgrade paths illustration photo (source: VMware blog) where different versions of vCenter servers are as a starting point.
Upgrade Existing Environment on the Same Hardware
Before you hit the upgrade button, you should think twice. Imagine that you migrated to very new environment, but your backup vendor can’t assure backup protection for now because the environment isn’t supported yet. Hey, you should have thought about it earlier, no?
One of your first considerations when upgrading should be your backups and restoration – you’ll need to think of every single scenario for backup/restoration or replication.
- You keep the same configurations – vCenter is the main piece in the puzzle. It’s on top of the pyramid. By keeping the existing network configuration for vCenter, you can save yourself hours of reconfiguring all the services which rely on vCenter (backup/replication, monitoring products…). Nothing changes on your ESXi hosts.
- No need for new hardware – It’s a software refresh, which means it can be faster to upgrade. If the hardware isn’t too old, it’s the way to go. Taking precautions, backing up configurations, etc, can mitigate the risk of something going wrong.
- In the event your existing hardware isn’t supported – If your hardware isn’t on the HCL (VMware hardware compatibility list), whether your upgrade will be successful or not is uncertain, due to unsupported NICs, Chipsets, etc..
- Lack of product support could require you to wait to upgrade - Sometimes it can take 6 months or more for your backup product to be supported on a new platform, which can lead to upgrade delays.
- The in-place upgrade of vCenter and ESX hosts – You’ll have to prepare a plan B for each scenario. You should be able to revert back in case something goes wrong. If the host upgrade triggers PSOD or blue screen, are you sure you can revert back? Unreachable vCenter – how will you revert back? For vCenter server VM, it’s necessary to plan a full backup before the upgrade. For ESXi upgrade, you can just backup the configuration through the CLI (command line interface).
Additional Questions Concerning Existing Backup/Replication Solutions:
Existing backup/replication solutions must be certified by the vendor on the new vSphere release before upgrading. A few of the questions that might arise:
Do you plan on having all of your VMs backed up by your existing backup solution? If not, then you’ll need to look for an update/replacement.
How about replication? If you have a remote site where you replicate with a certain product and it’s part of your DR plan, can you confirm that your existing solution is supported in the new vSphere release? This is important to know!
Will you be able to restore a file from few years back with new backup solution? Yes some files/e-mails shall be kept for archiving for legal purposes and for this the backup solutions are configured with Grandfather – Father – Son (GFS) backup scheme to keep older files for archiving purposes.
Grandfather-father-son backup refers to a common rotation scheme for backup media. In this scheme there are three or more backup cycles, such as daily, weekly and monthly. The daily backups are rotated on a daily basis using a First-in first-out (FIFO) system.. The weekly backups are similarly rotated on a weekly basis, and the monthly backup on a monthly basis. In addition, quarterly, half-yearly, and/or annual backups could also be separately retained. Additional off-site protection can be used and some of these backups are removed from the site for safekeeping and disaster recovery purposes.
Will you be able to restore if something goes wrong with the upgrade process? Imagine that after you upgrade your vCenter VM, you can’t connect back to vCenter. This might mean you don’t have access to the backup server (it’s a VM). Sure, you can probably connect to a single host, register the backup server VM there and launch a restore of the vCenter VM, but make sure that this is a supported scenario! Check with your backup vendor first.
Mixed Upgrade Approach – The Best of Both Worlds
Let’s consider a mixed approach where you use newly installed infrastructure managed by a new vCenter server for test VMs or for VMs that are “not-so-important.” You could test the performance, reliability, backup/replication, and at the same time, the older vSphere release would continue to function as before. So basically you’ll keep both environments – old hardware with older vSphere version and new hardware installed with latest release.
- Security – You know the new vSphere release works well on this new hardware (it’s on the HCL). The existing environment running on old hardware has proven to be resilient and reliable. No need to change it. Then you can start migrating the workloads with test and dev VMs.
- No Service Disruption: The transition phase can take a few months/years, but no need to rush, as the test VMs don’t need a proper backup solution yet, and in a few months, your backup vendor will release an upgrade of the backup product you’re using.
- No Downtime: The existing environment that hosts business critical applications can maintain its specific configuration/requirements and stay backed up with your current backup solution (and might stay this way until the end of the software support).
- More complexity – Adding another environment to your organization means another layer of complexity and “another single pane of glass”. But if the new environment is considered as a test and dev environment first, then it can turn into an advantage for you and your IT team, especially if your existing environment is running out of capacity. You can use the new environment for test and dev purposes first, then later to move production workloads there.
So this mixed approach in my opinion is the best and most secure, but adds an additional complexity to the environment.
Shared Storage Considerations
Upgrades and major version changes also means changes to your storage architecture. Shifting to a new storage platform like VMware Virtual SAN can directly influence your decision to take the mixed approach. You’ll most likely keep the old infrastructure hooked to your existing SAN and build a new environment based on VMware Virtual SAN.
By upgrading your existing vCenter server, you can also build a new cluster based on VMware Virtual SAN and keep your existing cluster as is with current ESX hosts – a single environment with two different clusters.
The upgrade process of any virtual infrastructure (even a very small one) is a complex process and needs to be considered carefully. Define your business priorities like uptime, security and application performance at the outset. Planning ahead can make all the difference between a successful or failed upgrade. .
Before you upgrade your system, visit the VMware Education page for vSphere 6 training and certification.