Introduction
When using App-V in production environment you would not be dependent on one server streaming the applications to the client. Also in larger environment you would like to have more App-V servers to load balance the request between servers. Unfortunate Microsoft does not deliver a load balancing/failover functionality within the App-V product, so another technique should be used. Microsoft mentions the possibilities of Network Load Balancing (NLB) included in the Microsoft Server products or (for large implementation) a hardware load balancer. Most load balancers are expensive to buy, however NLB is not really good to manage and within virtualized infrastructures it's difficult to implement properly. Searching for a solution for one of my customers I thought about the Kemp company I met during one of the BriForum events, which has affordable equipment that has lots of capabilities. In this article I'm will describe the phases we have gone through designing and implementing the load balancer for the App-V infrastructure.
Designing
The first question when designing the infrastructure was about moving the single point of failure from an App-V server to the hardware load balancer. When using a single load balancer this will be definitely a single point of failure within the App-V infrastructure. Happily Kemp has the possibility to set-up two load balancer in a shared configuration, where the second load balancer is available as a back-up. The first load balancer will be used for dividing the traffic and the second will take over when the first one fails (active-passive), unfortunate Kemp does not offer the functionality that both load balancer will be used for dividing the workload between both load balancers in a (very) large infrastructures.
A Kemp load balancer is forwarding the request based on a port number. App-V by default uses 554 and a second port in the (large) range between 1024 and 49151. This will create a large complicated configuration to arrange App-V forwarding with the load balancer. App-V has the possibility to secure the traffic with SSL. This configuration option has also as a side effect that only port is being used (322 by default), so we decided to use the SSL option of App-V so only port needs to be configured on the load balancer.
The last important consideration is that the App-V connection need to be "sticky". A sticky connection means that the client needs to keep the connection with the App-V server as the initial connection. So it's not supported that the Load Balancer points the second request to another App-V server in the load balancing team. Kemp support sticky connection within their configuration by default, a simple configuration settings need to be made to activate a sticky connection.
Installation/Configuration
I'm not going to describe the installation steps of the load balancers completely. First of all the installation is not that difficult and is well documented by Kemp. The installation went easily and to test the functionality we used a simple IIS website running on two servers, so we were 100% sure that the load balancer installation went well. We also tested the fail-over capabilities by shutting down the master load balancer and watch if the second takes over.
When all these basic tests were performed it was time to setup the App-V configuration.
The first step to perform is logically configuring the App-V infrastructure to use SSL. The configuration steps are described in one of my earlier articles published on an external website. Secondly the gateway address need to be configured to point to the management IP address .
When the servers were fully configured we could set-up the Load Balancing Service. Therefore we created a new generic service. For some scenario's the Kemp Administration Tool has already configured specific settings, but for App-V this is (not yet) available. We have chosen to ICMP ping option to test the real servers are available, for the load balancing option (scheduling method) we used round robin (but there are more options available) and with the persistence option we arranged the sticky connection.
However the first tests did not get created a connection, even when using a simple telnet command to the 322 port did not deliver a response. This was the time to contact Kemp support for supporting us with this issue. The support department came quickly with a solution by checking the Force L7 checkbox in the configuration of the service. After this change in the configuration the load balancing was functioning.
The App-V service configuration on the Kemp Load balancer.
Don't forget to add the FQDN into the DNS to point to the chosen IP address for the load balanced service, otherwise the clients cannot connect to the environment. So in our case we added APPVSRV as host in the DNS pointing to the IP-address 172.16.4.3
I set-up such a configuration both for a full infrastructure and a streaming only infrastructure. You need to configure the client to point to the FQDN name of the certificate on the App-V servers on the client. For the streaming only solution it is only necessary in the OSD file for the pointer to the SFT file (or using the registry ADM templates to overwrite the ODS value), while besides the OSD configuration logically also the App-V client should be configured to contact the FQDN to arrange the placement of the applications shortcuts.
App-V Client configuration to use the Load Balancer
In practice
The first time we put the load balancer in production it was also the introduction of application virtualization at that customer started with a new version of the business application that has included Office 2007 and some other virtualized applications. In total of 5 GB were streamed to each client (around 800) all at once on Monday morning. We underestimated the behavior and forget to management the load in advance, causing that loading of the applications was extremely slow, both the App-V servers as the Load Balancer were at maximum load (the load balancer both on CPU as network bandwidth) for several hours. However the load balancer continued performing the tasks and did not fail. So how we were not happy with our roll-out, it showed that the load balancer is robust and capable of performing his task. After that first false start it is running perfectly and there are no issues with the load balancer. Because you can disable the connection to the real server out of the management console it is possible to take one server out of production and perform maintenance on that server (during low usage moments). I will definitely recommend such load balancing solution at future customer with the Kemp Load Balancer productions.