In recent times, organisations have become more aware of the need to develop applications that closely align with their core business and that has been taking priority, rather than the platform that used to be the most important factor in the past. Recognising this trend, VMware has been working towards integrating its portfolio products to provide its customers with a platform that can seamlessly host and manage not only the traditional but also modern applications. The main focus of vSphere 7 is the integration of those technologies into a single platform to manage them all.
Modern Hybrid Cloud
For decades, we’ve been managing infrastructure and have become extremely good at it. But in the agile world of development today, developers want instant creation (or destruction for that matter!) of their workloads. Organisations and the IT teams within are learning that art well and rapidly so delivery of such systems is no longer a problem. However, Day-2 operations, audit and lifecycle management of those deployments is where the real challenge lies.
vSphere 7 addresses those challenges by providing a consistent experience to both IT admins and developers when it comes to the creation of workloads, along with management and ongoing operations of them.
It is powered by VMware Cloud Foundation 4 that natively integrates Kubernetes into the platform (via the Tanzu Kubernetes Grid Service) while traditional infrastructure services continue to work as before, with the addition of new container constructs. Traditional APIs have been extended accordingly and developers can continue to utilise the same commands that they’ve been used to in the Kubernetes space.
In addition, there are improvements in the security, authentication and lifecycle management of vSphere too which are summarised below.
So, let’s get into some of the key additions and improvements to vSphere 7.
vCenter Server Profiles
I am sure we’ve all thought at some point that how useful it would be if all the configuration of a vCenter server could be bottled up to be consumed by another instance of it. While there are bits and pieces one can do, rebuild of a vCenter has always been painful due to this missing feature. Well, that capability is there now and better late than never, I’d say!
For now, the export and import is via API but once exported, it can be version-controlled and imported into the same or other vCenter servers as required. That will make the job of an admin a lot easier and will help maintain consistent configuration throughout a VMware estate.
vCenter Server Scalability
With every version, one expects an increase in vCenter Server scalability. vSphere 7 continues that tradition and following are the increases as compared to 6.7.
Note that the big difference between the number of hosts in Linked Mode vCenter servers. Also, while the only change in latency numbers is in vCenter Server to vCenter Server i.e. 150ms as compared to 100ms, that’s a huge improvement and should enable a lot of deployments previously deemed risky or unsupported.
vCenter Server 7 Upgrade
We’ve known for a while that external PSC (Platform Services Controller) is being deprecated. In vCenter Server 7, it is no longer available as an option.
The good thing is that the upgrade process offers the convergence of external PSCs into an embedded one, making the whole process a lot simpler. As you would expect, the vCenter Server Converge tool isn’t available on the ISO any more.
Another notable improvement is the addition of vCenter Server Update Planner which provides native tooling to help with discovery, planning and execution of an upgrade. It can also run “what-if” scenarios for you to inform you if you are expected to see any post-upgrade interoperability issues. The latter is extremely useful in order to provide additional confidence before the actual upgrade is carried out.
As you can see, the checks are quite detailed and come with proposed resolution as well. Once the issues are fixed, it can be rerun until all are cleared.
This feature doesn’t replace your responsibility and wisdom before upgrading your environment but think of it as an additional brain looking at your upgrade compatibility checklist, which is nice.
Organisations typically standardise on their vSphere builds. They’re a mix of vSphere ESXi, some hardware, specific drivers and firmware versions. It is important to keep the hosts with a particular configuration uniform throughout the estate, not just for regular operations but later upgrades and problem resolution too. All this is especially important for service providers who might have thousands of servers running a particular build. A minor change in configuration could result in hours of hair-pulling for the administrator.
Simply put, this is desired state configuration for ESXi. It is even capable of pushing specific versions of firmware to hosts too but initially for specific Dell and HPE models, with compatibility coming for other manufacturers later.
There’s a major change introduced in vSphere 7 when it comes to DRS. Going forward, it will be “workload centric”, as compared to “cluster centric” in the past. That essentially means that DRS is actually going to focus on where the workload should sit for it to be able to run properly, rather than let the cluster run more comfortably. In other words, it is making hosted workload the first-class citizen here.
This is indeed the right approach as at the end of the day, it is the application that is important to the business. Performance requirements for applications vary according to their importance and this policy makes it easier for an admin to set the performance requirements and let vSphere decide where it’s going to get that level of service response. It is also important to mention that DRS won’t just look at performance metrics while making placement or migration decisions; it will also look at headroom for potential bursting activity.
In all, DRS is a lot cleverer about placement in vSphere 7 so I am quite excited to see the impact of this new placement policy on workloads.
Monster VMs have always been difficult to vMotion simply due to their size. Despite major advances in how vMotion transfers the contents of the memory, copying the final pages of memory during switchover has been an issue.
In vSphere, VMware has made major improvements in creating efficiencies that have reduced that time to under a fraction of a second, which eases vMotioning of such large VMs easy and practical.
Another improvement is in additional EVC modes for vMotion which now also include Intel Cascade Lake and AMD Zen2 generation baselines.
Anyone who has been through certificate management for vSphere in the past knows what a pain it can be! That’s why I am extremely excited to see the certificate management improvements in vSphere 7.
There’s a lot less to manage and it’s mostly automated! All the various modes are still supported and recommendation of hybrid is still the same. There are also APIs to manage the certificates that make updating and replacing them easier too.
Authentication is one area that needed a boost and with vSphere 7, VMware is introducing identity federation. For now, it will just integrate with ADFS but with time, support for more providers will become available.
It was a badly needed enhancement given all the major platforms now provide federated access. Nowadays, most enterprises have their identity handled by federated access and vSphere authentication was lacking previously so this is indeed a welcome addition.
There are many enhancements e.g. Trust Authority, Compliance enhancements, VM Hardware upgrades and more that I had to skip. That was due to the length of the post already but more importantly, these are the most important ones that I thought you should pay more attention to. VMware will release a lot more on these topics in coming days so do remember to check out those updates as they come!