Setup

The F5, as that’s were of course your attention was at, is not equipped with an APM module, the F5 is only used for load balancing. The costs in this project to get an F5 solution in was too high. So it’s only basic load balancing, we will look at configuring the F5’s that are there already and see if we can use some cookie/username persistence. For this blog, think as if there was a unknown load balancer there with no enterprise features something like DNSRR.

• The client connects to a broker 
• The user is authenticated with it’s domain account
• The VMware horizon client will show all desktops the user is entitled to.
• When the user starts a desktop the connection is setup directly with the desktop or through a tunnel. Internal connections are mostly directly, external ones are always through a tunnel.

Cloud Pod working

After you’ve setup a Cloud Pod the traffic flow will change, the two Pod’s are connected and know of each other existence. So a user connecting to a Cloud Pod environment in POD-A will be going through the following components.

Client – [POD-A: Security server – Connection server- Desktop]

Now I hear you say, that’s the same flow. That’s correct for new users connecting there is no difference. the only difference is that they now see only one desktop icon and the local desktop pool icons are gone.

The global entitlement (the one icon they see) is setup that it has the two local desktop pools configured, check my other blogs to see how to set this up.

When a client connects to a global entitlement VMware checks if the user has a home site and if they don’t will forward you to a desktop in that Pod. If they have a home site they will be forwarded to a desktop in the other Pod. So a user with POD-A as it’s home site will always be forwarded to a desktop in POD-A.

That last line is important, if a user has a home site he/she will be forwarded to a desktop in POD-A even when he is connected to a security server in POD-B. This will also happen when they reconnect and end up in the POD-B requesting a desktop running in the POD-A.

VMware has no possibility to redirect the user to the security server in POD-A and will be serving this user from POD-B.

The traffic flow in this case is:

Client – [POD-B: Security Server  – Connection server] [DC – A -> DC – B][POD-A: Desktop]

What happens is that all PCoIP traffic is travelling between data centers, the client will keep on talking to the security server in POD-B and from there it will travel to the desktop in POD-A.

Traffic between two data centers is not the best option I think, there is no way of controlling the amount of users accessing a desktop through the wrong data center. All the user with their session could seriously fill you bandwidth with unwanted traffic.

Traffic from the client (outside) to the Pod where the desktop is living directly is the way it should be. After the user is connected to a security server in the wrong Pod and VMware detects that the desktop is in the other Pod, a migration to the other security server should take place.

Ok, so the F5 is also there redirecting users to one of the Pod’s, is it a factor here? No it’s not for either way users are ending up on one of the security servers and are stuck there. The design feels a bit like a dice game, perhaps you’re lucky ending up in your data center with your desktop 🙂

I see a good topic for VMworld coming up.