Partager via

Support for Sessions

  • Article

Applies To: Windows Server 2003 with SP1

Q. Does NLB Support Sticky Sessions?

A. NLB supports limited forms of session stickiness:

  • Single Affinity. When Single affinity is enabled, the clients port number isn’t used and the mapping algorithm uses the clients full IP address to determine load distribution. As a result, all requests from the same client always map to the same host within the cluster. Because there is no time-out value (typical of dispatcher-based implementations), this condition persists until cluster membership changes. However, session stickiness may not be preserved if the cluster membership changes, in particular when a new host is added to the cluster, or a host is re-added after being temporarily out of service.

  • Class C Affinity. As in the case of Single affinity, client port numbers are not used to calculate load distribution. When Class C affinity is enabled, the mapping algorithm bases load distribution on the Class C portion (the upper 24 bits) of the clients IP address. As with Single affinity, sessions may not be preserved if the cluster membership changes.

  • IPSec and VPN Sessions. On Windows Server 2003, NLB has specialized support for sticky IPSec and VPN sessions. NLB preserves these sessions even if the cluster membership changes.

NLB cannot track the boundaries of UDP streams, since the logical session boundaries are defined by particular applications. Instead, Network Load Balancing affinity settings are used to assist in preserving client sessions. When a cluster host fails or leaves the cluster, its client connections are always dropped. After a new cluster membership is determined by convergence (see How Does NLB cluster convergence work?), clients that previously mapped to the failed host are remapped across the surviving hosts. All other client sessions are unaffected by the failure and continue to receive uninterrupted service from the cluster. In this manner, Network Load Balancing load balancing algorithm minimizes disruption to clients when a failure occurs.

When a new host joins the cluster, it induces convergence, and a new cluster membership is computed. When convergence completes, a minimal portion of the clients will be remapped to the new host. NLB tracks TCP connections on each host, and, after their current TCP connection completes, the next connection from the affected clients will be handled by the new cluster host; UDP streams are immediately handled by the new cluster host. This can potentially break some client sessions that span multiple connections or comprise UDP streams, or application sessions that span TCP sessions. Hence, hosts should be added to the cluster at times that minimize disruption of sessions. To completely avoid this problem, session state must be managed by the server application so that it can be reconstructed or retrieved from any cluster host. For example, session state can be pushed to a backend database server or stored in client cookies.

Q. How Does Single Affinity Mode Differ From No Affinity Mode? Which One Should I Use to Load Balance My Application?

A. In Single Affinity mode, NLB load balances traffic based only on the Source IP Address of the incoming connection. So, Single Affinity mode ensures that all TCP connections originating from the same client (IP Address) are sent to the same host in the cluster. This will continue indefinitely until a host is either added or removed from the cluster, at which time the connections originating from that IP address may get mapped to a different host in the cluster.

In No Affinity mode, NLB load balances traffic based on Source IP Address and Source Port of the incoming connection request. Therefore, in No Affinity mode, multiple connections from the same client may be handled by different hosts in the cluster as long as these connections have different source ports.

Which mode to use really depends on the application being load balanced. If the application makes use of sessions which persist over multiple TCP connections, NLB should be configured in Single Affinity mode because you want to make sure that all TCP connections which are part of a single session are mapped to the same host in the cluster.

On the other hand, No Affinity allows a better load distribution because it does not require client connections be handled by specific servers. Thus for applications that do not use sessions and for which it is acceptable for multiple incoming connections originating from the same client to be handled by different hosts in the cluster, No Affinity would be a better mode of operation.

Q. If My Clients Use SSL to Connect to My Front-End Web Servers, Can I Still Use NLB to Cluster These Web Servers?

A. Yes. For efficiency reasons, configure the port rule in Single Affinity mode. However, note the following side effects:

  • Load balancing will not be as precise as in No Affinity mode.

  • Sessions can break when hosts are either added to or removed from a cluster. Note that an SSL session will be transparently renegotiated by the protocol.

  • If all of the sessions come through a client-side proxy, you will not see any load balancing since all of the TCP connections will have the same IP Address and they will all be handled by the same computer in the cluster.