NLB cluster management

Three separate utilities can be used for management of an NLB cluster:

♦ The Network Load Balancing properties dialog box in the Network Connection properties for the cluster adapter for each cluster node

♦ The Network Load Balancing Manager, accessible from the Administrative Tools menu

♦ The NLB.EXE command-line utility, located in the %SystemRoot%\System32 folder

Configuration of the NLB properties available from the Network Connection Properties of a cluster adapter has been described earlier. We also have covered using NLB Manager for creating a cluster, adding and removing nodes, and port rule changes. As previously mentioned, this is the recommended way of managing NLB clusters due to its robustness and ease of use (the only exception being running NLB Manager directly from a cluster node configured in unicast mode with a single network adapter). In addition, NLB Manager provides the capability to work with multiple clusters from the same interface (you can add them by selecting the Connect to Existing option from the Cluster menu). Unfortunately, the names of clusters and hosts you connect to are not retained between sessions, so every time you launch NLB Manager, the list of clusters in the top-left window is empty. You can, however, save a list of hosts in a text file (each host name is separated by a line break) and load it the next time you launch the tool. You can do this either by using Save/Load Host List options in the File menu or by typing

NLBMGR /hostlist HostList.txt at the command prompt, where HostList.txt is the file with the line-break-separated host list. This will launch NLB Manager with the connections to these hosts already open.

When using NLB Manager, remember that the interface is not automatically refreshed, so to see the results of changes you applied, you might have to use the Refresh menu option or press the F5 key with the focus on the settings that you want to view (cluster or server).

Regardless of the tool you will be using for cluster management, you need to run it in the security context of an account with the administrative rights to each cluster node. This can be accomplished by logging on with this account, running the secondary logon (RunAs) utility, or, in the case of NLB Manager, setting default credentials (from the Options O Credentials menu option).

The remainder of this section concentrates on using NLB.EXE for cluster management. Although more difficult to use, NLB.EXE has two main advantages: Probably the biggest one is its response time, which is much faster than that of the NLB Manager interface. In addition, NLB can be incorporated into batch files or scripts, enabling the automation of a cluster's administration.

NLB.EXE is the Windows Server 2003 replacement for WLBS.EXE, which is present in previous versions of Network Load Balancing. This name is derived from the Windows Load Balancing Suite, which was an implementation of the network load balancing developed for the Windows NT 4.0 platform. NLB.EXE and WLBS.EXE provide identical functionality. They can be used to configure and monitor an NLB cluster both locally and remotely, although some options are available only locally. In order to administer a cluster remotely, remote control has to be first enabled and a remote control password set. This password needs to be entered with the /PASSW switch for every command executed remotely. The NLB.EXE utility has a standard help option (invoked by running NLB with ? or the help parameter or without any parameters).

There are several ways of referring to cluster nodes when running the NLB command remotely. You can reference an entire cluster by specifying a cluster IP address or full Internet name. If you want to refer to a specific node within a cluster, you can use a notation consisting of a pair of values. The first value is the cluster's name or IP address, followed by the node's host name, IP address, or numerical value equal to host priority ID. A value of 0 designates a default host. In order to be able to use the Internet name of an NLB cluster, you need to create an appropriate host record on your DNS server.

For example, to stop the host USNY-AP001 with an IP address 172.16.0.30 and host priority ID 1, which is a member of a cluster webcenter with an IP address of 172.16.0.200 and a remote control password set to Pa$$w0rd, any of the following can be used:

NLB stop webcenter:usny-ap001 /PASSW Pa$$w0rd NLB stop 172.16.0.200:172.16.0.30 /PASSW Pa$$w0rd NLB stop webcenter:172.16.0.30 /PASSW Pa$$w0rd NLB stop webcenter:1 /PASSW Pa$$w0rd

Following are some sample uses of the NLB.EXE command:

NLB display provides a variety of cluster-related and local-member-related information, such as configuration parameters (including port rules), most recent event log messages, IP configuration of the local host, and cluster state. Unfortunately, the display option can only be used locally. The remaining options operate both locally and remotely, but for remote access you must specify the IP address or the name of the target node and the remote control password.

NLB i p2mac 172.16.0.200

displays unicast and multicast MAC addresses generated for a given IP address. This command is useful when a router has problems processing ARP updates generated by NLB and a static entry needs to be added to a router's ARP cache.

NLB query 172.16.0.200 /PASSW Pa$$w0rd returns the state of the remote cluster. This can be used to verify convergence status. For example, when a cluster node is in the converging state for an extended period of time (convergence should not take more than 10 seconds), this might indicate that its configuration is inconsistent with the other nodes.

NLB start webcenter:usny-ap001 /PASSW Pa$$w0rd starts the remote cluster node usny-ap001 on the cluster webcenter.

NLB start webcenter:usny-ap001 /PASSW Pa$$w0rd starts the remote cluster that was stopped using the previous command.

NLB drainstop webcenter:usny-ap001 /PASSW Pa$$w0rd prevents any new connections to the usny-ap001 node of the webcenter cluster. Once the last existing connection ends, the node is stopped. A draining process can be used to gracefully remove an NLB cluster member. This prevents any new connections from being assigned to the selected server. You can accomplish the same result with the Drainstop option of the Control Host menu of an NLB Manager interface.

NLB drain 172.16.0.200:80 webcenter:usny-ap001 /PASSW Pa$$w0rd prevents any new connections on port 80 of the clustered IP address 172.16.0.200 to the usny-ap001 node of the webcenter cluster. A draining process can be used in order to gracefully stop traffic to a particular port or range of ports on an NLB cluster member. This will stop any new connections on all ports controlled by the port rules that include a port specified by the command. You can accomplish the same result with the Drain option of the Control Host menu of the NLB Manager interface, which operates on a per-port rule basis.

NLB disable 80 webcenter:usny-ap001 /PASSW Pa$$w0rd prevents new requests on port 80 from being accepted by the usny-ap001 node of the webcenter cluster. This can be used to temporarily redirect traffic for a load-balanced Web site to other nodes (e.g., when a current node needs to be reset). Note that this command disables all the rules that include port 80 within their port range, so it might possibly affect other traffic as well (depending on how port rules are set up).

NLB enable 80 webcenter:usny-ap001 /PASSW Pa$$w0rd allows new requests on port 80 of the same cluster node to be accepted (and, possibly, enabling traffic on other ports, depending on the way port rules are set up) by enabling all the port rules that include port 80 in their port ranges.

Both enabling and disabling ports is also possible using the NLB Manager interface, although it is done on a per-rule basis. This truly reflects the way this command operates.

Remember that changes to many configuration options (such as modification of existing port rules, or addition and removal of a cluster node) trigger convergence. Convergence involves a number of actions, depending on cluster settings and the type of change detected. One of the effects is the re-evaluation of the default host's role. Changing the default host affects the distribution of traffic not covered by port rules. Other types of changes, such as modifying the host priority in a single filtering mode or changing the load weight values in multiple filtering mode, also force traffic redirection. Because all these changes might break session coherency and, as a result, disrupt existing connections, they should be performed during off-hours.

Was this article helpful?

+1 0

Post a comment