大家好,又见面了,我是你们的朋友全栈君。
摘要
GSLB 是 Global Server Load Balance 的缩写,即全局负载均衡。本文首先介绍了什么是负载均衡 SLB ,以及为什么要使用 SLB 。接着引出全局负载均衡 GSLB 的概念和作用。为此介绍了其基于 DNS进行解析和分配负载的实现,包括 DNS 的原理简介、应用部署中的基本概念、分配负载的决策条件等内容。以外,本文还简单介绍了通过 HTTP 和 IP 实现 GSLB 的方式,并对三者的优缺点进行了简单对比。最后是本文的参考文献。
关键词: GSLB , DNS, CDN
1. 负载均衡 SLB
1.1 负载均衡及其作用
负载均衡(Server Load Balance, SLB),其含义是将负载(工作任务)平衡分散到多个服务器上。CDN是典型的负载均衡集群系统。
图1.1是负载均衡的示意图。从图中可以看出,负载均衡设备可以在用户请求到达服务器之前将其截获,然后将其分发到合适的后端服务器。
图1.1 SLB示意图
也就是说,客户端发出的请求,首先会到负载均衡设备的IP地址上。因为该IP地址并不负责处理实际的业务,所以通常将该地址称为【虚拟IP】(Virtual IP, VIP)。
后端真正的业务服务器被称为【真实服务器】(Real Server, RS),其IP地址被称为【真实IP】(Real IP, RIP),负责处理业务。
举个例子,VIP 就像是前台招待,会告诉你办什么事该去哪个房间。而RIP是内部实际办业务的房间号。
利用负载均衡,很大程度上可以避免单个服务器过载或者闲置,前者会引起服务能力下降,后者则没有充分利用资源。因此,为了达到更好的系统处理能力,需要进行以下两个步骤:
- 在集群前端部署负载均衡设备
- 根据预先配置的均衡策略,在集群中智能分发用户请求
1.2 负载均衡关键技术
要做到负载均衡,需要的问题包括但不限于以下几个方面
- 请求的分发
- 会话保持
- 服务健康监测
- 故障隔离
- 自动恢复
1.2.1 请求分发算法
请求分发算法,可以分为【静态算法】和【动态算法】两大类。
-
静态算法
静态算法是指按照预先设置好的策略进行分发,而不考虑服务器当前的实际负载状况。
这类算法包括轮询、加权轮询、基于源IP或目的IP的hash算法等等,优点是简单快捷。
-
动态算法
动态算法指的是能够根据当前服务器状况进行分发,包括最小连接,加权最小连接等。
1.2.2 会话保持
出于一些业务的特殊要求,有时候需要进行会话保持,以保证一段时间内,某一个用户与系统的交互(会话),只交给同一台服务器处理。
例如,大多数电商应用需要用户认证,而一次交易需要与服务器多次交互才能完成。这几次交互必须由同一台服务器处理,而不能被分散到不同服务器上。
会话保持有以下几种方法:
- 源IP地址的持续性保持
- cookie 持续性保持
- 基于HTTP报文头的持续性保持
1.2.3 服务器健康检测
为了保证服务质量,需要定时进行健康检测。我们可以利用ICMP、TCP、HTTP、FTP等协议进行检测,即主要是在传输层和应用层进行检测。
应用层的检测颗粒更细,但对系统的要求也比较高,因为需要针对应用层的不同的协议做不同的识别分发机制。应用层检测用的比较多的就是HTTP协议,比如先和集群中的设备建立连接,然后发出请求,如果收到正确应答,则说明HTTP处理正常。
传输层的检测,主要在于能否建立TCP连接,回响是否正常,等等。
2. 全局负载均衡GSLB
2.1 GSLB的简介与作用
GSLB, Global Server Load Balance, 即全局负载均衡。
由于现实中存在各种不稳定因素,比如某个服务器集群所在的数据中心断电,洪水或者地震造成数据中心瘫痪等等。在一个数据中心内,无论采用怎样的技术,总可能存在一些不可抗因素,导致其瘫痪。所以通常会把服务器分散部署到多个数据中心,以最大程度减小灾害对服务质量产生影响的概率和程度。
另外,CDN系统总是希望用距离用户最近的设备为其提供服务,这也需要在不同地域部署多个节点。
GSLB系统就是针对这个问题的。它负责多个CDN节点之间相互协作,将各节点和设备的负载保持在一个有利于提供优质服务的水平。GSLB的负载均衡结果可能直接将用户分配到RS,也可能将用户交付到下一层次的负载均衡系统。
经过多年发展,已有多种调度机制可实现CDN的全局负载均衡。其中最常用的是基于DNS的GSLB。
2.2 DNS简介
2.2.1 DNS工作流程
DNS是一个应用层协议,但它通常被其他的应用层协议使用,以便将主机名(host)解析为IP地址。DNS的工作流程如图2.1
图2.1 DNS的基本工作流程
在第4步中,本地DNS服务器(Local DNS, LDNS
)在得到浏览器解析的域名请求后,会采用迭代或递归查询的方式,向DNS 系统中其他远程域名服务器提出查询请求,如图 2.2 所示。
图2.2 域名解析
如果LDNS
中没有关于这个域名的缓存,则首先会去根域名服务器请求解析.root
,收到其返回的.com
域的域名服务器列表。LDNS在该列表中选出一个域名服务器,对其发出域名解析请求。
被请求的.com
域的域名会查找CDNbook.com
的权威域名服务器的IP,并将其返回给LDNS。
由于这个权威域名服务器是CDNbook.com
这个域名授权的,所以LDNS
对权威域名服务器请求后就能得到www.CDNbook.com
的IP地址,并将其返回给客户端。
另一方面,如果在LDNS
上有<www.CDNbook.com
—IP
>的缓存记录,就可以直接把这个结果返回给客户 端,节省了中间的递归查找步骤时间和资源开销。
2.2.2 DNS记录的类型
DNS服务器是根据资源记录来对DNS请求进行应答的。其中,最常见的是Internet
类的记录(Class IN
)。Internet
类的记录主要有以下几种类型(Type
):
-
A
记录A
记录即地址Address
记录,对应的value
是域名的IP
地址。 -
NS
记录域名服务器
Name Server
记录,保存了下一级域名信息的服务器地址。该记录只能设置为域名,不能设置为IP
地址。 -
CNAME
记录规范名称记录
Canonical Name for an alias
,也称为别名记录,其value
是另一个域名。也就是说,将原域名key
映射到了另一个域名value
。举个栗子。百度的域名是
www.baidu.com
,它的cname
是www.a.shifen.com
。那么,我们已经有了一个域名了,为什么还要设置cname呢?假设有
www.domain.com
和mail.domain.com
,其cname都指向host.domain.cdnxxx.com
。然后某一天,我们的服务器地址(A记录对应的IP地址)可能要变了。由于www和mail都会被引导到
www.domain.wscdn.com
,所以这时我们只需修改host.domain.wscdn.com
的A记录,而不必把www和mail的A记录都改一遍。因此cname增加了灵活性,在子域多的时候更为明显,相当于进行了批量管理。
-
RR
记录资源记录
Resource Record
。一个主机名可以对应多个IP地址,在一个DNS应答报文中可能含有多条RR
信息。
下面我们使用nslookup
来对上述的几个定义进行具体说明。
$ nslookup www.baidu.com
# 返回如下响应
Non-authoritative answer:
www.baidu.com canonical name = www.a.shifen.com.
Name: www.a.shifen.com
Address: 112.80.248.74
Name: www.a.shifen.com
Address: 112.80.248.73
首先,www.baidu.com
没有A记录,但是通过cname
被引导到了www.a.shifen.com.
。
其次,www.a.shifen.com
有2条A记录,也就是一个主机对应了2个IP。实际上,如过在不同地区进行DNS请求,则最后得到的这2条A记录也不同。采用某国外VPS进行请求的结果是14.215.177.38
和14.215.177.37
。这么做是为了将不同地区的用户分配其最近的服务节点,以便快速访问。后面的内容将会解释这一点。
发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/130967.html原文链接:https://javaforall.cn
【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛
【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...