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

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

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

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

 

An Axiom

对于GSLB，惟一可以实现高可用的方法就是在DNS解析结果中包含多个A记录。

高可用实现有超多的替代的解决方案，可是没有一个可以真正奏效（见下文“替代方案” ），除了修改全部可能访问该站点PC的注册表，在解析结果中回复多个A记录是惟一的方法。

 

为何多重A记录会抵消GSLB的负载均衡算法？

就像前文提到的，DNS服务器可以在解析结果中返回多重A记录。GSLB设备一样也能够返回多重A记录。即便互联网站点已经拥有DNS服务器（或购买了DNS解析服务），互联网站点的拥有者仍会采购GSLB设备，一般每台高达$30000，为的是得到那些比普通DNS服务器能提供的更多的特性。 

问题来了：

 

这些特性中，没有一个特性能够同多重A记录配合使用 。

 

简单的站点Active/Standby算法不行、静态的站点偏好算法不行、基于IANA的站点偏好算法不行、DNS persistence 算法不行，RTT或步长检测算法不行，基于Geotargeting的重定向也不行…没有任何一个特性能够！下图就来展现为何： 

 

基于GSLB的DNS解析前面已经阐述过了（为了简便，像健康检查、RTT测量等步骤这节就省略掉了）。 

1）咱们假设GSLB设备设置站点A为首选站点，IP地址1.1.1.1 ,它在解析响应中按照以下顺序返回解析结果： 

 - 1.1.1.1 

 - 2.2.2.2 

2）客户端的Local DNS 收到解析结果后，将结果缓存。此时Local DNS将结果返回给客户端，顺序多是： 

 - 1.1.1.1 

 - 2.2.2.2 

 或者： 

 - 2.2.2.2 

 - 1.1.1.1

 

目前，几乎全部的商用GSLB设备都会返回有顺序的多重A记录，一般被称为“顺序列表”。设想预约的结果顺序会一成不变穿越互联网传递给DNS请求者，不幸的是，这个设想是错误的。

 

实践证实：DNS解析结果的地址顺序会被客户端的Local DNS 篡改！

 

Local DNS服务器篡改解析结果中的地址顺序是为了平衡去不一样站点的流量，这是大多数提供商DNS服务器的默认动做。曾经有想法是将DNS响应结果的TTL设置为0，来避免Local DNS篡改顺序。可是很是不幸，解析结果的顺序仍会被篡改，彻底不受GSLB或权威名字解析服务器的控制，这种状况下，肯定性的控制客户端优先访问某一站点是不可能的。

 

网站Cookies:猜怎么着？依然不能奏效！

大多数多地部署的 网站都要求会话的持续 。换句话说，如何一个客户端链接到了站点A，那么必需要保证在整个会话期间，客户端一直链接在站点A。即使是站点已经很好的同步以适应某种级别的会话持续，而后实时同步是不可能作到的。

 

浏览器DNS缓存是解决会话持续的一线但愿。客户端解析了www.trapster.net 以后，获得结果是站点A---IP 1.1.1.1，客户端会持续链接到站点A直到浏览器缓存过时。前面提到过，IE的过时时间是30分钟，Netscape是15分钟。很明显，单独使用这个方法不能知足超过30分钟（或15分钟）的会话的持续性，由于超时后浏览器会从新解析域名，这时客户端可能会链接到错误的站点。同时，不论30分钟或15分钟，都是固定的时间段，不是客户端中止使用的等待时间。例如，一个用户访问了www.trapster.net，而后接了29分钟电话，挂断了电话后，继续浏览www.trapster.net 开始订购某些商品，浏览器会在一分钟后从新解析，极可能将用户引导到错误的站点。

 

DNS缓存时间超时问题是众所周知的，所以基本上全部的SLB(服务器负载均衡)都会去解决这一问题。使用一种被称为“站点 cookie”的方法，一般只为HTTP协议部署（也有一些厂商为流媒体协议实现了该方法）。 

1. 客户端解析www.trapster.net的结果——站点A、IP地址1.1.1.1。客户端链接到站点A，开始商务事务。在链接到站点A的同时，站点A的SLB设备植入了HTTP cookie，该cookie 指明了客户端须要持续链接哪一个站点（甚至是具体的服务器）。 
2. 通过一段时间，客户端浏览器的DNS缓存过时后，客户端会从新解析，此次的解析结果是站点B、IP 地址2.2.2.2，该地址将会在客户端浏览器中缓存30分钟（或15分钟），客户端如今向站点B创建链接，当客户端链接到站点B，其发送的站点cookie 代表客户端的当前会话须要链接站点A。 
3. 站点B的SLB设备读取这个cookie后，发送了一个条HTTP重定向。HTTP重定向中的FQDN部分不能是www.trapster.net，由于该域名对应的解析结果2.2.2.2，仍然缓存在客户端的浏览器中。同时，也不能使用地址1.1.1.1重定向，由于若是不使用DNS域名作重定向，服务器软件和SSL认证一般不能正常的工做。由于这个缘由，一般使用一个站点独立的FQDN。在这个例子中，HTTP重定向的域名多是www-a.trapster.net（或 site-a.www.trapster.net）。 
4. 客户端如今用www-a.trapster.net 从新链接原来的站点继续商务事务。 

以下图展现： 

 

通过一段时间，尤为是站点经历了很长的会话时间（好比股票交易或财经站点），很大比例的用户会经过站点独立的FQDN链接到网站。即便通过短暂的会话时间，有些用户也会使用到站点独立的FQDN www-a.trapster.net。

 

由于有用户已经使用了www-a.trapster.net，为了高可靠性考虑，不只仅须要为www.trapster.net使用多重A记录，并且还要为www-a.trapster.net使用多重A记录。若是IP 1.1.1.1 和 IP 2.2.2.2 都包含在www-a.trapster.net 的解析结果中，如前文所述，客户端可能会链接站点A，也多是站点B!

 

站点cookie 不能很好的与多重A记录一块儿工做，同GSLB不能很好的与多重A记录一块儿工做的缘由同样！

 

GSLB站点健康检查有用吗？

咱们已经证实了 多重A记录是有必要 的，可是剩下的问题是 “他们能胜任基于B/S架构的站点吗？” 。

当收到包含多重A记录的解析结果后，基于浏览器的客户端使用它们本身的“健康检测”方法，这就是为何多重A记录会设计在DNS协议中。也许有这样的情形，要求GSLB在解析结果中不返回已经检测到失效站点的A记录，可是也有不少情形要求返回失效站点的A记录，即便明确检测该站点失效。这一节就展现这样一个情形，许多种类的故障是很短暂的，换句话说，一样的问题可能会在不一样站点间次序的或同时的出现。例如： 

1. 电力故障也许会影响一个区域的数据中心，而且当电缆网络调整期间，也许会影响其余地区的数据中心。 
2. 拒绝服务器攻击(DoS)一般攻击指定的IP地址。一次DoS攻击也许会先攻击IP地址1.1.1.1，而后再攻击IP地址2.2.2.2。 
3. 电脑病毒也许会先影响数据中心A，也许会花半小时来人工的杀除病毒，在这期间，该病毒也许会在数据中心B爆发。 
4. ISP内部网络出现问题，一个路由器问题会同时影响一个国家不一样区域的网络。

根据前面的例子，站点A使用IP地址1.1.1.1，站点B使用IP地址2.2.2.2，若是一台SLB或GSLB设备（或者是绑定的某个健康检测脚本），发现站点A失效了，应该在解析结果中只返回单一的A记录2.2.2.2吗？若是站点B使用IP地址2.2.2.2随后也发生了故障，可是站点A在半小时的窗口中，从故障恢复，这种状况下最好仍是一直返回两个站点的A记录，即便健康检测进程检测到了失败。记住，返回多重记录不多是拔苗助长的，由于客户端会自动地链接A记录列表中健康的站点，不须要人工干预。

 

替代方法

还有一种不太严重的故障会发生。一个站点的全部服务器故障，然而站点的电力、互联网链接和SLB设备都工做正常。此类问题有许多商业上可用的解决方案，包括backup redirection, triangulation，proxying，或NATing。为了完整性这里会讨论一下这些解决方案，可是这节会说明，这些解决方案虽然能够解决不太严重的服务器故障，可是并不能解决更重要的站点故障问题。

 

Triangulation

Triangulation 是一种链接恢复方法，对全部的IP 协议都适用。 

1. 客户端已经链接到站点A，正常的浏览网站。 
2. 站点A的全部服务器故障（可是在这个例子中，SLB、互联网链接、交换机、路由器、电力等设备都正常）。运行在站点A的SLB上的软件检测到了服务器故障，固然全部的存在的TCP链接都会丢失，可是客户端会尝试重连。在站点A的SLB与站点B事先有预创建的TCP隧道，站点A的SLB将客户端的新链接请求经过TCP隧道转发给站点B。 
3. 站点B的SLB设备选择一个新服务器为该客户端提供服务，而且使用冒名的地址1.1.1.1将数据包直接返回给客户端。

Backup redirection

Backup redirection 只对应用层支持重定向的协议有效（好比 HTTP、HTTPS、一些流媒体协议等）。 

1. 客户端向站点A发起请求，请求的URL是FQDN www.trapster.net，已经解析为IP地址1.1.1.1。 
2. 站点A的SLB发现全部的服务器都故障了，因而发出一个HTTP重定向引导用户去链接站点B。这里的重定向必须使用一个不一样的FQDN，能够是www-b.trapster.net。若是HTTP重定向使用www.trapster.net，客户端的会使用已经缓存的地址（1.1.1.1）从新连回站点A。而且HTTP重定向可能不可使用IP地址，由于大多数的服务器、SSL认证等，须要客户端经过FQDN访问站点，而不能是IP地址。 
3. 客户端如今访问站点B。

IP proxy 和 NAT

IP proxy（和NAT）对全部的IP协议都有效，这里不详细介绍他们了。这两个方法，在发现站点A的全部服务器故障后，会将客户端的链接负载均衡到站点B的VIP(2.2.2.2)上，就像将客户端链接负载均衡到本地服务器同样。

 

Triangulation、backup redirection、IP proxy和NAT的问题

这些方法确实会对站点故障快速恢复有所帮助，但只能是在 互联网链接、网络设备、电力和本地SLB设备都工做正常的状况下起做用 ，换句话说， 仅当服务器故障时有效 。若是 这些方法同多重A记录一同使用，这些方法的可否起做用是值得怀疑的 。若是单独使用这些方法，而不使用多重A记录，等因而“丢了西瓜拣芝麻”。若是不将站点的灾难性故障考虑在内，那也没有什么强有力的论据去使用GSLB。看来最好是彻底忘掉GSLB，丢弃那些花费和复杂性，将全部的服务器汇集在一个数据中心，而不是两个，使用冗余的电力、网络链接、网络设备、和SLB设备。

 

这就是说，即便在灾难状况下的高可用是对GSLB最基本的需求，GSLB也只能在特定状况下知足，所以：

对于高可用的需求，Triangulation、backup redirection、IP proxy和NAT，这些方法都不能知足，或者说不须要。基于浏览器的客户端仍须要使用多重A记录。

 

BGP主机路由注入

还有一个解决方案，一般被叫作BGP主机路由注入（HRI），同时，至少有两家厂商也叫作“Global IP”。他并非简单与GSLB配合的备选方案，而是一种用来替换基于DNS的GSLB的解决方案。下面是其原理的概述： 

  

1. 客户端发起DNS解析，www.trapster.net 的解析结果中只有一个IP地址——1.1.1.1。
2. 站点A和站点B的SLB设备（或路由器）都向互联网宣告了地址1.1.1.1。互联网路由器将1.1.1.1的路由信息经过BGP传播，同时交换度量值，最终将路由信息传播给距离客户端最近的互联网路由器，该路由器选择度量值最小的路径，将1.1.1.1的路由加入路由表。 
3. 客户端此时链接拓扑上最近的站点。

此时发生了服务器（所有）故障，或互联网链接故障、电力故障、SLB设备故障、网络设备故障等灾难性故障：

1. 站点A的SLB设备发现了服务器故障，中止经过BGP向互联网宣告IP地址1.1.1.1(或 SLB、互连网链接被破坏，这种状况下宣告显然会中止)。 
2. 路由在互连网设备间收敛，前往站点A的路由条目最终会被删除。 
3. 客户端从新创建链接，仍链接IP 1.1.1.1,但此次链接的是站点B。

虽然在理论层次上，这个方案实现的功能像是GSLB求之不得的，可是它不多真正部署实现，下面阐述了为何： 

• 互联网的路由至关复杂，在不一样地区宣告同一个IP地址的实践，工做的并不可靠。在客户端的会话期间，若是发生路由变更，数据包会在站点A和站点B之间断断续续的传输，此时，即便两个站点均可以正常工做，客户端依然不能正常访问。 
• 路由收敛的时间会至关的长。当站点发生故障后，客户端的浏览器会超时，会跳转访问失败的页面。若是用户手动的持续尝试访问，最终链接会恢复，可是故障恢复时间超过5分钟也是有可能的，这么长时间的故障对于商业站点来讲是不能接受的。
•  BGP宣告的单个IP地址（主机地址）一般会被互联网路由器忽略。一个可能的解决方式是宣告整个网络地址段，然而仅仅为了GSLB这么作，等同于浪费昂贵的公网IP地址资源(由于仅仅一个地址，或一小部分地址会被实际使用到)。 
• 为了安全考虑，路由器上会配置源地址过滤（有时叫作“bogon”过滤），源地址过滤会防止从不一样的地域宣告同一IP地址。这个问题一般能够经过与ISP协商解决。尽管如此，即便与ISP协商去掉了源地址过滤，一般还会有人疏忽的从新加上去，这一般会形成站点失去互联网链接，须要故障报修处理等。

BGP HRI在站点分布在较小地域范围的网络中算是个健全的解决方案，也许能够用于一些互联网应用，可是部署至关的少见，由于它在实践中的表现远远不如理论分析的好。

 

结论

实现B/S架构的GSLB高可用，惟一的方法就是在解析响应中返回多重A记录，可是返回多重A记录，会破坏目前任何站点选择算法的做用。 由于这些特性，好比基本的active-standby算法、DNS persistence算法、基于RTT或步长或BGP跳数的站点选择算法、基于IP地址geotargeting或基于IANA的站点选择都不能奏效。

 

好消息是，如今消费者能够将本来花GSLB上的每单元$30000，用在购置更多的服务器和提高站点内部同步能力上!

 

Watering it down

冒着混淆前文理论的风险6，写了下文：

 

至少在理论上，GSLB设备能够以某种 “最佳选择+轮询” 的模式运转，例如若是一个FQDN在欧洲有两个站点，在美国有两个站点，对于欧洲的客户端，为了更好的服务，GSLB只返回位于欧洲的两个站点的A记录给客户端的Local DNS服务器。客户端的Local DNS服务器会在两个站点间轮询负载。见下图： 

1. 在这以前（没有在图上显示），客户端请求解析FQDN www.trapster.net，最终解析请求迭代到了www.trapster.net的权威服务器，也就是GSLB设备。GSLB执行站点选择算法，为客户选择法兰克福和巴黎站点，排除洛杉矶和纽约。 
2. GSLB返回两个站点的IP 1.1.1.1 和2.2.2.2。 
3. 解析结果中的A记录顺序会被客户端Local DNS服务器打乱，可是在这个例子中，该行为是可接受的，客户端会链接法兰克福或巴黎站点。

为了更好的说明，我随便选择一个术语“区域”，来描述这个GSLB拓扑结构。 

上文提到的站点A和站点B被划分为“欧洲GSLB区域”，站点C和站点D划在“美国区域”。这个方法，只有在网站的站点分布在全球，且划分为不一样的区域，每一个区域至少包含两个数据中心互为备份，这种状况下，才能被全局负载均衡。若是www.trapster.net的数据中心分布在伦敦、纽约、东京，那么“最佳选择+轮询”的模式就不会奏效了。某一客户端在伦敦，GSLB须要返回伦敦站点的A记录（地理位置最近的站点），同时它必须至少返回另外一个站点的IP（纽约或东京，两个站点与伦敦的距离都不近）。客户端会链接伦敦的站点或者链接其余的站点。很明显，这明显违背了GSLB站点选择算法的初衷。同时，一些站点选择算法（例如步长计算）不能在“最佳选择+轮询”模式下工做（留给读者来思考），DNS persistence 算法也不能同“最佳选择+轮询”协同。即便这个复杂的实现能够为超大的全球站点服务，对于本文讨论的案例来讲该方法并非一个通用的解决方案。

 

 

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

 

对于基于浏览器的客户端来讲，若是与返回多个A记录的惯常作法结合起来，基于全局服务器负载均衡 (GSLB)的DNS没法正常生效。Part 2 在忽略多A记录的高可用性因素状况下，涵盖了一些与基于GSLB的DNS的其余问题。

  在GSLB的DNS工做原理Part 1已经描述，这里再也不重复。

 

DNS解析时的就近路径问题：

问题一：客户端一般在地理上不接近器缓存DNS服务器。

基于GSLB的DNS解析过程当中，没有任何一个GSLB设备可以肯定实际客户端的IP地址和位置。由于和惟一和GSLB直接通讯的设备是客户端的缓存DNS服务器。GSLB必须假定客户端在地里上接近其缓存DNS服务器，不幸的是，这个是很差的假定。

 

下图展现了两个客户端及其各自的缓存DNS服务器的地里关系：

• Author位于卡尔萨德，Author的客户端一般被分配到位于20英里外的一个主DNS服务器（缓存DNS服务器），位于圣迪伊戈，在美国圣迪亚哥。
• Author的家庭成员也生活在卡尔斯巴德，但使用的一个Service的全部主机的缓存DNS服务器位于亚特兰大，大约2000英里之外。