GSLB Stickiness


Recall from Chapter 10 that some e-commerce applications require that clients remain connected to a server across TCP connections. The same principle pertains to GSLB in which clients must remain connected to a site even when the client refreshes its DNS entry for the site (some browsers refresh their DNS entries every 30 minutes, which may not be long enough for users to complete their transactions). However, because DNS is not extensible, as HTTP is, it cannot inherently simulate stateful connections through the use of such structures as cookies. Alternately, DNS sticky uses source IP sticky to enable your GSLB to remember the site at which a client DNS server was originally directed. If a client issues additional DNS queries for the domain throughout its session, it receives the same IP address from your content network.

You can configure DNS sticky with either source IP hash load balancing method, or by using a stateful DNS sticky table. Recall from Chapter 10 that source IP hash is a stateless load-balancing method in which the content switch hashes the source IP address for every new request to choose an available server. Hashing the source IP address results in the same site for every request from that source IP address. Therefore, hashing ensures that locally cached DNS entries that are refreshed before the end of a transaction are assigned to the same server as the original request.

As you learned from Chapter 10, the drawback to the source hashing method is an uneven selection of sites from client DNS requests. For example, source hashing can cause users in a source NAT environment to all stick to the same site, thus creating an uneven distribution of requests across the sites. The sticky database solution provides a more robust stateful sticky solution than simple hashing. With a sticky database, you can use other, more effective load-balancing methods, such as the proximity methods discussed previously, ordered lists, least connections, or weighted round-robin (WRR).

With CSS DNS-Sticky, you can store the Global Sticky database (GSDB) on a single CSS located at any site and accessed by other CSSs at your other sites. The GSDB is initially empty, and the CSS populates it with mappings of client DNS server IP address to zone indexes as the CSS receives client requests. Figure 12-10 illustrates DNS sticky using the CSS.

Figure 12-10. DNS Sticky


When a CSS at a site receives a client request for a sticky domain from the DNS infrastructure, it sends a lookup request to the GSDB, using the combination of the client's DNS server IP address and the sticky domain name as the key. If an entry exists for the client DNS server and domain in the GSDB, the GSDB returns the appropriate IP address to the requesting CSS. Otherwise, the GSDB CSS indicates that the entry does not exist to the requesting CSS. The requesting CSS then chooses a site using the configured load-balancing method and notifies the GSDB of the selected site. The GSDB stores the client DNS IP-to-zone index mapping so that future requests from the client DNS server for the domain will use the same A record.

The flow for the client request in Figure 12-10 to www.cisco.com is as follows:

  1. The client issues an A record request for the subdomain www.cisco.com to CSS-B in Zone 2.

  2. CSS-B first queries the GSDB stored in CSS-A through its APP connection to CSS-A.

  3. Because the GSDB is empty, CSS-A returns a null answer and CSS-B selects VIP C, using the least-load load balancing method and load information obtained over the APP connection to CSS C. In this example, CSS C is the least loaded when CSS-B receives the client's request

  4. CSS-B sends the A record response to the requesting client DNS server.

  5. The client DNS server informs the client of the IP address of the domain, and the client connects to the VIP on CSS C.

  6. CSS-B sends a database update to the GSDB in CSS-A containing the requested domain, the client DNS server source IP address, and the zone index of CSS-C; that is, CSS-B sends CSS-A the entry ["www.cisco.com," 192.168.10.11, 3].

  7. After a period of time, the client refreshes the DNS entry for www.cisco.com, which in this instance the DNS infrastructure sends to CSS-C.

  8. CSS-C first queries the GSDB on CSS-A, which now contains the entry for the client DNS server/domain/zone index tuple["www.cisco.com," 192.168.10.11, 3].

  9. CSS-A sends its query response to CSS-C.

  10. CSS-C sends the A record of the VIP that it serves to the client DNS server, which was the most appropriate server for the original request in Step 4. The client DNS server then sends the response to the client. Even if CSS-C is considered overloaded in terms of the configured load-balancing algorithm, the stickiness feature overrides the load thresholds for the sake of maintaining session persistence. However, when the original site is completely down, the CSS overrides the DNS-sticky feature with a new site that it chooses based on the configured load-balancing method.

For each CSS, you can manually configure sticky to apply only to the domains you want, using the configuration in Example 12-7.

Example 12-7. Configuring DNS-Sticky on the CSS

 CSS A app-udp  app  dns-server zone 1 tier1 "Site A" weightedrr  app session 172.16.10.1  app session 10.1.10.1 dns-server  dns-record a www.cisco.com 192.168.10.100 3600 single kal-ap weight 5 sticky-enabled  gsdb  gsdb ttl 14400 CSS B app-udp  app  dns-server zone 2 tier1 "Site B" weightedrr  app session 172.16.10.1 app session 192.168.10.1  dns-server  dns-record a www.cisco.com 10.1.10.100 3600 single kal-ap weight 10 sticky-enabled  gsdb-interface primary 192.168.10.1 CSS C app-udp  app  dns-server zone 3 tier1 "Site C" weightedrr  app session 10.1.10.1  app session 192.168.10.1 dns-server  dns-record a www.cisco.com 172.16.10.100 3600 single kal-ap weight 15 sticky-enabled gsdb-interface primary 192.168.10.1 

In the configuration in Example 12-7, the GSDB is enabled on the CSS-A using the gsdb command. CSS-B and CSS-C are each configured with a GSDB interface pointing to CSS-A using the gsdb-interface command. CSS-B and CSS-C query the GSDB configured with this command for all A records configured as sticky. You can configure your A records as sticky by adding the keyword sticky-enabled to the dns-record command. The gsdb ttl specifies the time that sticky entries exist in the GSDB. When a new request arrives for an entry, the GSDB resets the TTL for that individual entry to the value you specify with this command.

Note

The TTL you configure with the gsdb ttl is the time during which the GSDB stores the sticky A record in its databasethis TTL does not affect the TTL that the CSS advertises to client DNS servers in A record answers. Alternately, you can modify the TTL value in CSS A record answers for domains using the TTL option in the dns-record command.


You can also configure stateful DNS sticky in your proximity environment. The CSS containing the PDB houses the GSDB database and answers sticky queries from CSSs that you configure as PDNS servers. When the PDNS receives the client request for a sticky domain, it first queries the GSDB for the client DNS server IP address. If the GSDB contains the queried IP address, the PDNS formulates the DNS response for the returned site. If the site specified in the GSDB is down, the PDNS contacts the PDB for the client DNS server IP address. If the PDB does not contain the client DNS server IP address, it coordinates probes across the available sites, as described previously, and informs the GSDB of the new mapping.



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

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