This link has been bookmarked by 45 people . It was first bookmarked on 25 Jul 2006, by Zhe sto.
-
04 Jun 15
-
28 Jul 14
-
03 Dec 13
-
13 Nov 13
-
The fundamental purpose of GSLB
The overwhelmingly most compelling reason that Internet sites are hosted in multiple locations is high availability. If a catastrophic event causes one of the sites to become unavailable, one or more remaining sites must be able to service requests from users, such that business can be continued. Given the following example, with servers hosted in sites in Los Angeles and New York City:
-
If the Internet connection fails, or the power fails, or the switching or local server load balancing (SLB) equipment fails, or a Denial of Service (DoS) attack occurs, or if a catastrophic event causes the loss of the entire site, the GSLB device should detect the failure and route requests to the remaining site, so that clients can connect successfully and business can continue.
-
DNS resolution
At this point a review of DNS resolution with GSLB is in order.
-
Site A in Los Angeles has a virtual IP address (VIP) of 1.1.1.1, and Site B in NYC has a VIP of 2.2.2.2. A GSLB device is acting as the authoritative name server for www.trapster.net. Upon a DNS query for www.trapster.net, the job of the GSLB is to determine whether to return the IP address 1.1.1.1 or 2.2.2.2.
<!--[if !supportLists]-->1) <!--[endif]-->The stub resolver (a software program running on the client computer) makes a request to the assigned local DNS server, which in this example is in the client’s Internet Service Provider (ISP) DNS server farm in Atlanta, Georgia. The client must receive either an answer, or an error. This is called a “recursive” query. Note: the stub resolver program is not capable of “digging” through the Internet to find the answer. That is the job of a DNS server.
<!--[if !supportLists]-->2) <!--[endif]-->The client’s DNS server performs an “iterative” resolution on behalf of the client, querying the root name servers and eventually ending up at the authoritative name server for www.trapster.net. In this case the GSLB device is that authoritative name server.
<!--[if !supportLists]-->3) <!--[endif]-->The GSLB device performs some sort of communications with software or devices at each site, gathering information such as site health, number of connections, and response time.
<!--[if !supportLists]-->4) <!--[endif]-->The software or device at each site optionally performs some sort of dynamic performance measurement, such as a round trip time (RTT), or topographical footrace, or BGP hop count, back to the client’s DNS server.
<!--[if !supportLists]-->5) <!--[endif]-->Using the information gathered in steps 3 and 4, the GSLB device makes a determination as to the preferred site, and returns the answer to the client’s DNS server. The answer is either IP address 1.1.1.1 or IP address 2.2.2.2. If the time to live (TTL) is not set to zero, the answer is cached at the client’s DNS server, so that other clients that share the server will make use of the previous calculation (and not repeat steps 2 through 4).
<!--[if !supportLists]-->6) <!--[endif]-->The DNS answer is returned to the client’s stub resolver.
-
Unfortunately, the DNS caches in browser applications cannot observe the TTL. This is because a DNS query must be made via a standard available system call, gethostbyname() (or an equivalent derivative), which returns one or more IP address associated with the queried name (that system call does not allow the calling application to see the TTL). To get around this issue, the browser application developers use a configurable TTL value. In IE this value defaults to 30 minutes, and is configurable in the Windows Registry on the client. In Netscape, the value defaults to 15 minutes, and is configurable by the addition of a line of script to the prefs.js file.
-
Browser caching has extremely significant implications for GSLB. If a given site becomes unavailable because of a catastrophic failure, all clients that are currently using the site will experience connection failures until the browser DNS cache expires or they restart their browser or computer.
-
Internet sites already have DNS servers. Internet site owners purchase GSLB devices, often for as much as $30,000 per unit, for the features these devices provide over and above the capabilities that come for “free” with DNS servers.
-
The only way to achieve high-availability GSLB for browser based clients is to include the use of multiple A records
-
Most all current commercial GSLB solutions return multiple A records in what is sometimes called an “ordered list”, assuming that the order will be passed all the way to the client stub resolver unchanged<!--[if !supportFootnotes]-->[3]<!--[endif]-->. Unfortunately, that assumption is incorrect.
The order in which the addresses are returned can and will be changed by the client’s DNS server!
DNS servers do this to help with even distribution of traffic to multiple sites, and this is default behavior on most DNS servers at most providers<!--[if !supportFootnotes]-->[4]<!--[endif]-->. It was previously thought that setting a TTL value of zero in step 1 above would prevent this re-ordering from happening, but unfortunately that is not true. Because the order of the list of A records can and will be changed, completely outside the control of a GSLB device or authoritative name server, it is not possible to deterministically prefer one site over another.
-
BGP Host Route Injection
There is one more method, usually called BGP Host Route Injection (HRI), but also called “Global IP” by at least two vendors. It is not simply a backup method sometimes used in conjunction with DNS based GSLB, but rather a method used in place of DNS based GSLB. Here’s a high level overview of how it works:
-
0) <!--[endif]-->(DNS resolution takes place, only one IP address, 1.1.1.1, is returned in response to a query for the FQDN www.trapster.net).
<!--[if !supportLists]-->1) <!--[endif]-->Server load balancers (or routers) at Sites A and B each advertise to the Internet “I’m IP address 1.1.1.1”. Internet routers exchange metrics via BGP, and propagate this information to the router closest to the client.
<!--[if !supportLists]-->2) <!--[endif]-->The client now connects to the topographically closest site.
Now all servers, or even the Internet connection, power, SLB, or switching equipment fail, or there is a catastrophic site loss.
<!--[if gte vml 1]><v:shape id="_x0000_i1038" type="#_x0000_t75" alt="A diagram showing two sites, a Global Server Load Balancer GSLB method commonly known as "BGP Host Route Injection HRI", and BGP route convergence after a site failure." style='width:358pt;height:269pt' o:ole=""> <v:imagedata src="GSLBPageOfShame_files/image027.emz" o:title=""/> </v:shape><![endif]--><!--[if !vml]-->
<!--[endif]--><!--[if gte mso 9]><xml> <o:OLEObject Type="Embed" ProgID="PowerPoint.Show.8" ShapeID="_x0000_i1038" DrawAspect="Content" ObjectID="_1298373019"> </o:OLEObject> </xml><![endif]--><!--[if !supportLists]-->1) <!--[endif]-->The SLB at Site A detects the server failure, and stops advertising via BGP that it is IP address 1.1.1.1 (or the SLB or connection are destroyed, in which case advertising also obviously stops).
<!--[if !supportLists]-->2) <!--[endif]-->Route convergence between Internet routers occurs, so that the path to Site A is eventually removed.
<!--[if !supportLists]-->3) <!--[endif]-->The client now connects to IP address 1.1.1.1, but at Site B.
Though in theory this method may look like the Holy Grail of GSLB, it is seldom implemented. Here’s why:
<!--[if !supportLists]-->· <!--[endif]-->Internet routing is quite complex, and the practice of advertising the same IP address for disparate locations does not work reliably. If route maps change during a client session, packets may flow to Site A and Site B intermittently, so that the client cannot successfully connect even if both sites are functioning properly.
<!--[if !supportLists]-->· <!--[endif]-->Route convergence can take considerable time. In the case of a failure, the client browser will time out, presenting a failure dialog. If the user persists in manual reattempts, eventually a connection will succeed, but it is not uncommon for this to take more than five minutes. Such down time is usually deemed unacceptable for commercial Web applications.
<!--[if !supportLists]-->· <!--[endif]-->BGP route advertisements that are single IP addresses (hosts) are usually ignored by Internet routers. A possible solution is to instead advertise an entire network address, however doing so simply for the purpose of GSLB constitutes a waste of expensive IP addresses (since only one, or maybe a handful, are actually used).
<!--[if !supportLists]-->· <!--[endif]-->Source IP address filters (sometimes called “bogon” filters), configured on routers for security purposes, often prevent devices from advertising IP addresses from multiple locations. This problem is often solvable by negotiations with ISPs, but is nevertheless another complication, as in practice “bogon” filters that are removed by such negotiations are often inadvertently added back by ISP personnel, causing downed sites, requiring trouble ticket calls, etc.
BGP HRI is a sound approach for closed networks, and may be made to work for some Internet applications, but is quite rare because it does not work in practice nearly as well as it does in theory.
Conclusion
-
The only way to achieve high availability GSLB for browser based clients is to return multiple A records, but returning multiple A records diminishes any possibility of deterministic site selection. Because of this features such as basic two site active-standby, DNS persistence, RTT or footrace or BGP hop count based site selection, IP address based geotargeting or IANA table based selection are all effectively useless.
The good news – now customers can use the $30,000/unit they would have spent on GSLB devices to add more servers and inter-site synchronization capabilities!
Watering it down
At the risk of helping the technically correct to obfuscate the obvious<!--[if !supportFootnotes]-->[6]<!--[endif]-->, the following:
At least in theory, a GSLB device could operate in a “best choices, round robin” type fashion. For example, if a FQDN is hosted in two sites in Europe and two sites in the US, the GSLB could determine that a given client is best served by the Europe sites and return only the Europe A records to that client’s DNS server. The client’s DNS server would then round robin between those. From the following diagram:
-
-
07 Jul 12
-
26 Mar 12
-
24 May 11
-
05 May 11
-
24 Apr 11
-
30 Mar 11
-
15 Sep 10
-
29 Aug 10
-
18 Jul 10
-
27 Jun 10
-
26 Apr 10
-
02 Sep 09
-
09 Apr 09
-
31 Mar 09
-
07 Feb 09
-
22 Oct 08
-
01 Jul 08
-
28 Apr 08
-
27 Dec 07
-
13 Dec 06
-
DNS based Global Server Load Balancing (GSLB) solutions exist to provide features and functionality over and above what is available in standard DNS servers. This paper explains the pitfalls in using such features for the most common Internet services, including HTTP, HTTPS, FTP, streaming media, and any other application or protocol that relies on browser based client access.
-
-
04 Sep 06
-
25 Jul 06
-
05 Jun 06
M GOne man's opinions of some approaches to wide-area dns-based load balancing and their drawbacks. See also Part II (link in document).
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.