New features in ARR (Application Request Routing) 3.0
Technorati Tags: IIS News Item
Introduction
Application Request Routing (ARR) is a proxy-based routing module that uses HTTP headers, server variables, and load balance algorithms to determine how to forward HTTP requests to content servers. The release of ARR 3.0 in July 2013 contains a few new features, as well as bug fixes. The following information describes the new features and how to use them, as well as general information about ARR 3.0
Support matrix
ARR 3.0 was tested and is supported on Windows Server 2008, 2008 R2, 2012 and 2012 R2. It’s available in an X86 version for Windows Server 2008, and an X64 version, which is supported on all the above platforms.
Installation
Microsoft recommends ARR to be install from within the Web Platform Installer module (WebPI). To install from WebPI, type ARR in the search box, and click the appropriate item to install it.
It’s also possible to install ARR by downloading the MSI package, but please note that installing it directly requires the administrator to perform several steps in a specific order (normally, WebPI manages that automatically). These steps are:
1. Stop IIS by running the commands net stop was and net stop wmsvc on an elevated command-prompt window
2. Install URL rewrite (v2)
3. Install Web Farm Framework (v1)
4. Install ARR (v3)
5. Install the External Cache module (v1)
6. Start the IIS services back, or reboot the server.
To download the ARR MSI, visit this page. To download the MSI for the other pieces, visit this page.
New features
ARR 3.0 was released in Beta in December of 2012, and included the following new features:
· Retries for URL Health Monitoring
· Web Socket Support
The final version (July 2013) also adds support for Session affinity opt-out. Here are the details about these features.
Retries for URL Health Monitoring
As part of normal farm management, ARR performs health-test for configured web servers, so that if a server in the farm becomes unavailable, ARR would not forward requests to it. Before version 3, health monitoring would mark a server as unavailable if it fails to respond a single time. This may impact availability in certain situations, because intermittent network or application errors could lead to a server being marked as unavailable when in fact it was.
To address that, health-monitoring can now be configured by the administrator to retry, and conclude that the server is unavailable only after a defined retry-count. By default, Health-monitoring will retry the check 3 times, and the administrator can change the value to a different one by editing the configuration in ApplicationHost.config.
<element name="healthCheck"> <attribute name="url" type="string"/> <attribute name="retries" type="uint" defaultValue="3" validationParameter="0,20" /> .. </element> |
The following article describes additional parameters that can be configured as part of health monitoring: https://blogs.iis.net/richma/archive/2010/12/14/application-request-routing-health-check-features.aspx
WebSocket Support
With the release of Windows Server 2012, IIS added support for using WebSockets. Since WebSockets requires special handling by proxies, ARR needed some changes to be able to support this feature. This allows ARR to distinguish between a regular HTTP request and a WebSockets request, and handle them correctly.
WebSocket support requires the WebSocket feature to be installed on IIS, but does not require any other configuration or action. Install the feature using the Server Manager Add Roles and Features, and once that is complete, ARR 3.0 will handle the requests appropriately. The new feature supports both plain (ws://) and secure WebSocket (wss://) requests and it can also provide SSL offloading for WSS requests.
Session affinity opt-out
An important part of load balancing is maintaining affinity. Maintaining affinity means that once ARR routes a request to a server, subsequent requests from the same client that are a part of the same session should go to the same server. To maintain affinity, ARR attaches a unique affinity session cookie to each new session, with the selected server stored in the cookie. Once a subsequent request from the same client arrives, ARR decodes the cookie, extracts the server name, and knows to route that request to the same server. Similar methods are employed by all commercial reverse proxies. Here’s an example of such a cookie:
The challenge with this mechanism is that a session cookie can exist indefinitely, and so if the client’s browser remains open, it will continue serving back the affinity cookie, and be continuously redirected to that same server. In an environment where many clients keep their browsers open for extended period of time, this could, over time, lead to an imbalance in client distribution.
To address this, ARR 3.0 allows web applications to opt-out of session affinity. To do this, an application would need to set a special response-header that signals to ARR to disable affinity for the application.
The special response header is Arr-Disable-Session-Affinity and the application would set the value of the header to be either True or False. If the value of the header is true, ARR would not set the affinity cookie when responding to the client request. In such a situation, subsequent requests from the client would not have the affinity cookie in them, and so ARR would route that request to the backend servers based on the load balance algorithm. Note that this behavior could have serious impact on session-sensitive application, so enabling this on a web application must be considered carefully.
Troubleshooting
To help troubleshoot potential issues, FREB (Failed Requests Tracing – formerly known as Failed Request Event Buffering) has specific events for WebSocket requests. The WebSocket protocol mandates that when a WebSocket connection is initiated by a client, the accepting server should reply with a 101 status code, along with a Sec-WebSocket-Accept key. In the event a connection is accepted, IIS’s WebSocket module will raise a FREB event titled WEBSOCKET_HANDSHAKE_SUCCESS. If there is a problem, a failed event will be raised. By setting the appropriate filters in FREB, you can capture and examine these events:
When enabling FREB, keep in mind that setting a trace for success-type events (such as 101 and 200 status codes) on a production server would result in a large number of events, which could increase the load on the server to unacceptable levels, and is therefore not recommended.
In addition, new performance counters that are specific for WebSockets have been added to Windows, and they are under the W3SVC_W3WP group in PerfMon:
Blog post by Erez Benari and Jenny Lawrance