Elastic load-balancing using application request routing
A while I ago I started setting up the deployment of a new application that me and a few others at Info Support are creating for a client. We needed to be flexible with this deployment in the sense that it should be possible to scale up the webfarm from one server to multiple servers, without having to do a lot of work.
After careful consideration we settled on a add-on for IIS 7 called application request routing. This add-on is basically an OSI level 7 routing module that allows you to create a wide range of load balancing setups.
The IIS website already shows a couple of scenarios that you can build, but not ours. When I tried to create a test installation of the application request routing module I quickly hit a few walls. Google didn’t provide me with a good answer, so I was force to bend things into shape myself. Application request routing looks simple, but it really isn’t all that simple and it takes a bit of fiddling to get things going.
In this article I’m going to show you how you can create a setup that allows you to scale from one node to multiple nodes without having to change a lot of configuration.
Prerequisites
Before you can start setting up the scenario from this article you will need a couple of components from the IIS website:
– Application request routing add-on v2.0 (http://www.iis.net/applicationrequestrouting)
The application request routing add-on is made up out of a couple of components. It contains the URL rewriting module, a disk caching module and the webfarm module for IIS. Everything can be installed using the web platform installer, so you don’t need to worry about missing dependencies.
The scenario
The scenario I will be demonstrating is a scenario that I like to call an elastic scaling setup. It will support both SSL and HTTP bindings. The first part of the scenario is a single server that will host both the application request router and the application website. This will allow you to support the first group of users on your website.
This single node setup will use two different IP-addresses, one for each of the websites. This eliminates the need for setting different ports.
Note: You can also make this setup by configuring the sites on different ports if you really need that, but you will most likely run into problems. For example WCF services tend to stop working completely when you do this.
The single node setup supports a small number of users (I don’t have exact figures here, since the number of clients that you can support largely depends on the performance characteristics of your application). When the single node setup is no longer enough, you can expand the single node setup into a multi-node setup. The second stage of the scenario is shown below.
Eventually when things get really out of hand you can even choose to move the routing site to a dedicated server. This allows for even greater volumes of traffic to be routed to the webservers.
As you can see load-balancing with application request routing is rather elastic and allows for a broad number of setups. You can even opt for a scenario where there are two application request routers in a NLB (network load balancing) configuration that route towards a couple of webservers. It all depends on what you want to do and what requirements you have.
Setting up the network configuration for the server
Before setting up the site you need to configure the webserver so that it has at least two ip-addresses for available for the websites. One IP-address will be used by the routing website and one will be used by the application website.
For the example I used the following configuration:
Site |
IP-Address |
Routing site |
192.168.3.99 |
Application site |
192.168.3.100 |
You can configure the ip-address by going to the configuration of your local network adapter. Open the properties of the Internet Protocol v4 item and configure the IP-addresses as shown in the figure below.
Setting up the websites
For the scenario to work you will need two websites in IIS. The first website is the one for the application request router and the second website will be the website containing the actual web application(s).
You can create a new website in the IIS manager by right-clicking on the Sites node and selecting the option Create new website. You will see a dialog similar to the one below.
Give each of the sites a descriptive name and assign a fixed IP-address to each one. The following table shows the settings for each of the websites needed for the single node setup:
Site name |
Physical path |
IP-Address |
Routing |
C:WebsitesRouting |
192.168.3.99 |
Application |
C:WebsitesApplication |
192.168.3.100 |
Note: My webserver sadly doesn’t have an extra harddrive, but I suggest you always install your websites on a different drive than the one you installed windows on. This saves you a headache when your server goes down the drain.
Once each of the sites is installed you should be able to send requests to each one. You might get HTTP 404 or HTTP 403 errors, this is normal because they probably don’t contain any content (Unless you installed an application of course).
Configuring the webfarm
Application Request routing uses a mechanism where it creates a rewrite rule that modifies the URL of an incoming requests so that it routes to a webfarm URL. This webfarm URL isn’t a real URL, but rather a pointer for the request router that it should pick a server address from the pool and send the request to that webserver.
You can choose different algorithms to pick a server from the pool to route the request to. There’s a couple of algorithms to choose from:
– Least current requests
– Least response time
– Weighted round robin
– Weighted total traffic
– Server variable hash
– Querystring hash
– Request hash
Each one has a different impact on how the load is balanced between each of the nodes in the webfarm. I could write a whole article on how the routing algorithms work and what algorithm you can use in what situation, so I will not be going into details here.
Right click on the webfarms node and select Create new webfarm to set the wizard to create a new webfarm. It will ask you to enter a name for the new webfarm. After you have entered a name for the webfarm and clicked the Next button, the wizard will allow you to add one or more servers to the webfarm.
At this point you can enter the ip-address of the application site and click the add button to add it to the webfarm. When you click finish the wizard you will be asked if the IIS manager should create the necessary rewrite rules for the webfarm. Click yes to do this.
Patching up the rewrite rules
If you work with multiple physical machines this is the point where you should be able to reach your website. Things are however a bit more tricky when you build a single node setup. If you request a page by entering a URL like http://www.mysite.org/services/sampleservice.svc you will be presented with a page telling you that the router was unable to serve the request.
Note: If you don’t have the luxury of a DNS server you can add the url of the routing site to your host file to make the website available on a friendly name. Also, keep in mind that you only need to configure a DNS entry for the routing site. The rest will be taken care of by the application request routing module.
Because we’re working with a single node the router will mess things up. It will create and endless loop between the application site and the routing site. To solve this you will need to change the configuration of the load balancing rewrite rule a bit.
To change rewrite rules, select the webfarm node inside the IIS manager and double-click on the Routing Rules item in the middle section of the screen. The IIS manager will show a screen on which you can edit the basic settings of the application request router. To get to the rewrite rules themselves however you will need to click on the URL Rewrite link in the section to the right of the screen.
Clicking the URL Rewrite link will show you a list of rewrite rules used by the application request router to get the requests from the client to the right webserver and the responses back to the client.
There will be two rules configured in this section. One for SSL traffic and one for HTTP traffic. When you double click on a rule you can edit the details of the rule.
For the application request router to stop sending you in a circle, you will need to add a condition to both the SSL rewrite rule and the HTTP rewrite rule. You can add a new condition by clicking on the Add button in the conditions part within the details section of a rewrite rule. Use the following settings to stop the rewrite rule from executing when the request has been routed to the application site.
Setting |
Value |
Condition input |
{SERVER_ADDR} |
Check if input string |
Does not match the pattern |
Pattern |
192.168.3.100 (The IP-address of the application site) |
When you’re done editing the rewrite rules you can apply the settings by selecting the Apply link in the section at the right hand side of the screen.
Now that you have configured the necessary settings for the rewrite rules, you can start sending requests to the url of the routing site and it should start routing them directly to the application site.
Enabling SSL
Enabling SSL on a website that runs application request routing is only marginally trickier than on a normal website. Instead of setting a unique certificate for each website you need to set the same certificate for both the routing website and the application site. This is required because the application requests will have refer to the hostname of the routing website both on the routing website itself as well as on the application site.
Also make sure that the certificate is trusted on the webserver. The router will drop the connection if it encounters an invalid certificate or a certificate that isn’t trusted. When this happens you will see a HTTP 502.3 errorpage telling you that the connection was abnormally terminated.
It’s possible to configure the application requesting module for SSL offloading. You can enable this by opening the routing rules configuration of the webfarm. There you can activate or deactive SSL offloading by ticking the corresponding checkbox.
Note: Don’t use SSL offloading when using transport security for your WCF webservices. WCF doesn’t like it when services are accessed over an HTTP channel when transport security is enabled.
Scaling up to a medium sized webfarm
In the previous section I demonstrated how you can create a single node setup to begin loadbalancing your web applications. When it’s time to scale out you can simply right click the servers node on your webfarm and select “Add server…”. This will display the add server dialog:
Here you can enter the ip-address of the new server(s) to add to the webfarm. You can even provide advanced settings for the server entry by clicking the advanced settings button.
You can also manage servers in the webfarm by clicking the servers node of the webfarm. This allows you to take servers offline or remove them from the webfarm entirely. Finally you can also monitor things on the webfarm by double clicking the Health monitoring item when you have the webfarm node selected inside the IIS manager.
Conclusion
Application Request routing can be a very powerful loadbalancer when used correctly. It does take a bit of time to get used to however, so things can get a bit ugly the first time around.
When you do get past this point it’s a perfectly fine solution to work with, especially since you can configure everything through the IIS manager.
For more information check out the following sites:
– Basic introduction of the application request routing module