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 .. 38 39 40 41 42 43 < 44 > 45 46 47 48 49 50 .. 70 >> Next

Figure 5.6: Load balancer acts as the authoritative DNS.
Since the load balancer is taking over as the authoritative DNS, replacing the existing DNS server, the network can be affected based on the DNS functionality built into the load balancer. The exact amount of DNS functionality built into the load balancer varies from one product to another. In fact, some products, such as the 3DNS from F5 Networks, have a complete DNS implementation enhanced with GSLB features. Products from Foundry, Nortel, Cisco, and Radware incorporate varying amounts of DNS functionality. If a product can’t handle certain DNS queries, it may choose to drop them, return an error, or forward them to a real DNS server. This can be an issue for customers because this may represent a step down from the prevailing DNS functionality they are used to.
The Load Balancer as Forward DNS Proxy
Figure 5.7 shows how a load balancer works as a forward DNS proxy. A forward proxy server is one that explicitly acts on behalf of another server. The load balancer is registered as the authoritative DNS and the load balancer acts as a proxy to the real authoritative DNS that is deployed behind the load balancer. The load balancer forwards any DNS request to the real authoritative DNS and modifies the appropriate replies from the authoritative DNS to provide GSLB. In this mode, the load balancer may also be used to perform server load balancing for all DNS traffic if there are multiple DNS servers, or else simply forwards them to the DNS server. The VIP on the load balancer is registered and advertised as the authoritative DNS. The well-known port for DNS, port 53, is bound on the VIP to the DNS server(s). When the DNS replies with its usual response, the load balancer selects the best site and modifies the reply transparently. The load balancer needs to modify only those replies that deal with name and address translation for the domain names that need GSLB.
Fitting the Load Balancer into the DNS Framework
Figure 5.7: Load balancer as a forward DNS proxy.
In this approach, we get all the benefits of server load balancing. We can use multiple DNS servers for scalability and availability. We can use private IP addresses for DNS servers and enforce access-control polices to enhance security. We can transparently add or remove DNS servers. The load balancer does not have to implement the full DNS functionality. It only needs to implement the functionality necessary to make the DNS response smarter for name-to-address resolutions. Further, the GSLB functionality may coexist with the server load-balancing functionality, as shown in Figure 5.8. Here, there are two different VIPs: VIPD and VIP1. VIPD is the IP address advertised as the authoritative DNS and VIP1 is the VIP for the server farm. We can also use just one VIP for both the authoritative DNS and the application server farm by binding the appropriate TCP and UDP ports to the correct servers.
Web servers for in San Jose
Figure 5.8: Concurrent GSLB and SLB in the load balancer.
Fitting the Load Balancer into the DNS Framework
Web servers for vvvvw foocom in ban lose
Figure 5.9: Real authoritative DNS at a different location.
By having a load balancer be the forward DNS proxy, we can now place the DNS server wherever needed.
For example, a customer may want to keep control of the DNS server, but a service provider may provide the GSLB service to the customer by using the load balancer as the forward DNS proxy. The VIP on the load balancer will be registered as the authoritative DNS for the zone for which the service provider is providing the GSLB service. The customer gets to keep control of the DNS and change the configuration at will. However, if the authoritative DNS is located far away over a wide area network (WAN) from the load balancer, there can be additional latency induced whenever the load balancer forwards the DNS query to the authoritative DNS. One easy way to work around this is to have the load balancer cache a DNS response for a certain time, in the same way the local DNS caches the authoritative DNS response. For example, once the load balancer forwards the DNS query for it can cache the authoritative DNS reply for 60 seconds. For all subsequent queries for the same domain name in the next 60 seconds, the load balancer will simply use the earlier response it got from authoritative DNS, but apply the GSLB algorithms to select the best site and modify the DNS reply accordingly. Because the real DNS server is at a different location, the load balancer must use source NAT to force reply traffic to come back through itself, in order to modify the DNS reply.
What if one wanted to avoid any changes to the existing DNS environment? The forward DNS proxy approach is better than replacing the DNS with the GSLB product, but it still requires the VIP on the load balancer to be registered as the new authoritative DNS. This can be accomplished by either placing a new IP address as VIP on the load balancer and registering it, or by moving the IP address of the authoritative DNS to the load balancer as the VIP and giving a different IP address to the authoritative DNS. Either way, we must make some change to the existing authoritative DNS setup. Deploying the load balancer as a Transparent DNS proxy can eliminate any changes to the DNS setup. A transparent proxy is similar in function to a forward proxy, except that it acts as a proxy transparently.
Previous << 1 .. 38 39 40 41 42 43 < 44 > 45 46 47 48 49 50 .. 70 >> Next