One of the new features in VMware's Horizon 6 is the Cloud Pod Architecture, which allows an organization to significantly scale its virtual desktop deployments by spanning multiple data centers.
VMware's Cloud Pod Architecture provides a number of benefits, including fault tolerance, load balancing and centralized management, and it's great for disaster recovery.
To understand the Cloud Pod Architecture, you first need to be familiar with VMware View building blocks and View pods, and be aware that if your company uses persistent virtual desktops, you'll need a replication tool in the event of a pod-level outage.
Understanding View building blocks and pods
View building blocks are essentially a VMware vCenter instance. The block actually contains more than just vCenter, but vCenter is an integral part of the block.
In addition to a VMware vCenter Server, the block contains one or more vSphere clusters. The block also has shared storage and may include other components, such as a database, VLANs and a network switch. Collectively, the resources within the block allow for 2000 virtual desktops.
A View pod is a collection of View building blocks. Each pod can contain up to five building blocks, and can therefore accommodate up to 10,000 virtual desktops. A View pod is a standalone entity that has its own entitlements. You can manage it separately from any other pod that may exist.
Cloud Pod Architecture is based around the use of View pods. Although each pod can function as an independent collection of resources, Horizon 6 makes it possible for you to manage a collection of pods through a single interface, even if those pods reside in different data centers.
In addition to global pod management, the Cloud Pod Architecture also has a global user entitlement layer that spans multiple pods. The pod-level entitlement layer still exists, but it is treated as a local. The global entitlement layer and the new inter-pod communications channel make it possible to entitle users to virtual desktops in one or multiple data centers.
Such a capability could be extremely useful in disaster recovery situations. If, for example, an outage were to occur in your primary data center, workers could use a virtual desktop from another pod in another data center.
Cloud Pod desktop assignments
Of course, this raises the question of how virtual desktops are assigned to end users in a Cloud Pod environment.
In most cases, the connection broker performs all of the heavy lifting. When a user connects to a connection broker and is authenticated, the broker matches the user with the most appropriate virtual desktop, or allows the user to choose the virtual desktop that he wishes to use. The Cloud Pod Architecture supports a few different ways to assign users to desktops.
Probably the most common use case is that the broker assigns the user a desktop based on geographic proximity. Suppose, for instance, an organization has offices in New York and Los Angeles. Assuming the company uses non-persistent virtual desktops, a user who logs in from the New York office should be assigned a virtual desktop that is hosted in the New York data center.
Things work a little bit differently if you use persistent virtual desktops, because they are assigned to specific users. Under normal circumstances, a user is connected to his own persistent virtual desktop, regardless of which pod it exists in.
It's worth noting that persistent virtual desktops introduce challenges when it comes to providing protection against a pod-level failure. In the event of a data center-level outage, it's possible for a user to be redirected to an alternate data center -- even if they have a persistent virtual desktop -- but to make the user's persistent virtual desktop available in the secondary data center, you'll have to implement a replication tool to copy the persistent virtual desktop from one pod to another.
Horizon 6 faces stiff competition from XenApp
What's new in Horizon 6 with View?
VMware baits XenApp shops with Horizon 6
Dig deeper on VMware virtual desktop software