Journey after DNS GSLB

It is interesting to see discussion in load balancing mailing list on GSLB and a popular URL on page of shame. I thought to share my thoughts how the GSLB has advanced to this time.

In the first article of “why DNS based GSLB does not work?” the emphasis is mostly on problems associated with DNS cache and layer7 cookie information. But, at the same time, given its advantage in providing services under site break down these were assumed to be fine.

Before we go into details of modern DNS GSLB, lets see what the second article on GSLB highlights

• Clients are often not topographically close to their caching servers

• calculation of proximity can itself significantly degrade the user experience

• problems with static proximity and Geo-targeting

These problems are very much relevant to DNS based GSLB implementations. There are some enhancements that went into GSLB devices in recent times. Remember, Alteon Content Director?

ACD implemented client proximity in way back in 2000.

From ACDs documentation

Site-Selection Proximity Methods in ACD

The site-selection methods, are:

! FastPath

! SmartPath

! DualPath

! DNS Round-Robin

! DNS FastPath

! MediaPath

The first three methods determine which local domain can provide the fastest route from its

server to the client. The DNS Round-Robin method uses round-robin selection to equalize

domain traffic across distributed sites instead of client proximity to the site. (DNS Round-

Robin does not require an ACD for each local domain.) DNS FastPath awards the connection

based on the fastest route from its server to the client’s DNS server. MediaPath is specifically

designed for MMS requests

True client proximity is achieved by first three methods listed above. Fast path for example, upon receiving the client request, searches its cache to find nearest site. If there is no entry it starts creating one by sending a redirect message to all the sites. Each site responds with REDIRECT packet to client by optional changes in the URL path. Client will open a connection to the first received REDIRECT packet. That ensures the site is closer to the client.

The above implementation carries a security drawback. The firewalls in all the sites should have rules to allow REDIRECT packets that would not look coming up from their internal networks.

In the recent GSLB implementations of some products like Alteon application Switch (NAS) , true client proximity is achieved by addressing the limitations in ACD.

“After receiving the client request, the GSLB device in that site, scans client proximity table. If it does not find entry, it goes on to calculate response time to the client from each site. It sends a response to the client with HTTP text data with the following information

(Assume there are three sites – A, B and C)

http:///cntpurl

http:///cntpurl

•http:///cntpurl

cntpurl—special type of url used by sites to compute RTT

Client X sends an HTTP request to Site A, Site B, and Site C. Client X establishes a TCP connection with Site B and Site C, and sends a cntpurl request. Site B and C respond with a dummy response and

in the process compute the RTT of their TCP connections with the Client X. Site B and Site C update the computed RTTs to Site A. On receiving RTT from Sites B and C, Site A sends the consolidated

RTT list to all sites.

- At this time, Site A serves the request from the client.

- During the next request from the Client X, Site A redirects the HTTP request to the closest RTT Site (Site C in this example).

- Client X opens a new connection with Site C.

- Site C serves the HTTP request.

If the best site is down, the client is given next best site based on RTT in the Client proximity table.

The client proximity table is a cache maintained in all the sites and is completely in sync.

This solution works for all HTTP traffic and works in hand with DNS GSLB. Now lets again go back and see what 2^nd article said. This solution

• Always calculates the true client proximity with a solution that works in hand with DNS GSLB.

• Does not depend on Geo location so no problem with VPN clients

• A little overhead in traffic only during first contact by the client.

I agree completely with the views mentioned in GSLB article and I thought to share the latest features that addressed those problems mentioned in that article.