There’s been a lot that has changed with the release of Horizon with View in June 2014. Aside from the support for RDS hosted desktops and published applications using PCoIP, there is also a new feature called Cloud Pod Architecture (CPA). CPA enables entitlements to desktops between multiple View pods within or across multiple data centers.
F5’s Local Traffic Manager (LTM), Access Policy Manager (APM), and Global Traffic Manager (GTM) solution has been able to address this challenge for some time. From a 30,000-foot view, here is how today’s integrated VMware/F5 solution works when detecting an existing session without Cloud Pod Architecture:
With the introduction of Cloud Pod Architecture, how does this impact the F5 solution? What’s different? What value-add does F5 provide in this updated environment?
The beauty of the VMware/F5 relationship is that the solutions COMPLEMENT each other very well. But, a word to the wise - what you need (versus want) should be driven by an organization’s business and technical requirements in concert with the View/F5 solution capabilities.
Cloud Pod 101
So, let’s take a quick look at what Cloud Pod Architecture is and how it works. I’m not going to reinvent the wheel explaining this, as Narasimha Krishnakumar (Director of Product Management – EUC @ VMware) does a spot-on job of explaining it – check out this link for more info:
Basically, you can federate multiple “independent” View pods and bring together pools from each View Pod to appear as a “single” global pool (the official term is called Global Entitlement). If a user connects into one View Pod, and their desktop resides in another, the View Pod they connect to authenticates and brokers the connection on behalf of the other – and BAM! you are connected to your desktop.
This graphic - courtesy of VMware’s EUC Technical Enablement team - is the picture that’s worth a thousand words:
Let’s walk through the flow of a connection to a Cloud Pod-enabled desktop pool:
Even though the desktop is in NYC (in this example), the user connected to the London Connection Servers – these brokers authenticated the user on behalf of NYC, so the user never passes through the brokers in NYC. This same traffic flow would also apply if there were Security Servers – the connection to the NYC data center would be proxied through the Security Servers in London.
So, does this remove the need for the F5 Username Persistence solution or the need for load balancing in general?
Well, the honest answer is “it depends”. You still need to load balance between security servers and connection servers for system resiliency and scalability. Around whether CPA will adequately replace F5’s username persistence solution, you need to do some homework to determine the best approach. Here are some key points on how to determine what you’ll need to address load balancing/connection management and session persistence features when using F5’s APM and/or View’s Cloud Pod Architecture (CPA):
If we use the picture above as example, the user is accessing their desktop in the NYC Pod through the London Pod. Therefore, the path of data flow is over the internal link – which needs to be able to handle PCoIP traffic in addition to handling other inter data center traffic when hauling PCoIP over latency-sensitive connections.
How does F5's Username Persistence solution complement View's Cloud Pod Architecture?
F5’s username and session persistence solution can address many of the previously mentioned challenges through the use of GTM, LTM, and/or APM. Here's some guidance that will help you choose the right path:
Well, that wraps up this blog post. Our next blog post will focus on understanding and implementing F5’s PCoIP Proxy feature – we’ll cover how it works, when to use it, and how to integrate it with View.
You can also send any topics or ideas to email@example.com.
Until next time...