Technical Article F5 Friday: A Single Namespace to Rule Them All September 30, 2011 by Lori MacVittie 3341 article application delivery availability big-ip big-ip dns cloud design dynamic infrastructure f5 friday f5friday gtm hardware infrastructure infrastructure 2.0 load balancing management partner security us vdi virtualization vmware vmware view 0 #vmware An infrastructure architecture that overcomes VMware View concurrency limitations Sheer volume and geographically disparate deployment of VMware View pods can result in a confusing array of locations from which users must choose to find their preferred desktop. Currently, View deployments are called “pods” and each is limited to a maximum 10,000 concurrent users. That may seem an unlikely upper limit to hit, but there are organizations for which that number is an issue. Every additional 10,000 concurrent users requires a unique supporting infrastructure along with a unique endpoint – an URL – to which the client must point. Users must be aware of which URL they should use; Bob cannot rely on Alice for the information, because Alice may be assigned to a different pod. The same restrictions apply to geographically disparate deployments. A west coast-east coast or even region-based distributed architecture is not uncommon for large and global organizations. Each location requires that the infrastructure supporting the pod be local, too, which means duplicated infrastructure across each geographical location at which it is desirable to deliver virtual desktops. Again, each pod has its own unique endpoint (URL). This can be confusing for end users, and renders more difficult the process of automating client distribution and management, as it may not be known at installation and configuration time to which of the many endpoints the client should point, leaving it in the hands of users who may or may not remember the URL. A combination of F5 solutions mitigates these pain points by supporting a single, global “namespace” for VMware View, i.e. one URL from which virtual desktops can be delivered, regardless of pod membership or physical location. HOW IT WORKS Kevin’s preferred virtual desktop is in the east coast data center. This means if the east coast data center is available, it is preferred to have him connect there, most likely because of Kevin’s proximity to the east coast data center. Kevin travels to California for a business trip, and wants to access his desktop. His desktop has not traveled, and it is preferable to use the same namespace as Kevin would use when on the east coast. To accomplish this, we make use of several F5 technologies, enabling a consistent, global namespace without sacrificing security or performance. 1. The View client connects to the global namespace, e.g. mydesktop.example.com 2. BIG-IP GTM determines Kevin’s location correctly as being on the west coast, and directs his client to the west coast data center, returning 220.127.116.11 as an IP address in response to the DNS lookup. Kevin’s View Client then connects to 18.104.22.168 on port 443. 3. BIG-IP LTM watches Kevin authenticate, sending the username to Active Directory. Examining the response and user attributes, BIG-IP LTM determines that Kevin’s primary desktop is deployed on the east coast. 4. The BIG-IP LTM on the west coast forwards the login request to an available server on the east coast. The connection server logs Kevin in and shows him his available desktop. Kevin opens his preferred desktop. 5. BIG-IP LTM relays the appropriate information back to Kevin’s View client 6. Kevin’s View Client now has the connection information necessary to open his PCoIP session directly to the server in the east coast data center, and does so. SOLUTION SUMMARY BIG-IP Global Traffic Manager (GTM) provides the single namespace, e.g. mydesktop.example.com. BIG-IP Local Traffic Manager (LTM) provides SSL offloading and load balancing of of connection broker traffic, enabling scalability and improved performance. It also provides user-based persistence, enabling BIG-IP LTM to direct the user to the correct server based on the VMware View JsessionID. BIG-IP Access Policy Manager (APM) takes the username and validates it against Active Directory, Radius, LDAP or an HTTP-based authentication service as well as determining group membership to locate the preferred desktop. Working in concert with VMware View servers, this trifecta of intelligent application delivery technologies enables a single hostname for VMware View clients worldwide. It uses the recommended VMware pod deployment model, and has been tested with the iPad, Windows, and zero-client platforms. last modified: September 30, 2011 0 Comment(s): You must be logged in to post comments.