云内GSLB技术及应用场景

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

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

一、基本概念

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

2.服务成员
域名Zui后返回的ip的地址，这个ip地址一般就是slb负载均衡设备的ip。

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

4.健康检查

1）服务成员健康检查

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

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

2）链路健康检查

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

5.算法

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

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

二、应用场景

基本都是多数据中心，分布式部署，每个数据中心都有所有数据中心的配置信息，保证dns请求到哪个gslb都有同样的应答。
常见的应该场景有业务容灾，多活，就近访问加速等。
以两地三中心容灾方案为例详细说明下。

业务域名：

主数据中心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设备，Zui后的结果就是每个数据中心都有所有数据中心的健康检查结果，探测设备同时也是同步设备。

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

红色线：同步

黄色线：探测

 

①仅本地

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

②优先本地

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

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

③同时多数据中心

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

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