GSLB

CDN内容分发网络、DNS智能解析与全局负载均衡

首先抛出两个概念:

 智能DNS  CDN内容分发网络  全局负载均衡(GSLB)

  一、智能DNS
  普通的DNS服务器只负责为用户解析出IP记录,而不去判断用户从哪里来,这样会造成所有用户都只能解析到固定的IP地址上。
  智能DNS颠复了这个概念。智能DNS会判断用户的来路,而做出一些智能化的处理,然後把智能化判断後的IP返回给用户。

比如腾讯家的DNSPODS,免费版可以做到

  • 智能解析线路默认、电信、联通、移动、教育网、国外
  • A记录负载均衡2

     

    通过DNS设置路线来自定义Cloudflare的路线,比如我的网站境外是CName Cloudflare的免费节点,国内电信路线没有好的路线,所以干脆就A纪录到源站,源站电信走的CN2 GIA 电信骨干网,联通解析A到Cloudflare的NTT路线,而移动走的Cloudflare Hk直连,速度还是蛮不错的。

    通过路线DNS解析可以一定程度缓解Cloudflare免费版自动分配路线对国内路线不友好的情况,但是由于Cloudflare使用的是泛播技术,IP看上去是一成不变的,但是路线会只能自动选择,所以说现在DNS解析的路线只是就近最好方案,并不是永久有效。

    三、CDN内容分发网络

    上一段中提到的Cloudflare就是全球几大CDN厂商之一,在国内来看CF减速云用来防护DDOS的意义远远大于内容分发,其他CDN厂商还有FASTLY,AMAZON,GOOGLE,国内有ALI,Tencent,UPYUN,套壳CF的百度云加速

    CDN的全称是Content Delivery Network,即内容分发网络。其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节,使内容传输的更快、更稳定。通过在网络各处放置节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络,CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。其目的是使用户可就近取得所需内容,解决 Internet网络拥挤的状况,提高用户访问网站的响应速度。

    总结一下:

    1. 将内容分发与缓存,缓解源站压力
    2. 隐藏源站IP,一定程度缓解DDOS和CC
    3. 缓解甚至消除了不同运营商之间互联的瓶颈造成的影响
    4. 优化了网上热点内容的分布

    但是CDN的缓存规则一定要好好研究一下,不然就和我一样,刚才文章写到一半,突然一刷新只剩下浏览器缓存了,除去CF和百度的CDN,其他家的CDN都是按量付费的,睡了一觉被D了,醒了发现被D去了一套房

    三、全局负载均衡

    全局负载均衡(GSLB)的前提是在不同地区设立了多个数据中心,并不是所有的互联网服务都能做GSLB,实施全局负载均衡可能需要以下前提:

    • 业务与用户弱相关,无论用户从哪个IDC访问都能得到相同的结果;
    • 或者以地域划分用户,用户不会出现跨区域流动访问的情况,只会访问就近IDC;
    • 或者有一套入口调度或者内部调度机制,能将用户调度到所属的系统;
    • 或者用户数据能强一致性同步,并有一套数据同步失效的预案。

    现在很多CDN也都提供动态内容的加速,只不过这个加速只是数据传输上的优化,可以看做给你做了很多个转发节点,最终业务处理压力还是源站承担。如果不具备分布式部署改造的条件,只是要解决远距离客户访问慢问题,可以考虑CDN。

    全局负载均衡关键的技术是智能DNS

    除了使用域名托管服务商提供的智能DNS解析服务,一些对可靠性和性能要求高的用户都会使用硬件的全局负载均衡解决方案。我曾做过数个国有大型银行、企业的全局负载均衡项目,使用F5或Radware的GSLB设备来实现的。据我所知,目前国内智能DNS服务商提供的服务目前还无法感知线路繁忙和后端服务器真实负载情况,只能使用发http请求的健康检查的方法后知后觉避免过载,而硬件GSLB因为部署在IDC端,能与服务器联动,实时感知的线路和后端情况。

    下例的全局负载均衡解决方案中,域名服务商处将域名的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值太小会造成查询频繁,对设备和网络的压力增大。

     

    打个比方,用户像是MJJ,CDN有点像AFF与厂商的微妙关系,厂商(源服务器)只有一家,CDN充作AFF的角色,GSLB像是厂商与厂商之间,但不是竞争关系是同甘共苦的关系,而DNS智能解析就是AFF本人,根据您的需求给推荐。

    发布者

    王药酒

    本站采用 知识共享署名4.0 国际许可协议进行许可 本站文章除注明转载/出处外,均为本站原创或翻译,转载前请务必署名