云内 GSLB 技术及应用场景

本文分享自天翼云开发者社区《云内GSLB技术及应用场景》，作者:c****n

云业务容灾建设节奏一般是同城双活—异地双活—两地三中心（同城双活+异地多活），因为要解决的问题的复杂度和难度也是在逐步上升的，不可能一蹴而就。gslb 可以实现两地三中心容灾，这时应用在多数据中心的情况下，业务需要分布式部署，无论哪个数据中心都可以独立承担业务，数据中心内通过服务器负载均衡（lb）进行数据中心内的业务负载，gslb 是通过 dns 给 lb 做负载均衡，配合健康检查实现业务的故障切换，数据中心切换，一些算法如静态就近性可以就近访问加速等。

一、基本概念

1.业务域名

用户访问应用服务的 dns 域名。

2.服务成员

域名最后返回的 ip 的地址，这个 ip 地址一般就是 slb 负载均衡设备的 ip。

3.地址池

一组服务成员的集合，可以选择服务成员的调度算法，健康检查，ttl 等设置。用于服务成员的管理。

4.健康检查

1）服务成员健康检查

检查应用服务是否正常，常用的健康检查有 icmp, tcp,udp,http 等。

已 icmp 为例，探测设备主动去 ping 服务成员 ip，通过是否应答来判断服务成员是否有效。

2）链路健康检查

检查数据中心内的某条链路是否健康，用 icmp 方法，不能进行跨数据中心的探测。

5.算法

调度的规则，二级调度，一级是域名选池，二级是池选服务成员。

常用的算法有轮询，加权轮询，静态就近性，全局可用性等。

二、应用场景

基本都是多数据中心，分布式部署，每个数据中心都有所有数据中心的配置信息，保证 dns 请求到哪个 gslb 都有同样的应答。

常见的应该场景有业务容灾，多活，就近访问加速等。

以两地三中心容灾方案为例详细说明下。

业务域名：www.aaa.com

主数据中心 dc1，服务成员 m1(1.1.1.1 电信)，服务成员 m2(1.1.1.2 联通)。

同城灾备数据中心 dc2，服务成员 m3(2.2.2.1 电信)，服务成员 m4(2.2.2.2 联通)。

异地灾备数据中心 dc3，服务成员 m5(3.3.3.1 电信)，服务成员 m6(3.3..2 联通)。

每个数据中心一台 gslb 设备。

正常情况下 dns 请求到达任何一台 gslb 时，应答规则

1）电信的用户返回电信的服务成员，联通的用户返回联通的服务成员，其他的用户返回电信的服务成员。

2）主数据中心的成员可用时优先用主数据中心，主数据中心服务成员故障后用同城灾备数据中心，同城灾备数据中心也故障再用异地灾备数据中心。

1.业务图

2.配置逻辑图

3.核心算法

1）静态就近性算法

根据用户源 ip 所在物理位置进行策略匹配。

2）静态地址库

获取用户的物理位置需要全球 ip 地址库，需要把 ip 地址库加载到内存中，然后把源 ip 在内存中匹配下，就可以获取到相应物理位置信息，这个地址库一般每行是代表一个地理信息，例如

前面两列是起始 ip 和终止 ip，后面是国家，省，市，组织，运营商

3）动态用户区域

除了静态地址库设备自身携带外，也需要支持用户自定义某个网段属于哪个国家，省，市，运营商等。

这部分提供用户自定义网段属于某个物理位置配置，然后在配置静态就近性策略时去选择这个用户区域。

4.探测与同步

1）探测：

做健康检查的设备，分为服务成员探测和链路探测。

链路探测只能在本数据中心进行探测。

服务成员探测根据和同步规则可以进行跨数据中心探测。

2）同步：

正常情况下，本中心的 gslb 设备只对自己数据中心的服务成员做健康检查，然后把本数据中心的健康检查结果同步给其他数据中心的 gslb 设备，最后的结果就是每个数据中心都有所有数据中心的健康检查结果，探测设备同时也是同步设备。

3）同步规则和探测的关系：

红色线：同步

黄色线：探测

①仅本地

不管 gslb 设备之间的同步连接情况如何，本数据中心的 gslb 设备只探测本数据中心的服务成员。

②优先本地

gslb 设备之间的连接正常时，本数据中心的 gslb 设备只探测本地。

gslb 设备之间的连接异常时，本数据中心的 gslb 设备会探测连接异常的异地的数据中心的服务成员。

③同时多数据中心

gslb 设备会向所有数据中心的服务成员发送健康检查探测，这样每个服务成员会有所有数据中心的健康检查结果，最后这个健康检查的结果为配置的有效性个数决定。

例如：设置有效性为 2，m1 有 gslb123 设备三个探测结果，综合 2 个或者 2 个以上 up,则 m1 为 up。