=================================================================================================
原文：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。
- 边缘解析者（运行在客户端PC上的软件程序）向本地DNS发起解析请求，在这个例子中，“本地DNS”指的是客户端在佐治亚州亚特兰大的互联网提供商（ISP）的DNS服务器。客户端要么收到DNS的解析结果，要么收到错误消息。这种查询叫做“递归”查询。注：边缘解析者不支持在互联网上“挖掘”查询出结果，“递归”这是DNS服务器的工作。
- 客户端的本地DNS服务器为客户端代理“迭代”查询，向根域名服务器查询，并最终查询到www.trapster.net 的权威名字服务器。在本例中GSLB做为权威的名字服务器。
- GSLB同每个站点的软件或设备之间运行某种通信程序，收集各个站点的信息，比如，站点的健康状态、会话连接数、响应时间等。
- 每个站点的软件或设备运行某种动态特性的度量程序，比如测量该站点到客户端local DNS服务器的往返时间（RTT）、地理间隔、BGP跳数等。
- 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）作为备用站点。
- 为了实现该方案。 www.ReallyBigWellTrustedFinancialSite.com 的DNS解析响应中需回复唯一的结果，或者说“A 记录”——IP 地址1.1.1.1。一个GSLB设备部署在互联网上，使用最优秀的高级站点健康监控技术。
- 数千用户连接在站点A，顺利的进行交易事务，所有用户将IP地址1.1.1.1缓存在其浏览器中。
现在灾难发生了，如下图所示：
- GSLB优秀的高级站点健康监控技术立即检测到了故障。
- GSLB注意到站点B仍然健康，开始返回IP地址2.2.2.2，以便将新请求路由到站点B。
- 所有在线的用户仍然将站点A的IP地址1.1.1.1，缓存在其浏览器中。GSLB没有任何办法通知这些用户，因为这些用户在浏览器缓存过期之前，不会发起新的DNS请求。
对于所有在线用户，站点故障实际上持续了半个小时，完全超出基于高级站点健康监测技术的GSLB设备的控制。
然而这还不是最坏的，情况还会更糟，如下图：
- 一些新客户端的浏览器缓存和local DNS服务器缓存中没有解析结果1.1.1.1。这些用户会请求www.ReallyBigWellTrustedFinancialSite.com 。
- 这些客户端的local DNS会代理其发起迭代地址解析（至少会为第一个请求代理解析），最终请求到GSLB，GSLB 会响应健康站点的结果——IP 2.2.2.2 ,一切都很正常。
- 然而一些客户端的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记录。例如浏览器、代理服务器、邮件服务器等应用程序都可以使用该特性。
下图展示了他是如何工作的：
- 客户端请求解析FQDN www.trapster.net。
- 迭代查询之后（未显示），客户端的Local DNS服务器返回两个A记录——1.1.1.1 和 2.2.2.2 （按照这个次序）。
- 客户端向站点1的IP 1.1.1.1 建立请求。
- 当客户端访问站点A顺利的进行商务活动时，一个灾难性的事件导致站点失效。客户端与站点A失去连接。
- 因为第二条A记录2.2.2.2也包含在原始的解析结果中，客户端会平滑的连接到站点B2。注意：这取决于商业应用程序的架构，一些连接状态，比如登录状态、购物车、财务事项等，也许会因为灾难而丢失，然而客户端仍可以在站点B继续进行商务活动。
解析结果中回复多个A记录并不需要GSLB设备，不过大多数GSLB设备支持这一功能。所有重要的DNS服务器都支持回复多个A记录，基本上所有基于B/S的商业站点为了应对浏览器缓存问题，都会在解析结果中返回多个A记录。