QuXiao's Blog

Life && Tech && Thoughts

GSLB调研(二)产品 && 架构

Written on

GSLB产品

硬件

一般来说,一些财大气粗的公司都会购买专门的GSLB硬件产品,而那些卖GSLB的硬件厂商一般也都是在行业内精耕多年的老牌厂商,比如F5这类专门提供应用交付网络(Application Delevery Networking)解决方案。

一些提供GSLB硬件产品的厂商有:

  • F5 Networks
  • A10
  • Foundry
  • Nortel
  • Radware
  • ServerIron

而这些厂商提供的解决方案都如下图所示:

应用服务在公网中提供一系列的广域流量管理设备(其实就是权威DNS),这些设备会告诉请求的用户具体的服务器地址,而这些服务器又会通过本地流量管理设备将请求负载均衡至多台真实服务器上面,最终达到流量的调度以及负载均衡的目的。

Sass版本

除了以硬件为主的解决方案,还有一部分Sass版本的方案。在网上查了一下,专门做Sass版本的GSLB的只有一家——gslb.me。

gslb.me这个产品对应的公司感觉很特殊,是一家2007年成立的意大利公司,(据官网说)服务超过了100个国家的用户。但是打开官网你会发现,也前端样式看相当『朴素』,让我感觉是一个几个甚至一个人的团队作出的产品。但是从产品功能上看,又是相对比较全面的。上面介绍的功能主要有:

  • 权威DNS
  • CDN offload(基于用户体验以及成本的多CDN负载)
  • DNS防火墙
  • 动态DNS
  • 地域路由
  • 负载均衡
  • 数据报表
  • URL转发
  • RESTful API

这里面,重点的功能还是地域路由(Georouting)。gslb.me的地域路由规则基于三部分:

  1. 国家或地区
  2. ASN(Autonomous System Number)自治系统编号
  3. ISP运营商

根据以上三个规则中的一个或多个,将来源流量进行分类,接着就是根据流量的分类,指向不同的IP。不同IP之间通过调度算法来选择,gslb.me提供的调度算法有:

  • any available

  • priority

  • proximity
    • geographical proximity (distance between clients and servers)
    • country-based proximity
  • round robin

  • weighted

具体算法就不一一介绍了,其它主要思想就是这么几种:

  • 随机选(纯随机/考虑权重)
  • 根据链路情况选(延时/跳数)
  • 根据负载情况选(响应时间/机器层面/...)
  • 根据地域选(国家/距离)

界面如下图:

另外,除了gslb.me,AWS的Route 53产品也算是GSLB的范畴。Route 53的主要功能就是检测用户部署的冗余资源的健康情况,将用户的流量指向他认为最合适的资源实例,不过看介绍并没有Georoute的功能,算是一个全网范围的负载均衡服务吧。

GSLB系统架构

查阅网上的资料,比较全面且有参考意义的是《构建⾼效、安全的CDN —— 阿⾥CDN核⼼技术揭秘》中对于实时调度系统(也就是GSLB)的介绍。按照我的理解,GSLB分为三大部分:采集/计算、调度、以及DNS系统。

采集/计算

首先,采集数据就最基础的工作,没有数据谈何调度。采集系统主要用于获取CDN节点(当然也可以是其它业务节点)和用户访问的性能/状态/拓扑数据,是整个GSLB的基础。

其中,节点端会采集:节点负载数据(CPU/内存/带宽/连接数/…),以及节点上模块的访问日志数据(带宽/响应时长/错误码/拓扑关系/…);用户端会采集:节点链路信息(Ping RTT/丢包率),当然也可以是其它二、三、四、七层探测,比如ARP协议或者直接HTTP协议;DNS端会采集到:DNS的请求流量以及客户或者LocalDNS的IP。

计算主要是对采集到的原始信息按照不同粒度进行加工和统计,比如模块访问日志信息中会有Client IP、Server IP、返回码、响应时间、请求资源大小等数据,这些基础数据一般量都比较大(每秒MB~GB的级别),需要通过一些分布式计算框架来进行统计,最终得到按照不同运营商、机房、用户地区等维度的链路/带宽等数据,给调度模块提供数据支持。

调度

通过直接采集以及间接统计得到了数据之后,就需要调度系统派上用场了。而调度系统中提到的调度算法,前面也讲过一些,这里再罗列一下查询资料中提及的算法:

  • 通用算法
    • Round Robin
  • 基于负载的算法
    • Global Link
    • Member-based Weighted Round Robin
    • Site-based Weighted Round Robin
    • Connection Overflow
    • Member-based Volume Overflow
    • Site-based Volume Overflow
    • Member-based Hit Overflow
    • Site-based Hit Overflow
    • Response Time based
  • 基于距离(链路)的算法
    • Proximity
    • Least Hop
    • Least Latency

另外,在《 淘宝CDN全局流量调度算法介绍 》中,也介绍了三类调度算法,比较详细,大家也可以看看。

DNS

调度系统通过迭代的方式得到目前最优的流量调度结果,最终,还是通过对外提供服务的权威DNS系统来得以体现。目前市面上有许多开源DNS系统,最著名有Bind、PowerDNS、NSD等等。

衡量一个DNS系统是否优秀,我觉得需要参考方面:

  • 性能是否足够好
    • 单纯Query性能
    • 在Update的情况下的Query性能
    • 在不同Zone和View量级的情况下的Query性能
  • 支持协议是否完备
    • EDNS
    • DNSSEC
    • TSIG
    • Nsupdate
    • Slave mode
    • IPv6
  • 数据加载方式
    • 是本地文件(Zone file)/还是存入DB
    • 是否支持在线Reload/Reload效率

Wiki上面有个更加详细的 DNS对比

PS:

目前,我们团队已经基于Bind进行了二次开发,目前初步实现了以下功能:

  • 基于IP库 + View的流量地域+运营商识别
  • DNS记录查询退化(江苏南京电信没有A记录,则查找江苏默认电信A记录)
  • 简单的健康度检测以及调度
  • DB存储记录 + Cache

后续还有很多需要优化的地方,就看有没有机会来实践了。

This entry is posted in note.

comments powered by Disqus