System-Level Fault Tolerance (Clustering/Network Load Balancing) - Installing Network Load Balancing Clusters
(Page 23 of 26 )
An NLB cluster can be created easily using the Network Load Balancing Manager utility provided with the Windows Server 2003 Administrative Tools. NLB clusters can also be created using the network interface card property pages or at a command prompt using NLB.exe. To properly configure an NLB cluster, the administrator needs to research the type of network traffic the load-balanced application or service will utilize. For example, to load-balance standard Web traffic, the cluster needs to support TCP port 80, and for Terminal Services, the cluster needs to support TCP port 3389.
NLB Applications and Services
Network load balancing is well equipped to distribute user connections and create fault tolerance for a number of different applications and network services. Because NLB does not replicate data across cluster nodes, using applications that require access to local data that can be changed by the end users is not a good choice. For example, file servers that store user data directories or databases are not a good choice because a user may save a file or change some data within a database while connected to one node and later reconnect to a different node to find his file missing or the changes made to the database are nonexistent.
Applications well suited for NLB clusters are Web sites serving static content or dynamic content built from a back-end database running outside the NLB cluster. Also, Windows Server 2003 Terminal servers, VPN servers, Internet Security and Acceleration servers, and streaming media servers are well suited to be deployed on NLB clusters.
Because the most important part of an NLB deployment is determining what cluster operation mode and port rules need to be used for the load-balanced application to function correctly, the cluster administrator must understand the application thoroughly. It's important to read the vendor's application documentation regarding how the client communicates with the application. For instance, certain applications use cookies or other stateful session information that can be used to identify a client throughout the entire session. As a result, applications configured to prompt users for authentication upon starting a session will fail if the user's future requests are sent to a different cluster node that has not authenticated the user. Knowing these considerations in advance will help determine the required settings that need to be configured using cluster port rules and the filtering mode.
Creating Port Rules
When an NLB cluster is created, one general port rule is also created for this cluster. The port rule or rules define what type of network traffic the cluster will load-balance across the cluster nodes. The Port Rules Filtering option defines how the traffic will be balanced across each individual node. As a best practice, limiting the allowed ports for the clustered IP addresses to only those needed by the cluster load-balanced applications can improve overall cluster performance and security. In an NLB cluster, because each node can answer for the clustered IP address, all inbound traffic is received at each node. When a node receives the request, it either handles the request or drops the packet if another node already has a session with a source client. If a port rule does not define how traffic will be handled for a particular TCP or UPD port, traffic on those ports will be handled by the cluster node with the lowest host priority.
When an administrator creates port rules that allow only specific ports to the clustered IP address and an additional rule blocking all other ports and ranges, the cluster nodes can quickly eliminate and drop packets that do not meet the port rules, thereby improving performance by blindly dropping any packets not allowed by the cluster. The security benefit is that because only a specific port or service is available on the clustered IP address, monitoring that server and maintaining security updates are simpler.
Port Rules Filtering Mode and Affinity
Within a cluster port rule, the NLB administrator must configure the appropriate filtering mode. This allows the administrator to specify whether only one node or multiple nodes in the cluster can respond to requests from a single client throughout a session. There are three filtering modes: Single Host, Disable Port Range, and Multiple Host.
The Single Host Mode
The Single Host filtering mode provides network traffic meeting the port rule criteria to only one node in the cluster. An example is an IIS Web farm in which only one server has a Secure Sockets Layer (SSL) certificate for a secure Web site. In this case, creating a rule to allow port TCP 443 (SSL port) using single host filtering isolates this traffic to the node with the certificate installed.
The Disable Port Range Mode
The Disable Port Range filtering mode tells the cluster which ports not to listen on and to drop these packets without investigation. Administrators should configure port rules and use this filter mode for ports and port ranges that do not need to be load-balanced across the cluster nodes.
The Multiple Host Mode
The Multiple Host filtering mode is probably the most commonly used filtering mode and is also the default. This mode allows traffic to be handled by all the nodes in the cluster. When traffic is balanced across multiple nodes, the application requirements define how the affinity mode should be set.
There are three types of multiple host affinities:
None—This affinity type can send a unique client's requests to all the servers in the cluster during the session. This can speed up server response times but is well suited only for serving static data to clients. This affinity type works well for general Web browsing and read-only file and FTP servers.
Class C—This affinity type routes traffic from a particular class C address space to a single NLB cluster node. This mode is not used too often but can accommodate client sessions that do require stateful data. This affinity does not work well if all the client requests are proxied through a single firewall.
Single—This affinity type is the most widely used. After the initial request is received by the cluster nodes from a particular client, that node will handle every request from that client until the session is completed. This affinity type can accommodate sessions that require stateful data.
Avoiding Switch Port Flooding
Because each node in an NLB cluster answers for incoming traffic, the cluster nodes do not allow a switch to cache their network card MAC address because the cluster nodes want to determine how to route the incoming packets. Because the network switch cannot cache the MAC address associated with the cluster IP addresses, it broadcasts each incoming packet on every port of the switch, which triggers each device connected to respond. When there is heavy traffic going to the cluster, a network switch can become flooded with requests, decreasing performance.
To reduce the risk of switch flooding, the NLB nodes should be connected to an isolated switch or should be configured in a single VLAN if the switch and network support VLANs. For detailed information regarding VLAN configuration and avoiding switch flooding, refer to the network switch documentation.
Using Cluster Operation Mode
There are two cluster operation modes: Unicast and Multicast. Most network traffic is handled through Unicast mode. Clients and servers maintain a one-to-one network connection. Multicast networking allows a server to send out information to one multicast address that is then processed by a number of clients. To receive multicast data, a client joins a multicast group associated with the multicast address. Common applications that use multicast are streaming video Web sites, Internet radio, and Internet training or college courses.
Configuring Network Cards for NLB
Configuring the network cards on the NLB cluster nodes is the first step in building the cluster. Although these steps can be performed during cluster creation using the NLB Manager, the same result can be achieved by editing the TCP/IP properties of each of the cluster node's network cards.
Because many cluster installations utilize Unicast operation mode, this causes some limitations and network overhead on the cluster nodes. When a single network card is used in Unicast mode, the NLB Manager does not run from the local console, requiring the administrator to configure and manage the cluster from a non-cluster node or use the network card's TCP/IP and network load balancing property pages or the command-line tool NLB.exe. Also, due to the configuration, the network adapter's dedicated IP MAC address is replaced with the cluster IP MAC address, causing additional network traffic for all nodes in the cluster when communication is requested for the dedicated IP address.
Best practice for NLB cluster nodes running in Unicast mode is to have two network cards to allow host communication to occur on one NIC while cluster communication is isolated on the cluster NIC. Multiple NICS can also add greater flexibility when it comes to controlling traffic and managing network security.
 This chapter is from Microsoft Windows Server 2003 Unleashed, by Rand Morimoto, et al. (Sams Publishing, 2004, ISBN: 0672326671). Check it out at your favorite bookstore today.
Buy this book now. |
Next: Using the Network Load Balancing Manager to Create a Cluster >>
More MS SQL Server Articles
More By Sams Publishing
/ 15 
