Step-by-step configuration of NLB (continued) in-depth testing

Here http://blog.csdn.net/haoxiaozigang1/article/details/12198679 to share with you the NLB configuration process, and below are some of the results of the following tests for different scenarios of NLB:

First, prepare some tools:

1. Fiddler2, to see the allocation of the request, of course, the tool has other powerful features, today, we only use a small function;

2.Web performance Test1.0, used to send concurrent requests, put pressure on the server, can be http://www.cnblogs.com/smark/archive/2013/05/16/3081606.html here to download.

Second, let's look at the settings for the port rules inside NLB:

A. Right-click Clustering--cluster properties

B. Opening the Port Rule Properties dialog box

The following is an explanation of the individual properties:

Cluster IP Address: Specifies the cluster IP to which the rule is directed
Port range: default is all, you can specify the port range that the cluster listens to (for example, from 80 to 80, which means load balancing is only for Web services)
protocol: Specifies the type of protocol that the cluster serves
Filter Mode:

A: Multiple hosts:  
        I no Similarity (none) : The client's service requests are evenly distributed to every server within the cluster. Assume that there are 2 servers in the NLB cluster. When the request to the client, NLB will be the 1th request to the 1th server to process, the 2nd request to the 2nd server processing, 3rd requests to the 1th server to process, ... And so on Because all client-side opportunities are evenly distributed to each server, optimal load balancing can be achieved. If transaction processing is required, in order to be able to share the session state, the session state must be centrally stored in the states or database server, which is suitable for most applications.  
        ii single similarity: The client's service request is pinned to one of the servers in the cluster. When a request is received from a client, NLB decides which server to process according to the client's IP, that is, a server will only process requests from certain IPs. Because a service request for an IP is only fixed by one server, there is no problem with session state sharing, but it can cause load imbalance. This method is suitable for online communication protocols (such as FTP and PPTP) that need to support SSL set multiple online  
        III Network (Class C): depends on the IP's Class C shield to decide which server to handle, that is, a server will only process requests from certain network segment c. This approach ensures that clients that use multiple proxies can be directed to the same server.  
B. Single host: If you select this option, all requests within that port range will be handled by a single host, which will be used with the host's priority for subsequent hosts to determine. &NBSP
C. Disable this port range: Generally this option is set in the port exception, that is, when we specify a larger range port, there is one or several ports we do not need the client user access to, At this point we will use this rule to set up to prevent users from accessing this port request.

One of the more key parameters is the filter mode, may look after some puzzling, especially the third Kind of network (class C), I really do not know what is meant to have a friend to share with me.

Today, we only focus on the first two, none and single, these two good understanding, none is the server will be the request evenly allocated to each node node, take the example of a section, that is NLB2 and NLB3 will receive;

Single, the server will send the request to a node, either the node is down or overloaded, will be transferred to other nodes, or will be centralized on a node processing.

OK, now that the preparation is done, start our load test journey:

Scenario One:

Multiple hosts, single similarity, load equal, i.e. 50% each.

Prediction result: All requests are processed by the same node.

1. Set the load amount for each node to equal.

A. Right-NLB2 node---host properties--port rules----load volume selection equal.

2. Open Fiddler2, clear the left side of the session record, in order to easily view the results, it is best to close all browsers, because Fiddler2 will catch all HTTP requests.

3. Configure the Web performance Test1.0, about the use of this tool, you can learn on the download site, my configuration is as follows,

4. Click "Test";

5. View the Fiddler2 as follows:

6. Analyze the call results, from what we see, the request is the same, how do we know whether it is NLB2 or NLB3 processing it?

From the previous section, we can see that their return values are different, so we use this to filter them, we need to use the Fiddler search function, click on the "Find" button on the toolbar, search NLB2, will see is NLB2 return, This is NLB automatically directs all requests to the same server to be processed, consistent with the predicted results:

Scenario Two:

Multiple hosts, no similarity, equal load.

Forecast result: The average processing request for the node.

1. Set the cluster similarity to none.

A. Right-click Cluster properties and switch to port rule entry

B. Click "Edit ..."--similarity (Affinity) None (None), OK.

C. Set the load per node to 50%.

D. Clear the Fiddler2 session list, click the Web Performance Test1.0 Test button, after completion, find NLB2 in Fiddler2, the result is as follows:

We see that the distribution of the request is fairly uniform and consistent with the predicted results.

Scenario Three:

Multiple hosts, no similarity, NLB3 node load 30%,nlb2 node 70%.

Forecast results: 70% requests are processed by NLB2.

1. Modify NLB2 to 70%;

2. Modify the NLB3 load of 30%, the operation as above.

3. Clear the Fiddler2 session list, perform the stress test, after the Fiddler2 inside find NLB3, the results are as follows:

We saw that most of the requests were NLB2 processed, consistent with the predictions.

Scene Four:

Single host

Forecast result: All requests are handled by high priority NLB3 nodes.

1. Set the filter mode for the cluster's port rule to single host.

2. Perform the test, after, then Fiddler2 inside find NLB3, the result is as follows:

We see that all requests are NLB3 processed, consistent with the predicted results.

Step-by-step configuration of NLB (continued) in-depth testing