基于DNS的GSLB,基于应用重定向的GSLB，基于主机路由注入的GSLB

               基于DNS的GSLB，基于应用重定向的GSLB，基于IP地址假装（三角传输）的            GSLB，  基于主机路由注入的GSLB(Anycast)

引言
在过去的几年中，随着互联网的快速发展和企业应用WEB化，服务器负载均衡（SLB）技术已经再也不陌生。服务器负载均衡根据用户数据请求中的4-7层信息将其智能转发到后端少则数台多则成百上千台应用服务器，而且确保根据事先定义的策略选择最佳的服务器进行转发，从而必定程度上解决了应用的可用性、扩展性等问题。可是，随着用户对应用可用性和扩展性需求的进一步增长，愈来愈多的用户不知足于在单一数据中心提供服务，开始考虑容灾、用户就近访问等问题。这正是负载均衡设备中的全局服务器负载均衡技术（GSLB）所要解决的问题。尽管GSLB技术早在数年前就是大部分负载均衡设备提供的必备功能，但因为用户需求较小、功能不够完善、性能不足、价格高昂等因素，目前部署GSLB的用户在负载均衡整个用户群中所占比例仍是很小。相信在将来几年中，GSLB的应用比例将快速增长。本文针对GSLB相关技术及解决方案进行介绍。
GSLB技术
市场上存在的GSLB技术能够概括为如下几类：
基于DNS的GSLB
绝大部分使用负载均衡技术的应用都经过域名来访问目的主机，在用户发出任何应用链接请求时，首先必须经过DNS请求得到服务器的IP地址，基于DNS的GSLB正是在返回DNS解析结果的过程当中进行智能决策，给用户返回一个最佳的服务IP。用户应用流程与没有GSLB时未发生任何变化。这也是市场上主流的GSLB技术。
基于应用重定向的GSLB
基于应用重定向的GSLB是在负载均衡设备收到用户应用请求并选择最佳服务IP后，经过应用层协议将用户请求重定向到所选择的最佳服务IP。这种方式只适用于支持应用重定向的协议（如HTTP、MMS），且性能较差。
基于IP地址假装（三角传输）的GSLB
有个别负载均衡设备厂商采用这种技术来实现GSLB。当用户应用请求到达一台负载均衡设备时，这台负载均衡设备计算出对于该用户最佳的服务IP（定义在另外一台同一厂商负载均衡设备上）并将用户请求转发给该IP。第二台负载均衡设备直接将响应返回用户，但必须将源地址修改成第一台负载均衡设备的服务IP。这种方式要求全部站点必须为同一厂家的负载均衡设备，另外地址假装的数据包会可能被互联网中的路由设备过滤掉。由于全部用户请求都要通过广域网三角方式传输而不是发到最佳的负载均衡设备，用户访问效果和性能都比较差。
基于主机路由注入的GSLB(Anycast)
在多个站点定义相同的服务IP，并由负载均衡设备或路由器将该IP的主机路由发送出去，这样网络中会存在多条到达该主机地址的路由。因为路由设备老是选择最近（Metric最小）的路由转发数据，用户的访问请求老是被转发到最近的负载均衡设备。这种方式要在不一样站点广播相同的主机路由，因为运营商的限制问题很难实现。另外这种方式策略很是简单，只能根据最短路由选择，客户没法定义灵活的选择策略。
根据上面的分析，后面的三种方式都有不少局限性或性能较差，这也是为何基于DNS的GSLB成为主流技术的缘由。在基于DNS的GSLB具体实现中，不一样厂家的功能会有所不一样，也有部分用户本身开发智能DNS实现相似功能。整体来讲，一个完善的基于DNS的GSLB设备能够知足如下需求：
支持任何IP应用。
各服务站点可使用不一样厂家的本地服务器负载均衡设备或直接使用真实服务器。
GSLB控制设备可直接做为受权DNS，也能够配置为DNS代理方式。DNS代理方式在作GSLB决策控制同时能够对后端DNS服务器进行负载均衡。当业务量增长时能够经过增长后端的真实DNS服务器数量进行扩展。
内置国际IANA机构提供的全球各区域地址分配表，且用户自定义区域能够包含足够多的IP前缀。同时区域定义支持树状分层结构，如China.Beijing.HaiDian。这些功能在GSLB控制设备进行静态基于区域选择服务站点时是必须的。
支持返回A记录和CNAME等记录。尤为在多级GSLB控制时，返回CNAME是必须具有的。
支持丰富的GSLB策略，常见的如往返时间（RTT）、权重、活动服务器等。
具备灵活的自定义脚本用于过滤各类非法DNS请求或***。
强大的DDoS***防御功能。一旦GSLB控制设备被***瘫痪，全部业务都没法提供。
基于DNS的GSLB工做原理
下面咱们对基于DNS的GSLB的工做原理进行简单介绍。
 

 

 

上图中，中心控制节点配置一台GSLB Controller及数台指定域名（abc.com）的受权DNS服务器，GSLB Controller除了进行GSLB控制外还能够对DNS服务器及其余应用服务器进行负载均衡。设置2个站点（以中国电信和中国网通为例）提供应用服务。其工做流程以下：
1) 用户发起请求访问http://www.abc.com，关于www.abc.com 的DNS请求被送往 Local DNS服务器；
2) Local DNS经过根DNS服务器查询到abc.com 的受权DNS服务器，Local DNS向受权DNS服务器发DNS请求。
3) GSLB Controller 截获DNS服务器返回的应答，并基于一组策略选择最佳的站点VIP 地址，返回给Local DNS服务器。
GSLB Controller也能够根据事先定义的策略返回CNAME记录，在大规模的多级GSLB设计中会用到这种方式。Local DNS会递归发送DNS请求到负责指定CNAME域的下一级GSLB Controller。
4) Local DNS服务器返回该DNS应答到用户。
5) 用户根据解析到的IP地址创建链接进行正常访问。
从GSLB处理流程能够看出，其核心在GSLB策略。接下来简单介绍一下经常使用的一些GSLB策略。
1) 各内容站点的“健康情况”
GSLB Controller对各内容站点负载均衡设备上定义的VIP或服务器（没有本地负载均衡的状况）进行第四层TCP/UDP健康检查和第七层应用健康检查。未能经过健康检查的站点不会被选为最佳的内容节点。
2) 地理区域或用户自定义区域
一个区域为若干条IP地址前缀。根据用户本地DNS的IP地址，将特定IP范围的用户优先分配到某个经过健康检查的站点。值得一提的是，因为DNS自己的工做原理所限，GSLB Controller只能看到用户本地DNS的IP地址，而不是用户终端的IP地址。当用户使用错误的本地DNS（如教育网用户配置网通的DNS服务器）时，GSLB Controller返回的DNS应答将不是最佳的站点。这是基于DNS的GSLB的一个弱点，但因为绝大部分运营商如今限制其余运营商的客户使用本身的DNS，出现这种错误配置的比例很是小。
3) IP地址权重
能够为DNS应答中的每一个IP地址分配权重，权重决定与其余候选IP相比分配到该IP的流量比例。
4) 站点（Site）权重
能够为每一个Site分配权重，权重决定与其余候选Site相比分配到该Site的流量比例。
5) 会话能力阈值
经过厂商自由的GSLB协议，GSLB Controller能够得到每一个站点负载均衡设备当前可用会话数和会话表大小的最大值，当前会话数/最大会话数比值超过定义的阈值时，该站点再也不被选择。
6) 活动服务器
指一个GSLB节点绑定到一个VIP上的活动真实服务器数量。能够配置策略优先选择活动服务器最多的IP地址。
7) 往返时间(RTT)
RTT策略是基于区域以外最经常使用的策略。有两种模式的RTT测量：Active RTT测量与Passive RTT测量。在实际部署中，因为网络限制和性能缘由，Active RTT每每没法使用，Passive RTT更实用一些。
a) Active RTT 测量
- 当GSLB Controller收到来自LDNS的DNS请求时，GSLB Controller会通知全部站点负载均衡设备对该LDNS进行RTT测量。根据采集到的RTT值，GSLB Controller会选择RTT值最小的站点的VIP返回给LDNS。
- 因为Active RTT采用DNS Query或ICMP进行RTT测量，在有些网络中可能会被安全策略所过滤而没法工做。
- Active RTT测量会产生额外的DNS Query或ICMP流量，在有些网络中用户不但愿有太多相似的非用户流量。
b) Passive RTT测量
- Passive RTT测量不会主动去进行测量，也不会产生额外的数据流量，而是在用户向返回的VIP创建链接时进行采集。
- Passive RTT测量指从内容站点收到一个用户发出链接请求(发送TCN SYN)到接收到用户的确认(收到TCP ACK)所经历的时间。而不是简单的PING的响应时间，能够更精确的衡量访问最快的站点。
- Passive RTT的测量值真正反映了用户的上网感觉 ，在运营商网络中也不会产生额外流量。也不会受到其余运营商或网络的安全策略的影响。
与基于区域的策略相同，用户配置错误的DNS时，基于RTT的选择也将不是最佳的。
8) 当前可用会话数
9) 站点管理优先级（Admin Preference）
为每一个站点预设优先级，选择优先级较高的站点。
10) 最少选择
选择从前被选择的次数最少的节点。
11) 轮询（Round Robin）
采用轮询方式选择站点。
总结
 

尽管基于DNS的GSLB在特殊状况下（用户配置错误DNS）准确性会下降，但其丰富的策略、可扩展的性能、适用任何IP应用协议、不受互联网访问策略影响以及无改变的业务流程等优点使其成为最主流的GSLB技术，诸多厂家也都在这一技术上不断进行完善。

R.S.

本文出自 “ADC技术博客” 博客，请务必保留此出处http://virtualadc.blog.51cto.com/3027116/624466