Load balancing and client affinity

In many scenarios, for load balancing to be effective, affinity must be maintained between the client and the Web server that receives and responds to the client's request. Otherwise, a series of requests from the client and responses from the Web farm will be handled by different Web servers, ignoring the context of the requests. For example, Outlook Web Access is an application that requires client affinity, because the Outlook Web Access server maintains a context for the connected client.

The need for affinity is also demonstrated in a Web shopping scenario, where a client sets up a shopping cart on a Web server. If affinity is not maintained, at some point in the client's session, the client's requests may be directed to another Web server that is unaware of the shopping cart.

Types of client affinity

• Session affinity
• IP address-based affinity

Session affinity

Session affinity uses a cookie to identify the client and to maintain its affinity with a specific Web server. This function requires a browser that can accept HTTP cookies. Cookies are supported by all HTTP 1.1-compliant browsers and by some versions of HTTP 1.0 browsers. Session affinity is maintained until the browser is closed on the client computer.

When session affinity is used, if a Web server, such as Web Server 1, goes out of service, the clients that are associated with it will be directed by ISA Server to another server, such as Web Server 2. The context of the Web session is lost when this happens. When Web Server 1 becomes available again, client affinity is maintained with Web Server 2 until the session ends. The session ends when the client closes the browser. With session-based affinity, the restarting of the server does not result in a second loss of affinity.

We recommend that you use session affinity when possible, because it provides more reliable client affinity when a Web server is restarted. This is sometimes referred to as client stickiness. It also works better in a situation where you are draining a Web server.

We recommend that you use session affinity for load balancing Outlook Web Access or Windows SharePoint Services access, both of which use Internet Explorer, and therefore support HTTP cookies.

IP address-based affinity

When you use IP address-based affinity, when ISA Server receives a request, it determines which Web server in the farm should handle it, based on the client's IP address. Every request from that IP address will be sent to the same Web server, so affinity is maintained.

When IP address-based affinity is used, if a Web server goes out of service, the clients that are associated with it will be directed by ISA Server to another server. The context of the Web session is lost when this happens. Similarly, when that Web server is restarted, those clients' requests are redirected to the original Web server, and the context is lost again.

IP address-based affinity has an advantage over session affinity in that it supports clients that are not fully compliant with HTTP 1.1 (clients that do not support HTTP cookies), such as some mobile devices.

IP address-based affinity must also be used in a scenario where you are load balancing RPC over HTTP Outlook access. Outlook does not work with HTTP cookies, and therefore cannot use session affinity.

Notes

• When the client computers are behind a network address translation (NAT) device, IP address affinity does not work because the NAT device replaces the client's IP address with a different IP address, and only that address is seen by ISA Server.
• If you are publishing a server farm with ISA Server 2006 located behind another firewall, you must either use session affinity, or use IP address affinity and verify that the front-end firewall is configured to pass the original client's IP address to ISA Server.

---

Get latest ISA Server content at ISA Server Guidance. Send feedback about this page.

• English-to-Russian translation