Even though vSphere 6.5 has been announced and not released yet Since vSphere and vCenter 6.5 are released now, a customer engagement put me into a position to gather much more information about characteristics and limitations within vCenter 6.5.
In the following I will discuss some of the upcoming and current vCenter characteristics that might not be completely aware (are not well documented) within the field /community.
Thanks VMware @Twitter community for helping me out here. Once again I really benefit from this great network out there.
The goal was to define a logical and physical design for the new vCenter release. Within the project we will have two phases
- phase: vCenter 6.0
- phase: vCenter 6.5
We will give the GA release of vCenter 6.5 a minimum time of 3 months to observe its behaviour and production readiness. Since we might require feature from the vCenter 6.0 release we want to design that is ready for an easy transition from 5.5 over 6.0 to 6.5.
- Windows based vCenter (vCenter 5.5 U2e)
- SQL Server installed on the vCenter Windows
- Simplified management of a multi location environment (suitable feature: vCenter 6.0 enhanced Linked mode)
- CA signed SSL everywhere (suitable feature: vCenter 6.0 PSC Sub-CA)
- Central VM Template Management (suitable feature: vCenter 6.0 Content-Library)
- Highly available vCenter (suitable feature: vCenter 6.5 vCenter HA-Mode)
- Quick recoverable vCenter (suitable feature: vCenter 6.5 integrated backup)
Out of the requirements and constraint (not direct 6.5 migration) the following design decisions might play an important role to define a suitable management solution.
- Migrate to vCenter Server Appliance (vCSA) or remain with Windows based vCenter
- Embedded Plattform Service Controller (PSC) or Distributed PSC
- PSC as Sub-CA that is capable of creating enterprise signed SSL Certificates for VMware components
In the real scenario much more design decisions are playing an important role (for blog post scope limitations I just mentioned a few). Let’s clarify some of the component characteristics to make sure we know about the basic functionality and limitations for the present or during a future transition to a next version (e.g. 6.0 -> 6.5).
Only if you know limitations and exact functionality of features you will be able to create the best solution to meet a customers requirements.
Once we have an overview about those limitations, functionalities and the transition costs to get from a) Version 6.0 to b) Version 6.5 we can plan accordingly and effectively.
vCenter Server Virtual Appliance aka vCSA is the future.
There is no bigger discussion necessary here, since VMware is actively recommending people to use the vCSA if there are no really suiteable reasons to do otherwise. Even though there will still be a Windows based version in 6.5 the day will come where the appliance is the only delivery option for VMware’s management component.
With the release of the vCenter Server Appliance Migration Tool we can now migrate from vCenter 5.5 Windows to vCSA 6.0 in a supported way. Check out the FAQ and make sure to control the supported releases before migrating (Migration from windows 6.0 to vCSA 6.0 won’t work).
With the release of 6.5 we will gain more flexibility from which version we will be able to migrate from.
Make also sure to do upfront vCenter compatibility checks. I recommend to go through my vCenter upgrade article which is still valid nowadays.
The migration includes everything (distributed, switch, ids, hostname, certificates, etc.). No other system will recognize a difference after the migration took place.
From a fallback point of view vCSA upgrade and Windows to Linux migration are pretty useful since always new virtual machines gets deployed, connected to a temporary network and a data transfer takes place. Therefore the original instance remains quiet intact (don’t forget clean-up tasks after a successful migration).
Within vCenter 6.0 you will still need a Windows machine acting as the platform for the update manager. A vCSA integrated update manager will only be part of the version 6.5.
Configuring the PSC as a Subordinate Enterprise Certificate Authority
The biggest challenge when dealing with Certificates in vCenter 6.0 (or newer) is to remain comply with the corporates security policies. Since 6.0 the PSC can be configured as Intermediate CA which is now able to sign enterprise SSL certificates for the vCenter (and it’s solutions) and the ESXi hosts.
The process is quiet straight forward nowadays and pretty well documented by the VMware community, e.g. here.
Until now I don’t know about any improvements here in vCenter 6.5. I know from the field that for many security departments the feature-set of the PSC sub-ca was not ready for THEIR usage.
What happens if you repoint from e.g. an embedded PSC to an distributed PSC (or create multiple PSC)?
How to increase vCenter’s availability and recoverability
The vCenter becomes more and more important in our infrastructure. Virtual Desktop Infrastructures, Automation of workflows and Cloud Services are highly dependant of a running vCenter service. Even though we can protect the vCenter with vSphere HA, we are only covering failure on ESXi Level (hypervisor or hardware). Applications / OS / Filesystem problems can be mitigated only in a limited way.
With vCenter 6.5 two features were introduced to increase the availability and recoverability.
With vCenter 6.5 (vCSA only) we can have a 3 node active-standby-witness construct that protects against OS/Application failures. The HA vCenter will protect all services on this VM (vCenter, WebClients, PSC, Autodeploy, etc.).
The usage of the new Photon OS as the underlying Linux Operating System the boot-time and therefore service recovery time will be reduced a lot. Check out Féidhlim O’Leary brilliant blog post on that topic.
In vCenter 6.0 or earlier the only way to achieve a full consistent backup of the vCenter was to backup the postgresql database with VMware provided scripts on the vCSA shell.
Besides that a crash-consistent backup could be created via the usage of the vSphere API for data protection (Veeam, etc.). Just make sure here that your backup solution allows recovery directly to an ESXi host. There are still candidates out there that only allows the recovery against another vCenter (chicken-egg-problematic).
With vCenter 6.5 we will be able to also dump all vCenter relevant information (vCenter, PSC) to a central file share and recover our vCenter out of this data.
To Enhanced Linked Mode, or not to enhanced linked mode… that is the question.
The good old discussion and most-often the reason if we want to do have a distributed Platform Service Controller setup (2VMs) or an embedded PSC (vCenter and PSC installed on the same operating system).
The biggest limitation here: No enhanced linked mode with an embedded PSC
Other important characteristics:
- Migration from embedded to distributed possible via cmsso-util repoint.
- Migration from distributed to embedded NOT possible.
- vCenter 6.5 high-availability mode not applicable for an external PSC. If you want a high-available vCenter in 6.5 and and a high-available PSC you can use the integrated feature for the vCenter,but still need a load-balancer and multiple PSCs to have an automatic failover in-case of a PSC failure).
- CMSSO-Util repoint within 6.5 is only possible if you remain in the same PSC site.
Enhanced Linked Mode and therefore external PSC increase the complexity of the management environment. So in case you don’t really rely on the enhanced linked mode feature, a simple embedded installation might be suitable (for simplicity reasons). Maybe the limitation of embedded PSC might go away in the future (or we can use the new HA-mode also for an external PSC).
I hope those information help you to find the best decisions within your system design. If you have any further comments or think something is missing. Let me know!