Please review the following Q&A from the NLB FAQ:
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
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
Q.How Does the NLB Load Balancing Algorithm Work?
A.NLB employs a fully distributed filtering algorithm to map incoming
clients to the cluster hosts. This algorithm enables cluster hosts to
independently and quickly make a load balancing decision for each incoming
packet. It is optimized to deliver statistically even load balance for a
large client population making numerous, relatively small requests, such as
those typically made to Web servers. When the client population is small
and/or the client connections produce widely varying loads on the server,
the load-balancing algorithm is less effective. However, the simplicity and
speed of NLBs algorithm allows it to deliver very high performance,
including both high throughput and low response time, in a wide range of
useful client/server applications. If No Affinity is set, NLB load balances
incoming client requests so as to direct a selected percentage of new
requests to each cluster host; the load percentage for each host is set in
the NLB Properties dialog for each port range to be load balanced. The
algorithm does not dynamically respond to changes in the load on each
cluster host (such as the CPU load or memory usage). However, the load
distribution is modified when the cluster membership changes, and load
percentages are renormalized accordingly.
When inspecting an arriving packet, all hosts simultaneously perform a
mapping to quickly determine which host should handle the packet. The
mapping uses a randomization function that calculates a host priority based
on their IP address, port, and other information. The corresponding host
forwards the packet up the network stack to TCP/IP, and the other cluster
hosts discard it. The mapping remains unchanged unless the membership of
cluster hosts changes, ensuring that a given clients IP address and port
will always map to the same cluster host. However, the particular cluster
host to which the clients IP address and port map cannot be predetermined
since the randomization function takes into account the current and past
clusters membership to minimize remappings.
In general, the quality of load balance is statistically determined by the
number of clients making requests. This behavior is analogous to dice throws
where the number of cluster hosts determines the number of sides of a die,
and the number of client requests corresponds to the number of throws. The
load distribution improves with the number of client requests just as the
fraction of throws of an N-sided die resulting in a given face approaches
1/N with an increasing number of throws. As a rule of thumb, with client
affinity set, there must be at least five times more clients than cluster
hosts to begin to observe even load balance.
The Network Load Balancing client affinity settings are implemented by
modifying the statistical mapping algorithms input data. When client
affinity is selected in the NLB Properties dialog, the clients port
information is not used as part of the mapping. Hence, all requests from the
same client always map to the same host within the cluster. Note that this
constraint has no timeout value and persists until there is a change in
cluster membership. When single affinity is selected, the mapping algorithm
uses the clients full IP address. However, when Class C affinity is
selected, the algorithm uses only the Class C portion (upper 24 bits) of the
clients IP address. This ensures that all clients within the same Class C
address space map to the same cluster host.
Thanks in advance,
Mike Rosado | Microsoft Beta Support Engineer | Cluster Technologies
Hours: 8:00 AM - 5:00 PM Central (GMT-06:00)
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
This posting is provided "AS IS" with no warranties, and confers no rights.
Post by email@example.com
I have an NLB cluster set to no affinity. However I see that one
server in the cluster has anywhere from 60 to 80 connections while the
other has 0 and maybe 1. This doesn't seem quite right to me.
Shouldn't I have approx 30 to 40 per server? How can I fix this to
truly load balance the servers?