8.3 How NLB Works

---

Normally, the Application Center Wizard would be used to set up and con- figure NLB. Each member server must have at least two network adapters; one of which looks after client communication, while the other handles communications inside the cluster group.

Incoming client requests for TCP and UDP protocols, such as HTTP, are distributed across the cluster members using a software-based load- balancing mechanism. Member servers send an NLB exchange message over the load-balancing adapters about every second; this is used to coordinate actions between the cluster members. Any failure of these message exchanges will cause up to five retry attempts, after which any nonresponsive servers force Application Center to assume a server is not available. The workload is then distributed across the servers Application Center has had a response from, and any nonactive servers are automatically excluded from further work.

By default all member servers receive the workload coming into the cluster, but an algorithm decides which server actually processes the request, with the other servers discarding the workload. This architecture is actually faster than presorting the work for one server to undertake.

Affinity

A problem often found with load balancing is that of affinity. By definition the Web is a disconnected environment, so session state is often managed by the Web server. This is all very well when the client knows that it will be returning to the same server each time another HTTP round trip is made, but with load balancing this level of affinity needs to be explicitly managed since the client can return to any of the cluster servers, potentially losing session state.

NLB comes with three types of client affinity to preserve the all important session state information. These are as follows:

• None-Multiple requests from a client can access any member server in the cluster. This provides the best level of performance but will probably disrupt clients with established sessions, since any further requests will often hit other cluster server members that do not have the session information.

• Single-Multiple requests from a client must access the same member. NLB will use the client's IP address to ensure that subsequent responses are dealt with by the original cluster server member.

• Class C-Multiple requests from the same TCP/IP class C address range must access the same cluster server member. This is normally utilized when using NLB to serve an Internet Web site.

---