Gslb基础概念和原理

1. 采用全局负载均衡（GSLB）的前提是在不同地区设立了多个数据中心，并不是所有的互联网服务都能做GSLB，前提是业务已经做了分布式部署的规划，无论用户从哪个IDC访问都能得到相同的结果，或者用户基本不会出现跨区域流动访问的情况，只会访问就近IDC，或者有一套入口调度机制，能将用户调度到所属的节点。
2. 现在很多cdn也都提供动态内容的加速，只不过这个加速只是数据传输上的优化，可以看做给你做了很多个转发节点，最终业务处理压力还是源站承担。如果不具备分布式部署改造的条件，只是要解决远距离客户访问慢问题，可以考虑CDN。
3. 目前很多DNS服务商都提供了智能DNS服务，智能DNS可以通过多种负载均衡策略来将客户端需要访问的域名解析到不同的数据中心不同的线路上，比如通过各运营商分省IP地理信息数据来判断用户的就进性，并结合健康检查策略（通常是发一个固定的http请求）来分配访问量。
4. 第三方智能DNS的不足在于通过公网健康检查可能会受到运营商网络拥塞的影响，目前国内域名服务商提供的服务还无法感知线路繁忙程度和后端服务器真实负载情况。除了使用智能DNS解析软件或者云服务，多数对可靠性和性能要求高的用户都会使用硬件的全局负载均衡解决方案。全局负载均衡设备通过更丰富的维度来判断用户就进性，形成就进性表，除了分地域IP数据库外，还可以通过TTL、用户访问延时、服务器负载情况等来判断。
5. 下例的全局负载均衡解决方案中，域名服务商处将域名的NS记录指向有智能DNS解析功能的GSLB设备，然后由GSLB设备来进行A记录解析。如果在多地部署了GSLB设备，它们都应该添加到NS记录中以保证高可用性，域名服务商处轮询地返回GSLB地址或者一次性返回全部地址。GSLB设备会对自己所在的IDC后端服务器以及其他IDC公网IP进行健康检查，健康检查结果会通过自有协议在不同IDC的GSLB设备之间同步，最终根据全局负载均衡策略来选择最优的地址解析给用户。

解析的步骤示意如下图：

 

 

1. 用户向本级配置的本地DNS服务器发出查询请求，如果本地DNS服务器有该域名的缓存记录，则返回给用户，否则进行第2步；
2. 本地DNS服务器进行递归查询，最终会查询到域名注册商处的授权DNS服务器，这里可能有多个步骤，图中只反映最后一步；
3. 授权DNS服务器返回一条NS记录给本地DNS服务器。根据授权DNS服务器上的不同设置，这条NS记录可能是指向随机一个GSLB设备的接口地址或者是所有GSLB设备的接口地址；
4. 本地DNS服务器向其中一个GSLB地址发出域名查询请求，如果请求超时会向其它地址发出查询；
5. GSLB设备选出最优解析结果，返回一条A记录给本地DNS服务器。根据全局负载均衡策略设定的不同可能返回一个或多个VIP地址；
6. 本地服务器将查询结果通过一条A记录返回给用户，并将缓存这条记录。

通过DNS解析报文中的TTL（Time To Live）字段可以控制客户端缓存这条记录的时间，在缓存时间内客户端会使用旧的查询结果，当缓存时间超时后才可能重新发出查询，TTL值过大会导致故障发生时切换时间过长，TTL值太小会造成查询频繁，对设备和网络的压力增大。

1. 请注意GSLB设备收到的DNS请求的源地址不是用户的地址而是用户所配置的本地DNS服务器地址，而GSLB的就进性探测是根据这个地址来判断的，在我国大多数ADSL拨号上网用户都能就近分配正确的数据中心，但是当用户用户通过4G移动网络上网的情况下，客户会一直使用归属地的DNS服务器，或这手动设定本地DNS而设置的DNS距离用户较远的情况，GSLB不能分配最佳的地址。这种情况很常见，国内有很多人使用google的公有dns或者opendns。
2. 这种情况可以使用重定向来解决，SLB设备正式收到用户发来的请求时，会再次查找就进性表，当发现用户的最佳访问节点非自己时，通过http 302重定向来再次引导用户流量。

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

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

1. A记录（address）：域名->多个IP的映射。对同一个域名，可以有多条A记录
2. NS记录（name server）：指定由哪台DNS服务器来解析
3. SOA记录（start of authority）：指定该区域的权威域名服务器
4. CNAME记录（canonical name）：多个域名->服务器的映射
5. PTR记录（pointer record）：IP->域名的映射

1. 这是基于DNS的轮询机制。
2. 如果有多台Web服务器（多源）同时为站点 abc.com提供服务，abc.com的权威服务器可能会解析出一个或多个IP地址。
3. 权威域名服务器还可以调整响应中IP地址的排列方式，即在每次响应中将不同的IP地址置于首位（取决于可服务能力和服务质量），通过这种方式实现对这些Web服务器的负载均衡

1. 域名服务器获得CNAME记录后，就会用记录中的别名来替换查找的域名或主机名（实现多个域名->服务器映射）。
2. 后面会查询这个别名的A记录来获取相应的IP地址。
3. 具体操作为：
   1. 先将GSLB的主机名定义为所查询域名的权威DNS服务器的别名，然后将GSLB主机名添加多条A记录，分别对应多个服务器的IP地址。
   2. 这样，本地DNS服务器会向客户端返回多个IP地址作为域名的查询结果，并且这些IP地址的排列顺序是轮换的。
   3. 客户端一般会选择首个IP地址进行访问。

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

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

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

智能DNS功能，它在向本地DNS返回应答之前会先根据一些静态或动态策略进行智能计算。

1. 服务器的“健康状况”
2. 地理区域距离
3. 会话保持
4. 响应时间
5. IP地址权重
6. 会话能力阈值
7. 往返时间（TTL）
8. 其他信息，包括服务器当前可用会话数、最少选择次数、轮询等

1. 关于内容的缓存问题（如何智能调度最有效）和配置
   1. 在有些CDN中（用于视频网站加速的情况较多），网站需要加速的内容全部先缓存在OCS（内容中心）
   2. 然后再将一部分 （通常是热门的内容）分发到各个POP节点（Cache边缘集群）
   3. 所以POP节点在某些时候会出现本地不命中而需要回OCS取内容或者从其他POP节点取内容的情况

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

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

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

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

1. 性能
   1. 基于DNS解析方式：本地DNS服务器和用户终端DNS缓存能力使GSLB的负载得到有效分担
   2. 基于HTTP重定向方式：GSLB处理压力大，容易成为系统性能的瓶颈
   3. 基于IP路由方式：借助IP网络设备完成负载均衡，没有单点性能瓶颈
2. 准确度
   1. 基于DNS解析方式：定位准确度取决于本地DNS覆盖范围，本地DNS设置错误会造成定位不准确
   2. 基于HTTP重定向方式：在对用户IP地址数据进行有效维护的前提下，定位准确且精度高
   3. 基于IP路由方式：就近性调度准确，但对设备健康性等动态信息响应会有延迟
3. 效率
   1. 基于DNS解析方式：效率约等于DNS系统本身处理效率
   2. 基于HTTP重定向方式：依靠服务器做处理，对硬件资源的要求高
   3. 基于IP路由方式：效率约等于IP设备本身效率
4. 扩展性
   1. 基于DNS解析方式：扩展性和通用性好
   2. 基于HTTP重定向方式：扩展性较差，需对各种应用协议进行定制开发
   3. 基于IP路由方式：通用性好，但适用范围有限
5. 商用性
   1. 基于DNS解析方式：在Web加速领域使用较多
   2. 基于HTTP重定向方式：国内流媒体CDN应用较多
   3. 基于IP路由方式：尚无商用案例