经过负载均衡器+域名实现容灾切换-（8）基于DNS解析的GSLB在BS架构中应用实践（转）（1）

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

摘自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

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

 

摘录

基于DNS的全局负载均衡（GSLB）解决方案是为了提供互联网DNS服务、以及标准DNS服务以外的其余功能与特性。

本文阐述了大多数互联网服务，比HTTP、HTTPS、FTP、流媒体、和其余基于B/S架构的应用程序或协议，使用GSLB特性时会产生的问题。

此时我本应该加上“若是GSLB可以同时加强B/S架构互联网服务的高可用性”，可是我没有，由于人们老是预期GSLB解决方案能够很好的部署高可用，这是“显而易见”的。

本文从大互联网的意义出发，探讨了互联网的行为，固然也能够建立自定义的解决方案。例如，有可能在客户端计算机上运行特殊软件，这样的解决方案几乎是对于互联网网站来讲，历来不是实用的，所以不在这里讨论。

 

THE Punch line

在DNS响应中返回多个A记录，是GSLB高可用部署的最佳实践。可是返回多个A记录会从某种程度上影响GSLB的负载均衡特性（好比流量控制或站点选择算法）。所以全局负载均衡（或多站点流量控制）的实际价值是值得怀疑的（见为何基于DNS的全局负载均衡（GSLB）不起做用？ II）。人们必须在高可用和负载均衡之间作出妥协。下文会作出技术性的解释。

 

GSLB的根本目标

多站点部署互联网网站加强高可用性是没法争辩的，若是灾难性事件致使一个站点不可用，其余站点必须可以接替处理用户的请求，这样事务方可持续。下面给出一个例子，服务器站点分别部署在洛杉矶和纽约： 

 

互联网链接失效，断电事故、SLB设备故障、Dos攻击或者灾难性事件都会形成整个站点中止服务，GSLB设备必须检测到故障而且将请求路由到其他的站点，以保证客户端请求获得响应，事务能够继续。

 

DNS 解析

出于完整性考虑，这节回顾一下使用GSLB的DNS解析过程。若是您是GSLB的专家能够跳过这一部分。下图展现了客户端解析全域名（FQDN）www.trapster.net的 的步骤 

站点A在洛杉矶，使用虚IP 1.1.1.1。站点B在纽约城，使用虚IP 2.2.2.2。GSLB设备做为www.trapster.net的权威名字服务器。当DNS请求到达GSLB时，GLSB负责决定返回1.1.1.1或 2.2.2.2。

1. 边缘解析者（运行在客户端PC上的软件程序）向本地DNS发起解析请求，在这个例子中，“本地DNS”指的是客户端在佐治亚州亚特兰大的互联网提供商（ISP）的DNS服务器。客户端要么收到DNS的解析结果，要么收到错误消息。这种查询叫作“递归”查询。注：边缘解析者不支持在互联网上“挖掘”查询出结果，“递归”这是DNS服务器的工做。 
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记录。