Citrix’s Web Interface (WI) is a popular way for users to connect to their ICA applications running on Citrix Presentation Servers. Unfortunately, if a Web Interface server fails then users lose access to their applications. Since WI also provides the back-end functionality for Citrix’s Program Neighborhood Agent (PNA) client, a WI server failure also means no PNA users would be able to run any applications.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Therefore, ensuring that your WI server is always available is very important. The easiest way to ensure availability is to build a second server for redundancy. (duh!) This is easy to do (just buy another server, install WI, and configure it like the first one).
The challenge is in the load balancing. How do you balance your users across the two servers? Or, more importantly, how do you ensure that users are only routed to a working server if one of your WI servers fails?
Fortunately there are several options when it comes to load-balancing your WI servers, and some of the options are easy to configure and free!
Load Balancing Basics
Before we look at the specific techniques you can use, let’s take a quick look at the basics of load balancing. All web servers are simply web sites running at specific IP addresses. In a load-balanced world, two (or more) web servers “share” an IP address. (This is called a virtual IP address.) By doing so, web clients request the virtual IP address, and the load-balancing system figures out which physical server should receive the request and the request is sent to the proper server.
Load-balancing solutions can be hardware-based or software based. When using hardware load-balancing solutions, you have an appliance that you configure for a load-balanced group of servers. For example, you might configure your hardware load-balancer as such:
- Virtual IP address: 192.168.1.4
- Real IP addresses of servers that will receive incoming requests: 192.168.1.2, 192.168.1.3
In this case the load-balancing hardware would listen on 192.168.1.4 for incoming HTTP requests. It would then act as a proxy or NAT and forward the request onto one of the backend servers (in this case 192.168.1.2 or 192.168.1.3). How does the load balancer know which server it should send incoming requests to? That depends on the load-balancer. Some have agents that run on each server and can balance based on perfmon counters. Others will use simply round-robin load balancing or they’ll make an HTTP request to each server to check its load.
The other key point to make about the hardware load balancers is that they’re smart enough to realize when a web server is not working, and they won’t direct any incoming client requests to non-working web servers. They also keep track of HTTP session cookies, so once a client establishes a connection with one of your web servers, the load balancer will ensure that that user is always routed to the same web server.
By the way, no one ever really calls these things “hardware load balancers.” Most vendors call them “application switches” or “Layer 7 switches” (or simply "L7 Switches") because they are like regular network switches except that they operate at the OSI Model Layer 7 (Application / HTTP) level instead of at the TCP/IP or MAC address level like regular network switches.
So how much do these things cost? A lot! The SMB version of Citrix’s NetScaler Application Switch is like $17,000! (And double that since you’ll want two for redundancy!) F5’s devices are in the same ballpark price-wise. They’re all pretty expensive except for a company called “Kemp Technologies” that has a two-server application switch for $2500. (Side note: This is what we use in front of the BrianMadden.com web servers.) While Kemp doesn't offer all the compression and caching features of the big boys, they offer great hardware-based application load balancing for a super price!
However, even $5000 (cause you'll want two of them since this is all about redundancy) is too expensive for some people. Fortunately you can also use the Windows Network Load Balancing (NLB) capabilities that are built-in to Windows Server 2003 for a zero-cost software-based load-balancing solution that will probably be sufficient for 99% of the people reading this.
How does Windows NLB work?
At its most basic level, Windows NLB is a network service that runs on each of your web servers. Each server has its own IP address, and then the Windows NLB service uses an additional virtual IP address that is shared among all the servers that you’re load-balancing. (So you’ll need an “extra” IP address from your network guys.)
The Windows NLB service runs on each server that you want to load-balance, and each server’s NLB service communicates with each other server’s NLB service. Behind the scenes, NLB works by “multihoming” each network card in each server so that each server listens for its own IP address plus the shared “virtual” IP address. Then, when an incoming request comes in for the shared virtual IP address, all of the servers receive it. They do a quick check to see which server should handle the request, and then whichever server is chosen handles all additional IP communication for that TCP/IP session. The client still communicates with the virtual IP address—it’s just that only one server actually responds to that communication. The others simply ignore the traffic.
Windows NLB understands “stateful” connections which means that it’s smart enough to check the session cookies in the HTTP protocol stream to ensure that once a client’s browser establishes a session with a particular server, it stays with that server for the duration or the web session. That’s important when you’re using WI, because the web server maintains an encryption key for each user that connects to the server so that it can decrypt the user’s credentials as they launch applications.
Some people say that Windows NLB is crap, but those are usually people who have some other load balancing solution they want to sell to you. Let me be clear on this: Windows NLB is not fancy and has some limitations. (Maximum of 32 nodes in the load-balance group, all servers must be on the same subnet, and load algorithms based solely on network usage.) However, for the purposes of load-balancing a few WI servers, it works great and the price is right!
The main reason that people choose a hardware load-balancer over a Windows NLB is because NLB isn’t very “smart” when it comes to checking to see if a server is online. Of course NLB will not direct any incoming requests to servers that crash, but what if your WI application itself crashes? This might mean that WI is not working, but if NLB is just looking to see if a server is online, it will continue to send users to a broken WI server. The hardware load balancers are more advanced and can typically “test” a website to check for a certain response to ensure that the web application is really working before sending users to it.
I won’t go through all the details of configuring Windows NLB because there are plenty of places to find that online. Basically you just install the NLB Service (via Add/Remove Programs | Windows Components) and pick the IP address that you’ll virtualize between the two servers. You don’t even need to connect any special cables between the two servers. All of the “heartbeat” communication takes place over the standard network interface. (This means you can still team your NICs into a single virtual NIC.)
Once you have your NLB configuration set, make sure your users access your WI via the shared virtual IP address—not the individual IP address of one of the servers. It’s probably best to create a DNS alias for the shared IP address. Using the same IP addresses from above, you might create the following DNS entries:
192.168.1.4 access.mycompany.com <-- shared virtual IP address
192.168.1.2 access1.mycompany.com <-- WI Server 1
192.168.1.3 access2.mycompany.com <-- WI Server 2
All your users can use “access.mycompany.com” as their website which will be load-balanced, but as an administrator you can still connect to access1 or access2 if you need to check something out on a particular server.
Load Balancing WI for Program Neighborhood Agent
If you’re using the PN Agent, then there is nothing more to do other than to make sure that you configure your PN Agent clients to pull their configuration XML files from the virtual IP address. (Don’t forget to copy the XML config files to all your WI servers.) Also, when you’re making your configuration, specify the virtual shared IP address (or the DNS name associated with it) as the location for the WI server.
What about Web Interface version 4?
WI4 has a centralized configuration service which the instruction manual claims is used for configuring the WI servers in load-balanced environments. It’s important to note that WI4 does NOT have out-of-the-box load balancing. All this configuration service does is store the WI server configuration in the IMA data store instead of storing it locally on each WI server in the webinterface.conf file. Even if you use this centralized configuration service, you’re still on your own when it comes to the actual load-balancing of your WI servers, and you’ll still have to use Windows NLB or Kemp or F5 or Citrix NetScaler or whatever.
In reality, the WI4 configuration service is kind of a pain to use, and most people just configure one WI4 server to be how they want it and then copy the webinterface.conf file to the other servers.
Load balancing WI servers is really simple. So go ahead and use NLB, or get fancy and buy an application switch. The bottom line is that you have options and the configuration is pretty straightforward.