The following drawings illustrate client request handling in an NLB cluster. In the first scenario (Figure 5.7), session state (coherency) is not maintained; in the second scenario (Figure 5.8), session state is maintained.
In this scenario, the client request is sent to the cluster IP address—seen by the client as a single host—and NLB routes the request to the appropriate host based on the load-balancing algorithm that's in use.
Figure 5.7 Client request handling on a load-balanced cluster without session coherency
The processing steps for handling this type of client request are as follows:
This scenario is similar to the preceding one in that the client request is sent to the cluster IP address—seen by the client as a single host—and NLB routes the request to the appropriate host based on the load-balancing algorithm that's in use. However, the client request originates from a proxy server environment, so it's necessary to use the HTTP request forwarder to maintain session coherency and track which server handled the first client request. The next illustration, Figure 5.8, shows how two requests from the same client are handled by Application Center. The upper part of the drawing ("First Pass") shows how the first request is handled, and the lower part of the drawing ("Second Pass") shows how the second—and how a subsequent request that was balanced to a different server—would be processed by using request forwarding.
The processing steps for handling this type of client request during the first pass are as follows:
NOTE
At this point, the member that's designated to handle the request determines whether or not request forwarding is required. If it is, the member checks to see if session coherency is enabled. Among the other checks made at this point are: the nature of the request (for example, an ASP session or FrontPage publishing), whether the requested page is one of the files that should not be forwarded, and whether a cookie needs to be generated. If required, the member creates a routing cookie that contains information that uniquely identifies the server that owns the sticky client session.
Figure 5.8 Client request handling on a load-balanced cluster with session coherency
The processing steps for handling a client request during the second pass are as follows:
NOTE
A new cookie may be created if a request arrives that doesn't have its sticky flag enabled or if the routing information points to an invalid target.If the member specified in the cookie is out of service or offline, the request is handled locally. The original ASP session information is removed from the cookie and changed to reflect the new sticky server.
The preceding steps provide a simple summary of the process that takes place when session coherency is enabled and the HTTP request forwarder is used.