Network Load Balancing Clusters

[Previous] [Next]

Network Load Balancing provides a highly available and scalable solution for TCP/IP-based network applications such as a Web server or FTP server. By combining the resources of two or more servers into a single cluster, NLB can provide for redundancy of information and resources while servicing far more clients than a single server alone could handle.

NLB Concepts

NLB is a Windows 2000 Networking driver. It acts independently of the TCP/IP networking stack and is transparent to that stack. As shown in Figure 15-1, the NLB driver sits between the TCP/IP stack and the network card drivers, with the Windows Load Balancing Service (Wlbs.exe), the necessary Network Load Balancing control program, running on top, alongside the actual server application.

click to view at full size.

Figure 15-1. Network Load Balancing as a network driver.

Optimally, each server participating in an NLB cluster should have two network interface cards (NICs), although this is not an absolute requirement. Communications and management are materially improved with two NICs, however, especially in unicast mode. (Unicast mode, as opposed to multicast mode, allows each NIC to present only a single address to the network.) Overall network throughput is also improved, since the second network adapter is used to handle host-to-host traffic within the cluster.

Network Load Balancing supports up to 32 computers per cluster. Each server application can be balanced across the entire cluster or can be primarily hosted by a single computer in the cluster, with another computer in the cluster providing directed failover redundancy. For fully distributed applications, the failure of any single host causes the load currently being serviced by that host to be transferred to the remaining hosts. When the failed server comes back online, the load among the other hosts will be redistributed to include the restored server.

NOTE
Network Load Balancing is supported only by Windows 2000 Advanced Server and requires that TCP/IP be installed. It works over Fiber Distributed Data Interface (FDDI) based or Ethernet-based networks from 10 megabits per second (Mbps) to 1 gigabit per second (Gbps). It uses from 250 KB to 4 MB of RAM and roughly a megabyte of disk space.

Choosing an NLB Cluster Model

A host in an NLB cluster can use one of four models, each with its own merits and drawbacks. These models are

  1. Single network adapter in unicast mode
  2. Single network adapter in multicast mode
  3. Multiple network adapters in unicast mode
  4. Multiple network adapters in multicast mode

The choice of model for a given host and cluster will vary depending on the circumstances, requirements, and limitations imposed on the design of the cluster. The sections that follow provide details on each of the models.

NOTE
Network Load Balancing in Windows 2000 does not support a mixed unicast mode and multicast mode environment. All hosts in the cluster must be either multicast or unicast. Some hosts, however, may have a single adapter while others have multiple adapters. In addition, NetBIOS cannot be supported in a single-adapter-only configuration.

Single Network Adapter in Unicast Mode

A single network adapter running in unicast mode is in some ways the easiest type of host to set up, and with only a single adapter, is cheaper than one with multiple network adapters. It does, however, impose significant limitations:

  • Overall network performance is reduced.
  • Ordinary communications among cluster hosts are disabled.
  • NetBIOS support is not available within the cluster.

Single Network Adapter in Multicast Mode

Using multicast mode in clusters in which one or more hosts have a single network adapter means that normal communications are possible between hosts within the cluster. This capability overcomes one of the most awkward of the limitations of single adapter/unicast mode. However, there are still significant disadvantages:

  • Overall network performance is reduced.
  • Some routers do not support multicast MAC addresses.
  • NetBIOS support is not available within the cluster.

Multiple Network Adapters in Unicast Mode

Using multiple network adapters in unicast mode is generally the preferred configuration. It does impose the cost of a second network adapter per host, but given the relatively low cost of network adapters, including the per port cost of hubs, this is a relatively minor price to pay for the resulting advantages:

  • No limitations are imposed on ordinary network communications among cluster hosts.
  • Ordinary NetBIOS support is available via the first configured adapter.
  • No bottlenecks occur due to a single network adapter.
  • The model works with all routers.

Multiple Network Adapters in Multicast Mode

If you are forced by circumstances to use some hosts within a cluster that have only a single network adapter and you must be able to maintain normal network communications among the hosts in the cluster, you will need to run all of the hosts in multicast mode, even those with multiple adapters, since you can't run some hosts in unicast mode and some in multicast mode. This limitation may cause a problem with some routers, but otherwise it is a viable solution.

Planning the Capacity of an NLB Cluster

In general, an NLB cluster should contain as many hosts as are needed to handle the client load for the applications being run in the cluster. The exception to this would be cases in which the sole function of the cluster is to provide failover tolerance for a critical TCP/IP application—that is, when a single server can handle the load and the second server is there simply for fault tolerance.

The maximum number of hosts in a given cluster is 32. If your application will require more than 32 hosts, you can set up multiple clusters, using round-robin DNS to distribute the load among the clusters. The effective limitation, however, is likely to be the network saturation point. If you do run multiple clusters in a subnet, you should host each on its own network switch to minimize the network bottleneck.

Although fewer and more powerful servers may look cost-effective for a given application, you should consider how the failure of a server will affect the application and the remaining servers. If the remaining servers can't handle the resulting load, you may have a cascading failure, bringing down the entire application. Always provide sufficient server capacity within the cluster to handle the expected load when a single server is down. Also consider ways to limit the load to the application when there has been a failure.

When determining the expected cluster capacity, you also need to consider the application being clustered and the type of load it imposes on the cluster. Plan your servers according to where the limitation and stress will be greatest. File serving applications are I/O intensive, e-mail applications such as Microsoft Exchange are very CPU intensive, and database applications tend to be RAM hogs as well as a drain on the disk I/O subsystem.

Providing Fault Tolerance

While NLB clusters provide overall fault tolerance for your TCP/IP application, they are not a complete solution for all possible failures. Because they are "shared nothing" clusters, there is always some data lag between servers. For fully fault-tolerant, high-availability clustering that can run any application, you probably want to use server clustering. This provides the greatest level of fault tolerance.

One thing you can do to improve the overall fault tolerance of the cluster is to make the hard drives fault tolerant. Both hardware and software RAID solutions are viable options for improving the fault tolerance of an NLB cluster. For more on RAID and fault tolerance in general, see Chapters 14 and 35.

Optimizing an NLB Cluster

Optimizing an NLB cluster calls for clearly understanding where the bottleneck in your clustered application is likely to be. An application that is essentially a file and print server, for example, tends to be a heavy user of both disk I/O and network bandwidth. Microsoft Exchange, on the other hand, puts a heavy load on the CPU, and to a somewhat lesser extent, on RAM. Focus your optimization efforts on the bottleneck and you'll get the most gain for your effort.

One area that can be a problem is running an NLB cluster in a switched environment without planning your network load carefully. If each of the servers in your cluster is connected to a different switched port, you can easily end up flooding your switched ports, since every client request to the cluster will pass through all switched ports to which a member of the cluster is attached. Running in multicast mode can exacerbate the problem. If you're running in a switched environment, we suggest that you follow these guidelines:

  1. Use a top-quality hub to connect the servers in the cluster to one another, and uplink the hub to a single switched port.
  2. Use unicast mode. If you enabled multicast mode during setup, change it. (You'll need to change this on all servers in the cluster.)
  3. Edit the registry on each of the hosts in the cluster, changing the following key from the default parameter of 1 to 0:
  4.  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WLBS \Parameters\MaskSourceMAC 

    This change allows the switch to tell which MAC address is really the source of traffic, helping it to do its switching job properly. You'll need to restart the servers after making this change.



Microsoft Windows 2000 Server Administrator's Companion, Vol. 1
Microsoft Windows 2000 Server Administrators Companion (IT-Administrators Companion)
ISBN: 1572318198
EAN: 2147483647
Year: 2000
Pages: 366

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net