Open 24 Hours: Load Balancing

The proper level of load balancing services can ensure consistent availability of Web services.

In today's world, business hours are 24x7. Since Internet buyers and browsers come from around the globe at all hours, downtime is the one thing you can't afford. You need a reliable solution for maintaining and managing highly available Web services, and a solid resiliency or continuity strategy.

A complete resiliency strategy addresses each layer of the service equation: presentation, application logic and data services (see Figure 1 below). There are specific technologies required for each, but for the presentation layer, the technology focuses on load balancing or redirecting service requests to a server farm. Each of the load balancing solutions examined here is designed to meet those requirements. The first is Microsoft Windows Server 2003's native Network Load Balancing Services. The other two are hardware-based—the WebMux Pro from CAI Networks and F5 Networks' Big IP Local Traffic Manager.

Figure 1. Setting up a complete resiliency strategy.
Figure 1. To set up a complete resiliency strategy, you need to use appropriate technologies to support each of the three architectural layers—presentation, application logic and data services. (Click image to view larger version.)
On the strength of its features, security capabilities and interface, where it scored three perfect 10s, Big IP won top honors as the Redmond Roundup Champion, an award for the leading product in each roundup that debuts in this issue. With its Redmond Rating score of 9.2, it also earns the Redmond MVP—Most Valuable Product—award, which also debuts in this issue for any product that scores 9.0 or above.

Sharing the Load
Microsoft Network Load Balancing Services
Microsoft has enhanced the Network Load Balancing (NLB) Services in Windows Server 2003 to make it easier to use and more accessible. Like Microsoft Clustering Services, it's installed by default with Windows Server. This means you don't have to reboot the server to configure NLB. It's really only an additional driver that runs on the network interface card.

In Windows 2000, you had to configure the network load balancing clusters manually on the interface card for every server within the cluster. This method caused a lot of errors and incorrectly configured clusters.

Not so in Windows Server 2003—to create a load-balanced cluster, all you need to do is launch the NLB Manager, right-click on NLB Clusters and select New Cluster. This launches the NLB Cluster Wizard. Provide a name for the cluster, its IP address and the communication mode it will use. Unicast is the best choice with at least two network interface cards for each server, though Windows does support multicast as well.

Microsoft's NLB service is now available with all editions of Windows Server. NLB supports up to 32 servers per cluster.

In This Roundup / Redmond Rating Box
(Click image to view larger version.)

Microsoft's NLB provides two clustering scenarios. The first is strictly for load balancing. This means each machine responds to client requests as they're received. When one machine is busy, another shares the load. In this configuration, each node should handle the same number of clients. It also means each server must be as close to identical as possible.

You can also use NLB clusters for availability. This lets you build a cluster with machines that aren't identical and set different priorities for each. Even in this case, machines need to store identical data.

The core of the NLB service is the wlbs.sys driver that sits between the network interface card and network traffic. It filters all NLB communications and sets individual servers to respond to each request they receive. NLB is similar to a round-robin domain naming system, but provides better fault tolerance. Because every server within the cluster hosts the NLB services, there is no single point of failure. There is also immediate and automatic failover for every server.

Microsoft has made significant improvements to the NLB service in Windows Server 2003. The most notable improvement is adding the NLB Manager, which provides a graphical interface for creating and administering NLB clusters. The second is the ability to make a server a member of more than one NLB cluster. In fact, given the proper combination of hardware and content, a server running Windows Server 2003 can be part of several NLB clusters, each responding to different services.

Overall, NLB is a good solution for organizations that want to start working with load balancing but don't want to invest in a third-party device to do so. Microsoft's Network Load Balancing services provide an easy to use—and free—basic load balancing solution.

Software-free Load Balancing
CAI Networks WebMux Pro Load Balancer
Most other load balancing solutions are hardware-based. One advantage of the Microsoft NLB Service is that it resides on every server in the NLB cluster. That avoids the possibility of a single point of failure.

When looking at hardware-based load balancing, you should consider getting at least two devices to provide redundancy. The last thing you need is to set up a load balancing service and have the device fail during operation. On the other hand, having a hardware device manage the load balancing cluster frees the servers to provide only Web services, which can help improve server performance.

The CAI WebMux Pro is self-contained, 1U in height and installs in minutes. It includes a front-panel menu-driven display and keypad, as well as a Web-based configuration interface (see Figure 2 below). The configuration interface is simple and resembles those of small Internet router/firewalls. In an ideal load balancing scenario, your primary WebMux Pro would handle the entire load balancing workload, while a secondary WebMux would provide failover and constant availability. If the primary load balancer fails, the secondary device takes over and pages the system administrator about the failure.

Figure 2. WebMux Pro's Web-based configuration interface.
Figure 2. WebMux Pro’s Web-based configuration interface—with a few clicks, you can set up both load balancing and failover solutions. (Click image to view larger version.)

The WebMux Pro can handle more than 4,000 new connections per second and a sustained volume of more than 300,000 concurrent connections. It can perform even better when using its network address translation (NAT) feature. The maximum supported number of concurrent connections is more than 5.7 million. By comparison, a public Web site that has 1 million page views per day only gets about 30 new connections per second, and will often peak at 500 concurrent connections during peak hours.

WebMux Pro includes some basic firewall features, such as the previously mentioned NAT, protection against Denial of Service (DoS) attacks and SYN flood attacks and SSL support. It also supports gigabit Ethernet connections, an unlimited number of virtual servers and up to 65,000 real server connections. It can page system administrators in the event of failures, or send email alerts.

Failover from one device to another happens over the network or through a direct device-to-device serial connection. Connections are managed through NAT or out-of-path approaches. You'd normally use the latter when you want the device to handle incoming traffic.

One of WebMux's best features is that there's no software to load on your servers. Also, to take down one of the servers for maintenance or repairs, just turn it off. The WebMux device automatically detects that it's down and reconfigures load balancing to the remaining servers. Once the server is back up, WebMux automatically reinserts it into the farm and begins directing requests its way. By contrast, you have to stop servers in an NLB farm in the NLB Manager interface before restarting.

Overall, the WebMux Pro is relatively inexpensive and easy to install. Configuration is straightforward, taking just a few minutes. Just make sure to reset all the default system passwords, because all devices come with the same passwords.

Serious Traffic Cop
F5 Networks Big IP Local Traffic Manager
The Big IP Local Traffic Manager provides a complete set of services, ranging from load balancing to WAN optimization to firewall packet filtering, all configured through its Web interface (see Figure 3).

Figure 3. Big IP uses a Web interface for configuration.
Figure 3. Like WebMux, Big IP uses a Web interface for configuration. The summary view gives you a high-level view of the objects being managed and their status. (Click image to view larger version.)

Big IP is an application switch designed to provide complete content management services at the application layer. You can link the Local Traffic Manager (LTM) to a Global Traffic Manager (GTM), which provides high availability and site redundancy, since the GTM provides load balancing across sites.

With the LTM/GTM combination, your sites are up and running with a few clicks. The GTM operates through a feature called 3DNS, which automatically chooses the site to which users should be directed at the DNS layer. This lets the LTM take over to provide services.

There are four versions of the LTM—the 1500, the 3400, the 6400 and the 6800—in increasing order of capability and cost. For example, the 1500 can handle up to 500 megabytes per second, while the 6800 can manage four gigabytes per second. That's about eight million concurrent connections.

The LTM works through what F5 calls the TM/OS, or traffic management/operating system. Version 9 of Big IP's TM/OS isolates clients from all server-related services and translates communications between all connected systems. Translations are based on customizable iRules and a universal inspection engine. This engine can inspect and transform payloads, and provide session-aware switching. The base engine gives Big IP most of its functionality, but F5 also has a series of adaptable modules with additional functions like an IP version 6 gateway, SSL acceleration, HTTP compression, and client authentication—all features that provide a comprehensive set of network-based services. With these extra features, Big IP is really in a class of its own when it comes to load balancing.

In terms of load balancing, the Big IP switch works with both static and dynamic balancing methods. It can also verify the state of an application, whether it's based on SQL, session initiation protocol (SIP), light weight application protocol (LDAP), extensible markup language (XML) or the simple object access protocol (SOAP)—and ensure it's available to respond to client requests.

The modular IPV6 gateway seamlessly transforms traffic from IP version 6 to version 4 and vice versa, making it a good choice for organizations that want to make a gradual transition to IPV6. Big IP's content compression also helps speed up your applications, whether they're running in HTTP, XML, Javascript, J2EE or other platforms. The compression feature also helps reduce bandwidth utilization by up to 80 percent in some cases. It can prioritize applications, giving more bandwidth to critical applications while throttling others. It can also supply up to two gigabytes of sustained SSL throughput. Like the WebMux, you'll need two switches for complete load balancing redundancy.

There's no doubt that F5 has done its homework with this system. It goes beyond simple load balancing and provides a comprehensive series of network-based services. Because of this comprehensive service offering, Big IP can simplify your application development, since you can offload many application functions to the switch itself. Big IP is an application proxy that can secure and ensure service delivery. For this reason, integrating Big IP switches into your infrastructure accomplishes much more than just load balancing.

Finding Balance
The decision to go with Microsoft's NLB services or a hardware device like the Big IP or the WebMux Pro is not really an "either-or" decision. It's more based on what you need and what you want to do. If simple network load balancing is what you're looking for, Windows 2003 provides great enhancements to the NLB services, especially through its configuration interface. Windows 2003 also supports multiple virtual IP addresses on the same server, letting one server be a member of multiple NLB clusters. NLB is a good choice if you just want to get your feet wet.

If you want to offload load balancing processing from the servers, you might consider the WebMux Pro.

It's reasonably priced, performs well and is easy to configure. You can easily be up and running in a few minutes. That's the advantage of its "black box" approach.

For service acceleration, network protection, and other capabilities that go beyond simple load balancing, go with the F5 Networks Big IP switch. It's more expensive than the WebMux Pro, but provides a comprehensive set of services, speeds service delivery and completely controls the communication between clients and servers.

Which is the best out of the three? The response is "all of the above," because each fits into a discrete category with respect to load balancing.

More Information

Out of Balance
Not all technologies or services lend themselves to load balancing. That's because any service that can be load balanced must store its variable data elsewhere, usually in a server cluster. This means you must implement services like IIS, ISA Server 2004, Windows Terminal Services and others with the proper data storage architecture design to support the load balanced front end services.

This is one reason why Microsoft offers two free clustering technologies; one for load balancing—the Network Load Balancing (NLB) Service—and another for backend data storage—the Microsoft Cluster Service (MSCS). Microsoft also provides a third clustering solution through Microsoft Application Center Server 2000 which is focused on Component Load Balancing, but you have to buy additional product to access this service.

Together, the three support the three tiers of a modern Web service—presentation, logic and data. Both of the technologies included in Windows 2003 have been available since Windows NT and were much improved in Windows 2000 Server, but they haven't been commonly available until the release of Microsoft's latest server operating system.

— N.R and D.R.

Configuration Questions
There are two primary factors you'll need to consider when setting up your network load balancing clusters with Microsoft's NLB services—whether to use multicast or unicast communications and whether to use single or no affinity. The methods you choose will depend on the configuration of your clusters and what you need them to accomplish.

Multicast Vs. Unicast
Microsoft NLB clusters communicate in either multicast or unicast mode, with unicast as the default. In this mode, the NLB cluster automatically reassigns the MAC address for each server within the cluster because NLB needs to control the MAC addresses to be able to redirect traffic sent to the cluster out to individual servers. If every server has only one network interface card (NIC) though, they can't communicate with other servers in the cluster because of the MAC address change. As far as the server is concerned, every other server has the same MAC address as it does itself. The NLB process must be the communication point. There's one reason why it's best to install two NICs in each server. With two NICs, you can communicate directly with the server by using the NIC that is not part of the cluster.

In multicast mode, NLB assigns two multicast addresses to the cluster adapter, ensuring that all servers within the cluster can communicate with each other because there are no changes to the original MAC addresses. This mode has its disadvantages as well, especially if you use Cisco routers, which reject the address resolution protocol (ARP) response sent by the cluster host. If you use Cisco routers with an NLB cluster in multicast mode, you must manually reconfigure the routers with ARP entries, mapping the cluster IP address to its MAC address.

In Windows 2003, Microsoft has reduced the impact of this discrepancy by letting you limit the range of multicasts to the Internet Group Management Protocol (IGMP), which helps control multicast configurations. Multicast mode is still preferable if you need to configure each server differently. For example, it lets you change the load a server can take on compared to the others. This is quite useful if your servers aren't identical and some can respond faster than others.

Either way, you should always use two NICs on each server. One advantage of doing so is that it lets you configure one card to receive incoming traffic and the other to send outgoing traffic, making your servers more responsive. You can also ensure that if your NLB cluster is only the front end of a complex clustering architecture (like the one illustrated in Figure 1), all back end communications are handled by the non-clustered NIC.

If you expect your NLB clustered servers to handle extremely high traffic loads, you can use gigabyte Ethernet cards to improve communication speed and host only essential networking services on each card. You can also add more NICs to every server and bind the NLB service to each one, improving the overall response time for each member.

Single Affinity Vs. No Affinity
Another major characteristic of NLB clusters are affinity modes. This refers to the way NLB load balances traffic. Single affinity is load balancing based on the source IP address of the incoming connection. It automatically redirects all requests from the same address to the same cluster member.

No affinity refers to load balancing based on both the incoming IP address and its port number. Class C affinity is even more granular than single affinity. It ensures that clients using multiple proxy servers to communicate with the cluster are redirected to the same cluster member. Either no affinity or Class C is useful when supporting calls from networks using network address translation (NAT), because these present a single IP address to the cluster. If you use single affinity mode and receive a lot of requests from NAT networks, these clients won't benefit from the cluster experience since all requests will be redirected to the same server.

If you use an NLB cluster to provide VPN connections using either L2TP/IPSec or PPTP sessions, you have to configure your cluster in single affinity mode to ensure that client requests are always redirected to the same host. You should also use single affinity for any application using sessions over multiple TCP connections to ensure that the entire session is mapped to the same server. Another instance in which single affinity is required is if your client sessions use a secure socket layer (SSL) to connect to NLB servers.

Single affinity doesn't give you the same load balancing results as no affinity. You'll have to consider the type of requests you expect before deciding on your cluster architecture. The make-up of your applications may also affect your architecture decision. For example, if your application is based on ASP.NET and IIS version 6.0, then you can design the application to manage the session state at the application logic layer instead of the presentation layer. This frees you to use any type of affinity you need because the NLB cluster doesn't have to manage the state of user sessions.

On the other hand, if you're using older applications, you'll have to keep the session state issue in mind when you design your NLB cluster. Microsoft provides a ton of information on NLB clusters and cluster design (see Additional Resources). You can also use Table 1 to prepare your cluster configuration.

— N.R and D.R.

Table 1—Configuration Checklist for Network Load Balancing

The following table can help you prepare your load balancing cluster configuration:

Part I — Application or Software
Application or service to be supported by NLB
(Web Server, FTP, Media or VPN server)
Protocol support required TCP UDP Both
Inbound port usage (typically Port 80)
Outbound port usage (numbers can range from 1024-65535)
Is the use of NLB required for Performance Scaling Fault Tolerant
Part II — Physical Network Constraints
Number of hosts required in the cluster (1-32)
Is there a need for public (Internet) and private (Intranet) connections? Yes No
Are staging servers and interhost communication required for the cluster? Yes No
Number of network interface adapters required (minimum of 2)
Are there special network considerations? (switched network, proxy servers) Yes No
Part III — Physical Cluster Configuration
Select multicast or unicast (unicast recommended) Multicast Unicast
Select the cluster's full Internet name
Select the cluster's virtual IP address
Select the subnet mask for the virtual IP of the cluster
Select the dedicated IP address for each host in the cluster
Select the subnet mask for the dedicated IP for each host in the cluster
Select the priority for each host in the cluster
Part IV — Cluster Traffic Handling Configurations
Port Rule 1
Select the required port range (Minimum, Maximum)
Select TCP, UDP, or both for the supported protocols TCP UDP Both
Select the filtering mode for inbound traffic Multiple Single Disabled
Select client affinity None Single Class C
Select load weight for each host when filtering is Multiple (percent)
Select handling priority for this rule when filtering is single (1-32)
Port Rule 2
Select the required port range (Minimum, Maximum)
Select TCP, UDP, or both for the supported protocols TCP UDP Both
Select the filtering mode for inbound traffic Multiple Single Disabled
Select client affinity None Single Class C
Select load weight for each host when filtering is Multiple (percent)
Select handling priority for this rule when filtering is single (1-32)
Part IV — Cluster Traffic Handling Configurations (continued)
Port Rule 3
Select the required port range (Minimum, Maximum)
Select TCP, UDP, or both for the supported protocols TCP UDP Both
Select the filtering mode for inbound traffic Multiple Single Disabled
Select client affinity None Single Class C
Select load weight for each host when filtering is Multiple (percent)
Select handling priority for this rule when filtering is single (1-32)
Port Rule 4
Select the required port range (Minimum, Maximum)
Select TCP, UDP, or both for the supported protocols TCP UDP Both
Select the filtering mode for inbound traffic Multiple Single Disabled
Select client affinity None Single Class C
Select load weight for each host when filtering is Multiple (percent)
Select handling priority for this rule when filtering is single (1-32)
Port Rule 5
Select the required port range (Minimum, Maximum)
Select TCP, UDP, or both for the supported protocols TCP UDP Both
Select the filtering mode for inbound traffic Multiple Single Disabled
Select client affinity None Single Class C
Select load weight for each host when filtering is Multiple (percent)
Select handling priority for this rule when filtering is single (1-32)

Additional Resources for Network Load Balancing:


comments powered by Disqus

Subscribe on YouTube