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