CDN技术之--全局负载均衡（GSLB）

负载均衡就是智能调度
全局负载均衡（GSLB）的负载均衡主要是在多个节点之间进行均衡，其结果可能直接终结负载均衡过程，
也可能将用户访问交付下一层次的（区域或本地）负载均衡系统进行处理。
GSLB最通用的是基于DNS解析方式，还有HTTP重定向、IP路由等方法

DNS就是IP地址和网址互换
当需要访问abc.com这个站点时，
实际上我们想要浏览的网页内容都存放在互联网中对应某个IP的服务器上，
而浏览器的任务就是找到我们想要访问的这台服务器的IP地址，然后向它请求内容。

本地DNS服务器（local DNS server）是用户所在局域网或ISP网络中的域名服务器。
当客户端在浏览器里请求abc.com时，浏览器会首先向本地DNS服务器请求将 abc.com解析成IP地址，
本地DNS服务器再向整个DNS系统查询，直到找到解析结果。
客户端可以配置DNS服务器或通过DHCP来分配
DNS给使用它的互联网应用带来额外的时延，有时时延还比较大，为了解决问题，需要引入“缓存”机制。
缓存是指DNS查询结果在主机（local DNS server）中缓存。
在区内主机对某个域名发起第一次查询请求时，
负责处理递归查询的DNS服务器要发送好几次查询（先查.root，再查.com之 类，再定位IP地址等）才能找到结果，
不过在这过程中它也得到了许多信息，
比如各区域权威DNS服务器（就是告诉你最终abc.com在哪里的DNS服务 器）和它们的地址、域名解析最终结果。
他会把这些信息保存起来，当其他主机向它发起查询请求时，它就直接向主机返回缓存中能够找到的结果，直到数据过期。

客户端浏览器也可以缓存DNS响应信息。
Internet类资源记录分为
–A记录（address）：域名->多个IP的映射。对同一个域名，可以有多条A记录
–NS记录（name server）：指定由哪台DNS服务器来解析
–SOA记录（start of authority）：指定该区域的权威域名服务器
–CNAME记录（canonical name）：多个域名->服务器的映射
–PTR记录（pointer record）：IP->域名的映射

DNS系统本身是具备简单负载分配能力的，这是基于DNS的轮询机制。
如果有多台Web服务器（多源）同时为站点 abc.com提供服务，abc.com的权威服务器可能会解析出一个或多个IP地址。
权威域名服务器还可以调整响应中IP地址的排列方式，即在每次响应中将不同的IP地址置于首位（取决于可服务能力和服务质量），
通过这种方式实现对这些Web服务器的负载均衡通过CNAME方式实现负载均衡：域名服务器获得CNAME记录后，
就会用记录中的别名来替换查找的域名或主机名（实现多个域名->服务器映射）。
后面会查询这个别名的A记录来获取相应的IP地址。

具体操作为：先将GSLB的主机名定义为所查询域名的权威DNS服务器的别名，
然后将GSLB主机名添加多条A记录，分别对应多个服务器的IP地址。
这样，本地DNS服务器会向客户端返回多个IP地址作为域名的查询结果，并且这些IP地址的排列顺序是轮换的。
客户端一般会选择首个IP地址进行访问。

负载均衡器作为权威DNS服务器：负载均衡器就会接收所有对这个域名的DNS请求，
从而能够根据预先设置的一些策略来提供对域名的智能DNS解析。
F5的DNS具有完整的DNS功能以及增强的GSLB特性，Foundry、Nortel、Cisco和Radware的产品 能实现部分DNS功能。

负载均衡作为代理DNS服务器：负载均衡器被注册为一个域名空间的权威DNS服务器，
而真正的权威域名服务器则部署在负载均衡器后面。
所有的DNS请求都会先到达负载均衡器，由负载均衡器转发到真正的权威DNS服务器，然后修改权威DNS服务器返回的响应信息。
真正的权威DNS服务器正常响应浏览器的DNS请求，返回域名解析结果列表，
这个响应会先发送到负载均衡器，而负载均衡器会根据自己的策略选择一个性能最好的服务器 IP并修改需要实现GSLB的域名的DNS查询响应，
对其他请求透明转发，这样就不会影响整个域名空间的解析性能。

在基于DNS方式下无论采用何种工作方式，都会有一些请求不会到达GSLB，这是DNS系统本身的缓存机制在起作用。
当用户请求的域名在本地DNS或本机（客户端浏览器）得到了解析结果，这些请求就不会达到GSLB。
Cache更新时间越短，用户请求达到GSLB的几率越大。由于DNS的缓存机制屏蔽掉相当一部分用户请求，从而大大减 轻了GSLB处理压力，使得系统抗流量冲击能力显著提升，这也是很多商业CDN选择DNS机制做全局负载均衡的原因之一。
但弊端在于，如果在DNS缓存刷新间隔之内系统发生影响用户服务的变化，
比如某个节点故障，某个链路拥塞等，用户依然会被调度到故障部位去。

智能DNS功能，它在向本地DNS返回应答之前会先根据一些静态或动态策略进行智能计算。
– 服务器的“健康状况”
– 地理区域距离
– 会话保持
– 响应时间
– IP地址权重
– 会话能力阈值
– 往返时间（TTL）
– 其他信息，包括服务器当前可用会话数、最少选择次数、轮询等

关于GSLB的部署问题

关于内容的缓存问题（如何智能调度最有效）和配置

在有些CDN中（用于视频网站加速的情况较多），网站需要加速的内容全部先缓存在OCS（内容中心），
然后再将一部分 （通常是热门的内容）分发到个POP节点（Cache边缘集群），
所以POP节点在某些时候会出现本地不命中而需要回OCS取内容或者从其他POP节点取内容的情况

纯粹基于DNS方式的GSLB只能完成就近性判断。
为实现智能调度，大多数解决方案需要在GSLB设备附近以旁路的方式部署一台辅助设备（为方便描述，我们可称之为GRM——全局资源管理设备），
用以实现和各POP节点的本地资源管理设备进行通信，完成CDN对各POP节点的状态检查，
并根据POP节点的状态和流量情况，重新制订用户调度策略，将策略实时发送到GSLB中去执行

因为DNS服务采用以UDP为基础的、默认无连接的访问方式，给分布式攻击（DDoS）带来了更大的便利。
（有DNSSEC可以提供某程度的DDoS攻击保护）
隐藏节点的存在很大程度上可以避免GSLB被攻击致瘫痪的机会，
实际隐藏节点的实现方法就是在实际组网时除了部署正常工作的GSLB以外，
再部署一台备份的GSLB设备，并将这一备份GSLB设备隐藏起来，不对外公布。

HTTP重定向（CDN GSLB用302重定向）：在HTTP协议中，有三类重定向状态码：
301永久性转移（permanently moved）、
302暂时转移（temporarily moved）、
meta fresh在特定时间后重定向到新的网页
HTTP重定向只适用于HTTP应用，不适用于任何其他应用。
比如微软的MMS协议，RTSP协议，就不能使用这种方式 进行重定向。
其次，由于HTTP重定向过程需要额外解析域名URL，还需要与URL建立TCP连接并且发送HTTP请求，使得响应时间加长。
第三，不同于DNS方式，没有任何用户请求能被外部系统终结（不能缓存），
所有请求都必须进入GSLB系统，这将成为性能和可靠性的瓶颈。(流媒体用的比较多)

基于IP路由的GSLB
基于路由协议算法选择一条路由到达这两个本地均衡器中的一个。
因为每次访问请求的终端IP地址不同，路由条件也不同，
所以在多个路由器上优选的路由不同，从统计复用的角度来看基本是在负载均衡器1和2之间均匀分布的。
IP路由在多个POP点之间实现的负载均衡是一种概率上的均衡，而不是真正的均衡（没做智能调度）。

基于DNS解析方式,基于HTTP重定向方式,基于IP路由方式 这3种方式的比较

性能
基于DNS解析方式：本地DNS服务器和用户终端DNS缓存能力使GSLB的负载得到有效分担
基于HTTP重定向方式：GSLB处理压力大，容易成为系统性能的瓶颈
基于IP路由方式：借助IP网络设备完成负载均衡，没有单点性能瓶颈

准确度
基于DNS解析方式：定位准确度取决于本地DNS覆盖范围，本地DNS设置错误会造成定位不准确
基于HTTP重定向方式：在对用户IP地址数据进行有效维护的前提下，定位准确且精度高
基于IP路由方式：就近性调度准确，但对设备健康性等动态信息响应会有延迟

效率
基于DNS解析方式：效率约等于DNS系统本身处理效率
基于HTTP重定向方式：依靠服务器做处理，对硬件资源的要求高
基于IP路由方式：效率约等于IP设备本身效率

扩展性
基于DNS解析方式：扩展性和通用性好
基于HTTP重定向方式：扩展性较差，需对各种应用协议进行定制开发
基于IP路由方式：通用性好，但适用范围有限

商用性
基于DNS解析方式：在Web加速领域使用较多
基于HTTP重定向方式：国内流媒体CDN应用较多
基于IP路由方式：尚无商用案例

备注：随笔中内容来源于网上资料整理,仅供参考