Intro
Upgrading and maintaining a vSphere environment is a broad topic that also can be difficult. As you probably have noticed already in the blogpost series, there are numerous ways of doing a vSphere upgrade, and each has its own benefits, drawbacks but also consequences. That’s why I’m so focused in this blogpost series on how you can define a Roadmap, instead of creating an upgrade tutorial. Tutorials are also great and thanks to other fellow bloggers for those contributions, but they will often not give you that grant overview that will help you to validate certain choices. Deciding which road is best suitable for you, can depend on many factors. In the previous posts we talked about some of the technical challenges that we could face with a vSphere Upgrade. In this post we’re going to discuss the common upgrade challenges customer face that can have impact on the road you choose. This will be divided into 5 topics:
- Dependencies & Compatibility
- New vSphere Features & Changes
- Available Resources
- Downtime & (App) Availability
- Rollback Options
BlogPost Serie Overview:
✓ Phase 1: Kick-off
✓ Phase 2: Assessment
✓ Phase 3: Defining the IST (Current State)
✓ Phase 4: Dependencies & Compatibility
✓ Phase 5.1: Technical vSphere Challenges
⇒ Phase 5.2: Common vSphere Challenges
⚬ Phase 5.3: Solving vSphere Compatibility Challenges with VVD
⚬ Phase 6: Defining the Soll & Roadmap (Future State)
Dependencies & Compatibility
One of the factors that has the most impact on the type of upgrade path you’ll choose is in my opinion dependencies & compatibility. This is because dependencies & compatibility issues can be a real blocking factor for moving forward in your upgrade. If a certain dependency isn’t compatible with a newer version of vSphere or has difficulties to cope with changes in the vSphere environment, chances are that you’ll will have a difficult time to move on or that you maybe get stuck on a certain version or upgrade path. In some cases, this will result that you may choose to migrate towards newer hardware, and therefor do a new vSphere deployment. It can also be that reconfiguring or redeploying one or multiple dependencies is too difficult or time-consuming, that you maybe go for an in-place upgrade.
Spotting dependencies is quite a difficult and time-consuming task as well. Especially if there is not a clear overview of how the organization operates. How daunting this may be, it is still important. It helps to prevent undesired outages or problems and is therefore a big part of the “Assessment” and “Defining the IST” phase. The Template for defining the IST, can help you with this difficult topic. Since this is widely discussed in another blogpost here, I will not go much deeper.
New vSphere Features & Challenges
The previous blogpost discussed most of these important Technical Changes & Challenges. At the time of this writing, the PSC Architecture and its Upgrade Path is one of the factors that can have quite an impact on the path you (need to) choose. Not only the choice if you want to go to embedded or external, but also the vSphere version that you choose, can have an impact on how things need to be deployed or upgraded. Numerous examples have been given in the previous blogpost about these new changes and features, but in overall the PSC is one is the most important aspects to think about. For more information about all the challenges that can define your Upgrade Roadmap, I also refer to a previous blogpost of mine here.
Available Resources
Resources are quite important for your upgrade path. When doing an “in-place upgrade”, we most of the time don’t need much additional resources, except when a new feature or special vSphere changes demands otherwise. However, when going for a “Lift & Shift” migration, chances are that you need to have some additional free resources. Resources that will be able to absorb some of the extra pressure on the environment. This can because of extra virtual machines, or applications that are rebuild or duplicated in the meantime. Maybe quite straightforward, but for some reason this is often overlooked. So definitely check if you have enough resources available for the upgrade to continue.
Downtime & (App) Availability
Downtime & Availability is together with dependencies, also one of the leading factors for customers choosing a certain path for their upgrade. An “in-place upgrade” often doesn’t have that much downtime if there are enough resources available. A migration Path however can have some downtime, depending on the application. It is therefore also important to list up all the applications that make use of the environment and that have some SLA or special Downtime / Availability needs. This is different from listing up dependencies, but it is still important, since it can impact operations if not done with care. If there are applications that cannot have any downtime, chances are that you have to take multiple steps in your upgrade procedure when you have to make a big jump. Just for the simple reason that you can keep operation up-and-running.
Rollback Options
Now you wouldn’t expect this as one of the leading factors for choosing a type of upgrade path. However, in a highly critical and specific type of environment, being able to roll back any time to the exact same setup can have an extreme high priority, which was with one of my customers. For that simple reason, we choose to migrate instead of doing an in-place upgrade. The simple reason for this was, that it is much easier to restore back to the original state of the vSphere environment, when everything is still intact, then when you have to downgrade. The cool thing is, that from version 6.0 when upgrading a vCenter, it will automatically deploy a new vCenter, at least in the vCSA version. This way, it is also easier to restore back to the older vCenter. However, everything below 6.0, still upgrades the vCenter itself, and this is more difficult to undo. You can still of course use back-ups as a Rollback method, but when certain applications are that tightly integrated, a restore of a backup can also sometimes have undesired results. Especially when dependencies are counting on a certain type of version or id.
Update Order & Sequence
Another important topic in creating a Roadmap for vSphere Upgrades, is the order of updating each component & dependency while staying supported & compatible. With dependencies like Hardware, Third Party software, or even VMware its own product portfolio, this can become complex quickly. The Hardware & Third Party Software can be sorted out with the template that is shared here. However, the update Sequence & Compatibility between different products of the VMware Portfolio can maybe become a bit easier, with VMware Validated Designs. Which we will talk about in the next blogpost.
See you there.
Samir is the author of vSAM.Pro & a Life enthusiast who works as a consultant in the field of IT. With a great passion for Tech & Personal Development, he loves to help people with their problems, but also inspire them with a positive outlook on life.
Besides that, he is also a big Sport & Music junky that loves to spend a big chunk of his time on producing music or physically stretching himself.
