Horizon 6 Cloud POD Architecture

In a past article, I reviewed the Horizon 5.2 POD architecture. Horizon View components fit together within a physical architecture, based on the concept of building blocks and pods. It is a scalable approach which allows IT operations to build out their VDI enviroment as end users move to virtual desktops.

A Horizon View pod integrates five 2,000-user building blocks into a View Manager installation that you can manage as one entity.

By taking this approach, you can be fairly user-agnostic and deploy additional blocks or pods with varying performance characteristics, geographical locations, or access mechanisms as required.

A typical Horizon View deployment can consist of 500 to 10,000 virtual desktops hosted across a single or multiple ESXi clusters managed by a management building block.

The Cloud pod architecture extends the entitlement capabilities for Horizon desktops across datacenters and physical sites with Global Entitlements.



Previously, latency was the primary issue in extending a View architecture because of Java Message Service. AD LDS uses Microsoft's built-in replication mechanism for replication. Volatile session state data is stored in the connection server's memory in a session state map. Connection servers replicate this data using the JMS Router service. The JMS Router has inter-router connections to the JMS Routers on all connection servers in the group. The message bus is extremely sensitive to latency, and because of this fact, the VMware support policy explicit states that installing connection servers on either side of a WAN link is not supported.

Until Horizon 6, the new design is enabled by a new LDAP replication layer that can span View pods across physically remote datacenters. It is enabled by the View Inter Pod API (VIPA) that is more tolerant to latency to support the remote sites. 

Users can connect to a single namespace with a global URL and it will look up their global entitlements across View pods and sites. This is achieved through a combination of the Cloud pod architecture, global load balancing, and local load balancing.

Some of the use cases include:

• DR in an active/passive configuration
• Active/active configuration to extend the entitlement capabilities across sites and beyond the 10,000 connection pod constraints
• Geo-roaming users 

Lets take a look at an example of the Horizon 6 Cloud pod architecture. In the below diagram, the London pod and the New York pod are talking to each other, they know the state of each other, entitlements and session information.

Here are the steps for a client to connect to the federated pod:

1. Client logs into a broker in the London pod using existing mechanism
2. Broker looks up local and global entitlements for users
3. Broker gets desktop state via inter-pod protocol and returns the list of desktops to the client
4. User selects a desktop (in this case the user selects a desktop that is not managed by the same pod as initially authenticated against)
5. Broker launches remote desktop via inter-pod protocol

This is a pretty significant advancement, when designing a Vmware View solution for a enterprise organization you can now look at it from a regional or global perspective. It provides more options when building out your functional requirements and logical design.