In my previous blog post introducing Cloud Pod Architecture, I provided you with a high-level, conceptual overview. Now, let’s get to the details.

VMware Horizon 6 Cloud Pod Architecture & Multi-Data-Center View

One of the key features of the VMware Horizon Cloud Pod Architecture is the high availability and scalability of Horizon 6 virtual desktops. Many of you may have heard about this feature referred to as Linked-Mode View or Multi-Data-Center View or Federated View Pods. All of these mean the same thing.

Today, virtual desktops provided by Horizon can be deployed using a block and pod architecture, or design. (Refer to sections titled View Building Blocks and View Pods in the View Architecture Planning Guide.) A single View pod can contain up to five View blocks, can scale up to 10,000 (10K) desktops, and can be deployed in a single data center. Customers looking to scale beyond 10K desktops can deploy multiple View pods. However, each View pod is an independent entity that has its own user entitlements and is managed separately. With the new Horizon 6 Cloud Pod Architecture, customers can aggregate multiple View pods in either the same data center or different data centers and entitle users to a desktop in any location.

Now, let’s look at an example that describes this feature in its entirety. Figure 1 below shows two View pods—Pod 1 and Pod 2. Pod 1 is located in a data center in the United States, and Pod 2 is located in a data center in India. Each pod has two connection brokers—VCS1 and VCS2 in Pod 1, VCS3 and VCS4 in Pod 2. Both Pod 1 and Pod 2 maintain their own user entitlements, which provide a mapping of an end user to a virtual desktop in the respective pod. The new architecture in Horizon 6 introduces two new elements:

• A global entitlement layer which spans multiple pods (shown as a single layer spanning Pod 1 and Pod 2 in the diagram)

• An inter-pod communication layer (shown with a bi-directional arrow between Pod 1 and Pod 2 in the diagram)

This new architecture provides three major benefits:

• Support for active-active deployments – Customers who have multiple data centers can now leverage all the data-center assets efficiently. They can entitle users to desktops either in one or in multiple data centers.

• Consolidation of multiple pods within a single data center – Multiple pods of desktops within the same data center can be consolidated and managed centrally through a single global user-entitlement layer.

• Disaster recovery – The global user-entitlement layer can be used to assign a user to desktops in both Pod 1 and Pod 2. If Pod 1 were to become unavailable either due to a data-center failure or to another form of failure, the user could always get to a desktop in Pod 2. It is important to note that this feature assumes that the desktops in Pod 1 and Pod 2 are replicated using some form of data-replication technology.

Figure 1: Cloud Pod Architecture with Pod 1 in U.S. and Pod 2 in India

Brokering a Desktop in a Cloud Pod Architecture

Figure 1 conceptually illustrates how two View pods can be used to entitle users to desktops in different data centers. Brokering a desktop to a user who logs in from any location follows the simple workflow below:

1. The end user enters the URL or IP address for their View environment, which can be an address of a View Connection Server (broker) or a load balancer, and enters their credentials.

2. The broker looks up both local and global entitlements for the user.

3. The broker gets the current desktop state via inter-pod protocol and returns a list of desktops to the client.

4. The user selects a desktop.

5. If the desktop is remote, the broker launches the remote desktop via inter-pod protocol.

6. The client connects to the remote desktop directly or via a local tunnel.

The top use cases for end-user desktop access are as follows:

• Global roaming desktop – This is a use case where the end user needs access to a desktop only to access their Windows-based applications. An end user can be located either in India or the U.S. with an entitlement to a nonpersistent desktop pool. The end user gets a desktop in their connected pod (that is, close to their client location—If they connect from India, they get a desktop in India).

• Global home desktop – This is the typical case where the end user wants to get the same persistent desktop every time they request access, irrespective of their location. To accomplish this, persistent desktop pools in all pods need to be set up. The FromHome policy can be used to direct the user back to their home site. The end user gets the same desktop machine irrespective of which pod they are connected to.

• Local scale desktop – In this use case, each site has multiple pods, each offering a standard nonpersistent desktop pool. A global entitlement layer provided by Cloud Pod Architecture joins all these pools together. Using the site’s Scope policy, one can control and limit access to a desktop that is available within the site.

Global Entitlement

The global entitlement layer controls the mapping of end users to desktops in a Cloud Pod Architecture. Global entitlement consists of a set of parameters as shown in Figure 2:

Figure 2: Global Entitlement in the Cloud Pod Architecture

Following are the various parameters of global entitlement:

• Name – Name of the global entitlement

• Members – The users and/or groups that share the global entitlement

• Desktops – Desktops that the members of the global entitlement are entitled to

• Scope – Controls the scope of search when placing a new desktop session. This allows the administrator to control the amount of cross-data-center traffic.

• FromHome (true/false) – This controls where the desktop search is started. When false, it starts from the current pod; when true, it starts from the user’s home site.

The scope can be one of:

• Local – Look only in the local pod for available desktops

• Site – Look in all pods in the local site (typically in the same data center)

• All – Look across all pods for an available desktop to service the request

The search order favors local resources, starting in the same pod that the user connected to, then extending to the same site, and then across the entire linked environment. In addition to this default search order, administrators can nominate a home site for a single user or for a group of users. When a global entitlement has the FromHome policy set, the search for a new desktop is started in the user’s home site and not the current connected pod. This ensures that, where needed, the desktop session remains close to any backend resources it needs.

Scale Limits and Maximums

The Cloud Pod Architecture was developed with the goal of scaling View desktop deployments to hundreds of data centers and tens of thousands of desktops. To deliver this capability in time for product launch, the VMware team has done a phenomenal job of validating this feature by focusing the testing efforts on the following scale-out parameters:

• Number of pods – 4

• Number of sites – 2

• Number of desktops – 20,000

This scale is just the beginning, and the team at VMware is committed to increasing these numbers over the next few releases.

Architectural Assumptions

A number of architectural assumptions have been made in delivering this feature:

• The deployment can have both persistent (stateful) and nonpersistent (stateless) desktops

• A third-party load balancer such as Geographic DNS or a similar product provides the single-URL capability

• Replication of desktops or end-user data is provided by a third-party data replication technology

• WAN links between data centers are sufficiently provisioned and have good latency characteristics—however, the feature works on low-bandwidth, high-latency connections and does not impose either a latency drag or additional bandwidth. It is important to note that user experience varies with both the latency and the bandwidth between data centers.

• All pods are accessible to each other across the corporate network

As you can see, the Horizon Cloud Pod Architecture further advances end-user mobility by delivering desktops from any data center in any geographic location. This is just the beginning of the journey to the hybrid DaaS era!