Won Yoo's Blog : Application Request Routing

Application Request Routing: Benefits of caching

wonyoo — Thu, 15 Oct 2009 01:20:00 GMT

As you know, ARRv2 RC was released a few weeks ago. (To learn more about ARRv2, click here. Download x64 or x86.) With ARRv2 RC, ARR now has two cache tiers, kernel memory cache and disk cache. I think people in general understand the benefits of caching (reduced latency, reduction in bandwidth consumption, etc) but recently, a customer who has deployed ARRv2 RC in production sent me the following data. The customer is using ARR as a reverse proxy to load balance the requests to several content servers.

The data on the left is from the content servers (aggregated) and the data on the right is from ARR. In this customers environment, over the course of 4 days (duration of time in Oct when the logs have been captured), he saved approximately 100GB worth of bandwidth (160GB total bytes in ARR vs. 62GB at the content servers). Of course, your mileage may vary depending on the cache-ability of the contents that you serve, but savings of 100GB in 4 days is significant for this customer.

I was really impressed to see the "real customer" data on ARR cache performance so I figured I would share it on iis.net. If you haven't already, check out ARR and see what it can do for you in your environment. ARRv2 RC comes with GoLive license, which means it can be deployed in production.

Note: Because some of the contents are being served from the cache in ARR, if you are providing logs to your customers, you will need to gather logs from ARR as well as from the content servers to provide the complete log.

Microsoft Application Request Routing (ARR) Version 2 RC for IIS7 has been released.

wonyoo — Thu, 24 Sep 2009 19:09:00 GMT

Microsoft Application Request Routing (ARR) Version 2 RC for IIS7 has been released.

Overview:
Application Request Routing v2.0 RC is an incremental release that includes all the features from version 1.0, and adds support for disk based cache. ARR v2.0 RC comes with Go Live rights and is licensed to be deployed in production environments.

ARR v2.0 RC can be used to:
• Enhance ARR v1.0 scenarios with disk cache.
• Use ARR as an edge cache CDN/ECN environments.

Download ARRv2 RC from:
• Microsoft Application Request Routing Version 2 RC for IIS 7.0 (x86) here.
• Microsoft Application Request Routing Version 2 RC for IIS 7.0 (x64) here.

Feature list:
• Disk-based caching
In addition to the kernel memory cache in ARR Version 1, Version 2 adds support for disk-based cache, including support for a secondary network-based drive.

• Cache hierarchy management
Define and manage relationships between cache nodes, including support for the Cache Array Routing Protocol (CARP).

• Cache proxy node in CDN/ECN environment
Because ARR is a proxy-based HTTP request routing module with support for disk cache and CARP, ARR can be used as a cache proxy in a CDN/ECN environment.

• Caching compressed objects (Improved in RC)
Disk-based cache stores compressed objects so that the objects do not have to be compressed in real time for every request. In RC, ARR will gzip compress objects even if the content server does not respond with gzip content-encoding.

• Browsing cached contents using IIS Manager (Improved in RC)
Browse through cached contents across multiple drives in one consolidated graphical view in IIS Manager. In RC, the performance enhancements in the UI (inetmgr) allows browsing of cached directories and files more quickly. It also includes improvements to usability.

• Removing cached contents
Delete cached contents by matching URL patterns.

• Overriding cache-control directives
Manually override the cache-control directives in the response header to change the cache behavior.

• Warming up cache node (Improved in RC)
Proactively warm up your cache node with contents that will be in demand before they are requested. In RC, the contents can be pre-cached selectively only at the parent cache tier.

• Intelligent byte-range support
ARR converts the byte-range request into manageable segments to increase cache hit/miss ratio without sacrificing response time.

• Intelligent live request support
ARR is designed to work with Live Smooth Streaming to support live content requests without over-loading the live streaming server.

• Caching while serving response
Caching large content, such as a movie clip, may take some time. ARR Version 2 Beta 2 is capable of caching the content while serving the response immediately.

Support:
Support for the RC release is available only on the forum.

ARR and MaximumASP

wonyoo — Mon, 24 Aug 2009 16:25:00 GMT

As you may know, Application Request Routing (ARR) has a host name affinity feature that is designed specifically for hosters to use to maximize the available resources across their environment. More info on host name affinity and hosting can be found here and here.

I am happy to announce that one of our partners, MaximumASP has launched a private beta hosting offering based on ARR and IIS7/IIS7.5. To quote MaximumASP, the MaxESP - an "Elastic Shared Platform" offers:

...while most of the great features of MaxESP are below the surface, such as load balancing, SAN storage, redundant web servers, etc., you can opt to have your website clustered across multiple servers.

...allow your website to run on a single or multiple web servers simultaneously. Down the road, we’ll be expanding this capability so that you can select as many web servers as you want, and move your resources around dynamically as the situation demands.

The elastic scalability per host name is achieved by a combination of host name affinity feature and the ability to assign the number of servers to consume per host name in ARR. A step-by-step walkthrough on host name affinity is found here.

Congratulations to MaximumASP for the successful launch. You can also learn more about MaxESP at MaximumASP's blog site here.

Pre-caching contents using Application Request Routing (ARR) and Search Engine Optimizer (SEO)

wonyoo — Thu, 13 Aug 2009 19:52:00 GMT

Application Request Routing (ARR) Version 2 includes support for disk caching capabilities which effectively allows ARR to be used as a cache proxy. ARRv2 also includes management of cache hierarchy so that it can be used to build a network of cache servers, as in Content Delivery Network (CDN) or Edge Caching Network (ECN).

More information on ARRv2 can be found here and they can downloaded at:

Microsoft Application Request Routing Version 2 for IIS 7.0 (x86) here.
Microsoft Application Request Routing Version 2 for IIS 7.0 (x64) here.

One of the features in ARRv2 Beta2 release is a way to pre-cache contents on ARR servers in anticipation for the expected demand for the contents. (ie. A popular movie is being released on DVD on Friday and you expect users to rent and watch them online when it is released.) The walkthrough on the pre-cache feature in ARRv2 can be found here.

In order for this feature to work, the ARR administrator must provide a list of URLs for ARR to pre-cache. ARR can either consume this list via a file or via a URL which in turn has the list of URLs in the entity-body in the response. ARR expects the list of URLs in the following format (one URL per line):

http://somedomain.com/somepath/somefile1.jpg
http://somedomain.com/somepath/somefile2.jpg
http://someotherdomain.com/somepath1/somefile1.jpg
http://someotherdomain.com/somepath2/somefile1.jpg
.
.
.

If the ARR administrator or the content owner/publisher can provide such list of URLs, that's great. You are all set - just follow the steps in the walkthrough to pre-cache the contents.

But what if you don't have such file? How could such file be created with minimal effort?

The Search Engine Optimizer (SEO) Toolkit is a much more powerful tool than just using it to generate the pre-cache URL list (and the readers are strongly encouraged to check SEO out), but in the context of this blog, I will use SEO to generate the list of URLs.

Step 1: Open IIS Manager and locate Site Analysis icon:

Step 2: Configure SEO to analyze the site that you want to pre-cache. The site, in this case, could be a staged site where the new DVD is ready to be published. In my example below, I am simply pointing at a site which contains pictures.

Step 3: Once the site is analyzed (and this is where the real value of the SEO comes in, but I won't get into that in this blog), it should look like the following.

Step 4: What I am interested in are links to the jpegs on my site so that I can generate the pre-cache URL file. So, I am going to run a query to just list the URLs with content type that begins with images.

Step 5: I just want to export the URL, so I am going to remove all the columns that I don't want.

Step 6: Once I export the file, I see something like:

URL
http://wonyoo-w2k8/pix/IMG_1400.JPG
http://wonyoo-w2k8/pix/IMG_1401.JPG
http://wonyoo-w2k8/pix/IMG_1412.JPG
http://wonyoo-w2k8/pix/IMG_1413.JPG
http://wonyoo-w2k8/pix/IMG_1414.JPG
.
.
.

Step 7: Simply remove the column header, URL, from the file and voila! You now have the pre-cache URL file that is generated for you. This file can now be used to feed ARR to pre-cache them.

Application Request Routing Version 2 in action.

wonyoo — Mon, 03 Aug 2009 21:20:00 GMT

As you know, in Application Request Routing Version 2, the focus is around enabling ARR as a cache proxy in CDN/ECN environment. We had our first beta release in March 09 and the currently available release for supporting this scenario is ARRv2 Beta 2 (Released in July 09 and more info can be found here.)

You can download ARRv2 Beta2 from:

Microsoft Application Request Routing Version 2 for IIS 7.0 Beta 2 (x86) here.

Microsoft Application Request Routing Version 2 for IIS 7.0 Beta 2 (x64) here.

The event is already over, but for those of you who watched REMIX Japan 09 on Live Smooth Streaming, the video "stream" was being proxied through and cached by ARRv2 servers (and I must say that the HD quality was fantastic). The deployment was done in single tier for this event, although it could be multi-tiered (as documented in this walkthrough). With additional features that are much more powerful for handling byte-range requests to consolidating live requests, ARRv2 was able to play an important role in broadcasting REMIX Japan 09.

Please check out the new features in ARRV2 Beta 2 here and let us know what you think via this forum.

Lastly, I must thank the team in Japan who made it possible - BIG THANK YOU - and it was nice meeting with you all at TechReady 9.

HostingCon 2009 and Application Request Routing (ARR)

pharr — Mon, 03 Aug 2009 16:49:00 GMT

Ahead of HostingCon 2009 next week, I wanted to show how ARR can be used in hosting environment to offer elastic scalability. This feature has been highlighted in other walkthroughs and blogs, but here is the video version.

To learn more about the proxying and load balancing capabilities of ARR, visit the following link.

Microsoft Application Request Routing (ARR) Version 2 for IIS7 Beta 2 has been released.

wonyoo — Thu, 16 Jul 2009 23:47:00 GMT

Microsoft Application Request Routing (ARR) Version 2 for IIS7 Beta 2 has been released.

Overview:Microsoft Application Request Routing (ARR) for IIS 7.0 is a proxy-based routing module that forwards HTTP requests to application servers based on HTTP headers, server variables, and load balance algorithms. ARR Version 2 Beta 2 is an incremental release that includes all of the features from Version 1, and adds support for disk-based cache. More specifically, this feature allows IIS to compete as a cache proxy in a whole new market place:

Enhance ARR Version 1 scenarios with disk cache.
Use ARR as a cache proxy as a cache node in a CDN/ECN environment.

Use ARR as an edge/child cache node.
Use ARR as a parent cache node.

Download ARRv2 beta 2 from:

· Microsoft Application Request Routing Version 2 for IIS7 Beta 2 (x86)

· Microsoft Application Request Routing Version 2 for IIS7 Beta 2 (x64)

What’s new in ARRv2 beta 2:

Disk-based caching (Improved in Beta 2)
In addition to the kernel memory cache in ARR Version 1, Version 2 Beta 2 adds support for disk-based cache. This feature is improved in Beta 2 with an introduction to secondary cache concept.

Cache hierarchy management
Define and manage relationships between cache nodes, including support for the Cache Array Routing Protocol (CARP).

Cache proxy node in CDN/ECN environment (Improved in Beta 2)
Because ARR is a proxy-based HTTP request routing module with support for disk cache and CARP, ARR can be used as a cache proxy in a CDN/ECN environment. This feature is improved in Beta 2 with support for more advanced routing rules, such as being able to set host headers to route requests accordingly.

Caching compressed objects
Disk-based cache stores compressed objects so that the objects do not have to be compressed in real time for every request.

Browse cached contents using IIS manager (New in Beta 2)
Browse through cached contents across multiple drives in one consolidated graphical view in IIS manager.

Remove cached contents (Improved in Beta 2)
Delete cached contents by matching URL patterns.

Override cache-control directives (New in Beta 2)
Manually override the cache-control directives in the response header to change the cache behavior.

Warm up cache node (New in Beta 2)
Proactively warm up your cache node with contents that will be in demand before they are requested.

Intelligent byte-range support
ARR converts the byte-range request into manageable segments to increase cache hit/miss ratio without sacrificing response time.

Intelligent live request support (New in Beta 2)
ARR is designed to work with Live Smooth Streaming to support live content requests without over-loading the live streaming server.

Caching while serving response
Caching large content, such as a movie clip, may take some time. ARR Version 2 Beta 2 is capable of caching the content while serving the response immediately.

Support:

· Support for the beta release is available only on the forum.

Microsoft Application Request Routing (ARR) Version 2 for IIS7 Beta 1 has been released.

wonyoo — Wed, 18 Mar 2009 18:01:00 GMT

Following the ARRv1 RTW release last month, the ARR team has released ARRv2 Beta1 release today. (The "official" announcement can be found here.)

ARRv2 is an incremental release that has all the features of ARRv1, but we added a support for disk cache. What is really exciting about this feature is that now we can start thinking about using ARR as a cache proxy. (Read about the disk cache feature here.) Also, we have added support for CARP (Cache Array Routing Protocol) and cache hierarchy management that will enable customers to build a network of ARR cache nodes in CDN (Content Delivery Network)/ECN (Edge Cache Network).

You can learn more about ARRv2 Beta 1 here.

Downloads:

Microsoft Application Request Routing Version 2 for IIS 7.0 Beta 1 (x86) here.
Microsoft Application Request Routing Version 2 for IIS 7.0 Beta 1 (x64) here.

Support:

For Beta releases, the support is provided via this forum. It is also a great place to ask for feature requests as we are currently working on Beta2.

Benefits of host name affinity provider in ARRv1 RTW

wonyoo — Tue, 24 Feb 2009 01:51:00 GMT

As you know, ARRv1 has RTW'ed last week.

Download the RTW release from:

One of the features that we have added between ARRv1 RC and ARRv1 RTW is host name affinity provider. This feature is used only when host name affinity is enabled in shared hosting scenarios. The feature is located at Server Farm -> Server Affinity -> Host Name Affinity:

There are two providers that are available out of the box:

Microsoft.Web.Arr.HostNameRoundRobin
Microsoft.Web.Arr.HostNameMemory

They are all documented in the walkthroughs (How to configure Microsoft.Web.Arr.HostNameMemory is here.) and online help so I won't repeat what they are in this blog.

What I would like to share are some of the findings and the benefits of these providers.

ARRv1 RC:

In ARRv1 RC, without the providers, the host name affinity decision was made using the same load balance algorithm that was selected for the server farm. In our environment, where we have 4 application servers behind ARR, below is what we have seen:

Above graph is showing the available memory on each of the 4 servers in the server farm and as you can see, they are not evenly distributed. This is because the load balance algorithms are largely based on the number and size of requests/responses and the responsiveness of the servers. More explicitly, they do not take the memory consumption as a decision point.

This is not ideal, especially in a shared hosting environment, where 100's or even1000's of sites are competing for the same resources on the shared server. With running ASP.NET application, we also know that the application servers are memory bound.

In order to address this challenge, in ARRv1 RTW, we have introduced the two providers mentioned above.

ARRv1 RTW: Microsoft.Web.Arr.HostNameRoundRobin

Microsoft.Web.Arr.HostNameRoundRobin tries to evenly distribute the number of affinitized servers, but it still does not take the memory consumption as a decision point. Using Microsoft.Web.Arr.HostNameRoundRobin provider, we have seen a dramatic change in the distribution of active worker processes:

Note the difference between before and after.

However, it still didn't result in an even distribution of memory consumption on the application servers:

It is a good improvement, but we can do better.

ARRv1 RTW: Microsoft.Web.Arr.HostNameMemory

Microsoft.Web.Arr.HostNameMemory provider queries the memory utilization of the application servers in the server farm using WMI (Refer to this walkthrough for details on how to configure Microsoft.Web.Arr.HostNameMemory).

Using Microsoft.Web.Arr.HostNameMemory, the number of affinitized servers are not as evenly distributed as Microsoft.Web.Arr.HostNameRoundRobin:

However, the memory utilization across the application server is evenly distributed:

Since Microsoft.Web.Arr.HostNameMemory provider relies on WMI, it is true that the application servers in the server farm must be Windows. Also, the configuration of Microsoft.Web.Arr.HostNameMemory provider is more involved than that of Microsoft.Web.Arr.HostNameRoundRobin.

Having said above, there are other great use cases for ARR. For this and other great features of ARR, checkout the RTW release at http://www.iis.net/extensions/ApplicationRequestRouting.

The Microsoft Application Request Routing (ARR) Version 1 for IIS7 has been released to web (RTW).

wonyoo — Mon, 16 Feb 2009 23:41:00 GMT

This is the official release for ARR Version 1 for IIS7 and it is now fully supported by Microsoft Support.

Overview:ARR Version 1 for IIS7 is a proxy based routing module that forwards HTTP requests to content servers based on HTTP headers and server variables, and load balance algorithms. It is designed for web server administrators and hosting providers and to increase Web application reliability and scalability. ARR also enables shared hosters to maximize resource utilization on application servers and reduce management costs for server farms.

Balance web requests more efficiently across servers to maximize resource utilization.
Increase Security and Scalability of Application Servers.
Optimize and scale server capacity through client and host name affinity.

Download the RTW release from:

What’s new in RTW:

Host name affinity providers: Optimize and manage how to affinitize host names.

Round Robin provider.
Memory based provider.

Contextual online help: Targeted help contents.
Manual override of health status: Web server administrators can manually override the results from URL and live traffic tests.
Specify port numbers on application servers: Using the UI, HTTP and HTTPS ports can be defined for application servers.
Improved least response time load balance algorithm.
Support readiness: Support is provided by Microsoft Support.

Documentation:

Install Application Request Routing
Define and Configure an Application Request Routing Server Group
HTTP Load Balancing using Application Request Routing
- Includes using health monitoring and client affinity
Configure 3-tier deployment architecture using Application Request Routing
Pilot Program Management using Application Request Routing
Shared Hosting using Application Request Routing
- Memory based provider
- Using Microsoft External Cache for IIS7
Using Failed Request Tracing Rules to Troubleshoot Application Request Routing
High availability at ARR tier
- ARR and NLB
- ARR and Hardware Load Balancer

Support:

The support is now provided by Microsoft Support.
The existing ARR forum will continue to exist and the product team will continue to moderate the forum.

Meaning of "minimum servers" in Application Request Routing

wonyoo — Mon, 26 Jan 2009 23:17:00 GMT

The product team is currently working on ARRv1 RTW and online help, in addition to the walkthroughs, will be part of this release effort.

That said, it has come to my attention that the "minimum servers" (available on Health Test page) has not been documented very well. (More info on ARR is here. You can also download x86 ARR here and x64 ARR here.)

As you know, one of the goals of ARR is to provide high availability among application servers. ARR achieves this by 1) monitoring the health of the application servers and 2) forwarding requests only to the healthy servers. Sounds simple enough, but it is actually a bit more complicated than that. Let's suppose that you have 10 application servers in a server farm where ARR is responsible for load balancing the requests. Given your traffic load, let's also suppose that you need at least 5 healthy servers at any given time in order to sufficiently handle the normal amount of traffic.

In a such environment, if 2 of the servers become unhealthy, there is no real impact on your environment because you still have 8 healthy servers that can handle the traffic. However, what happens if you have less than 5 healthy servers, say only 3 servers are healthy? What is the desired behavior? Given that you need at minimum 5 healthy servers to service the normal amount of traffic, having only 3 healthy servers isn't sufficient. I am over simplifying the problem but largely, there are one of the two outcomes:

Honor the health of application servers and send all requests to 3 healthy servers. In this case, you are overloading the 3 remaining healthy servers and most, if not all, of your end users will have bad experiences. Also, depending on the resiliency of the application servers, the experience may get even worse over time.
Disregard the health of application servers and load balance as usual. In this case, some requests are being routed to the healthy servers and some are being routed to unhealthy servers, based on the load balance algorithm. While is is not ideal, this is a better alternative than the first because only some of your end users will have bad experiences.

In order to address such situations, ARR has introduced the concept of "minimum servers" which represents the minimum number of healthy servers that you must have in your environment before it starts to disregard the health of the application servers to provide services to some end users without bringing down the entire service. In above example, the "minimum servers" value would be set to 5.

Application Request Routing Release Candidate (RC) has been released

wonyoo — Fri, 14 Nov 2008 02:08:00 GMT

Today, IIS team has made the Application Request Routing (ARR) RC for IIS 7 available for download. This is the last major milestone release before the Release To Web (RTW) release. In addition to the feature improvements based on customer feedback, this release has been tested for stability and performance. As such, it has the quality level suitable for production deployment. During the RC period, the support will continue to be provided via the ARR forum.

Download the RC release:

What's new in RC?

Shared hosting and elastic scalability: Ability to specify different number of servers to utilize per host name. Increase and decrease the number of servers in real-time.
Host name affinity routing table: View where requests have been routed based on server name and host name.
High availability at ARR tier: Make ARR tier fault tolerant using hardware load balancers and NLB.
State management using Microsoft External Cache for IIS 7.0: Leverage External Cache to share runtime state between multiple ARR servers.
New and improved UI: Better usability based on Web farm framework.
APIs for monitoring and managing ARR: ARR programmability.
Kernel caching: Achieve higher throughput by caching static contents.
UI integration with URL rewrite: Tighter user experience between ARR and URL rewrite.

Documentation

All the documentations have been updated accordingly for the RC release. Start from the TOC.

Support

During RC, the support will continue to be provided via the ARR forum.

Video walk-through for Application Request Routing (ARR)

wonyoo — Mon, 29 Sep 2008 04:05:00 GMT

A couple of weeks ago, I put together a video walk-through of Application Request Routing.

The video is about 45 minutes long and it highlights the key features and scenarios that were included in CTP1 release which can be downloaded from:

Application Request Routing x86

Application Request Routing x64

If you have further comments, questions, or suggestions, please feel free to use the forum.

Thanks.

Relationship between Application Request Routing and URL Rewrite modules

wonyoo — Sun, 27 Jul 2008 05:34:00 GMT

As most of you know by now, Application Request Routing (ARR) CTP1 was released in early July. (Download x86 here and x64 here. Support is available via this forum.) ARR relies on the URL Rewrite module for inspecting the incoming HTTP requests and making the routing decisions based on the rewrite rules. These two modules work together via an extensibility point in ARR and the same extensibility can be used for routing HTTP requests via other routing logic.

First, let me explain how ARR works with URL Rewrite module. As the diagram below illustrates, both the URL Rewrite module and the ARR are invoked in the same request pipeline. The key point to note is that the URL Rewrite module subscribes to a notification that comes before ARR.

So as the request is being processed through the pipeline, URL Rewrite is applied first. It inspects the HTTP request and tries to apply the rewrite rules and conditions. If the rules for ARR match the request, then it calls a setURL API to rewrite the URL with the server group name as the destination (ie. http://<server group name>/{R:1}) As the rewritten URL makes its way through the pipeline, ARR is applied next. ARR detects that the rewritten URL matches the server group name that has been defined. Given what ARR knows about the server group, it applies the settings, including a load balance algorithm, for the server group and routes the request to one of the content servers defined in the server group.

That said, ARR relies on an external module to determine which server group to route the HTTP requests to. The URL Rewrite module is one such external module that can be used to determine the destination server group based on URL rewrite rules. Other modules can be written, for example, to route the HTTP requests based on the user profile or geo approximity to the requested content resources. Below is an example of how requests from a user may be routed to an appropriate OWA (Outlook Web Access) server based on where the user's mailbox is located:

ARR is a native module, but the external module that determines the server group can either be a native module or a managed module, thanks to the integrated pipeline in IIS 7.

SSL off-loading in Application Request Routing

wonyoo — Fri, 11 Jul 2008 05:01:00 GMT

One of the features that has not been called out explicitly in Application Request Routing (ARR) documentations is SSL off-loading. This is a feature in which the communications between the clients and the ARR server are done via SSL while the communications between the ARR server and the content servers are done via clear text. In this scenario, SSL is terminated at the ARR server.

This feature is designed to better utilize the resources on the content servers. The task of decrypting and encrypting SSL requests and responses is "off-loaded" to the ARR server and the cycles saved by not performing such task can be spent on process additional user requests.

So, how do you configure SSL off-loading in ARR? We will work on enhancing the user experience in later releases, but in CTP1, here is how you can do it. As you may know, ARR relies on URL Rewrite module to inspect the incoming requests and determine which server group to route the requests based on the rewrite rules. Given this, in order to route all traffic to the server group via HTTP, you can simply state this in the URL Rewrite module UI as shown below:

In some cases, though, you may not want to use SSL off-loading. One such example would be if the applications on the content servers expect certain communications to be requested via SSL. (If this is true, in most cases, appropriate changes are made to the applications so that SSL off-loading can be used. For example, Windows Live ID - formally Passport ID - has specific APIs for enabling SSL off-loading. However, this may not be possible in all situations. For instance, it is possible that the deployment schedule of ARR is not aligned with the deployment schedule of the updated applications.)

In such situations, ARR can be configured so that SSL off-loading is not used. Note, though, that ARR does not support CONNECT tunneling. The SSL is still terminated at the ARR server, but the ARR server can be configured so that it will make SSL connections with the content servers. To do this, you will need to write two rules in the URL Rewrite module.

First, we are going to determine if the request is made via SSL. If so, it will forward the request to the content server via SSL:

Note that the Stop processing of subsequent rules check box is selected.

Secondly, we are going to route the remaining requests via HTTP:

In either of the two cases above, appropriate server certificate must be imported on the ARR server. In the SSL off-loading case, however, the server cerficiate does not need to be imported on the content servers. In the second case where the SSL off-loading is not used, the server certificate must be imported on all of the content servers.