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

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 .. 44 45 46 47 48 49 < 50 > 51 52 53 54 55 56 .. 70 >> Next

78
Limitations of DNS-Based GSLB
Figure 5.11: GSLB with routing protocols.
There is no limit to how much one can tune the site-selection process. It doesn’t seem worth tuning the process to the maximum extent possible. Rather, the 80-20 rule applies here, whereby 80 percent of the benefits can be obtained with 20 percent effort.
The success of GSLB can perhaps be defined as the percentage of users served directed to a site that provides the best response time at that instant. In the standard DNS round-robin method, this percentage is pretty minimal. As we apply different policies, this percentage goes up; it’s pretty difficult to determine how well a GSLB load balancer will work.
Limitations of DNS-Based GSLB
There are some limitations to the DNS-based GSLB because of the way DNS works. Again, let’s keep in mind that DNS was not designed for GSLB, but we are simply exploiting it for this purpose.
First, end users may be far enough from their local DNS server that the Internet-delay characteristics are not similar for the two. It is very difficult to work around this within the DNS-based GSLB system. There seem to be no reliable statistics on how much of the Internet-user population has this type of DNS configuration. For example, if enterprise users manually set the local DNS to a specific IP address in their network configuration, as the users move from one office to another, they will continue to use the same local DNS. For some enterprises this may not matter at all if the enterprise is a centralized Internet connection for all users. Nevertheless, the increasing use of DHCP in networks greatly increases the probability that the local DNS is pretty close to the end user. Keep in mind that the terms close and far do not mean physical distance, but refer to the network distance and whether the Internet delay will be similar or not for the local DNS and the end user. One example people often misunderstand is when an enterprise user dials into the corporate network from a remote location. If I go to Japan and I connect using a dial-up number provided by Foundry’s internal network, then I am in the same network location as Foundry’s internal computers in San Jose. The reason for this is that all my network traffic will go through Foundry’s remote-access server that provides me the dial-up connection. The fact that I am in Japan does not get me any different Internet delay than Foundry’s
79
GSLB Using Routing Protocols
internal users in San Jose. I will probably experience a longer client-side delay that is specific to me because of the physical circuit distance from Japan to Foundry’s office over the telecommunications carrier’s equipment.
Second, there are some local DNS servers that do not conform to the specification and ignore the TTL values specified by the authoritative DNS. Such local DNS servers cache the DNS response for an indefinite time, providing stale data to end users.
Third, the browsers cache the DNS response and will not make a DNS query unless the browser is terminated and restarted. If we leave the browser and the computer on for a few days, our browser will keep going to the same site, although there may be another site that provides better response time.
Fourth, a site may go down, or site conditions may change drastically after the authoritative DNS sends the DNS reply. If the site is functional, the site may be able to perform an HTTP redirect to an alternate site, which again comes with all the limitations of HTTP redirect, as discussed earlier in this chapter. If the site is not functional at all, we have to rely on the browser’s DNS cache time-out mechanism. Otherwise, the user must terminate and restart the browser to trigger another DNS query to the local DNS.
Despite all the limitations that come with the DNS framework, GSLB provides an array of benefits and represents tremendous improvement over standard DNS.
GSLB Using Routing Protocols
This approach works outside the DNS framework and comes with its own set of limitations. This method can be used typically within a service provider or enterprise network. Nevertheless, this is a very interesting way to accomplish GSLB. In this approach the same IP address is hosted at multiple locations. Once a DNS responds to the user with an IP address for a given domain, this approach attempts to direct requests to the best possible location.
Figure 5.11 shows how GSLB with routing protocols works. In this design, there are two load balancers, A and B, at two different locations. Each has two real servers attached to it. Each load balancer is configured with the same VIP address. The load balancer needs to have a somewhat special functionality here. If the load balancer is able to service requests received to the VIP, it needs to make the VIP available. That means a router can see the VIP through ARP queries and is able to ping it. For the VIP to be available, at least one real server must be available for the load balancer to forward requests to.
Previous << 1 .. 44 45 46 47 48 49 < 50 > 51 52 53 54 55 56 .. 70 >> Next