Network load balancing on windows 2000

When an incoming packet destined for a particular IP address and port reaches the external interface of the NAT server, the NAT server changes the header information in the packet, places information about the packet in its state table, and forwards the packet to the internal network server.

The destination IP address always has to be changed in order for the packet to reach the published server on the internal network. Both of these implementations allow the incoming packet to be forwarded to the internal network server and also allow the internal network server to respond to the Internet host that made the request. The ISA Server on the left uses the default Server Publishing configuration and preserves the source IP address of the client making the incoming request.

The published server is able respond to the client by sending its response to the IP address of the internal interface of the ISA Server. You just configure the published server as a SecureNAT client. The sequence of events appears in the figure below. In the first shot, you see the external client with an IP address of By default, Windows keeps the socket pair open for seconds after an active closing of the sessions via the FIN.

The figure below shows a trace taken on the internal interface on the ISA Server array member that did not accept the incoming request. The published server tries to respond to the external client by sending its responses to its default gateway. It makes more sense when you realize that you can have multiple load balancing rules:. The primary address is the cluster address. The dedicated address is the unique host address.

In the advanced properties of the. Now, one annoying thing about the telnet service that comes with Windows is that it only allows two connections. That is why we only made four connections total in the above example. Network load balancing is a statistical process. That is, it randomly selects a host to use. It is possible that the first three connections try to go to one host. If that happens, then just try again to fill up both connection limits on both hosts in the pool.

With today's multi-processor hardware and Windows 's ability to use up to 16 processors in the not-yet-released DataCenter Server; 8 in Advanced Server , a single machine can serve a tremendous number of backend hits. However, some applications eventually reach a point where a single machine is just not enough, regardless of how much hardware you throw at it.

Applications of this scope also need backup and redundancy that requires multiple machines for piece of mind. In addition, there are pure hardware solutions, such as routers that provide round robin DNS services. Router solutions tend to be 'dumb' in that they simply change IP addresses for any hit that comes in.

Software tools tend to be smart, using a machine polling mechanism to see which servers are available and how loaded they are. Some newer routers provide both the routing hardware as well as load balancing features in their firmware. All of these solutions work well and have proven themselves in production environments. Unfortunately, many of them are very expensive and hard to install and administer.

Network Load Balancing in Windows Advanced Server and higher is the new kid on the block, and promises to bring down the cost of load balancing into the affordable range for companies in the non-Fortune set. Keep in mind, though, that the Windows Network Load Balancing service doesn't provide all of the bells and whistles of the other tools.

For example, Resonate provides dynamic rebalancing of hits based on server load, live graphical status reports and administration, and routing of URLs to specific machines. Like many Windows services, the Network Load Balancing Service is bare-bones, but it has the key features needed to take advantage of load balancing quickly and inexpensively. Many of the older tools were very expensive because they fall squarely into the Enterprise domain, where big dollars are usually paid for system management software.

Many of these run into tens of thousands of dollars for only a few load balanced machines. On the other hand, the Network Load Balancing Service ships with Windows Advanced Server and above, which makes it affordable for smaller organizations.

The concept behind Network Load Balancing is simple: You have a 'virtual' IP address that is configured on all the servers that are participating in the load balancing 'cluster' a loose term that's unrelated to the Cluster Service mentioned above.

When a request is made on this virtual IP, a network driver service intercepts the request and re-routes it to one of the machines in the load balancing cluster, based on rules that you can configure for each machine. Network Load Balancing is Microsoft's term for this technology. The most common scenario is that each of the servers is identically configured, running the Web server and local Web applications. The key is redundancy in addition to load balancing. If any machine in the cluster goes down, the virtual IP address will re-balance the incoming requests to the available servers in the cluster.

The servers in the cluster need to be able to communicate with each other to exchange information about their loads, and to allow basic checks to see if a server is down. Each server in the cluster is self-contained, which means it should be able to function without any other server in the cluster, with the exception of the database which is not part of the NLB cluster.

This means that each server must be configured separately to run the Web server as well as any needed Web server applications. If you're running a static site, all HTML files and images must be replicated across servers. Source control programs like Visual SourceSafe can make this process relatively painless by allowing you to deploy updated files of a project in Visual Interdev or FrontPage for example to multiple locations simultaneously.

If you have COM components as part of your Web application, things get more complicated, since the COM objects must be installed and configured on each of the servers.

This isn't as simple as copying the file, but will also require re-registering the servers, plus potentially moving additional support files DLLs, configuration files, and non-SQL data files. If you're accessing databases, you also need to configure the appropriate DSNs to allow each server to access the data source. In addition, if you're using In-Process components, you'll have to shut down the Web server to unload them.

You'll likely want to set up some scripts or batch files to automatically perform these tasks, pulling update files from a central deployment server. You can use the Windows Scripting Host. This is often tricky and can be a major job, especially if you have a large number of cluster nodes and updates are frequent.

Strict operational rules are often required to make this process reliable. In general, the update process is likely to occur one machine at a time so that the Web site can continue to run while the changes and updates are made.

In this scenario only one machine is taken down, updated with the latest version of the application, then put back online. Then, the next machine in the cluster receives the same treatment. Since multiple redundant machines are involved in a cluster, you'll want to have your data in a central location that can be accessed from all the cluster machines. Note that in heavy load balancing scenarios running a SQL backend, the database can become the performance bottleneck!

You need to think about what happens when you overload the database, which is running on a single box. Max out that box, and you have problems that are much harder to address than Web load balancing. At that point, you need to think about splitting your databases so that some data can be written to other machines. For redundancy, you can use the Microsoft Cluster Service to monitor and synchronize a backup server that can take over in case of primary server failure.

Network Load Balancing is very efficient and can provide close to performance improvement for each machine added into the cluster. There is some overhead involved, but I didn't notice it. You may notice that with this level of redundancy, increasing your load balancing capability becomes simply a matter of adding additional machines to the cluster, giving you practically unlimited application scalability as long as the database allows it.

Network load balancing in Windows is fairly easy to set up and run, assuming that you can manage to decipher the horrible documentation in the online help. In this section, I'll take you through a configuration scenario that hopefully will make your installation and configuration much easier, by highlighting important aspects of installation and startup. Let's start by discussing what you need in order to use NLB.

You'll need at least two machines running. Windows Advanced Server or better. You'll need at least one network card in each machine. You can also use multiple network cards? For testing, it's a good idea to have another machine that can run a Web stress testing tool to let you see how the cluster works under load. For example, you have found nodes in the cluster and want to check whether Load Balancing is working or not.

Create different four shares on four nodes and try to access them from one machine. You must get each time different share when browsing using UNC patch. NLB doesn't detect application failure. Automatically detects and recovers from a failed or offline computer. Automatically balances the network load when hosts are added or removed. Recovers and redistributes the workload within 10 seconds. The load is automatically redistributed to other nodes when a host goes offline. All the active connections to that host are lost.

If you're internationally taking a node offline, then you can use the drainsstop command to service all the active connections before you take the node offline. You can have a mix of applications running in the NLB cluster. This way you can designate the traffic for database to SQL server node only. NLB can load balance multiple requests from client on the same node or different node.

This is done randomly. NLB automatically detects and removes the failure of NLB Node but it can't judge whether an application is running or stopped working. This should be done manually by running a script.