Finally, DNS does not provide server load-balancing. So, Server "A" may be overloaded and drop connections, while Server "B" continues to run smoothly. DNS is unaware of the server that's down or not responding, and client requests go unanswered until the failed servers are restored--regardless of other live servers. And any changes you make to your Web site, including the implementation of additional servers or network configuration modifications, will not be instantaneous.

Load-Balancing To eliminate the need for DNS records and improve reliability and system maintenance, you need a technology that can listen to one IP address while balancing the load on several Web servers. Web or TCP/IP load-balancers tackle these tasks for HTTP- and TCP/UDP-based services, such as SMTP, POP, IMAP and NNTP.

Load-balancers can host multiple farms. Real servers can be associated with multiple Web farms and host multiple sites. In effect, larger, more powerful servers are affiliated with multiple Web addresses, while smaller servers operate in a more limited capacity. With the proper preparation and configuration, a load-balancer makes the best use of your Web servers and reduces the costs that you will incur while you perform a site upgrade.

The Payoff The benefits of a load-balancer are twofold. First, a load-balancer eliminates points of failure normally associated with round-robin DNS setups. Load-balancers monitor the state of the services on each server; they routinely check a service's availability via a ping or service request (e.g., retrieving a URL). When a server or service fails to respond, the server is marked as out of service and is no longer sent incoming requests. A load-balancer instead routes the requests to the remaining, active Web servers. When the failed server becomes available, the load-balancer routes requests to it once more.

To provide complete redundancy, all load-balancing products have a fail-over mechanism, which usually requires an additional load-balancer and fail-over cable. When considering the importance of Web-site reliability, the extra cost for a second load-balancer--starting as low as $1,000 and ranging up to $30,000 including configuration and installation--is acceptable.

URL Load-Balancing A distinguishing characteristic of load-balancers is the level at which they can balance Web requests. All load-balancers work at the transport level and can recognize TCP and UDP services based on port number. Some products, however, read the HTTP header space and can differentiate or balance HTTP traffic based on the request URL. This application-level load-balancing gives administrators refined control over content and traffic patterns.

When you use a load-balancer to balance Web content based on URL, you can segment content based on URL path rather than specific domains. A sales farm can then serve all sales content from a sales URL, www.company.com/sales/. You're not limited to one URL for the sales farm and can include /information/sales_contacts/ and any other relevant information to sales.

URL load-balancing varies by way of balancing convention implementation. URLs are typically balanced by URL path. For example, /sales will redirect all content under /sales to sales' content-bearing servers. A unique URL, such as /sales/receipts. html, can also be balanced to specific servers. By analyzing your Web sites' log files and content, you can determine where the load resides and how to segment it effectively. By placing large files on beefy servers, or CPU-intensive scripts on faster multiprocessor machines, URL load-balancing can optimally use your site's resources.

You can place Web sites around the world in an effort to better serve your global clients and regional employees. How then is a surfer guaranteed a fast, reliable response time through traditional round-robin DNS load-balancing schemes? Load-balancing vendors have addressed this with new products aimed at load-balancing across vast geographical architectures.

Think Globally By placing load-balancing products in front of all regional Web sites, each site can relay geographical information to one another. This data includes Internet topology and routing information, some of which is pulled directly from network databases frequently updated. With this information, each global load-balancer can transfer client requests to regional sites that are better equipped. This is done with HTTP redirection within the headers or by physically forcing the connection using TCP. Both methods are virtually seamless and do not affect the end transaction.

Global load-balancing also lets you control site content regionally. Rather than maintain copies of sales data on each regional Web site, you can instruct each global load-balancer to redirect client requests for sales to the appropriate servers. For example, one site may not have all your sales content, so it redirects all sales URL requests to one of the other regional sites that has the necessary content. Although the site may be the closest and fastest site for the user, that site will check with the other sites for the desired content. When clients request content that is located at the site, the other regional sites will redirect the request. And while each transfer introduces some delay, your site's overall response improves, with the best site serving subsequent requests.

Send your comments on this article to Greg Yerxa at gyerxa@nwc.com.