One of the coolest features in my opinion of VMware Horizon View, is the Blast protocol. The Blast protocol makes it possible to connect and work on your desktop with just a browser and even better it does this all by making use of HTML5, no flash needed!
(vCenter guys watch & learn from these guys)
There already some good articles about load balancing VMware Horizon View to the outside world, however they all miss the part about how to load balance the Blast protocol to the outside world.
Some good articles, worth reading:
Below I will describe how you could set-up VMware Horizon View including the Blast protocol. I will focus on the outside connections, which means the security servers.
The set-up consists of the following components;
- 1 x outside firewall
- 2 x Loadbalancers (ADC)
- 2 x VMware View security server
- 2 x VMware View connection server
- 1 inside firewall, between security servers and connection servers (not important for this case)
This is how it actually works;
- A user will connect to the VIP address (workplace.breekeenbeen.nl), this can be done by either using the client or a web browser, port 443.
- This DNS entry contains a public IP address, let’s assume 188.8.131.52
- The firewall will NAT this address to the VIP address of the ADC’s (in this set-up Active/Passive)
- The ADC will determine which security server has to be used. Let’s assume round-robin, but in most ADC’s you can make more advanced rules.
- The user logs in and the connection broker will do his job, to see if the user is allowed to access an available desktop. If this is true, the security server, will communicate a direct address for PCoIP or a direct address for Blast.
- The user connects to this address and should be able to work on his/her desktop.
I have embolden the three most important variables, which you will also see, when you go to the View configuration of a security server.
- External URL: VIP Address
- PCoIP external URL: direct address for PCoIP
- Blast external URL: direct address for Blast
I used the term direct address, cause this connection will not go through the ADC. So we need a separate public IP for the direct connections and NAT them to the internal IP’s of the server, for the connection to the security server, the NAT should work both ways! So our configuration would look like.
- 184.108.40.206 NAT > 10.1.1.8 (VIP ADC)
- 220.127.116.11 < NAT > 10.1.1.6 (Sec. server 1)
- 18.104.22.168 < NAT > 10.1.1.7 (Sec. server 2)
Make sure in the security server configuration, you use the public IP addresses, cause an user would not know where to find the internal addresses.
So a working configuration for this example, would look like this.
Although this is a perfectly working configuration, it has one caveat, when using Blast, it will redirect your browser to “https://22.214.171.124:8443”, this will result in an SSL warning, cause this IP is not the same as the certificates name “workspace.breekeenbeen.nl”.
So what we want is, connecting to “https://workspace.breekeenbeen.nl:8443”, this will result in a desktop through Blast without an SSL warning. However, we can use a public IP and port only once and we want also Blast to be spread over the two servers. Luckily we can easily do this by the use of Port-NAT, also called NAPT. Another benefit you gain by using NAPT is you really specify which ports to use, so this will more tighten the security.
Especially watch the last line in the table below.
- 126.96.36.199:443 (T) NAPT > 10.1.1.8:443 (VIP ADC)
- 188.8.131.52:4172 (T/U) < NAPT > 10.1.1.6:4172 (PCoIP – Sec. server 1)
- 184.108.40.206:4172 (T/U) < NAPT > 10.1.1.7:4172 (PCoIP – Sec. server 2)
- 220.127.116.11:8443 (T) NAPT > 10.1.1.6:8443 (Blast – Sec. server 1)
- 18.104.22.168:8444 (T) NAPT > 10.1.1.7:8443 (Blast – Sec. server 2)
The security server configuration would look like this.by