Practice: using (NLB) Network Load Balancing on WIN2008R2

Copyright Notice: Original works, declined reprint! Otherwise, the legal liability will be investigated.An official description of NLB, you must first understand the principles of NLB before building an NLB cluster

Network Load Balancing (NLB) features in Windows server R2 can enhance the availability of Internet server applications such as those used on Web, FTP, firewalls, proxies, virtual private networks (VPNs), and other mission-critical servers and scalability. A single computer running Windows server R2 provides limited server reliability and scalable performance. However, by combining resources from two or more computers running one of the products in Windows server R2 into a single virtual cluster, NLB provides the reliability and performance required for WEB servers and other mission-critical servers. NLB allows the use of the same cluster IP address set to specify the addresses of all computers in the cluster, and it also retains a unique set of dedicated IP addresses for each host. For load-balanced applications, the load is automatically redistributed between computers that are still running when the host fails or goes offline. When a computer fails unexpectedly or goes offline, an active connection is broken between the server that is failing or is offline. However, if you intentionally shut down the host computer, you can use thedrainstopcommand to process all active connections. In either case, you can explicitly rejoin the offline computer to the cluster when you are ready, and re-share the cluster load so that the other computers in the cluster process less traffic. The primary opportunity in the NLB cluster exchanges the heartbeat message to maintain consistency with the data about the cluster membership. By default, when the host fails to send a heartbeat message within five seconds, the host fails. When a host fails, the remaining hosts in the cluster are aggregated and perform the following actions: Determine which hosts are still active members in the cluster. Select the highest-priority host as the new default host. Ensure that all new client requests are processed by the host that is still active. During aggregation, the active host is still looking for a consistent heartbeat. If the host that cannot send the heartbeat begins to provide a consistent heartbeat, it will rejoin the cluster during the aggregation process. When a new host attempts to join the cluster, it sends a heartbeat message, which also triggers the aggregation. When all cluster hosts agree on the current cluster membership, the client load is redistributed to the remaining hosts and the aggregation is completed. Aggregation typically takes only a few seconds, so there is very little client service that is interrupted by the cluster. During aggregation, hosts that are still active continue to process client requests without affecting existing connections. If all hosts report a consistent cluster membership and distribution mapping during several detections, the aggregation ends.

What's new in NLB? The following improvements are included for Windows Server R2,NLB: the relevance of the extension . The extended option maintains client affinity when the configuration of the NLB cluster changes. This option allows the client to remain relevant to the cluster host, even if there are no active connections between the client and the host. Windows PowerShell for the NLB cluster. Windows PowerShell is a new command-line interface and scripting language. Windows PowerShell accelerates the automation of system administration tasks. You can use Windows PowerShell to manage your NLB cluster. For more information about using Windows PowerShell with an NLB cluster, see http://go.microsoft.com/fwlink/?LinkId=140180 (possibly an English web page). supports rolling upgrades . NLB supports rolling upgrades from Windows Server 2003 to Windows Server R2 and from Windows Server 2008 to Windows Server R2. For information about the deployment of NLB, including information about rolling upgrades, see http://go.microsoft.com/fwlink/?LinkId=87253.

NLB includes the following features: Scalability scalability is a measure of how computers, services, or applications can better improve to meet the continuously growing performance requirements. For NLB clusters, scalability refers to the ability to incrementally add one or more systems to an existing cluster when the full load of the clusters exceeds their capabilities. To support scalability, NLB can perform the following actions: Balance the load requests on each TCP/IP service on the NLB cluster. Support for up to 32 computers in a cluster. Balances multiple server load requests (from the same client or from several clients) between multiple hosts in the cluster. When the load increases, it is supported to add hosts to the NLB cluster without shutting down the cluster. The removal of hosts from the cluster is supported when the load is reduced. Improve performance and reduce overhead with all of your plumbing. Pipelines allow requests to be sent to the NLB cluster without waiting for a response from the previous send request. High availability by minimizing downtime, highly available systems can reliably deliver acceptable levels of service. To provide high availability, NLB includes built-in features that automate the following actions: Detects and recovers a failed or offline cluster host. Balance the Network load when you add or remove hosts. Recover and redistribute the load within 10 seconds. Manageability NLB provides the following manageability features: With NLB Manager, you can manage and configure multiple NLB clusters and cluster hosts from a single computer. With port management rules, you can specify load balancing behavior for a single IP port or a set of ports. You can define different port rules for each site. If you use the same set of load-balancing servers for multiple applications or sites, the port rule is based on the destination virtual IP address (using a virtual cluster). With optional single-host rules, all client requests can be booted to a single host. NLB routes client requests to specific hosts that run specific applications. You can prevent unwanted network access to certain IP ports. Internet Group Management Protocol (IGMP) support can be enabled on cluster hosts to control switch broadcasts (when operating in multicast mode). With shell commands or scripts, you can remotely start, stop, and control NLB operations from any networked computer running Windows. You can view the Windows event log to check for NLB events. NLB logs all operations and cluster changes in the event log. Ease of Use NLB offers a number of handy features: NLB can be installed as a standard Windows network connection driver component. NLB does not require any hardware changes to enable and run. Use NLB Manager to create a new NLB cluster. With NLB Manager, you can configure and manage multiple clusters and all hosts of a cluster from a remote or local computer. NLB allows clients to access the cluster using a single logical Internet name and virtual IP address, called the cluster IP address, which retains the individual names of each computer. NLB allows multi-homed servers to have multiple virtual IP addresses. Note If you are a virtual cluster, you do not need the server to be a multihomed server to have multiple virtual IP addresses. You can bind NLB to multiple network adapters so that you can configure multiple independent clusters on each host. Support for multiple network adapters differs from virtual clusters because virtual clusters allow you to configure multiple clusters on a single network adapter. You do not need to modify the server application to run in the NLB cluster. If the cluster host fails and then comes back online, NLB can be configured to automatically add the host to the cluster. After that, the added host will be able to start processing new server requests from the client. You can take the computer offline for preventative maintenance without disturbing cluster operations on other hosts.

Second, understand the technical knowledge of NLB, and then we can do the test, first look at the topology of this testthird, the test stepsfirst need to build the experimental environment, this example in a domain environment testing, for the convenience of the experiment, I first changed the advanced sharing settings and firewall settings Install Network Load Balancing on NLB1 and NLB2 respectively  after two nodes are installed, configure Network Load Balancing on NLB1, node one configuration is completed, then node two is added to the node one NLB Create a new cluster, add the current node to NLB, and set the public NIC as the cluster interfacein host parameters, set the priority (single host identifier) to prioritize the load on the nodes in the NLB clusterset a cluster IP address, if you are testing with IIS, when you visit the Web, actually access the cluster IP, or establish a record of the site a corresponding to the cluster IP in DNS, access the FQDN name of the cluster IP. When a client accesses IIS, it does not feel a change in the back load. set up a cluster IP address for the same network segment as the public NIC  set the full Internet name for a cluster IP, and the operating mode of the cluster remains the defaultabout the difference between unicast and multicast (below is quoted from the network)

Unicast: On each cluster member, NLB overrides the MAC address provided by the manufacturer on the network adapter. NLB uses the same unicast MAC address for all members. The advantage of this model is that it can work seamlessly with most routers and switches. The disadvantage is that traffic that arrives at the cluster spreads to all ports on the switch virtual LAN (VLAN), and communication between hosts cannot be tied to the adapter that NLB binds to, that is, the entity hosts cannot communicate with each other. If we select unicast mode when NLB is created, the network address in cluster IP configuration begins with "02-BF", followed by the hexadecimal representation of the IP address, which is the same as the MAC address of the actual host, and the subsequent host will be modified to this MAC address. Multicast: Keeps the original MAC address unchanged, but adds a 2nd multicast MAC address to the network adapter. All inbound traffic will reach this multicast MAC address. The advantage is that this approach allows inbound traffic to reach only the hosts in the cluster by creating static entries in the contents addressable memory (CAM) Table of the switch. The disadvantage is that the cam item must statically correlate a set of switch ports, and if none of these cam entries, the inbound traffic will still spread to all ports on the switch VLAN. Another drawback is that many routers do not automatically associate a unicast IP address (the cluster's virtual IP address) with a multicast MAC address. Some routers can have this association if they are statically configured. If we select multicast mode when NLB is created, the network address in cluster IP configuration starts with "03-BF", followed by the hexadecimal representation of the IP address. When selecting multicast mode, there is also a complex option "IGMP multicast (IGMP multicast)", if checked, as with multicast operation mode, NLB retains the original MAC address, but adds an IGMP multicast address to the network adapter. Additionally, the NLB host issues the IGMP join message for this group. If the switch detects these messages, it can populate its own CAM table with the desired multicast address so that inbound traffic does not spread to all ports on the VLAN. This is the main advantage of this clustering pattern. The disadvantage is that some switches do not support IGMP probing. In addition, routers still support the conversion of unicast IP addresses to multicast MAC addresses. In IGMP multicast mode, the MAC address that starts with "01–00-5e" will be used. In multicast mode, entity hosts can communicate with each other. In general, when NLB is created, single-NIC multicast, dual-NIC unicast. Dual NIC unicast, because the host can not communicate with each other, will set up the network communication card, that is, the heartbeat in the cluster settings. In Microsoft's official recommendation when setting up NLB, first consider the unicast mode, unless unicast does not meet its requirements, to resolve the method of traffic expansion, it is recommended to use VLANs.

 Once the node configuration is complete, go back to node two, open the cluster Manager for node two, and connect the NLB2 to the existing clusterEnter the first node hostname, and after clicking Connect, the cluster window below will show the existing clusterafter connecting to the cluster, join the node n3.contoso.com to the existing cluster  when the add is complete,The following is an NLB load testfirst, the Web site is accessed by default and the address is:http://10.1.1.100one more cluster IP address in the NICDisconnect the NIC from the node accessed in the previous step, try the access again, the effectConfiguring a Network Load Balancing cluster you need to be aware that Network Load Balancing does not provide additional security for a load-carrying host, nor can it be used for firewalls, so it is important to properly protect load-balanced applications and hosts. If possible, use at least two network adapters on each cluster host, but not a requirement, use only the TCP/IP protocol on the cluster adapter, ensure that all hosts in the cluster belong to the same subnet and that the client has access to the subnet, configure the NLB cluster with Network Load Balancing Manager, enable logging, Do not enable remote control of Network Load Balancing. NLB provides Network Load balancing services that each node hears requests from clients, each of which stores one copy of data locally, supporting 32 nodes, which can be a domain environment or a workgroup environment. Iv. possible problems in implementing Network Load Balancing (Microsoft official documentation)

After installing Network Load Balancing and restarting the cluster host, a message appears: "The system has detected an IP address that conflicts with other systems on the network ..." cause : The same IP address already exists on the network. Solution : Select a new IP address, or delete the duplicate address. cause : You have configured a different cluster operating mode ("unicast" or "multicast") on the host, which maps two different MAC addresses to the same IP address. Solution : Ensure that all hosts are configured to have the same cluster operation mode. cause : The IP address of the cluster has been configured before NLB is bound to the network adapter. Solution : Remove the IP address of the cluster from the TCP/IP properties, enable NLB on the appropriate adapter, and then configure the cluster's IP address. cause : You have added the IP address of the cluster to the network adapter that is not already enabled for NLB. Solution : Remove the IP address of the cluster from the TCP/IP properties of the incorrect adapter, enable NLB on the appropriate adapter, and then configure the cluster's IP address. For more information about enabling NLB, see Installing Network Load Balancing when you use ping to access the cluster's IP address from the external network is not responding. Verify that you can usePingAccess the private IP address of the cluster host from a computer other than the router. If the test fails, and you use more than one network adapter, this issue is not related to NLB. If you use a network adapter for private IP addresses and cluster IP addresses, consider the following reasons: cause : If you are using multicast support, you may find that the router cannot resolve the primary IP address to a multicast media access control (MAC) address by using Address Resolution Protocol (ARP). Solution : Verify that you can use ping to access the cluster from clients on the cluster subnet, and that you can access the private IP address of the cluster host from a computer other than the router. If these tests are working correctly, the router may have failed. You should be able to circumvent this problem by adding static ARP entries to the router. You can also turn off NLB multicast support and use unicast network addresses (in the absence of hubs). cause : When using NLB in multicast or unicast mode, routers need to accept proxy ARP responses (the mapping of IP-to-network addresses received with different network source addresses in the Ethernet framework). Solution : Make sure that your router has proxy ARP support turned on. You can also set a static ARP entry to keep proxy ARP support disabled in the router. cause : The cluster's Internet Control Message Protocol (ICMP) is blocked by the router or firewall. solution : Allow ICMP traffic to pass through the router or firewall. Please note that this may expose your system to other security risks. There is no response when using ping to access the private IP address of another host from one cluster host. cause : When using NLB in multicast or unicast mode, routers need to accept proxy ARP responses (the mapping of IP-to-network addresses received with different network source addresses in the Ethernet framework). Solution : Make sure that your router has proxy ARP support turned on. You can also set a static ARP entry to keep proxy ARP support disabled in the router. cause : The cluster's Internet Control Message Protocol (ICMP) is blocked by the router or firewall. solution : Allow ICMP traffic to pass through a firewall or router. Please note that this may expose your system to other security risks. When you try to use a Network Load Balancing Manager to connect to a host in the cluster, you receive the error "Cannot access the host." cause : The host's Internet Control Message Protocol (ICMP) is blocked by the router or firewall, or it is disabled on the host's network adapter. solution : Enable ICMP on the host's network adapter or allow ICMP traffic through the firewall or router. Please note that this may expose your system to other security risks. You can also use the NLB Manager's /noping option. There is no response when using Telnet or attempting to browse a computer outside the cluster from a clustered host. cause : Verify that you can use ping to access computers outside the cluster. If this test succeeds, the host's private IP address may not be listed first in the TCP/IP properties. solution : If ping fails to access a computer outside the cluster, refer to the following questions (described earlier in this troubleshooting topic): There is no response when using ping to access the cluster's IP address from the external network. There is no response when using ping to access the private IP address of another host from one cluster host. When a Network Load Balancing remote control command is called from a computer other than the cluster, there is no response in one or more cluster hosts. cause : The remote control command is not sent to the cluster's IP address. Solution : The command must be sent to the cluster's primary IP address, which can be specified in the Network Load Balancing Properties dialog box. Make sure that the remote command is sent to the correct IP address. cause : Internet Protocol security (IPSEC) encrypts remote control traffic. If the NLB Remote control command is sent from a computer that has IPSec configured for IPSec to encrypt remote control traffic, these commands will not function correctly. Solution : Disable IPSEC. For more information, see Internet Protocol security (IPSEC) Help content. cause : The firewall does not properly protect the NLB UDP control port. By default, remote control commands are sent to UDP ports 1717 and 2504 on the cluster IP address. Solution : Ensure that these ports have not been blocked by a router or firewall error. You can also change the port number by modifying the appropriate NLB parameters. There is no answer when you use the host's private IP address to designate it as the target of a remote control command. However, the host is specified to function correctly by its priority (ID). cause : No host has a private IP address. solution : Specify a private IP address for each host. For more information, see Configure Network Load Balancing host parameters. Some users (not all users) are denied connectivity to the cluster. cause : The application that is in load balancing is not responding. Solution : This is an application-specific issue that is not related to NLB. Please refer to your application documentation to correct this problem. You may need to stop and restart the application. cause : If the cluster is configured for unicast mode, a switch may already know the MAC address of the NLB network adapter. Solution : Clear the Port-to-MAC address mapping for the switch. cause : On one or more hosts, the IP address of the cluster is not added to TCP/IP. Solution : If you do not configure your cluster with NLB Manager, you must manually configure TCP/IP with the IP address of the cluster. cause : A host is leaving the cluster because the drainstop or Stop command was used, but the aggregation did not complete properly. solution : Wait for the aggregation to complete. If aggregations are not complete, see the following questions in the troubleshooting topic: Cluster hosts start aggregations after they are started, but they never complete aggregations You cannot view or change the properties of Network Load Balancing by using net Config and Windows Management Instrumentation (WMI). cause : To view or change Network Load Balancing Properties, you must be a member of the Administrators group. solution : Log on as a user who is a member of the local Administrators group on the computer that is running NLB. The number of TCP connections that are reset by the server or client to the cluster IP address is abnormal. cause : The HTTP keep-alive value is enabled on the NLB host and the client that has the Keep-alive value enabled is connecting to the cluster. Solution : Disable the HTTP keep-alive value. For more information about HTTP keep-alive values and Internet Information Services (IIS), see the IIS documentation set. To view the IIS document set from the desktop, install IIS, click Start, click Run, and then type the following command in the open text box: %windir%\help\iisrv.chm cause : There is insufficient system resources on the server, which causes TCP to reject the connection. Solution : Free system resources, for example, by adding additional system memory or by shutting down unnecessary applications. cause : The cluster has been divided into two separate aggregated clusters, resulting in multiple nodes requiring ownership of each connection. solution : Remove both clusters, and then recreate a cluster. Virtual Private Network (VPN) calls fail when making changes that cause aggregation, such as adding a host, removing a host, or draining a host. cause : When using NLB to load balance VPN traffic, you must configure the port rules to use for management processing of VPN traffic (for Pptp/gre to TCP port 1723; for ports IPSEC/L2TP UDP Port 500) and for using "single" or "network" dependencies. Solution : Configure the port rules that are used to manage ports 500 and 1723 to use single or network affinity. For more information, see Network Load Balancing Manager properties. Cluster hosts start aggregations after they are started, but they never complete aggregations. cause : Different number of port rules were entered on different clusters or incompatible port rules were entered. This will prevent aggregations. solution : On each cluster host, open the Network Load Balancing Properties dialog box and verify that all hosts have the same port rules. cause : The network adapter or cable is damaged. Solution : Use the ping command to test the connection condition. Enter the fully qualified domain name of the host. You can also learn more about this issue by using the ping command to search for domain controllers by IP address and searching for other network servers by name and IP address. cause : The duplex setting on a switch or hub does not match. Solution : Verify that the duplex settings in each switch and hub are configured correctly. cause : A dedicated IP address is already available on the network for one of the hosts. Solution : Select a new IP address, or delete the duplicate address. cause : Your cluster contains hosts that are running Windows 2000. Solution : Your cluster must be running Windows Server 2008 on all hosts. NLB cluster environments that contain hosts running Windows Server 2003 and Windows Server 2008 are supported only when you roll-upgrade to Windows Server 2008. Long-term mixed use of Windows Server 2003 and Windows Server 2008 in the same cluster is not supported. cause : Different cluster operating modes (unicast and multicast) are configured on the host. solution : Use NLB Manager to ensure that all hosts are configured with the same cluster operation mode. Note You can also view the Windows event log to check for errors and warnings. For more information, see Installing Network Load Balancing. The cluster moves in and out of the aggregated state. cause : The heartbeat is missing because the network adapter or cable is damaged or other network problems cause intermittent network connections. Solution : Use the ping command to test the connection condition. Enter the fully qualified domain name of the host. You can also learn more about this issue by using the ping command to search for domain controllers by IP address and searching for other network servers by name and IP address. After the cluster host is started, the Network Load Balancing report aggregation is complete, but there are multiple default hosts. cause : The cluster host has become a member of a different subnet and therefore cannot access all hosts on the same network. Solution : Ensure that all cluster hosts can communicate with each other. cause : A layer three switch is being used. Solution : Place a two-layer switch between the host and the layer three switch. cause : an outage of a redundant switch causes the cluster to be divided into two clusters, creating two default hosts. solution : Remove both clusters, and then create a cluster. cause : Your switch is configured to reject broadcast packets. Solution : Configure your switch to accept broadcast packets (note that this may introduce some security risks) or configure the NLB cluster to use multicast mode. cause : A host cannot send or receive heartbeats. Solution : Use the ping command to test the connection to each host. Enter the fully qualified domain name of the host. cause : A host was plugged into the wrong port of the switch. Solution : Use the correct port on the switch. Network Load Balancing does not apply load balancing, and the default host handles all network traffic. cause : The port rule is missing. By default, NLB directs all incoming network traffic that is not managed by the port rule to the default host, which ensures that you do not want load-balanced applications to behave properly. solution : To load balance applications on the cluster, create port rules on each cluster host for the TCP/IP ports that the application processes. cause : A second host was added to a single host cluster, but the second host is not configured correctly. The cluster never aggregates and the initial host continues to process all traffic. Solution : Carefully review (correct if necessary) each setting on the second host, such as the cluster IP address, private IP address, and port rules. cause : If the cluster is configured for unicast mode, a switch may already know the MAC address of the NLB network adapter. Solution : Clear the Port-to-MAC address mapping for the switch. cause : The proxy server is sending all connections that use a single IP address to a cluster in a "single" affinity mode. Solution : Configure the proxy server to use multiple IP addresses. Traffic is exchanged unexpectedly between cluster hosts and a TCP connection is disconnected. cause : The unicast network address causes a problem with the interchange hub. If you use a switch hub to interconnect the cluster hosts, you must use NLB multicast support. Otherwise, the switch may behave abnormally when using the same unicast network on multiple switch ports. Solution : Verify that multicast support is selected in the Network Load Balancing Properties dialog box. If you do not want to use multicast support, you can interconnect the cluster hosts with a hub or coaxial cable instead of using a switch. There is no uniform load balancing of network traffic between cluster hosts. cause : Network traffic comes from a limited number of IP addresses and may be caused by settings on the proxy server. Solution : Configure the proxy server to use multiple IP addresses. When you use Network Load Balancing for Microsoft Internet Security and Acceleration (ISA) Server, one cluster host records the blocked packets that are booted to the private Internet Protocol (IP) address of another host. cause : One of the cluster hosts is configured with a master priority identifier equal to 1. solution : Do not configure any cluster hosts with a master priority identifier equal to 1. Use a number greater than 1. For more information, see Configure Network Load Balancing host parameters. You cannot create a Network Load Balancing cluster in a 64-bit version of the environment. cause : The appropriate NLB version may not be running for your environment. When you use a 32-bit version of NLB on a 64-bit version of your computer, NLB cannot form a cluster. This issue may not be detected because 32-bit NLB components (nlb.exe, Wlbs.exe, and nlbmgr.exe) appear to function correctly in a 64-bit version of the environment. Solution : If you plan to use a 64-bit version of the computer environment, you must use the 64-bit NLB version.

Note: This article has a large number of text quoted from the network, in this to the source of the information expressed deep thanks to the author, thank you, Google, thank you Baidu ....

This article from "Zeng Hung Xin Technical column" blog, declined to reprint!

Practice: using (NLB) Network Load Balancing on WIN2008R2