By Jonathan McDonald
As a member of VMware Global Technology and Professional Services at VMware I get the privilege of being able to work with products prior to its release. This not only gets me familiar with new changes, but also allows me to question—and figure out—how the new product will change the architecture in a datacenter.
Recently, I have been working on exactly that with vCenter 6.0 because of all the upcoming changes in the new release. One of my favorite things about vSphere 6.0 is the simplification of vCenter and associated services. Previously, each individual major service (vCenter, Single Sign-On, Inventory Service, the vSphere Web Client, Auto Deploy, etc.) was installed individually. This added complexity and uncertainty in determining the best way to architect the environment.
With the release of vSphere 6.0, vCenter Server installation and configuration has been dramatically simplified. The installation of vCenter now consists of only two components that provide all services for the virtual datacenter:
- Platform Services Controller – This provides infrastructure services for the datacenter. The Platform Services Controller contains these services:
- vCenter Single Sign-On
- License Service
- Lookup Service
- VMware Directory Service
- VMware Certificate Authority
- vCenter Services – The vCenter Server group of services provides the remainder of the vCenter Server functionality, which includes:
- vCenter Server
- vSphere Web Client
- vCenter Inventory Service
- vSphere Auto Deploy
- vSphere ESXi Dump Collector
- vSphere Syslog Collector (Microsoft Windows)/VMware Syslog Service (Appliance)
So, when deploying vSphere 6.0 you need to understand the implications of these changes to properly architect the environment, whether it is a fresh installation, or an upgrade. This is a dramatic change from previous releases, and one that is going to be a source of many discussions.
To help prevent confusion, my colleagues in VMware Global Support, VMware Engineering, and I have developed guidance on supported architectures and deployment modes. This two-part blog series will discuss how to properly architect and deploy vCenter 6.0.
vCenter Deployment Modes
There are two basic architectures that can be used when deploying vSphere 6.0:
- vCenter Server with an Embedded Platform Services Controller – This mode installs all services on the same virtual machine or physical server as vCenter Server. The configuration looks like this:
This is ideal for small environments, or if simplicity and reduced resource utilization are key factors for the environment.
- vCenter Server with an External Platform Services Controller – This mode installs the platform services on a system that is separate from where vCenter services are installed. Installing the platform services is a prerequisite for installing vCenter. The configuration looks as follows:
This is ideal for larger environments, where there are multiple vCenter servers, but you want a single pane-of-glass for the site.
Choosing your architecture is critical, because once the model is chosen, it is difficult to change, and configuration limits could inhibit the scalability of the environment.
Enhanced Linked Mode
As a result of these architectural changes, Platform Services Controllers can be linked together. This enables a single pane-of-glass view of any vCenter server that has been configured to use the Platform Services Controller domain. This feature is called Enhanced Linked Mode and is a replacement for Linked Mode, which was a construct that could only be used with vCenter for Windows. The recommended configuration when using Enhanced Linked Mode is to use an external platform services controller.
Note: Although using embedded Platform Services Controllers and enabling Enhanced Linked Mode can technically be done, it is not a recommended configuration. See List of Recommended topologies for vSphere 6.0 (2108548) for further details.
The following are some recommend options on how—and how not to—configure Enhanced Linked Mode.
- Enhanced Linked Mode with an External Platform Services Controller with No High Availability (Recommended)
In this case the Platform Services Controller is configured on a separate virtual machine, and then the vCenter servers are joined to that domain, providing the Enhanced Linked Mode functionality. The configuration would look this way:
There are benefits and drawbacks to this approach. The benefits include:
- Fewer resources consumed by the combined services
- More vCenter instances are allowed
- Single pane-of-glass management of the environment
The drawbacks include:
- Network connectivity loss between vCenter and the Platform Service Controller can cause outages of services
- More Windows licenses are required (if on a Windows Server)
- More virtual machines to manage
- Outage on the Platform Services Controller will cause an outage for all vCenter servers connected to it. High availability is not included in this design.
- Enhanced Linked Mode with an External Platform Services Controller with High Availability (Recommended)
In this case the Platform Services Controllers are configured on separate virtual machines and configured behind a load balancer; this provides high availability to the configuration. The vCenter servers are then joined to that domain using the shared Load Balancer IP address, which provides the Enhanced Linked Mode functionality, but is resilient to failures. This configuration looks like the following:
There are benefits and drawbacks to this approach. The benefits include:
- Fewer resources are consumed by the combined services
- More vCenter instances are allowed
- The Platform Services Controller configuration is highly available
The drawbacks include:
- More Windows licenses are required (if on a Windows Server)
- More virtual machines to manage
- Enhanced Linked Mode with Embedded Platform Services Controllers (Not Recommended)
In this case vCenter is installed as an embedded configuration on the first server. Subsequent installations are configured in embedded mode, but joined to an existing Single Sign-On domain.
Linking embedded Platform Services Controllers is possible, but is not a recommended configuration. It is preferred to have an external configuration for the Platform Services Controller.
The configuration looks like this:
- Combination Deployments (Not Recommended)
In this case there is a combination of embedded and external Platform Services Controller architectures.
Linking an embedded Platform Services Controller and an external Platform Services Controller is possible, but again, this is not a recommended configuration. It is preferred to have an external configuration for the Platform Services Controller.
Here is as an example of one such scenario:
- Enhanced Linked Mode Using Only an Embedded Platform Services Controller (Not Recommended)
In this case there is an embedded Platform Services Controller with vCenter Server linked to an external standalone vCenter Server.
Linking a second vCenter Server to an existing embedded vCenter Server and Platform Services Controller is possible, but this is not a recommended configuration. It is preferred to have an external configuration for the Platform Services Controller.
Here is an example of this scenario:
Stay tuned for Part 2 of this blog post where we will discuss the different platforms for vCenter, high availability and different deployment recommendations.
Jonathan McDonald is a Technical Solutions Architect for the Professional Services Engineering team. He currently specializes in developing architecture designs for core Virtualization, and Software-Defined Storage, as well as providing best practices for upgrading and health checks for vSphere environments.
