vSphere Datacenter Design – vCenter Architecture Changes in vSphere 6.0 – Part 2

Again, this is a repost from the VMware Consulting Blog Article I wrote on this topic.  It is located:

http://blogs.vmware.com/consulting/2015/03/vsphere-datacenter-design-vcenter-architecture-changes-vsphere-6-0-part-2.html

-----

In part 1 the different deployment modes for vCenter and Enhanced Linked Mode were discussed. In part 2 we finish this discussion by addressing different platforms, high availability and recommended deployment configurations for vCenter.

Mixed Platforms

Prior to vSphere 6.0, there was no interoperability between vCenter for Windows and the vCenter Server Linux Appliance. After a platform was chosen, a full reinstall would be required to change to the other platform. The vCenter Appliance was also limited in features and functionality. 

With vSphere 6.0, they are functionally the same, and all features are available in either deployment mode. With Enhanced Linked Mode both versions of vCenter are interchangeable. This allows you to mix vCenter for Windows and vCenter Server Appliance configurations. 

The following is an example of a mixed platform environment:

This mixed platform environment provides flexibility that has never been possible with the vCenter Platform.

As with any environment, the way it is configured is based on the size of the environment (including expected growth) and the need for high availability. These factors will generally dictate the best configuration for the Platform Services Controller (PSC).

High Availability

Providing high availability protection to the Platform Services Controller adds an additional level of overhead to the configuration. When using an embedded Platform Services Controller, protection is provided in the same way that vCenter is protected, as it is all a part of the same system. 

Availability of vCenter is critical due to the number of solutions requiring continuous connectivity, as well as to ensure the environment can be managed at all times. Whether it is a standalone vCenter Server, or embedded with the Platform Services Controller, it should run in a highly available configuration to avoid extended periods of downtime. 

Several methods can be used to provide higher availability for the vCenter Server system. The decision depends on whether maximum downtime can be tolerated, failover automation is required, and if budget is available for software components.

The following table lists methods available for protecting the vCenter Server system and the vCenter Server Appliance when running in embedded mode.

Redundancy Method	Protects vCenter Server system?	Protects vCenter Server Appliance?
Automated protection using vSphere HA	Yes	Yes
Manual configuration and manual failover, for example, using a cold standby.	Yes	Yes
Automated protection using Microsoft Clustering Services (MSCS)	Yes	No

If high availability is required for an external Platform Services Controller, protection is provided by adding a secondary backup Platform Services Controller, and placing them both behind a load balancer.

VMware supports only the following Load Balancers for this configuration:

• VMware NSX
• NetScaler
• F5 Networks

Here is an example of this configuration using a primary and a backup node.

With vCenter 6.0, connectivity to the Platform Services Controller is stateful, and the load balancer is only used for its failover ability. So active-active connectivity is not recommended for both nodes at the same time, or you risk corruption of the data between nodes. 

Note: Although it is possible to have more than one backup node, it is normally a waste of resources and adds a level of complexity to the configuration for little gain. Unless there is an expectation that more than a single node could fail at the same time, there is very little benefit to configuring a tertiary backup node.

Scalability Limitations

Prior to deciding the configuration for vCenter, the following are the scalability limitations for the different configurations. These can have an impact on the end design.

Scalability Maximum
Number of Platform Services Controllers per domain	8
Maximum PSCs per vSphere Site, behind a single load balancer	4
Maximum objects within a vSphere domain (Users, groups, solution users)	1,000,000
Maximum number of VMware solutions connected to a single PSC	4
Maximum number of VMware products/solutions per vSphere domain	10

Deployment Recommendations

Now that you understand the basic configuration details for vCenter and the Platform Services Controller, you can put it all together in an architecture design. The choice of a deployment architecture can be a complex task depending on the size of the environment.

The following are some recommendations for deployment. But please note that VMware recommends virtualizing all the vCenter components because you gain the benefits of vSphere features such as VMware HA. These recommendations are provided for virtualized systems; physical systems need to be protected appropriately.

• For sites that will not use Enhanced Linked Mode, use an embedded Platform Services Controller.
• This provides simplicity in the environment, including a single pane-of-glass view of all servers while at the same time reducing the administrative overhead of configuring the environment for availability. 
• High availability is provided by VMware HA. The failure domain is limited to a single vCenter Server, as there is no dependency on external component connectivity to the Platform Services Controller. 
• For sites that will use Enhanced Linked Mode use external Platform Service Controllers.
• This configuration uses external Platform Services controllers and load balancers (recommended for high availability). The number of controllers depends on the size of the environment:
• If there are two to four VMware solutions – You will only need a single Platform Services Controller if the configuration is not designed for high availability; two Platform Services Controllers will be required for high availability behind a single load balancer. 
• If there are four to eight VMware solutions – Two Platform Services Controllers must be linked together if the configuration is not designed for high availability; four will be required for a high-availability configuration behind two load balancers (two behind each load balancer). 
• If there are eight to ten VMware solutions – Three Platform Services Controllers should be linked together for a high-availability configuration; and six will be required for high availability configured behind three load balancers (two behind each load balancer). 
• High availability is provided by having multiple Platform Services Controllers and a load balancer to provide failure protection. In addition to this, all components are still protected by VMware HA. This will limit the failure implications of having a single Platform Services Controller, assuming they are running on different ESXi hosts.

With these deployment recommendations hopefully the process of choosing a design for vCenter and the Platform Services Controller will be dramatically simplified. 

This concludes this blog series. I hope this information has been useful and that it demystifies the new vCenter architecture.

vSphere Datacenter Design – vCenter Architecture Changes in vSphere 6.0 – Part 1

Reposting my latest Blog entry from the VMware Consulting Blog:

http://blogs.vmware.com/consulting/2015/03/vsphere-datacenter-design-vcenter-architecture-changes-vsphere-6-0-part-1.html 

------------

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 release. This not only gets me familiar with the changes but allows for me to be able to question and figure out how the architecture will change in a datacenter.

I have recently been working on doing exactly this with vCenter 6.0 because of all the changes which are coming as a part of the release. One of my favorite things about vSphere 6.0, is actually 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 as its own entity.  This added complexity and uncertainty to what the best way to architect the environment. 

As of vSphere 6.0, vCenter Server installation and configuration has been dramatically simplified. The installation of vCenter now consists of only two components which provide all services for the virtual datacenter. The two components are as follows: 

·         Platform Services Controller – provides infrastructure services for the datacenter.  The Platform Services Controller contains the following services:

o    vCenter Single Sign-On

o    License Service

o    Lookup Service

o    VMware Directory Service

o    VMware Certificate Authority

·         vCenter Services – The vCenter Server group of services provides the remainder of the vCenter Server functionality.  It includes the following services:

o    vCenter Server

o    vSphere Web Client

o    vCenter Inventory Service

o    vSphere Auto Deploy

o    vSphere ESXi Dump Collector

o    vSphere Syslog Collector (Windows) / VMware Syslog Service (Appliance)

When deploying vSphere 6.0 you therefore have to understand the implications of this change to properly architect the environment, whether that be a fresh installation or an upgrade. This is actually a dramatic change from previous releases, and one that is going to be sure a source of many discussions. 

To help prevent confusion, along with my colleagues from VMware Global Support and VMware Engineering, we 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 which can be used when deploying vSphere 6.0.  The deployment modes are as follows:

• vCenter Server with an Embedded Platform Services Controller – This mode installs all services on the same virtual machine or physical server as vCenter Server.  This is ideal for small environments, or if simplicity and reduced resource utilization are key factors for the environment. The configuration looks as follows:  

• vCenter Server with an External Platform Services Controller – This mode installs the platform services on a separate system to vCenter services.  The platform services must be installed first as it is a prerequisite for vCenter to be installed. This is ideal for larger environments, where there is a need for single pane of glass in the environment and there are multiple vCenter Servers in the same site. The configuration looks as follows:

Choosing an architecture to be used is critical as once the model is chosen, it is difficult to change and configuration limits could limit 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 which 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 which 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 the recommended and not recommended options for Enhanced Linked Mode configurations:

•  Enhanced Linked Mode with an External Platform Services Controller with No HA (Recommended)

In this case the Platform Services Controller is configured on a separate virtual machine and then the vCenter Servers are then joined to that domain, providing the Enhanced Linked mode functionality. The configuration looks like the following:

There are benefits and drawbacks to this approach.  The benefits include:

·         Less resources consumed by the combined services.

·         More vCenter instances are allowed.

·         Single-Pane of glass management of the environment

The drawbacks include the following:

·         Network connectivity loss between vCenter and the Platform Service Controller can cause outages of the services

·         More Windows licenses 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.  High availability not included in this design

·         Enhanced Linked Mode with an External Platform Services Controller with HA (Recommended)

In this case the Platform Services Controllers are configured on separate virtual machines and configured behind a load balancer to provide 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. The configuration looks like the following:

There are benefits and drawbacks to this approach.  The benefits include:

·         Less resources consumed by the combined services.

·         More vCenter instances are allowed.

·         Platform Services Controller configuration Highly Available

The drawbacks include the following:

·         More Windows licenses 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 win an embedded configuration on the first server.  Subsequent installations are then configured in embedded mode but joined to an existing Single Sign-On domain.

Linking embedded platform services controllers is possible but it is not a recommended configuration.  It is preferred to have an external configuration for the platform services controller. 

The configuration looks like the following:

·         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 it is not a recommended configuration.  It is preferred to have an external configuration for the platform services controller. 

As an example, the following depicts 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 and vCenter Server linked with an external standalone vCenter Server.

Linking a second vCenter Server to an existing embedded vCenter Server and platform services controller is possible but it is not a recommended configuration.  It is preferred to have an external configuration for the platform services controller. 

As an example, the following depicts one such scenario:

Part 2 of this blog post will discuss the different platforms for vCenter, High Availability and different deployment recommendations. 

vSphere 6.0 - Released Today!

For some time now it has been anticipated, but today is the day!  As of this morning vSphere 6.0 is Generally available.  I am not going to lie, it has been a difficult task trying to keep quiet on some of the amazing new features.  I think that some of my personal top 10 are fixed in it as well....which some of them have been a long time coming, but will serve to make the vSphere suite even better.

The following are some of the best updates included in the release:

Compute 

• Increased Scalability – Increased configuration maximums: Virtual machines support up to 128 virtual CPUs (vCPUs) and 4TB virtual RAM (vRAM). Hosts support up to 480 CPU and 12TB of RAM, 2,048 virtual machines per host, and 64 nodes per cluster. 
• Expanded Support – Expanded support for the latest x86 chip sets, devices, drivers, and guest operating systems. 
• Amazing Graphics – NVIDIA GRID™ vGPU™ delivers the full benefits of NVIDIA hardware-accelerated graphics to virtualized solutions. 
• Instant Clone – Technology, built in vSphere 6.0, that lays that foundation to rapidly clone and deploy virtual machines, as much as 10x faster than what is currently possible today.

Storage

• vSphere Virtual Volumes -  enables your external storage arrays to become VM-aware. Storage Policy-Based Management (SPBM) allows common management across storage tiers and dynamic storage class of service automation. Together they enable exact combinations of data services (such as clones and snapshots) to be instantiated more efficiently on a per VM basis. 
• Virtual SAN 6.0 - Improvements to Virtual SAN system which allow for greater scalability of the environment, including all Flash Support, JBOD Support, 64 Host clusters and the ability to set failure domains

Network

• Network IO Control – New support for per-VM Distributed vSwitch bandwidth reservations to guarantee isolation and enforce limits on bandwidth. 
• Multicast Snooping - Supports IGMP snooping for IPv4 packet and MLD snooping for IPv6 packets in VDS. Improves performance and scale with multicast traffic. 
• Multiple TCP/IP stack for vMotion - Allows vMotion traffic a dedicated networking stack. Simplifies IP address management with a dedicated default gateway for vMotion traffic.

Availability

• vMotion Enhancements – Perform non-disruptive live migration of workloads across distributed switches and vCenter Servers and over distances of up to 100ms RTT. The astonishing 10x increase in RTT offered in long-distance vMotion now makes it possible for data centers physically located in New York and London to migrate live workloads between one another.
• Replication-Assisted vMotion – Enables customers, with active-active replication set up between two sites, to perform a more efficient vMotion resulting in huge time and resource savings – as much as 95 percent more efficient depending on the size of the data. 
• Fault Tolerance (up to 4-vCPUs) – Expanded support for software based fault tolerance for workloads with up to 4 virtual CPUs. 

Management

• Content Library – Centralized repository that provides simple and effective management for content including virtual machine templates, ISO images and scripts. With vSphere Content Library, it is now possible to store and manage content from a central location and share through a publish/subscribe model. 
• Cross-vCenter Clone and Migration – Copy and move virtual machines between hosts on different vCenter Servers in a single action. 
• Enhanced User Interface – Web Client is more responsive, more intuitive, and more streamlined than ever before.
• Enhanced Linked Mode - Replaces Linked mode which used to use Microsoft ADS, and has been completely built in house at VMware.  This allows for a single pane of glass between multiple vCenter Servers as well as replication of data between them such as licenses.
• VMware Certificate Authority - Allows for signed certificates for the entire management component infrastructure.  With this technology implementing signed CA certificate infrastructures is simplified.

I am sure there will be a flurry of other information coming out soon.  I in fact will be posting next week on the VMware Consulting blog about the new Platform Services Controller Architecture, which is sure to be a popular topic as designs begin to flow for it!