Request Handling Examples in a Network Load Balancing Cluster

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.

Stateless Session

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

Processing Activities and Their Sequence

The processing steps for handling this type of client request are as follows:

1. A client sends a request to the Web site, http://samples.microsoft.com, which has a cluster IP address of 207.46.130.30.
2. All of the members hear the incoming request and resolve its destination according to the cluster's load-balancing algorithm, which is based partially on NLB client affinity.
3. Server A, designated as the target, picks up the client request.
4. Server A resolves the client request, and then returns the requested item to the client.

Stateful Session

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.

Processing Activities and Their Sequence

The processing steps for handling this type of client request during the first pass are as follows:

1. A client sends a request to the Web site (http://samples.microsoft.com ), with the cluster IP address of 207.46.130.30 to the proxy server farm. The request is handled by Proxy 2, which gives the request an originating address of 207.46.130.14
2. Proxy server 2 sends the request to the Application Center cluster.
3. All of the members hear the incoming request and resolve the request based on the load-balancing algorithm, which is determined partially by the cluster's NLB client affinity. Server A picks up the client request.
4. The request forwarder on Server A determines if a cookie is required and, if so, creates one for the session.

   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.

5. Server A sends the cookie and the requested page to the proxy server that initiated the request, Proxy 2.
6. Proxy 2 sends the requested page and cookie to the client.

   

   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:

1. The client sends a request that's handled by the server Proxy Server.
2. Proxy 1 assigns an originating IP address of 207.46.130.45 to the request, and then sends the request to the cluster.
3. The members resolve the request based on the load-balancing algorithm, which is determined by the cluster's NLB client affinity. This time, Server B picks up the client request.
4. Server B determines that the requested file is dynamic and checks for a cookie in the request header. Based on the cookie information, Server A is identified as the target for the request. The request forwarder sends the request to Server A over the back-end network.

   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.

5. Server A prepares the response, which is then pipelined by the request forwarder to Server B.
6. Server B passes the requested page to Proxy 1.
7. Proxy 1 sends the response to the client.

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.