Disaster recovery is achieved by switching the load balancer domain + - (8) GSLB basic principle DNS resolution (revolutions) (1) based on

=================================================================================================

Taken https://blog.csdn.net/windyf2013/article/details/79727348

原文：Why DNS Based Global Server Load Balancing (GSLB) Doesn’t Work  http://www.tenereillo.com/GSLBPageOfShame.htm

          Why DNS Based GSLB Doesn't Work, Part II   http://www.tenereillo.com/GSLBPageOfShameII.htm

=================================================================================================

 

extract

 

DNS-based global load balancing (GSLB) solution to provide Internet DNS services, and other functions and features than the standard DNS service.

 

This paper describes the most Internet service than HTTP, HTTPS, FTP, streaming media issues, and the other based on B / S structure of the application or protocol, when using GSLB properties will produce.

 

At this point I should add, "If GSLB can simultaneously enhance the B / S structure of high-availability Internet services," but I did not, because people always expect GSLB solution can be deployed very good high availability, it is "obvious" .

 

Starting from the large significance of the Internet, we discuss the behavior of the Internet, of course, you can create custom solutions. For example, it is possible to run special software on the client computer, such a solution is almost for Internet web sites, has never been practical, and therefore not be discussed here.

 

THE Punch line

 

A plurality of records in the DNS returns a response, the best practice is to deploy high availability GSLB. But the return multiple A records will affect the load balancing properties of GSLB some extent (such as flow control or site selection algorithm). So the actual value of the global load balancing (or multi-site traffic control) is doubtful ( see Why DNS-based global load balancing (GSLB) does not work? II ). People have to make a compromise between high availability and load balancing. The following will explain technical.

 

The fundamental goal of GSLB

 

Multi-site deployment of Internet sites to enhance high availability can not be argued, if a catastrophic event leading to a site is unavailable, another site must be able to take over the process the user's request, so that the transaction party sustainable. Here's an example, server sites were deployed in Los Angeles and New York: 

 

Internet connection failure, power outage, SLB equipment failure, Dos attack or catastrophic events will cause the entire site to stop the service, GSLB device must detect the failure and routes the request to the rest of the site to ensure that client requests are answered, the transaction can carry on.

 

DNS resolution

 

For completeness, this section reviews the use GSLB DNS resolution process. If you are a GSLB experts can skip this part. The following figure shows the client resolves the fully qualified domain name (FQDN) www.trapster.net of step 

A site in Los Angeles, the use of virtual IP 1.1.1.1. Site B in New York City, the use of virtual IP 2.2.2.2. GSLB device as an authoritative name server www.trapster.net. When a DNS request arrives GSLB, GLSB responsible decided to return to 1.1.1.1 or 2.2.2.2.

 

1. Edge resolver (running on the client PC software program) originate resolution request to the local DNS, in this case, "Local DNS" refers to the client in Atlanta, Georgia Internet provider (ISP) DNS server. Either the client received the analysis results of the DNS, or receive an error message. This query is called "recursive" query. Note: The edge analysis on the Internet is not supported by "mining" the query results, "recursive" This is the work of the DNS server. 
2. 客户端的本地DNS服务器为客户端代理“迭代”查询，向根域名服务器查询，并最终查询到www.trapster.net 的权威名字服务器。在本例中GSLB做为权威的名字服务器。 
3. GSLB同每个站点的软件或设备之间运行某种通信程序，收集各个站点的信息，比如，站点的健康状态、会话连接数、响应时间等。 
4. 每个站点的软件或设备运行某种动态特性的度量程序，比如测量该站点到客户端local DNS服务器的往返时间（RTT）、地理间隔、BGP跳数等。 
5. GSLB使用从步骤3和4 收集到的信息，向客户端的local DNS服务器返回计算最优的结果，这个结果是1.1.1.1 或 2.2.2.2 两者之一，如果DNS保活时间（TTL）不为0，这个结果会缓存到客户端本地 DNS服务器上，以便其他共享该本地DNS服务器的客户端可以直接使用这个结果（不在重复步骤2-4）。

 

DNS 解析结束后，客户端会向相对最优的站点建立TCP连接。

 

浏览器DNS缓存

 

IE浏览器、Netscape 浏览器、其他浏览器、甚至Web 代理缓存程序和邮件服务器，都内建“DNS 缓存”。

DNS 缓存是一个小型数据库，可以将DNS解析结果存储一段时间。通常情况下，DNS结果的存储时间由回答这条结果的权威DNS服务器指定，这段时间被称作保活时间（TTL）。

不幸的是，浏览器的缓存不能够获得DNS服务器返回的TTL，这是因为DNS请求是由通过调用操作系统的gethostbyname()函数(或其他提供类似功能的函数)完成的，该函数调用仅返回请求域名对应的一个或多个IP地址（该系统调用不允许请求应用程序获取TTL）。为了解决这个问题，浏览器的开发者引入了一个可配置的TTL值。在IE浏览器中，该值默认是30分钟，可以通过Windos 的注册表修改。在Netscape中，这个值默认是15分钟，可以通过修改prefs.js文件中的一行来配置该值。

 

DNS解析请求的频率主要取决于不同的浏览器。旧版的浏览器请求时间间隔是固定的，对应每个站点，IE浏览器每30分钟执行一次请求，Netscape是15分钟，不管用户/客户端这个时间段内连接多少次该站点。点击刷新，甚至其他组合操作都不会改变这一行为。唯一能够刷新浏览器DNS缓存的办法就是退出并且重启浏览器（或者重启计算机）。在大多数情形下，“重启浏览器”意味着关闭所有正在浏览的页面，不光是出现连接问题的这个页面——当页面发生连接问题时，这件事（重启浏览器），用户不一定会自行去做。Microsoft 很早以前修复了这一问题。但是在最近的统计中（2007-8），仍有相当一部分的浏览器受该问题影响。更多关于DNS缓存与浏览器的问题请参见http://www.tenereillo.com/BrowserDNSCache.htm

 

浏览器缓存带来的问题

 

浏览器缓存会给GSLB带来相当大的影响。如果一个站点因为灾难性的事故不能提供服务，所有当前连接到该站点的客户端都会遭遇连接故障直到浏览器中的DNS缓存过期，或者用户重启浏览器或计算机。同时，任何指定缓存了失效站点IP的DNS服务器作为Local DNS服务器的客户端，也会遭遇连接故障。这显然是不能接受的。

 

下图可以帮助展示这个相当严重的问题。以一个金融行业站点（提供证券、股票交易，网上银行等）为例，使用active/backup负载方案，该方案是最简单，并且最广泛使用的GSLB配置，见下图： 

虚构一个站点 www.ReallyBigWellTrustedFinancialSite.com，使用位于洛杉矶的站点A（1.1.1.1）作为主要站点，站点B（2.2.2.2）作为备用站点。

1. 为了实现该方案。 www.ReallyBigWellTrustedFinancialSite.com 的DNS解析响应中需回复唯一的结果，或者说“A 记录”——IP 地址1.1.1.1。一个GSLB设备部署在互联网上，使用最优秀的高级站点健康监控技术。 
2. 数千用户连接在站点A，顺利的进行交易事务，所有用户将IP地址1.1.1.1缓存在其浏览器中。

现在灾难发生了，如下图所示： 

1. GSLB优秀的高级站点健康监控技术立即检测到了故障。 
2. GSLB注意到站点B仍然健康，开始返回IP地址2.2.2.2，以便将新请求路由到站点B。 
3. 所有在线的用户仍然将站点A的IP地址1.1.1.1，缓存在其浏览器中。GSLB没有任何办法通知这些用户，因为这些用户在浏览器缓存过期之前，不会发起新的DNS请求。

对于所有在线用户，站点故障实际上持续了半个小时，完全超出基于高级站点健康监测技术的GSLB设备的控制。

 

然而这还不是最坏的，情况还会更糟，如下图：

1. 一些新客户端的浏览器缓存和local DNS服务器缓存中没有解析结果1.1.1.1。这些用户会请求www.ReallyBigWellTrustedFinancialSite.com 。 
2. 这些客户端的local DNS会代理其发起迭代地址解析（至少会为第一个请求代理解析），最终请求到GSLB，GSLB 会响应健康站点的结果——IP 2.2.2.2 ,一切都很正常。 
3. 然而一些客户端的local DNS服务器缓存中已经有解析结果1.1.1.1，或者是因为这条结果中由GSLB设置的TTL没过期，要么是local DNS服务器器忽略了过低或为零的TTL值（事实上，有些DNS服务器确实这么做）。因为解析结果仍在缓存中，local DNS服务器不会向GSLB发起迭代请求，并且无法感知到站点A——1.1.1.1 已经失效，因此这些新加入客户端也会经历半个小时的故障，完全不受GSLB的控制。

解决浏览器缓存问题的方法

 

对于浏览器缓存问题有一个存在已久的解决方案，就是权威DNS服务器（或GSLB）在解析响应中返回多个DNS结果（”A 记录”）。

在解析响应中返回多个A记录并不是什么诀窍。也不是负载均衡设备厂商的持有的特性。DNS协议在设计之初就支持在解析响应中返回多个A记录。例如浏览器、代理服务器、邮件服务器等应用程序都可以使用该特性。

 

下图展示了他是如何工作的： 

1. 客户端请求解析FQDN www.trapster.net。 
2. 迭代查询之后（未显示），客户端的Local DNS服务器返回两个A记录——1.1.1.1 和 2.2.2.2 （按照这个次序）。 
3. 客户端向站点1的IP 1.1.1.1 建立请求。 

1. 当客户端访问站点A顺利的进行商务活动时，一个灾难性的事件导致站点失效。客户端与站点A失去连接。 
2. 因为第二条A记录2.2.2.2也包含在原始的解析结果中，客户端会平滑的连接到站点B2。注意：这取决于商业应用程序的架构，一些连接状态，比如登录状态、购物车、财务事项等，也许会因为灾难而丢失，然而客户端仍可以在站点B继续进行商务活动。

解析结果中回复多个A记录并不需要GSLB设备，不过大多数GSLB设备支持这一功能。所有重要的DNS服务器都支持回复多个A记录，基本上所有基于B/S的商业站点为了应对浏览器缓存问题，都会在解析结果中返回多个A记录。