Shared Hosting Using Application Request Routing (ARR)

Published on June 24, 2008 by pharr

Updated on July 10, 2008 by pharr

Average Rating Rate It (1) Thank you for your feedback!

Tags: ARR

RSS

advertise here

Overview

The use of Application Request Routing (ARR) in a shared hosting environment introduces a new deployment architecture that provides additional benefits and opportunities for the shared hosters. This scenario is enabled by a feature called “host name affinity” in Application Request Routing. For more information on the “host name affinity” feature and how it relates to shared hosting, refer to Shared hosting deployment using Application Request Routing.

This topic leads the reader through the steps to configure “host name affinity” feature in Application Request Routing as illustrated below:

Goal

To configure Application Request Routing in shard hosting environment.

Prerequisites

This walkthrough requires the following prerequisites:

Three IIS 7.0 on Windows 2008 (any SKU).

One will be used to install URL Rewriter and Application Request Routing
- Two will be used as content servers
- Microsoft URL Rewriter Customer Technical Preview (CTP) 1.
Microsoft Application Request Routing CTP1.
A file share to be used for shared configuration and shared content.

If URL Rewriter CTP1 or Application Request Routing CTP1 has not been installed, it is available for download at:

URL Rewriter x86
URL Rewriter x64
Application Request Routing x86
Application Request Routing x64

Step 1 – Set up shared configuration

Before configuring Application Request Routing, the content servers need to be prepped. More specifically:

1. The content servers are configured to use shared configuration.
2. Create at least two sites using shared content.

To set up shared configuration via UI:

1. On one of the two content servers, launch IIS Manager (inetmgr).
2. Select the root of the server:

3. Under Management heading, select Shared Configuration.
4. (You may skip this step, if you already have a configuration that you wish to share on the file share. Otherwise, follow this step to create one.)

Under Actions, click on Export Configuration. Enter the Physical path of the file share where you would like for the configuration file to be exported to. Also provide the Encryption keys password. Ensure that proper permissions are set on the file share for this operation:

5. Check Enable shared configuration and enter the Physical path to the share where the configuration is shared. Provide the user credential as necessary to satisfy the file share permissions:

6. Enter the Encryption Keys Password and restart inetmgr.

7. Now, on the second content server, launch IIS Manager (inetmgr).
8. Select the root of the server:

9. Under Management heading, select Shared Configuration.
10. Repeat the steps 5 and 6 to configure the second content server to use the same shared configuration as the first server. Restart inetmgr.

Step 2 – Create sample sites using shared content

To create sample sites via UI:

1. On one of the two content servers, launch IIS Manager (inetmgr).
2. Create a site by right clicking on Sites, and select Add Web Site…:

3. Create sampleSite1 on port 80 as shown below and bind it to host name sampleSite1. Create appropriate Physical path, as needed:

4.       Repeat the steps in 2 and 3 to create sampleSite2 on port 80 and bind it to host name sampleSite2.
5.       In this walkthrough, the application pools for sampleSite1 and sampleSite2 are running as NETWORK SERVICE. Therefore, ensure that the machine accounts of the content servers have sufficient permissions to the shared content file share. (In production deployment, the recommendation is to create a dedicated credential per site and application pool. In such deployment, ensure that each credential has sufficient permission to access the shared content file share.)
6.       Create the following default.htm file and place it at the root of sampleSite1 (and sampleSite2, after changing “Sample site 1” to “Sample site 2” to reflect that the content is for sampleSite2.):

<html>
  <body>
    Sample site 1
  </body>
</html>

7. At the root of the server in inetmgr, click on Authentication under IIS heading.
8. Select Anonymous Authentication. Click on Edit… under Actions. Select Application pool identity:

9. Verify that the sites have been created correctly. To do so, modify the hosts file on the machine where you will be testing the sites such that the sampleSite1 and sampleSite2 resolve to the IP addresses of the content servers. (The hosts file is located at %windir%\system32\drivers\etc\ on Windows Vista and Windows Server 2008.) Open the browser and open sampleSite1 and sampleSite2.

Remove the entries in the hosts file after testing.

Step 3 – Change application pool process model for Application Request Routing

All HTTP requests and responses for the content sites go through Application Request Routing. Given this, you would want the worker process of Default Web Site on Application Request Routing be always running regardless of whether the worker processes for some of the sites are running or not.

In this step, we will disable the Idle Time-Out under application pool process model for Default Web Site.

To change application pool process model via UI:

1. Launch IIS 7 inetmgr.
2. Select Application Pools:

3. By default, DefaultAppPool is the corresponding application pool for Default Web Site. Select DefaultAppPool. Under Actions, under Edit Application Pool, select Advanced Settings…:

4. Change the Idle Time-out (minutes) to 0 to disable the setting. Click OK to save the changes.

Step 4 – Create a server groups in Application Request Routing

To create and define a server groups via UI:

1. Launch IIS 7 inetmgr.
2. Select the root of the server:

Locate Application Request Routing icon under IIS group heading and double click on the icon.

3. To create a server group, under Actions, click on Create Server Group and name the server group sharedServers:

4. Select the server group that was created in step 3.
5. To add servers to the server group, under Actions, under Server Group Management, click on Add Server. Below example shows adding the two sites created above:

Some load balance algorithms use the weight of the server to proportionally load balance the traffic. The ones that use the Load Balance Weight are:

Weighted Round Robin
Weighted Total Traffic

The weights are normalized. So if all servers have the same weight, they will all get the equal amount of traffic.

Auto Start indicates the default server status of corresponding servers in the server group when Application Request Routings starts. By default, the servers should be considered to be Available. That is to say that the Auto start checkbox is checked by default.

6. Click OK to save changes.
7. To further configure the server group, under Actions, under Server Group Management, click on Server Group Settings. Click through the tabs in Server Group Settings dialog to get familiarized with the available settings. Select Proxy Setting and ensure that the Preserve host header is checked:

Since the site binding rely on the host header, the original host header must be made available to the content servers.

8. Select Health Check tab and enter http://sampleSite1/default.htm in URL:

Application Request Routing uses two different ways to determine the health of the content servers:

Specific URL testing
Live traffic failures

The live traffic testing is performed automatically when the requests are made to Application Request Routing. The explicit URL testing is an additional testing that can be used with the live traffic testing. In this walkthrough, Application Request Routing will use http://sampleSite1/default.htm as a test URL to perform an explicit test.

9. Select Load Balance tab and select Weighted round robin as the Load Balance Algorithm.
10. Select the Affinity tab and check Use host name to enable the “host name affinity” feature in Application Request Routing:

As mentioned above, the “host name affinity” is a feature that is designed specifically for shared hosters. When this feature is enabled, Application Request Routing routes the traffic for a site to a one content server for the lifetime of the corresponding worker process. If there is no running worker process for the site, then Application Request Routing applies the load balancing logic to select the server that is best suited to service the requests for the site for the lifetime of the worker process. This is shown as Time-out value above which is set by default for 20 minutes. The recommendation is that this value is set the same as the Idle Time-out value of the application pools. The Idle Time-out is also set to 20 minutes by default.

For additional information on the “host name affinity” feature and how it relates to shared hosting, refer to Overview of Shared Hosting Deployment Using Application Request Routing.

Step 5 – Define URL rewrite rules

The final step in using Application Request Routing in shared hosting scenario is to configure a rule in URL rewrite.

If there are any previous rewrite rules in URL Rewrite Module, remove them by selecting the rules and under Actions, click on Remove.

To define URL rewrite rules via UI:

1. Launch IIS 7 inetmgr.
2. Select the root of the server:

Locate URL Rewrite Module icon under IIS group heading and double click on the icon.

3. To create an URL Rewrite Rule, under Actions, click on Add Rule… and enter the following values:

Name: ARR in shared hosting
Match URL
- Request URL: Matches the pattern
- Using: WildCards
- Patterh: *
- Ignore Case: Checked
Action
- Action: Rewrite
- Action properties
  - Rewrite URL: http://sharedServers/{R:1}
  - Append query string: checked

Below diagram shows above configuration:

Note that the Rewrite URL, http://sharedServers/{R:1}, references the server group name that you have defined in step 3. The rewrite rule will inspect all incoming requests, as defined by asterisk (*), and send them to the group of servers, defined as sharedServers, where Application Request Routing would load balance and affinitize the requests.

Click on Apply under Actions to save the rule.

4. To test this functionality, modify the hosts file on the machine where you will be testing the sites. Both sampleSite1 and sampleSite2 should resolve to the IP address of Application Request Routing. (The hosts file is located at %windir%\system32\drivers\etc\ on Windows Vista and Windows Server 2008.)

Open a browser and navigate to http://sampleSite1. Verify that as you send additional requests to http://sampleSite1, refresh the dash board in inetmgr for Application Request Routing by hitting F5. (The dashboard is shown on the bottom half of the window when the shared servers name is selected under Server Groups:

Note that the runtime statistics are incremented only for one of the two content servers. This is because the requests for http://sampleSite1 are affinitized to that content server.

Now, send requests to http://sampleSite2. Note that the server that used to have zero values for runtime statistics now have positive values. This is because the requests for http://sampleSite2 are affinitized to that content server.

5. Optionally, to see the behavior without the “hostname affinity” feature in Application Request Routing, under Actions, under Server Group Management, click on Server Group Settings. Select Affinity tab and uncheck Use host name. Click OK to save the change:

6. Send requests to http://sampleSite2. Note that the runtime statistics are incremented for both content servers. This is because there is no host name affinity. You may want to send additional requests and refresh the dashboard, as needed.

Summary

You have now successfully configured the “host name affinity” feature in Application Request Routing and created URL rewrite rules in a shared hosting scenario. For additional Application Request Routing properties and capabilities, refer to other Application Request Routing walkthroughs.