Exploring Distributed Director Technologies


The drawback to DNS load balancing is that client DNS servers are blindly sent A records for each site, even if one of the sites is overloaded or goes down completely. Instead of using DNS load balancing, you can use the Distributed Director (DD) to intelligently distribute requests across your sites. The DD is the GSLB equivalent of the SLB Local Director (LD) device discussed in Chapter 10, "Exploring Server Load Balancing." As you learned, Cisco retired the LD and replaced it with the features and functionality of the CSS and CSM. Similarly, Cisco previously packaged the Distributed Director (DD) within a standalone GSLB hardware appliance. However, Cisco also retired the DD hardware appliance but ported the DD features to the Cisco IOS platform.

Note

Future GSLB development is moving towards the Global Site Selector (GSS); therefore, you should consider using GSS in the place of the DD for GSLB. However, as Figure 12-4 suggests, a core GSS can be used with the CSS and CSM located at individual sites for site selection and request distribution using the Content Application Peering Protocol (CAPP).


Figure 12-4. Distributing DNS Requests Across Sites


Figure 12-4 shows how you can place a router running DD or a GSS in a multisite distributed network.

DDs do not contain full DNS server software but can respond to iterative DNS requests with A records for a small number of subdomains. To configure your DD to respond to A record requests, you must delegate authority of the domain of your distributed application from your iterative DNS server to your DD. To do this, you can add the following NS record and A record to your iterative DNS server, thus delegating the domain to the DD:

 www.cisco.com. IN NS dd.cisco.com. dd.cisco.com. IN A 10.1.10.1 


You can locate your DD at your organization's headquarters, or at any one of the sites. To configure your DD to respond to A record requests from clients, first create the SOA record on the DD as follows:

 ip dns primary www.cisco.com soa dd1.cisco.com gslb-admin@cisco.com   21600 900 7776000 86400 


Note

With the design in Figure 12-4, if the central site containing the DD and IDNS server goes down, then your entire GSLB goes down. To avoid this, you can enable a DD and IDNS server at each site and configure the TLD DNS server to perform DNS load balancing across the IDNS servers (for the *.cisco.com domains), which in turn can DNS load balance across your DDs (for the www.cisco.com domain).


To enable the DD to respond to A record requests for www.cisco.com with IPs 192.168.10.100, 10.1.10.100, or 172.16.10.100 located at three different sites, enter the following command:

 ip host www.cisco.com 192.168.10.100 10.1.10.100 172.16.10.100 


Now that you have set up basic DNS functionality, you can configure your DD to select one of the available servers, based on one or more of the following DD metrics:

  • Randomized distribution

  • Proportional distribution

  • Absolute preferences

  • Routing protocol metrics

  • Round Trip Times (RTT)

  • Boomerang

If you specify more than one metric for a server, you can assign a priority that the DD uses to decide which metric to use in selecting a server. If there is a tie across the sites or if the metric fails to yield a result, the DD uses the next highest priority metric to select the site. To configure your DD to randomly select one of the IP addresses and assign the random metric a priority, you can use the command

 ip director host www.cisco.com priority random 40 


This command gives the random metric a priority of 40, but because it is the only metric configured thus far, the DD uses it for all requests for the domain. A metric with a lower priority number has an overall higher priority.

You can also proportionally divide requests among available sites using the commands

 ip director server 192.168.10.100 portion 1 ip director server 10.1.10.100 portion 3 ip director server 172.16.10.100 portion 2 ip director host www.cisco.com priority portion 10 


With these commands, the server 192.168.10.100 receives one of every six requests, 10.1.10.100 receives three of every six requests (that is, one half of the requests), and 172.16.10.100 receives two of every six requests. Additionally, the priority for the portion metric is 10.

Unlike standard BIND DNS servers, DDs have the ability to determine if the sites are available before answering the client's DNS A record request with an A record response. With this design, when the DD receives DNS requests from client DNS servers, the requests can be intelligently load balanced to the different sites, thus avoiding sending clients to sites that are unavailable. To ensure that the IP address that your DD selects is available, you can configure the DD to first attempt to connect to the available sites using the command

 ip director host www.cisco.com connect 80 interval 300 


This command attempts to connect to port 80 every 300 secondsthe DD caches each IP address that it successfully connects to for 60 seconds. Additionally, if you configure random selection, the DD randomly selects among the cached IP addresses for 60 seconds for each subsequent request for the domain.

To configure a primary/backup setup (that is, absolute preference), you can use the preference keyword to direct clients to a backup site if the primary site(s) is down.

 ip director server 192.168.10.100 preference 3 ip director server 10.1.10.100 preference 3 ip director server 172.16.10.100 preference 5 ip director host www.cisco.com priority admin 15 


This configuration assigns 192.168.10.100 and 10.1.10.100 as primary sites and distributes requests across the two using the portions you configured previously (that is, 1/6 and 1/2, respectively). If either of these two sites fails, the backup site 172.16.10.100 will take over. The primary/backup metric is called admin and is given the priority 15 in this example.

Director Response Protocol and Boomerang Protocol

Cisco developed Director Response Protocol (DRP) as a simple way for the DD to communicate with routers at remote sites. Based on information exchanged between the DD router and DRP agent routers, the DD can select the site with the best routing metrics and shortest round-trip time (RTTthe sum of the forward and return paths to/from the client DNS server). Additionally, using the Boomerang protocol in conjunction with DRP, the DD can use the site with the shortest return path time to the client.

To determine the routing metrics for the individual sites, the DD can learn the following routing protocol information from the remote routers using DRP:

  • DRP external (drp-e) Number of BGP autonomous systems between the DRP agent and the client DNS server.

  • DRP internal (drp-i) The IGRP or EIGRP routing distance between the DRP agent and the closest Autonomous System Border Router (ASBR).

  • DRP server (drp-s) The IGRP or EIGRP routing distance between the origin server and DRP agent. You shouldn't use DRP-I or DRP-S if you use an IGP other than IGRP or EIGRP.

Figure 12-5 illustrates what each of these metrics means.

Figure 12-5. The DRP-E, DRP-I, and DRP-S Routing Metrics


When the central DD receives an A record request from a client, it queries the DRP agents at each site to look up the DRP-E, DRP-I, and DRP-S routing metrics based on the client and origin server IP addresses. The sum of these three metrics gives the total routing distance between the origin server at each site and the client. The DRP agents then respond to the central DD, which then compares the returned metrics from each site and decides which site's A record to send to the client. In Figure 12-5, the DRP-S and the DRP-I are the same for both sites, but the DRP-E values are different and thus break the tie. To configure a router as a DRP agent, use the command

 ip drp server 


To configure DRP on the central site DD, you must associate the server IP addresses with router DRP agents located at the individual sites

 ip director server 192.168.10.100 drp-association 192.168.10.1 ip director server 10.1.10.100 drp-association 10.1.10.1 ip director server 172.16.10.100 drp-association 172.16.10.1 ip director host www.cisco.com priority drp-e 20 drp-i 25 drp-s 25 


If you do not have access to a router at each site that has the necessary routing information to supply routing metrics for the site, you can use RRT calculations or Boomerang instead. The DD supports the following stateless time-based metric calculations:

  • ICMP probes If you use ICMP probes, the DD directs all the DRP agents to send an ICMP echo request to the client DNS server. When a DRP agent receives the ICMP echo response, it calculates and reports the RTT to the coordinating DD using the DRP protocol.

    Note

    DD's usage of RTT is stateless because the DD does not store per-client RTT information. Alternately, the CSS uses a stateful Proximity Database (PDB), which you will learn about later in this Chapter.


  • TCP probes If you use TCP probes, the DD directs all the DRP agents to send TCP SYN/ ACK segments to the client DNS server on TCP port 53. When the client DNS server receives the SYN/ACK for an invalid connection, it should send a TCP RST packet in response. The DRP agent uses this response to calculate the RTT to report to the coordinating DD. Use the keyword drp-r to specify the priority of the ICMP or TCP probe metric using the ip director host priority command.

    Note

    As you learned previously, most DNS servers use TCP port 53 for zone transfers to achieve reliable delivery of zone files. As a result, most DNS servers listen on TCP port 53. If the DD cannot access the DNS server on TCP port 53, the proximity calculations for the particular client DNS server will not succeed.


  • Boomerang DNS racing If you use Boomerang DNS racing, the coordinating DD forwards the A record request to the DRP agents. In response, the DRP agents formulate a DNS A record response to send directly to the client DNS server. The client DNS software uses the first A record response it receives as the response for the requesting client. With the Boomerang metric, the coordinating DD must know the RTTs between itself and other sites in advance in order to ensure that each DRP agent sends the A record response at the same time. Use the keyword boomerang to specify the priority of the Boomerang metric using the ip director host priority command.

Note

To make sure that the DRP agents receive the A record request from the DD at the same time, you can configure the Boomerang protocol to synchronize the clocks between the DD and the DRP agents using the ip director drp synchronized command. With synchronized clocks, the DD can specify an absolute wallclock time to send the A record responses. If this command is disabled, which is the default, the DD specifies a relative time to the individual DRP agents based on the measured delay between the DD and the DRP agents.


To configure RRT ICMP or TCP probes, you can use the following command (TCP is the default):

 ip director drp rttprobe [tcp | icmp] 


Like the CSS load calculations that you learned in Chapter 10, the DD differentiates between RTT times using a tolerance value similar to the load step/sensitivity value on the CSS. The tolerance is the percentage difference between RTT values at which the DD deems the RTTs as being different. You can change the tolerance percentage from the default 10 percent to 20 percent using the command

 ip director host www.cisco.com drp-rtt tolerance 20 


You can also change the number of probes that the DRP agents use to calculate the RTTs using the command

 ip director host www.cisco.com drp-rtt probes 2 


You can also use the Boomerang protocol to determine which site has the shortest return path time to the requesting client. Figure 12-6 shows you how Boomerang works.

Figure 12-6. Boomerang Protocol Operation


Consider the example shown in Figure 12-6 in which a client sends an A record request that ends up at the DD subdomain DNS server for the domain www.cisco.com.

  1. The client request arrives at the DD.

  2. The DD sends a DRP packet to each DRP agent. If you configured clock synchronization, the packet includes the wallclock time at which each DRP agent should send its request. If not, the DD staggers the DRP packets such that the DRP agents receive the packets at the same instance in time.

  3. The DRP agents sends the A record responses for the subdomain www.cisco.com to the client DNS server.

Note

The Boomerang protocol, ICMP, and TCP probes assume that the client is in close proximity to its local DNS server, which is the case in the vast majority of DNS environments. Otherwise, proximity-based DNS does not provide any added value to your clients. If possible, evaluate the proximity of clients that are using your application to their DNS servers before enabling a proximity-based solution.


To configure your DRP agents to use the Boomerang protocol, you can use the following command:

 ip drp domain www.cisco.com 


To configure the DD to use the Boomerang protocol and set its priority to 1, use the following command:

 ip director host www.cisco.com priority boomerang 1 


As a security measure, your firewall or router may contain filters that block packets with source IP addresses outside the range you allocated within your network. For example, this measure would prevent someone from maliciously using your network for sourcing Distributed Denial of Service (DDoS) attacks. Because the DD spoofs the client's DNS server IP address, these packets may be blocked before leaving the DD's subnet. To determine whether such filters exist, use a sniffer and the boomerang send-packet command to send a packet with a source address outside the subnet on which the DD resides. The sniffer should be installed on one of your other sites or somewhere on the outside interface of your firewall to see if the firewall blocks the packet. If the sniffer detects the packet, you know that the firewall did not block the packet containing the boomerang-altered source IP address.

Note

The GSS also supports DRP. Refer to your GSS product documentation on Cisco.com for more information on configuring the GSS with DRP.


HTTP Redirection

HTTP redirects can provide GSLB functionality with less involvement of the DNS infrastructure than methods described in previous sectionsthe DD uses HTTP redirects to inform the client of the most suitable site to which to send their requests. If you use HTTP redirection, each site not only requires a separate routable IP address space but also requires a separate domain name. You can use HTTP redirection by having the client issue the HTTP request directly to the DD. The DD then chooses the most appropriate server, using the DNS metrics that you learned about so far (except the Boomerang protocol), to send an HTTP 301 Moved response to.

In the previous example, you could assign sites as follows:

  • Headquarters site (Site A) Domain site-a.cisco.com and IP address 10.1.10.100

  • Site B Domain site-b.cisco.com and IP address 172.16.10.100

  • Site C Domain site-c.cisco.com and IP address 192.168.10.100

When the DD receives the HTTP GET request, it uses the metrics you configured to determine the most suitable site and sends an HTTP 301 Moved with the selected site name in the "Location:" header. The client then issues a regular DNS query for IP address of the new domain to connect to with HTTP. If you want to avoid this additional DNS resolution, you do not have to use site-specific domain names but bear in mind that your clients will see the IP address of the site in the URL field of their web browsers instead of a domain name.

With HTTP redirection, you do not delegate your subdomains to your DD (with NS records). Instead, you must create the A record for your DD directly on your IDNS server:

 www.cisco.com. IN A 10.1.10.101 


Note

HTTP redirection is used for HTTP traffic onlyyou cannot use this method for distributing non-HTTP requests, such as FTP and SMTP, across your sites.


Now your clients can establish an HTTP session directly to your DD. To configure your DD to use HTTP redirects to distribute requests across your sites, you first need to enable the HTTP server on the DD and specify the main IP address that clients use to connect to your domain:

 ip director ip-address 10.1.10.101 


You then specify your DD host as having this IP address:

 ip host www.cisco.com 10.1.10.101 


Note

HTTP redirection occurs after the DNS resolution occurs. Additionally, with HTTP redirection the DD sees the source IP address of the client, and not the IP address of the client's DNS server.


You then create an additional hidden domain (that is, www-servers.cisco.com) to allocate to the group of sites, and specify the site IP addresses to this domain. Note that this domain will be used only in the DD configuration.

 ip host www-servers.cisco.com 10.1.10.100 172.16.10.100 192.168.10.100 ip dns primary www-servers.cisco.com soa dd1.cisco.com gslb-admin@cisco.com 


Now you can specify the names you wish to assign to your sites, which the DD uses to redirect your clients to

 ip director server 10.1.10.100 server-name site-a.cisco.com ip director server 172.16.10.100 server-name site-b.cisco.com ip director server 192.168.10.100 server-name site-c.cisco.com 


Note

The Content Switching Module (CSM) and the Content Services Switch (CSS) also support HTTP redirection. For more information on configuring HTTP redirection on the CSS and CSM, refer to the technical documentation on Cisco.com.


A Robust Distributed Director Configuration

Example 12-2 shows you the complete central DD configuration that you have learned about so far (except the Boomerang protocol). For the DRP agents, you simply need to enable the DRP agent using the ip drp server command.

Example 12-2. Sample DD Configuration

 ip host www.cisco.com 10.1.10.101 ip host www-servers.cisco.com 10.1.10.100 172.16.10.100 192.168.10.100 ip host dd1.cisco.com 10.1.10.1 ! ip dns primary www.cisco.com soa dd1.cisco.com gslb-admin@cisco.com ip dns primary www-servers.cisco.com soa dd1.cisco.com gslb-admin@cisco.com ! ip director ip-address 10.1.10.101 ip director server 10.1.10.100 portion 3 ip director server 10.1.10.100 preference 3 ip director server 10.1.10.100 drp-association 10.1.10.1 ip director server 10.1.10.100 server-name site-a.cisco.com ! ip director server 172.16.10.100 portion 2 ip director server 172.16.10.100 preference 5 ip director server 172.16.10.100 drp-association 172.16.10.1 ip director server 172.16.10.100 server-name site-b.cisco.com ! ip director server 192.168.10.100 portion 1 ip director server 192.168.10.100 preference 3 ip director server 192.168.10.100 drp-association 192.168.10.1 ip director server 192.168.10.100 server-name site-a.cisco.com ! ip director host www.cisco.com drp-rtt tolerance 20 ip director host www.cisco.com drp-rtt probes 2 ip director host www.cisco.com priority drp-r 5 portion 10 admin 15 drp-e 20   drp-i 25 drp-s 25 random 40 ip director drp synchronized ip director host www.cisco.com connect 80 interval 300 



Content Networking Fundamentals
Content Networking Fundamentals
ISBN: 1587052407
EAN: 2147483647
Year: N/A
Pages: 178

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net