Distributing Network Load

You can set up an NLB (Network Load Balancing) cluster using

Win 2k Advanced Server. This can be scaled up to 32 nodes, depending on the

amount of traffic (for more on NLB, see the previous article "Cluster and

Reduce Network Downtime"). Here, we’ll show you how to set up a simple

two-node cluster using NLB.

You don’t need any special hardware to set up NLB. It gets

installed with Advanced Server. You could set it up with one or two network

cards in each node. With two network cards, one can be part of the cluster,

while the second can be used to handle traffic directed specifically to the

server. We used a single network adapter configuration.

When you create the NLB cluster, all nodes in it act as one

entity to the outside world. Therefore, a cluster name–like

cluster.pcqlabs.com, and cluster IP address–we chose 192.168.1.100, must be

selected. All machines outside this cluster will then access the cluster using

this name.

NLB is not enabled by default. So, go to the Network

Neighborhood Properties of a server and select the network segment that’ll

become part of the cluster. Go to its Properties, and you’ll see the NLB

option with a checkbox. Click the checkbox to enable it. You must also give each

node in the cluster a unique IP address. Administrators could use this IP

address to manage individual nodes. Open TCP/IP properties and give your network

card an IP address. Next, open Advanced TCP/IP properties, and add the IP

address you chose for your cluster.

Next, go to NLB properties. There are three tabs here that

must be configured–cluster parameters, host parameters, and port rules. Under

Cluster Parameters, enter the cluster’s IP address in the "Primary IP

Address" field, and subnet mask in the subnet mask field. If you’re using

a single network adapter, be sure to enable multicast. This gives your network

card another MAC (Media Access Control) address, in addition to the one it

already has. The new MAC address is used for cluster access, while the original

one can be used to access the individual node. This helps improve cluster

communication.

The remote password is for restricting access to the cluster

from remote computers–you can use this for remote administration of your

cluster.

In Host Parameters, assign each node its unique host ID, or

priority. This ID is used to prioritize incoming network traffic. If this node

is given priority one, all incoming traffic that hasn’t already been assigned

to other nodes by port rules (explained later) will come to this node by

default. Similarly, you can assign IDs to other nodes in the cluster. So a node

with priority ID of two will take over if the node with ID one fails. In case

you want this node to join the cluster as soon as it’s rebooted, check the

"Initial cluster state" option. You must also enter the node’s own

IP address and subnet mask here.

Port Rules decide how incoming traffic will be distributed

between nodes. You must define these rules properly to balance load between all

nodes. Let’s take an example here to make things clearer.

Suppose you have a two-node cluster, and you want to split

all incoming FTP requests equally between the two (see above screenshot). To do

this, you must first know the port number on which FTP works (each protocol in

the TCP/IP stack communicates through a specific port number by default–for

example, HTTP is on port 80, FTP on port 21, Telnet on 110, etc). So, first

define the port range as 21 to 21 for FTP. Next, specify the kind of incoming

packets to which this rule would be applied. The option is to either handle TCP

or UDP, or both kinds of packets. We chose TCP only.

Next, choose the filtering mode for all incoming FTP packets.

Here, you have to decide whether single or multiple hosts will handle the

traffic. As we want the FTP load to be split equally between the two cluster

nodes, we’ll choose multiple hosts.

An option called Affinity–which refers to how incoming

requests will be distributed among nodes–can be set to None, Single, or Class

C. If you choose Single, all requests coming from one particular client will be

handled by only one node in the cluster. So for example, if someone sends

multiple FTP requests to the cluster from the same client, all of them will

automatically go to only one node. If the Affinity is set to Class C, one node

in the cluster will handle requests coming from all clients having class C IP

addresses. If Affinity is set to none, all incoming requests get distributed

among the nodes in the cluster.

There’s an option to set the Load Weight here as well. If

this is set to equal, then all incoming requests will be distributed equally

amongst the nodes. So for example, if we send four FTP requests from a client,

they’ll be equally distributed between the two nodes that we’ve set up in

the cluster.

We chose Affinity as None, and Load Weight as equal. After

that, we started four FTP sessions with the cluster from the same client. When

we opened the FTP User Sessions Log in IIS–which was set up on each node in

the cluster, we saw that two were handled by the first node, and the other two

were handled by the second node.

So, port rules must be carefully set depending on what you

want. A word of caution here–port rules must be the same on all nodes in a

cluster. If there’s a node with a different set of rules, it will be unable to

join the cluster.

There’s also a command line utility called wlbs.exe, which

you can run to find out the state of the cluster, error messages, logs, etc. It

can also be used to stop, start or remotely administer a cluster.

Anuj Jain