Configure Horizon View 6 Cloud Pod Architecture

By | June 20, 2014

Now View 6 has become GA, it’s time to look further into one of the many new features!  One of the features that grabbed my attention, is the Cloud Pod Architecture feature, essentially allowing you to link multiple View Pods over a WAN connection (to another datacentre).  This has always been a limiting factor with large View architecture, essentially limiting a pod per datacentre, or multiple pods per datacentre.  Back in 2012 at VMworld US, the ability to bring this added dimension to View designs was discussed in the EUC 1470 session – Demystifying Large Scale Enterprise View Architecture.  This will dramatically change the way large View designs can be designed.  Let’s drill further into the details (from the official VMware docs):-

View Cloud Pod Architecture

  • With the Cloud Pod Architecture feature, you can link together multiple View pods, to provide a single large desktop brokering and management environment.
  • In a traditional View implementation, you manage each pod independently. With the Cloud Pod Architecture feature, you can join together multiple pods to form a single View implementation called a pod federation.
  • A pod federation can span multiple sites and datacentres, and simultaneously simplify the administration effort required to manage a large-scale View deployment.
  • View Connection Server instances in a pod federation use the Global Data Layer to share key data. Shared data includes information about the pod federation topology, user and group entitlements, policies, and other Cloud Pod Architecture configuration information.
  • View Connection Server instances communicate in a Cloud Pod Architecture environment by using an interpod communication protocol called the View InterPod API (VIPA).
  • You use the lmvutil command line tool to configure and manage a Cloud Pod Architecture environment. lmvutil is installed as part of the View installation. You can use View Administrator to view pod health and desktop session information.
  • Before you begin to configure the Cloud Pod Architecture feature, you must make decisions about your Cloud Pod Architecture topology. Cloud Pod Architecture topologies can vary, depending on your goals, the needs of your users, and your existing View implementation. If you are joining existing View pods to a pod federation, your Cloud Pod Architecture topology is typically based on your existing network topology.
  • In a Cloud Pod Architecture environment, a site is a collection of well-connected pods in the same physical location, typically in a single datacentre. The Cloud Pod Architecture feature treats pods in the same site equally.
  • When you initialize the Cloud Pod Architecture feature, it places all pods into a default site called Default First Site. If you have a large implementation, you might want to create additional sites and add pods to those sites.
  • The Cloud Pod Architecture feature assumes that pods within the same site are on the same LAN, and that pods in different sites are on different LANs.
  • Ports – 22389 Global Data Layer LDAP Instance and 8472 View interpod API (VIPA) interpod communication.
  • Limitations
    • 20,000 desktops, 4 pods, 2 sites and 20 Connection Servers
    • This release does not support using the HTML Access feature. With HTML Access, end users can use a Web browser to connect to remote desktops and are not required to install any client software on their local systems.
    • This release does not support using remote Windows-based applications hosted on a Microsoft RDS host. 
  • Below is a summary of Cloud Pod Architecture (slide via VMware)

cloud-pod-arch

Jumping into the Lab

Having been fortunate enough to have access to View 6 beta, I decided to take a closer look and have a play with this new feature in my lab…

Summary of steps

  1. Initialize feature
  2. Join Pod(s) to Pod Federation
  3. Find and Change Pod Names
  4. Create and Configure Sites
  5. Move Pods to relevant Site
  6. Create & Configure a Global Entitlement (future post)

Lab Environment

  • Two datacentres – London and New York City (NYC).
    • London – View Connection Server = ViewCS6
    • New York City – View Connection Server = ViewCS6-nyc

The goal is to join the London pod to the New York City pod, creating a Pod Federation, with two unique Sites called London and NYC

Please be aware the example is for Lab purposes only, in production you would have at least two Connection Servers in each pod, to provide redundancy & availability.  My lab has limits, and I do not have two physical datacentres, or two domains, which would be minimum requirement, for a typical real world environment.

This is purely to test the configuration of the Cloud Pod Architecture feature at a simplistic level.

Initialize feature

Before you configure a Cloud Pod Architecture environment, you must initialize the Cloud Pod Architecture feature. You need to initialize the Cloud Pod Architecture feature only once, on the first pod in a pod federation. When you add pods to the pod federation, the new pods join the initialized pod.

Run the following command from any View Connection Server instance in the London pod.  I will run from ViewCS6, which is a Connection Broker running in my London datacentre.

lmvutil –authAs steve.dunne –authDomain lab.local.com –authPassword “*” –initialize

Note: “*” Will prompt you to enter your password.

Note: The commands\switches start with hyphen hyphen (or dash dash), you may not be able to see these clearly from the text or graphics below.  Check the official documentation for confirmation if unsure.

1

During the initialization process, View sets up the Global Data Layer on each View Connection Server instance in the pod, configures the VIPA interpod communication channel, and establishes a replication agreement between each View Connection Server instance.

List Pods

The Pod is now created and called Cluster-ViewCS6, and the Owning site is Default First Site (we can change the names further down the line to suit our needs).  Run the following to list out the pods.

lmvutil –authAs steve.dunne –authDomain lab.local.com –authPassword “*” –listPods

2

Join additional Pods to Pod Federation

During the Cloud Pod Architecture initialization process, the Cloud Pod Architecture feature creates a pod federation that contains a single pod.  You can use the lmvutil command to join additional pods to the pod federation.  Joining additional pods is optional.

Within the New York City datacentre, a single pod is running from here.  On any View Connection Server (in my case ViewCS-nyc) in the pod, we need to join this pod to the pod federation

lmvutil –authAs Steve.dunne –authDomain lab.local.com –authPassword “*” –join –joinServer viewcs6.lab.local.com –userName lab.local.com\steve.dunne –password “*”

3

After you finish joining the pod(s) to the pod federation, the pod(s) begin to share health data. You can view health data on the dashboard in View Administrator.

4

From the above, you can see the Health of the Local Pod (ViewCS6-NYC), and the Remote Pod, ViewCS6 (running from London).

Change Pod Names

The Cloud Pod Architecture feature assigns default names to the pods in a pod federation. You can use lmvutil commands to list the names of the pods in your pod federation, and change the default names to names that reflect your network topology.

From my View Connection Server (ViewCS6 in London), I used the following:-

lmvutil –authAs steve.dunne –authDomain lab.local.com –authPassword “*” –updatePod –podName “Cluster-ViewCS6” –newPodName “London-Pod-1”

lmvutil –authAs steve.dunne –authDomain lab.local.com –authPassword “*” –updatePod –podName “Cluster-ViewCS6-NYC” –newPodName “NYC-Pod-1”

lmvutil –authAs steve.dunne –authDomain lab.local.com –authPassword “*” –listPods

5

We now have two pods, correctly named:-

NYC-Pod-1, containing ViewCS6-NYC

London-Pod-1, containing ViewCS6

Create Sites and move pods to relevant site

On any Connection Server instance in the pod federation (I selected ViewCS6), run the following to create two sites (one for London & one for New York), and move the pods to the relevant site.

lmvutil –authAs steve.dunne –authDomain lab.local.com –authPassword “*” –createSite –siteName “London Datacentre”

lmvutil –authAs steve.dunne –authDomain lab.local.com –authPassword “*” –assignPodToSite –podName “London-Pod-1” –siteName “London Datacentre”

lmvutil –authAs steve.dunne –authDomain lab.local.com –authPassword “*” –createSite –siteName “New York City Datacentre”

lmvutil –authAs steve.dunne –authDomain lab.local.com –authPassword “*” –assignPodToSite –podName “NYC-Pod-1” –siteName “New York City Datacentre”

6

Verify our configuration

lmvutil –authAs steve.dunne –authDomain lab.local.com –authPassword “*” –listPods

8

Horizon View Administrator Dashboard

Viewing the below graphic – New York View Broker (left hand side)  & London View Broker (right hand side).  Both sites show the Remote Pods with the relevant names.

Ignore the ‘red’ status of the two Connection Servers, this is because I haven’t yet installed the certificates.  Both servers are functioning fully after the above changes.

9

Wrapping Up

You can achieve much more using the lmvutil tool, including creation and configuration of Global Entitlements and assigning a Home Site to a User or Group.  I encourage you to check out the official VMware documentation for ‘Administering the View Cloud Pod Architecture

I hope the above brings some insight into the configuration of this new feature.

Leave a Reply