in black and white
Main menu
Home About us Share a book
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics

Load Balancing Servers, Firewalls and Caches - Kopparapu C.

Kopparapu C. Load Balancing Servers, Firewalls and Caches - Wiley Computer Publishing, 2002. - 123 p.
ISBN 0-471-41550-2
Download (direct link): networkadministration2002.pdf
Previous << 1 .. 37 38 39 40 41 42 < 43 > 44 45 46 47 48 49 .. 70 >> Next

If the local DNS receives multiple IP addresses as part of the DNS reply, it may give one IP address to each of its clients in a round-robin manner.
In addition to the local DNS caching the DNS responses, the client browser also caches the DNS response. Unfortunately, popular client browsers currently ignore the TTL set by the authoritative DNS. Versions 3.x of Microsoft Internet Explorer, for example, cache the DNS response for 24 hours. Unless the browser application is terminated and restarted, it does not query the DNS again for 24 hours for a given domain. Versions 4.x and later cache the DNS response for 30 minutes. Microsoft provides a note on the support section of its Web site on how to change the cache time-out value for Internet Explorer by modifying certain entries in the registry. (Search for keywords ie cache dns timeout in the support section of Microsoft’s Web site.)
Using Standard DNS for load balancing
DNS can be used for load balancing across multiple servers using the standard round-robin mechanism available in the DNS servers. Each IP address configured for the domain name may actually be a VIP on a load balancer that’s bound to several servers connected to the load balancer. DNS can be used for some rudimentary load balancing across the various individual servers or multiple load balancers at different sites where each load balancer performs server load balancing.
But the DNS has no knowledge of which of the different IP addresses is actually working or how much load is on each one of those sites. A site may be completely inaccessible, but the DNS may continue to provide that IP address as part of its reply. We can’t view this as a shortcoming of the DNS architecture because DNS was never designed for GSLB. It was devised as a way to provide the name-to-address translation.
HTTP Redirect
HTTP Redirect
One approach that can be used with no changes to the existing DNS system or configuration is a method called HTTP redirect. The protocol definition for HTTP includes a way for a Web server to reply with an HTTP response that contains a redirect error code and the redirected URL. This informs the browser that it must go to the new URL in order to get the information it’s looking for. Figure 5.5 shows how HTTP redirect works. When a user types the local DNS resolves the name to the IP address of a Web server in New York. When the browser makes the HTTP request, the Web server in New York redirects the browser to The browser goes to the local DNS again to resolve the name to an IP address that is in San Jose. Finally, the browser makes the HTTP request to the server in San Jose and retrieves the Web page content. The server in New York can decide whether and where to redirect the user, based on different parameters or policies.
Figure 5.5: HTTP redirect.
Let’s look at the advantages of the HTTP redirect method. First, there is no change to any of the existing DNS setup or configuration. Second, when the server in New York gets the HTTP request, it knows the client’s IP address, which can be helpful, as we will discuss in the later sections on site-selection policies. Let’s now turn to the disadvantages of the HTTP redirect method. As the name indicates, this method works only for HTTP applications and not for any others. Second, the initial response time now increases as it includes an additional DNS lookup for, establishing a TCP connection with and sending the HTTP request again. Third, since all users must first go to this may become a performance or reliability bottleneck, although this can be alleviated a bit by using standard DNS-based round-robin load balancing.
DNS-based GSLB essentially means a way to get GSLB within the DNS framework. We need to fit the load balancer into the DNS framework and choose the IP address of the best site to serve a particular client. To understand DNS-based GSLB, let’s break it down into two steps. First, how do we get a load balancer to fit into the DNS framework so that it can respond back to clients with the IP address of the best site for a given user? Second, how exactly can the load balancer determine what the best site is?
Fitting the Load Balancer into the DNS Framework
We discuss a few approaches of how a load balancer plugs into the DNS framework to provide GSLB. The
Fitting the Load Balancer into the DNS Framework
approaches vary in the amount of DNS functionality implemented in the load balancer and the impact it has on the existing DNS configuration and setup.
The Load Balancer as the Authoritative DNS
The easiest thing for a load balancer to do is act as the authoritative DNS for a particular zone or a domain name space as shown in Figure 5.6. Since the VIP on the load balancer is advertised as the authoritative DNS, the load balancer will receive all the DNS queries, and therefore it can provide a smart DNS response that a regular DNS could not do. Most GSLB products available in the market today can do this job.
Previous << 1 .. 37 38 39 40 41 42 < 43 > 44 45 46 47 48 49 .. 70 >> Next