Each server in a Network Load Balancing cluster is referred to as a node. Network Load Balancing nodes work together to provide availability for critical IP-based resources, which can include TCP, UDP, and GRE traffic requests.
Network Load Balancing provides failover support for IP-based applications and services that require high scalability and availability. You can use Network Load Balancing to build groups of up to 32 clustered computers, starting with as few as 2 computers and incrementally scaling out as demand increases. Network Load Balancing is ideally suited to improving the availability of Web servers, media servers, terminal servers, and e-commerce sites. Load balancing these services ensures that there is no single point of failure and that there is no performance bottleneck.
Network Load Balancing uses a virtual IP address, and client requests are directed to this virtual IP address, allowing for transparent failover and failback. When a load-balanced resource fails on one server, the remaining servers in the group take over the workload of the failed server. When the failed server comes back online, the server can automatically rejoin the cluster group, and Network Load Balancing starts to distribute the load to the server automatically. Failover takes less than 10 seconds in most cases.
Network Load Balancing doesn't use shared resources or clustered storage devices. Instead, each server runs a copy of the TCP/IP application or service that is being load balanced. Local storage is used in most cases as well. As with Server cluster, users usually don't know that they're accessing a group of servers rather than a single server. The reason for this is that the Network Load Balancing cluster appears to be a single server. Clients connect to the cluster using a virtual IP address and, behind the scenes, this virtual address is mapped to a specific server based on availability.
Anyone familiar with load-balancing strategies might be inclined to think of Network Load Balancing as a form of round robin Domain Name System (DNS). In round robin DNS, incoming IP connections are passed to each participating server in a specific order. For example, an administrator defines a round robin group containing Server A, Server B, and Server
C. The first incoming request is handled by Server A, the second by Server B, the third by Server C, and then the cycle is repeated in that order (A, B, C, A, B, C, …). Unfortunately, if one of the servers fails, there is no way to notify the group of the failure. As a result, the round robin strategy continues to send requests to the failed server. Windows Network Load Balancing doesn't have this problem.
To avoid sending requests to failed servers, Network Load Balancing sends heartbeats to participating servers. These heartbeats are similar to those used by the Cluster service. The purpose of the heartbeat is to track the condition of each participant in the group. If a server in the group fails to send heartbeat messages to other servers in the group for a specified interval, the server is assumed to have failed. The remaining servers in the group take over the workload of the failed server. While previous connections to the failed host are lost, the IPbased application or service continues to be available. In most cases, clients automatically retry the failed connections and experience only a few seconds delay in receiving a response. When the failed server becomes available again, Network Load Balancing automatically allows the server to rejoin the group and starts to distribute the load to the server.
Although Network Load Balancing is normally used to distribute the workload for an application or service, it can also be used to direct a specific type of traffic to a particular server. For example, an administrator might want to load Hypertext Transfer Protocol (HTTP) and File Transfer Protocol (FTP) traffic to a group of servers but might want a single server to handle other types of traffic. In this latter case, Network Load Balancing allows traffic to flow to a designated server and reroutes traffic to another server only in case of failure.
Network Load Balancing runs as a network driver and requires no hardware changes to install and run. Its operations are transparent to the TCP/IP networking stack. Because Network Load Balancing is IP-based, IP networking must be installed on all load-balanced servers. At this time, Network Load Balancing supports Ethernet and Fiber Distributed Data Interface (FDDI) networks but doesn't support Asynchronous Transfer Mode (ATM). Future versions of Network Load Balancing might support these network architectures. There are four basic models for Network Load Balancing:
Single network adapter in unicast mode This model is best for an environment in which ordinary network communication among cluster hosts is not required and in which there is limited dedicated traffic from outside the cluster subnet to specific cluster hosts.
Multiple network adapters in unicast mode This model is best for an environment in which ordinary network communication among cluster hosts is necessary or desirable and in which there is moderate to heavy dedicated traffic from outside the cluster subnet to specific cluster hosts.
Single network adapter in multicast mode This model is best for an environment in which ordinary network communication among cluster hosts is necessary or desirable but in which there is limited dedicated traffic from outside the cluster subnet to specific cluster hosts.
Multiple network adapters in multicast mode This model is best for an environment in which ordinary network communication among cluster hosts is necessary and in which there is moderate to heavy dedicated traffic from outside the cluster subnet to specific cluster hosts.
Network Load Balancing uses unicast or multicast broadcasts to direct incoming traffic to all servers in the cluster. The Network Load Balancing driver on each host acts as a filter between the cluster adapter and the TCP/IP stack, allowing only traffic bound for the designated host to be received. Network Load Balancing controls only the flow of TCP, UDP, and GRE traffic on specified ports. It doesn't control the flow of TCP, UDP, and GRE traffic on nonspecified ports, and it doesn't control the flow of other incoming IP traffic. All traffic that isn't controlled is passed through without modification to the IP stack.
To provide high-performance throughput and responsiveness, Network Load Balancing normally uses two network adapters, as shown in Figure 18-3. The first network adapter, referred to as the cluster adapter, handles network traffic for the cluster, and the second adapter, referred to as the dedicated adapter, handles client-to-cluster network traffic and other traffic originating outside the cluster network.
Network Load Balancing can also work with a single network adapter. When it does so, there are limitations. With a single adapter in unicast mode, node-to-node communications are impossible, meaning nodes within the cluster cannot communicate with each other. Servers can, however, communicate with servers outside the cluster subnet. By using a single adapter in multicast mode, node-to-node communications are possible as are communications with servers outside the cluster subnet. However, the configuration is not optimal for handling moderate to heavy traffic from outside the cluster subnet to specific cluster hosts. For handling node-to-node communications and moderate to heavy traffic, two adapters should be used.
Regardless of whether a single adapter or multiple adapters are used, all servers in the group operate in either unicast or multicast mode—not both. In unicast mode, the cluster's Media Access Control (MAC) address is assigned to the computer's network adapter and the network adapter's built-in MAC address is disabled. All participating servers use the cluster's MAC address, allowing incoming packets to be received by all servers in the group and passed to the Network Load Balancing driver for filtering. Filtering ensures that only packets intended for the server are received and all other packets are discarded. To avoid problems with Layer 2 switches, which expect to see unique source addresses, Network Load Balancing uniquely modifies the source MAC address for all outgoing packets. The modified address shows the server's cluster priority in one of the MAC address fields.
Because the built-in MAC address is used, the server group has some communication limitations when a single network adapter is configured. Although the cluster servers can communicate with other servers on the network and with servers outside the network, the cluster servers cannot communicate with each other. To resolve this problem, two network adapters are needed in unicast mode.
In multicast mode, the cluster's MAC address is assigned to the computer's network adapter and the network adapter's built-in MAC address is maintained so that both can be used. Because each server has a unique address, only one adapter is needed for network communications within the cluster group. Multicast offers some additional performance benefits for network communications as well. However, multicast traffic can flood all ports on upstream switches. To prevent this, a virtual LAN should be set up for the participating servers.
Inside Out: Using Network Load Balancing with routers
If Network Load Balancing clients are accessing a cluster through a router, be sure that the router is configured properly. For unicast clusters, the router should accept a dynamic Address Resolution Protocol (ARP) reply that maps the unicast IP address to its unicast MAC address. For multicast clusters, the router should accept an ARP reply that has a MAC address in the payload of the ARP structure. If the router isn't able to do this, you can also create a static ARP entry in the router to handle these requirements. Some routers will require a static ARP entry because they do not support the resolution of unicast IP addresses to multicast MAC addresses.
Several options can be used to optimize performance of a Network Load Balancing cluster. Each server in the cluster can be configured to handle a specific percentage of client requests, or the servers can handle client requests equally. The workload is distributed statistically and does not take into account CPU, memory, or drive usage. For IP-based traffic, the technique does work well, however. Most IP-based applications handle many clients, and each client typically has multiple requests that are short in duration.
Many Web-based applications seek to maintain the state of a user's session within the application. A session encompasses all the requests from a single visitor within a specified period of time. By maintaining the state of sessions, the application can ensure the user can complete a set of actions, such as registering for an account or purchasing equipment. Network
Load Balancing features allow administrators to configure client affinity to help maintain application sessions. Client affinity uses a combination of the source IP address and source and destination ports to direct multiple requests from a single client to the same server. Three client affinity settings can be used:
None Specifies that Network Load Balancing doesn't need to direct multiple requests from the same client to the same server
Single Specifies that Network Load Balancing should direct multiple requests from the same client IP address to the same server
Class C Specifies that Network Load Balancing should direct multiple requests from the same Class C address range to the same server
Class C affinity is useful for clients that use multiple proxy servers to access the cluster.
Network Load Balancing clusters use filtering to ensure that only packets intended for the server are received and all other packets are discarded. Port rules specify how the network traffic on a port is filtered. Three filtering modes are available:
Disabled No filtering
Single Host Direct traffic to a single host
Multiple Hosts Distribute traffic among the Network Load Balancing servers
Port rules are used to configure Network Load Balancing on a per-port basis. For ease of management, port rules can be assigned to a range of ports as well. This is most useful for UDP traffic when many different ports can be used.
Many applications and services can work with Network Load Balancing, provided they use TCP/IP as their network protocol and use an identifiable set of TCP or UDP ports. Key services that fit these criteria include the following:
FTP over TCP/IP, which normally uses TCP ports 20 and 21
HTTP over TCP/IP, which normally uses TCP port 80
HTTPS over TCP/IP, which normally uses TCP port 443
IMAP4 over TCP/IP, which normally uses TCP ports 143 and 993 (SSL)
POP3 over TCP/IP, which normally uses TCP ports 110 and 995 (SSL)
SMTP over TCP/IP, which normally uses TCP port 25
Network Load Balancing can be used with virtual private network (VPN) servers, terminal servers, and streaming media servers as well. For Network Load Balancing, most of the capacity planning focuses on the cluster size. Cluster size refers to the number of servers in the cluster. Cluster size should be based on the number of servers necessary to meet anticipated demand.
Stress testing should be used in the lab to simulate anticipated user loads prior to deployment. Configure the tests to simulate an environment with increasing user requests. Total requests should simulate the maximum anticipated user count. The results of the stress tests will determine whether additional servers are needed. The servers should be able to meet demands of the stress testing with 70 percent or less server load with all servers running. During failure testing, the peak load shouldn't rise above 80 percent. If either of these thresholds is reached, the cluster size might need to be increased.
Servers that use Network Load Balancing can benefit from optimization as well. Servers should be optimized for their role, the types of applications they will run, and the anticipated local storage they will use. Although you might want to build redundancy into the local hard drives on Network Load Balancing servers, this adds to the expense of the server without significant availability gains in most instances. Because of this, Network Load Balancing servers often have drives that do not use redundant array of independent disks (RAID) and do not provide fault tolerance; the idea being that if a drive causes a server failure, other servers in the Network Load Balancing cluster can quickly take over the workload of the failed server.
If it seems odd not to use RAID, keep in mind that servers using Network Load Balancing are organized so they use identical copies of data on each server. Because many different servers have the same data, maintaining the data with RAID sets isn't as important as it is with server clusters. A key point to consider when using Network Load Balancing, however, is data synchronization. The state of the data on each server must be maintained so that the clones are updated whenever changes are made. The need to synchronize data periodically is an overhead that must be considered when designing the server architecture.