Cloud Pod – Enabling the Future

Cloud Pod – Enabling The Future

As mentioned in my previous blog, I am going to drill down into a few technologies that are enabling VDI. I will try to keep them from being a deep dive but as you can imagine some of the explanations will inevitably be Tech Talk.

One of the recent developments in the VDI space was VMwares announcement of Cloud Pod. It took up quite a bit of VMwares premier event VMWorld and has generated a lot of attention within their Technical Blogs.

For this Blog I will try to explain what Cloud Pod is and how it can be used.

What is a Pod?

If you are not familiar with Horizon design you may not be familiar with this term so I want to explain this straight off the bat. Essentially a pod is a boundary, a unit organization determined by Horizon View Scalability limits. “Block and Pod Architecture” is an industry recognised architecture for Horizon View.

What are the limitations without Cloud Pod?

Without going into every scalability limit, it is important to call out a few that Cloud Pod has really been brought in to solve.

Size – A view pod could not be scaled beyond 10,000 desktops. While some may view this as an extreme use case, you would be surprised how many businesses require that number of desktops when they get down to crunching the numbers. The Financial and Healthcare sectors are two that spring to mind.

Single Datacentre – Following VMwares best practice a Pod could not span Datacenters. This is due to the JMS protocol which requires extremely quick (low latency) responses. Many viewed this idea of a “Stretched Pod” as a way of doing quick DR, but it is not officially supported by VMWare and due to the JMS Protocol, corruption can occur.

DR Provision – DR in previous incarnations of Horizon was effectively another Pod that was administrated separately. DR meant either repointing the client manually or being achieved using load balancers in an Active / Passive solution, although the load balancing options were limited.

Roaming Users – Unless manually changed, a user was tied to a deployment. So if James Smith normally works in the US, then he travelled to the UK office, he would either have to adjust the view client to connect to UK deployment (assuming he was entitled to do so) or connect back to US deployment.

Enter Cloud Pod

To explain how Cloud Pod solves some of these limitations, it is necessary to explain a few of the features.

Global Entitlements

As I have mentioned, entitlements within an Horizon View environment are only valid within a Pod. This means that multiple pods are in effect managed independently.

Cloud Pod allows Global Entitlements; these are entitlements that can span across Pods, allowing users to use any desktop in any pod if you wish them to.

The Global Entitlements allows its behaviour to be modified using a number of options.

The Scope Option

The Scope Option specifies where Horizon View looks for an available desktop. This can mean that the desktop you are delivered is not necessarily in your home site. The following scope options are valid:

ANY – Horizon View looks for desktops on any pod in the Cloud Pod.

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 connected

By default, Horizon View will use the following order to locate a desktop – Local, Site, and finally Any.

The Home Site Option

A home site is assigned either to a user or a user group. By using the home site, Horizon View will search the home site of the user for a desktop, even if the user is connected to another pod.

Geographic Load Balancing

Cloud Pod allows for Single Name Space. This means that all the Pods effectively respond to the same DNS Name. It is then up to a Geo Load Balancer to place you at the geographically closest Pod.

To try and illustrate how all this plumbs together, I will give a few example scenarios.

Beyond the 10,000 – You can now have 20,000 desktops provisioned.  This is a soft and supported limit within the current version and is likely to grow. VMware have said don’t be put off if you have a bigger deployment, talk to them and see what can be done.

Scenario: A large healthcare organisation requires 15,000 desktops with follow me desktop provision. This can now be provisioned with linking two pods together enabling them to be managed as one, with all the same desktop entitlements.

DR Provision – By utilising the Global Entitlements along with the home tag then Pods can be deployed to allow for DR.

Scenario: Company “Brilliant Paper” has two Datacentres geographically separate. When the user James Smith normally connects he is presented with his “Sales” desktop in Home Site. Should there an outage then IT can flip this to a DR provision using another Pod in the other DC. James Smith would log back in and a desktop would be presented as “Sales – DR” in the DR Site. James can then log on and continue working.

Roaming Users – Users that travel globally or even within a country can find VDI a challenge as they may have to manually connect to different View deployments. Cloud Pod solves this by enabling a Single Name Space. This means the Pods are all accessible under a single name, and it is Cloud Pod that determines which Pod and Desktop the user actually connects to.

Scenario: Company “Power Paints” has Datacentres in New York and London, James normally works in NY and his desktop is homed within the NY DC. Today James travelled to London, using the Home option will ensure James connects back to his desktop in NY. Conversely he could be allowed to access a desktop that is geographically closer to him to ensure the best performance.

Conclusion           

As you can see, Cloud Pod has brought a set of features that enable Horizon View to provide an improved user experience as well as improved deployment options. One thing to bear in mind is this an initial release. As such the management of it is done at command line, and there is no representation of the Global entitlements within the Horizon View Administrator. That said, it is unlikely you would change global entitlements on a regular basis, and even if this was a requirement it could be very easily scripted.

The Future

Cloud Pod is a new feature that is  set to solve some real problems and challenges without a great deal of complexity, it is likely to mature in to a very useful feature set and I look forward to watching it and reporting back on its progress.