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:
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 ProtocolCisco 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:
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:
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.
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 RedirectionHTTP 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:
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 ConfigurationExample 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
|
EAN: 2147483647
Pages: 178