Horizon View 6 – Cloud Pod Architecture

From:

http://virtualfuture.info/2014/06/horizon-view-6-cloud-pod-architecture/

 

 

In this blogpost I will share my experience with one of the new features of Horizon View 6: Cloud Pod Architecture. What are the use-cases, advantages and disadvantages and I will show how to configure a Horizon View Cloud Pod Architecture.

Cloud Pod Architecture
Horizon View can be implemented acording a so called “block” and “Pod” architecture. With this architecture a View infrastructure of 10.000 desktops can be created. More information about Vi View “Blocks” and View “Pods” can be found in the “View Architecture Planning Guide”.

The most important part to know about a Horizon View Pod is that 1 View Pod can only be implemented within a datacenter. A View Pod cannot cross multiple datacenters. This is because the communication between the connection servers and the View desktops is very sensitive to latency. The slightest latency or connection loss between connection servers can cause corruption in the database. This means that when you want to use multiple datacenters with Horizon View you have to create multiple View Pod environments, which you have to manage separately. In case of an active-active or an active-passive datacenter configuration, you have to use a session-aware loadbalancer. The only one capable of load balancing multiple View Pods is the F5 BIG-IP loadbalancer. With Horizon View 6 a new feature is introduced: Cloud Pod architecture. With this feature, multiple View Pods exchange information about sessions and assignements.
Horizon View 6 introduces the so called “Global Entitlements”. These entitlements can consists desktop pools from multiple View Pods.

Global Entitlement
To create a Cloud Pod architecture, a number of steps need to be taken. A commandline utility called “lvmutil.cmd” needs to be used to configure a Cloud Pod Architecture. In this version of Horizon View the initialization, the configuration and the entitlement needs to be configured using the commandline utlity. The global entitlements are not visible in the View Admin console unfortunately.
The following steps are required:

• Initialize the Cloud Pod Architecture
• Connect the Pods to the Pod Federation
• Create and configure a Global entitlement
• Create Sites
• Assign a “Home site” to a user or group

Cloud Pod initialization
From one of the connection servers the following command needs to be executed:
Lmvutil.cmd –authAs <username> –authDomain <FQDN> –authPassword “*” –initialize

The Cloud Pod Federation is now created.

Connect the Pods to the Pod Federation
The next step is to add other Pods to the Cloud Pod Federation. From a connection server from another View Pod, execute the following command:
Lmvutil.cmd –authAs <username> –authDomain <FQDN> –authPassword “*” –join –joinServer <FQDN of a server of the Cloud Pod Federation> –username <domain\username> –password “*”

Create and configure a Global Entitlement

A Global Entitlement needs to be created. Use the following command:
Lmvutil.cmd –authAs <username> –authDomain <FQDN> –authPassword “*” –createGlobalEntitlement –entitlementName “Global Win7” –scope <ANY|SITE|LOCAL> –isFloating|isDedicated

There are a couple of other options you could use with this command, but these are the most important ones. The “Scope” specifies where Horizon View looks for an available desktop. The following scope options are valid:

• ANY – Horizon View looks for desktops on any pod in the pod federation.
• SITE – Horizon View looks for desktops only on pods within the same site as the pod to which the user is connected.
• LOCAL – Horizon View looks for desktops only in the pod to which the user is connected.

A Global entitlement group called “Global Win7” has now been created. You can now add pools to the Global entitlement. Use the next command from a connection server which the desktop pool hosts to add a desktop pool to a Global entitlement:
Lmvutil.cmd –authAs <username> –authDomain <FQDN> –authPassword “*” –addPoolAssociation –entitlementName “Global Win7” –poolID W7-B1-Pool

The poolID is the ID from the pool that needs to be added. It is best practice not to locally entitle users or groups to this pool. Users could then see two desktop pools in their View client, which would represent the same desktop-pool.
Now is the time to add users or user groups to the Global Entitlement:
Lmvutil.cmd –authAs <username> –authDomain <FQDN> –authPassword “*” –addGroupEntitlement –groupName <Domain group> –entitlementName “Global Win7”

Now the domain user group called “Horizon Users” is entitled to the global entitlement group called “Global Win7”.

Configure sites
In a Cloud Pod Architecture a site is a collection of LAN-connected pods on the same physical location, for example a datacenter. By default with Cloud Pod architecture, All Pods are placed in a site called “Default First Site”. When there are multiple locations, used in a Cloud Pod architecture, Pods need to be configured in a separate site per location.
To configure a site, execute the following command:
Lmvutil.cmd –authAs <username> –authDomain <FQDN> –authPassword “*”–createSite –siteName “site 1”
The Pods can now be assigned to a site. Use the following command from any connection server in a Pod:
Lmvutil.cmd –authAs <username> –authDomain <FQDN> –authPassword “*” –assignPodToSite –podName <podnaam> –siteName <sitename>

Home site
A “Home Site” can be assigned to a user or group. This means that Horizon View will search in the user’s home site, even if the user is connected to a connection server from another Pod. Let’s take a look at an example:
John usually works at location New York (Site 2). Today, John works in Amsterdam (Site 1) and is connected to the local connection server. However, his data is located New York. When John connects to the View Pod in Amsterdam, the Global Entitlement will make sure John will connect to a desktop in New York:

Another scenario can be that John needs the fastest connection to a desktop, in an active-active datacenter configuration for example. John will then be assigned to the first available desktop:

The Global entitlement will make sure that whenever there is no desktop available in Site 1, John will be assigned to a desktop in Site 2:

Limits
In this version of Cloud Pod architecture the following limits need to be considered:
Number of Pods: 4
Number of Sites: 2
Maximum number of desktops: 20,000
These limits could be higher in next versions.

Advantages
The Cloud Pod architecture with Horizon View 6 offers a couple of advantages over local group entitlements. Especially the ability to create an Active-Active and Disaster Recovery environment using Horizon View.

Disadvantages
The disadvantage of this option is that the configuration of Global Entitlements is performed through a command line tool (lmvutil). When a global entitlement is created, this is not presented in the administrator console of Horizon View. This can be very confusing for Horizon View administrators. When a desktop pool has a global entitlement, this will be in the admin console when the administrator looks at the properties of a pool:

In the View Admin console, the only thing you will see about Cloud Pod architecture is the health of the remote pods:

Conclusion
View Cloud Pod architecture offers the possibility to use Horizon View in multiple datacenters in an active-active or active-passive configuration. Unfortunately, this first version lacks the integration in de View admin console. And you still have to manage multiple View Pods, which means you have to take care of a consistent configuration and manage the desktop master images across multiple environments. You could of course use Horizon Mirage to manage the desktop master images.