Other NLB links:
Network Load Balancing never load-balances traffic for the dedicated IP address. Instead, it load-balances incoming traffic from all IP addresses other than the dedicated IP address. Because NLB makes the routing decisions at layer 3, application specific information, such as HTTP headers and server variables, can not be used to provide application level based routing. Each Network Load Balancing host can specify the load percentage that it will handle, or the load can be equally distributed among all of the hosts. Using these load percentages, each Network Load Balancing server selects and handles a portion of the workload. Clients are statistically distributed among cluster hosts so that each server receives its percentage of incoming requests. This load balance dynamically changes when hosts enter or leave the cluster. In this version, the load balance does not change in response to varying server loads (such as CPU or memory usage). For applications, such as Web servers, which have numerous clients and relatively short-lived client requests, the ability of Network Load Balancing to distribute workload through statistical mapping efficiently balances loads and provides fast response to cluster changes. Network Load Balancing cluster servers emit a heartbeat message to other hosts in the cluster, and listen for the heartbeat of other hosts. If a server in a cluster fails, the remaining hosts adjust and redistribute the workload while maintaining continuous service to their clients. Although existing connections to an offline host are lost, the Internet services nevertheless remain continuously available. In most cases (for example, with Web servers), client software automatically retries the failed connections, and the clients experience only a few seconds’ delay in receiving a response.
there are DNS providers who will integrate DNS Round Robin with server health checks, and will temporarily remove dead servers from the DNS records.
Current Microsoft browsers cache DNS data for 30 minutes, so you’re looking at more than 30 minutes failover time for a subset of your users, depending on their initial DNS cache state.
Achieving High Availability and Scalability:
Microsoft Application Request Routing (ARR) for IIS 7.0 and Network Load Balancing (NLB).
Microsoft Application Request Routing (ARR) for IIS 7.0 is a proxy-based routing module that forwards HTTP requests to content servers based on HTTP headers, server variables, and load balance algorithms.
While ARR provides high availability and scalability for the content servers, the overall deployment is not highly available or scalable because:
- ARR is the single point of failure.
- The scalability of the content servers is limited by the maximum capacity of one ARR server.
In order to overcome these challenges, administrators may consider using multiple ARR servers with Network Load Balancing (NLB). ARR can be deployed in active/passive mode to only achieve high availability or in active/active mode to achieve both high availability and scalability. ARR does not provide fault tolerant deployment features for itself and must rely on other complementary technologies and solutions to achieve high availability for the ARR tier.
The NLB configuration is divided into the following steps:
- Install the NLB feature on all ARR servers.
- Create NLB cluster for ARR.
- Configure NLB for active/passive deployment.