Copyright © 2012 杭州华三通信技术有限公司 版权所有,保留一切权利。 非经本公司书面许可,任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部, 并不得以任何形式传播。本文档中的信息可能变动,恕不另行通知。 |
随着Internet的快速发展和业务量的不断提高,基于网络的数据访问流量迅速增长,特别是对数据中心、大型企业以及门户网站等的访问,其访问流量甚至达到了10Gb/s的级别;同时,服务器网站借助HTTP、FTP、SMTP等应用程序,为访问者提供了越来越丰富的内容和信息,服务器逐渐被数据淹没;另外,大部分网站(尤其电子商务等网站)都需要提供不间断24小时服务,任何服务中断或通信中的关键数据丢失都会造成直接的商业损失。所有这些都对应用服务提出了高性能和高可靠性的需求。
但是,相对于网络技术的发展,服务器处理速度和内存访问速度的增长却远远低于网络带宽和应用服务的增长,网络带宽增长的同时带来的用户数量的增长,也使得服务器资源消耗严重,因而服务器成为了网络瓶颈。传统的单机模式,也往往成为网络故障点。
图1 现有网络的不足
针对以上情况,有以下几种解决方案:
(1) 服务器进行硬件升级:采用高性能服务器替换现有低性能服务器。
该方案的弊端:
· 高成本:高性能服务器价格昂贵,需要高额成本投入,而原有低性能服务器被闲置,造成资源浪费。
· 可扩展性差:每一次业务量的提升,都将导致再一次硬件升级的高额成本投入,性能再卓越的设备也无法满足当前业务量的发展趋势。
· 无法完全解决现在网络中面临的问题:如单点故障问题,服务器资源不够用问题等。
(2) 组建服务器集群,利用负载均衡技术在服务器集群间进行业务均衡。
多台服务器通过网络设备相连组成一个服务器集群,每台服务器都提供相同或相似的网络服务。服务器集群前端部署一台负载均衡设备,负责根据已配置的均衡策略将用户请求在服务器集群中分发,为用户提供服务,并对服务器可用性进行维护。
该方案的优势:
· 低成本:按照业务量增加服务器个数即可;已有资源不会浪费,新增资源无需选择昂贵的高端设备。
· 可扩展性:当业务量增长时,系统可通过增加服务器来满足需求,且不影响已有业务,不降低服务质量。
· 高可靠性:单台服务器故障时,由负载均衡设备将后续业务转向其他服务器,不影响后续业务提供,保证业务不中断。
图2 负载均衡技术
SSL VPN网关、IPsec网关、防火墙网关等网关设备,因为业务处理的复杂性,往往成为网络瓶颈。以防火墙网关为例:防火墙作为网络部署的“警卫”,在网络中不可或缺,但其往往不得不面临这样的尴尬:网络防卫越严格,需要越仔细盘查过往的报文,从而导致转发性能越低,成为网络瓶颈。
在这种情况,如果废弃现有设备去做大量的硬件升级,必将造成资源浪费,随着业务量的不断提升,设备也将频繁升级。频繁升级的高成本是相当可怕的。因此将网关设备等同于服务器,组建网关集群的方案应运而生:将多个网关设备并联到网络中,从而形成集群,提高网络处理能力。
信息时代,工作越来越离不开网络,为了规避运营商出口故障带来的网络可用性风险,和解决网络带宽不足带来的网络访问问题,企业往往会租用两个或多个运营商出口(如:电信、网通等)。如何合理运用多个运营商出口,既不造成资源浪费,又能很好的服务于企业?传统的策略路由可以在一定程度上解决该问题,但是策略路由配置不方便,而且不够灵活,无法动态适应网络结构变化,且策略路由无法根据带宽进行报文分发,造成高吞吐量的链路无法得到充分利用。链路负载均衡技术通过动态算法,能够在多条链路中进行负载均衡,算法配置简单,且具有自适应能力,能很好的解决上述问题。
随着社会各领域全球化进程的日益深化,实现各方面信息的全球共享成为人们的迫切需求。然而,无论用户的数据中心内部采用多么完善的冗余机制、安全的防范工具以及先进的负载均衡技术,单个数据中心的运行方式仍然不能保证关键业务的7×24小时不间断运行。此外,单一的数据中心也无法使广域范围内全球各地用户在访问应用时具有相同的快速访问感受。通过在不同物理位置构建多个数据中心,并利用全局负载均衡技术在多个数据中心间实现协调工作,引导用户访问最优的站点,当某个站点出现灾难性的故障后依然可以让其他站点为用户提供服务,这样便能有效解决上述问题。
负载均衡提供了一种廉价、有效、透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力,提高网络的灵活性和可用性。
负载均衡技术具有如下优点:
· 高性能:通过调度算法,将客户端请求合理地均衡到后端各台服务器上,消除系统可能存在的瓶颈。
· 可扩展性:当服务的负载增长时,系统能被扩展来满足需求,且不降低服务质量。
· 高可用性:通过健康性检测功能,能实时监测应用服务器的状态,保证在部分硬件和软件发生故障的情况下,整个系统的服务仍然可用。
· 透明性:高效地使由多个独立计算机组成的松耦合的服务系统构成一个虚服务器;客户端应用程序与服务系统交互时,就像与一台高性能、高可用的服务器交互一样,客户端无须作任何修改。部分服务器的切入和切出不会中断服务,而用户觉察不到这些变化。
负载均衡设备对外提供的服务称为虚服务。虚服务由VPN实例、虚服务IP地址、服务协议、服务端口号唯一标识,配置在负载均衡设备上。客户的访问请求通过公共或私有网络到达负载均衡设备,匹配到虚服务后,由负载均衡设备按照既定策略分发给真实服务。
实服务是真实服务器提供的一种服务。该服务含义比较广泛,可以是传统的FTP、HTTP等业务应用,也可以是广义的转发服务,如防火墙网关负载均衡中,实服务只是报文转发路径。
OAA即开放应用架构,是华三通信技术有限公司(以下简称H3C)提出的一个开放的软硬件体系,它以路由器或以太网交换机这样的传统网络设备为基础,并在此基础上,提供一套完整的软、硬件标准接口。任何厂商只要按照这样的接口来生产软件或硬件,这些新开发的软硬件就可以和H3C系列路由器或以太网交换机等构成一个完整的系统,为客户创造更大的价值。
持续性功能将属于同一个应用层会话的多个连接定向到同一服务器,从而保证同一业务由同一个服务器处理(或链路转发),并减少LB设备对服务和流量进行分发的次数。
负载均衡设备需要将业务流量根据某种算法分发给不同的实服务(实服务对应服务器负载均衡中的服务器、网关负载均衡中的网关设备和链路负载均衡中的链路),这个分发算法就是负载均衡调度算法。
在链路负载均衡中,就近性功能是指,实时探测链路的状态,并根据探测结果选择最优链路,保证流量通过最优链路转发。
健康性功能是指负载均衡设备对真实的服务器是否能够提供服务进行探测。依据不同的探测方法(即健康性检测方法)可以探测出服务器是否存在,以及是否可以正常提供服务。
系统内置的ISP表描述了不同运营商拥有的地址段信息。链路负载均衡可以基于报文的源或目的地址(Outbound链路负载均衡基于目的地址,Inbound链路负载均衡基于源地址)查找ISP表,得到对应的运营商信息,根据运营商信息为该流量选择一条物理链路。
GLB设备是具有全局负载均衡功能的LB设备,可以是一台独立的设备,也可以与本地负载均衡在同一台设备上提供服务。
多个数据中心协作对外提供服务的描述。例如,通过分布在全球的多个站点对外提供WWW服务,但使用相同的域名www.domainname.com。为了便于管理,不同设备间配置的全局服务名称应一致。
虚服务器是全局负载均衡中为了便于管理而抽象出来的概念,是用户能够直接访问的主机。例如,一个数据中心对外提供一个IP地址,则可以抽象出一台服务器;一个数据中心对外有多个链路,配有多个访问的IP地址,则可以抽象出多台服务器。虚服务器分为本地虚服务器和远程虚服务器,不需要专门配置,是从本地虚服务和远程设备上动态获取的。
全局就近性是全局负载均衡中用于选取虚服务器的一种调度算法,是指通过探测虚服务器与用户之间的网络状态,以及虚服务器本身的负载情况,根据探测结果选取最优的虚服务器来为用户提供服务。
GLB设备之间会进行信息交互,例如获取其它GLB设备上对应全局服务的虚服务器状态信息、通知其它GLB设备进行就近性探测等,承载此类信息的协议为全局LB交互协议。
服务器负载均衡,顾名思义就是对一组服务器提供负载均衡业务。这一组服务器一般来说都处于同一个局域网络内,并同时对外提供一组(或多组)相同(或相似)的服务。服务器负载均衡是数据中心最常见的组网模型。
服务器负载均衡分为四层(L4)服务器负载均衡和七层(L7)服务器负载均衡两种:
· L4服务器负载均衡支持IPv4协议和IPv6协议,是基于流的服务器负载均衡,对报文进行逐流分发,将同一条流的报文分发给同一个服务器。L4服务器负载均衡对基于HTTP的7层业务无法做到按内容进行分发,限制了负载均衡业务的适用范围。依据转发方式,L4服务器负载均衡分为NAT方式和DR方式。
· L7服务器负载均衡只支持IPv4协议,是基于内容的服务器负载均衡,对报文的承载内容进行深度解析,包括HTTP协议、RTSP协议等,根据其中的内容进行逐包分发,按既定策略将连接导向指定的服务器,实现了业务使用范围更广泛的服务器负载均衡。L7服务器负载均衡仅支持NAT方式。
NAT方式L4服务器负载均衡的组网灵活,后端服务器可以位于不同的物理位置,不同的局域网内。NAT方式下,LB设备分发服务请求时,进行目的IP地址转换(目的IP地址为实服务的IP),通过路由将报文转发给各个实服务。NAT方式L4服务器负载均衡的典型组网如图3所示。
图3 NAT方式L4服务器负载均衡
NAT方式L4服务器负载均衡包括以下几个基本元素:
· LB Device:负责分发各种服务请求到多个Server的设备。
· Server:负责响应和处理各种服务请求的服务器。
· VSIP:对外提供的虚拟IP,供用户请求服务时使用。
· Server IP:服务器的IP地址,供LB Device分发服务请求时使用。
客户端将到VSIP的请求发送给服务器群前端的负载均衡设备,负载均衡设备上的虚服务接收客户端请求,依次根据持续性功能、ACL策略、调度算法,选择真实的服务器,再通过网络地址转换,用真实服务器地址重写请求报文的目标地址后,将请求发送给选定的真实服务器;真实服务器的响应报文通过负载均衡设备时,报文的源地址被还原为虚服务的VSIP,再返回给客户端,完成整个负载调度过程。
NAT方式L4服务器负载均衡的工作流程图如图4所示。
图4 NAT方式L4服务器负载均衡流程图
流程简述请参见表1。
表1 NAT方式L4服务器负载均衡流程描述
步骤 | 说明 | 备注 |
(1) | Host发送服务请求报文 | 源IP为Host IP、目的IP为VSIP |
(2) | LB Device接收到请求报文后,借助持续性功能或调度算法计算出应该将请求分发给哪台Server | - |
(3) | LB Device使用DNAT技术分发报文 | 源IP为Host IP、目的IP为Server IP |
(4) | Server接收并处理请求报文,返回响应报文 | 源IP为Server IP、目的IP为Host IP |
(5) | LB Device接收响应报文,转换源IP后转发 | 源IP为VSIP、目的IP为Host IP |
从以上一系列的说明可以看出——在负载均衡时使用网络地址转换技术,NAT方式因此而得名。
组网灵活,对服务器没有额外要求,不需要修改服务器配置,适用于各种组网。
相对于NAT方式,DR方式L4服务器负载均衡中只有客户端的请求报文通过LB,服务器的响应报文不经过LB,从而减少了LB的负载,有效的避免了LB成为网络瓶颈。DR方式下,LB设备分发服务请求时,不改变目的IP地址,而将报文的目的MAC替换为实服务的MAC后直接把报文转发给实服务。DR方式L4服务器负载均衡的典型组网如图5所示。
图5 DR方式L4服务器负载均衡
DR方式L4服务器负载均衡包括以下几个基本元素:
· LB Device:负责分发各种服务请求到多个Server的设备。
· Server:负责响应和处理各种服务请求的服务器。
· VSIP:对外提供的虚拟IP,供用户请求服务时使用。
· Server IP:服务器的IP地址,供LB Device分发服务请求时使用。
DR方式L4服务器负载均衡时,除了LB设备上配置了VSIP,真实服务器也都配置了VSIP,配置的VSIP要求不能响应ARP请求,例如在环回接口上配置VSIP。实服务除了VSIP,还需要配置一个真实IP,用于和LB通信,LB设备和真实服务器在同一个链路域内。发送给VSIP的报文,由LB分发给相应的真实服务器,从真实服务器返回给客户端的报文直接通过交换机返回。
DR方式L4服务器负载均衡的工作流程图如图6所示。
图6 DR方式L4服务器负载均衡流程图
流程简述请参见表2。
表2 DR方式L4服务器负载均衡流程描述
步骤 | 说明 | 备注 |
(1) | Host发送服务请求报文 | 源IP为Host IP、目的IP为VSIP |
(2) | General Device收到请求后转发给LB Device | Server上的VSIP不会响应ARP请求 |
(3) | LB Device接收到请求报文后,借助持续性功能或调度算法计算出应该将请求分发给哪台Server | - |
(4) | LB Device分发报文 | 源IP为Host IP,目的IP为VSIP,目的MAC为Server的MAC地址 |
(5) | Server接收并处理请求报文,返回响应报文 | 源IP为VSIP、目的IP为Host IP |
(6) | General Device收到响应报文后,直接将报文转发给Host | - |
从以上一系列的说明可以看出——负载均衡设备没有采用传统的转发方式(查找路由表)来分发请求报文,而是通过修改目的MAC直接路由给服务器,DR方式也因此而得名。
只有单边报文经过负载均衡设备,负载均衡设备负担小,不易成为瓶颈,转发性能更强。
L7服务器负载均衡的典型组网如图7所示。
图7 L7服务器负载均衡
L7服务器负载均衡包括以下几个基本元素:
· LB Device:负责分发各种服务请求到多个Server的设备。
· Server:负责响应和处理各种服务请求的服务器。
· Service group:实服务组是一个逻辑概念,是指依据多个服务器的一些公共属性,将服务器划分成不同的组。例如:可以按照不同的功用划分为静态资料存储服务器组和动态交换服务器组;还可以按照不同的内容划分为歌曲服务器组、视频服务器组或图片服务器组等。
· VSIP:对外提供的虚拟IP,供用户请求服务时使用。
· Server IP:服务器的IP地址,供LB Device分发服务请求时使用。
客户端首先与服务器群前端的负载均衡设备建立TCP连接,然后将到VSIP的请求发送给负载均衡设备。负载均衡设备上的虚服务接收客户端请求,依次根据持续性功能、实服务组匹配策略、调度算法,选择真实的服务器。然后,负载均衡设备先用客户端地址与真实服务器建立TCP连接,再用真实服务器地址重写客户端请求报文的目标地址,并将请求发送给真实服务器。真实服务器的响应报文通过负载均衡设备时,报文的源地址被还原为虚服务的VSIP,再返回给客户端,完成整个负载调度过程。
L7服务器负载均衡的工作流程图如图8所示。
图8 L7服务器负载均衡流程图
流程简述请参见表3。
表3 L7服务器负载均衡流程描述
步骤 | 说明 | 备注 |
(1)~(3) | Host发起TCP连接请求,与LB Device建立TCP连接 | TCP连接请求的源IP为Host IP、目的IP为VSIP |
(4) | Host发送服务请求报文 | 源IP为Host IP、目的IP为VSIP |
(5) | LB Device收到请求后,根据匹配策略为该请求选择一个合适的实服务组,再借助调度算法计算出应该将请求分发给该实服务组中的哪台Server,并缓存该请求报文 | - |
(6) | LB device向Server发SYN报文,序列号为Host的SYN报文序列号 | 源IP为Host IP、目的IP为Server IP |
(7) | Server发送SYN ACK报文 | 源IP为Server IP、目的IP为Host IP |
(8) | LB device接收Server的SYN ACK报文后,回应ACK报文 | 源IP为Host IP、目的IP为Server IP |
(9) | 修改步骤(5)中缓存的请求报文的目的IP和TCP序列号,然后发给Server | 源IP为Host IP、目的IP为Server IP |
(10) | Server发送响应报文到LB device | 源IP为Server IP、目的IP为Host IP |
(11) | LB device修改响应报文的源地址和TCP序列号后转发给Host | 源IP为VSIP、目的IP为Host IP |
对报文进行深度解析获取报文载荷中携带的信息,实现按内容进行分发,拓宽了负载均衡业务的适用范围。适用于不同的服务器提供不同功能的组网。
网关负载均衡包括以下几个基本元素:
· LB Device:负责分发请求发起方的网络流量到多个网关设备。LB Device又分为一级和二级。如图9所示,如果请求发起方的网络流量方向为Host A > Host B,则LB Device A为一级,LB Device B为二级;如果请求发起方的网络流量方向为Host B > Host A,则LB Device B为一级,LB Device A为二级。
· 网关设备:正常处理数据的网关设备,如:SSL VPN网关,IPsec网关,防火墙网关等。
以防火墙网关负载均衡为例,组网应用如图9所示。
防火墙是基于会话开展业务的,即一个会话的请求和应答报文必须通过同一个防火墙。为了保证防火墙业务正常进行,内部组网不受影响,需要采用双侧负载均衡,即防火墙三明治。在这种组网环境中,对于流入流量,一级LB设备做防火墙负载均衡,二级LB设备保证从哪个防火墙进来的流量,还要从这个防火墙返回。流出流量正好相反。
图10 防火墙负载均衡流程图
表4 防火墙负载均衡流程描述
步骤 | 说明 | 备注 |
(1) | LB Device A接收流量 | - |
(2) | LB Device A依次根据持续性功能、负载均衡调度算法选择一个Firewall,并将流量转发给该Firewall | 由于防火墙基于会话开展业务,建议优先选用源地址散列算法 |
(3) | Firewall将流量转发给LB Device B | - |
(4) | LB Device B作为二级LB Device,记录转发该流量的防火墙,并将流量转发到目的地 | - |
(5) | LB Device B接收目的地发回的流量 | - |
(6) | LB Device B根据(4)中的记录将流量转发给同一个Firewall | - |
(7) | Firewall将流量转发给LB Device A | - |
(8) | LB Device A将流量转发回源地址 | - |
从以上一系列的说明可以看出——两台LB Device之间并联的防火墙进行网络流量的负载分担,提高了网络的性能。两侧的LB Device和中间并联的防火墙——我们称之为三明治负载均衡。
服务对象为防火墙,提高防火墙组网灵活性。没有特殊要求,适用于任何组网环境。
网关负载均衡也可以和服务器负载均衡融合使用,以防火墙网关和服务器负载均衡综合组网为例,具体组网如图11所示。
图中Cluster A为防火墙负载均衡的集群,Cluster B为NAT方式服务器负载均衡的集群。综合组网的工作流程就是防火墙、服务器负载均衡流程的叠加。这样的组网方式既避免了防火墙成为网络中的瓶颈,也提高了各种网络服务(如HTTP、FTP)的性能和可用性。
链路负载均衡根据业务流量方向可以分为Outbound链路负载均衡和Inbound链路负载均衡两种情况。
内网和外网之间存在多条链路时,通过Outbound链路负载均衡可以实现在多条链路上分担内网用户访问外网服务器的流量。Outbound链路负载均衡的典型组网如图12所示。
图12 Outbound链路负载均衡组网图
Outbound链路负载均衡包括以下几个基本元素:
· LB device:负责将内网到外网流量分发到多条物理链路的设备。
· 物理链路:运营商提供的实际链路。
· VSIP:对外提供的虚服务IP,即用户发送报文的目的网段。
Outbound链路负载均衡中VSIP为内网用户发送报文的目的网段。用户将访问VSIP的报文发送到负载均衡设备后,负载均衡设备依次根据持续性功能、ACL策略、就近性算法、ISP表、调度算法选择最佳的物理链路,并将内网访问外网的业务流量分发到该链路。
图13 Outbound链路负载均衡流程图
表5 Outbound链路负载均衡流程描述
步骤 | 说明 | 备注 |
(1) | LB Device接收内网用户流量 | - |
(2) | LB Device依次根据持续性功能、ACL策略、就近性算法、ISP表、调度算法进行链路选择 | 在Outbound链路负载均衡组网中,通常使用就近性算法或带宽调度算法实现流量分发 |
(3) | LB device按照链路选择的结果将流量转发给选定的链路 | - |
(4) | LB Device接收外网用户流量 | - |
(5) | LB Device将流量转发给内网用户 | - |
· 可以和NAT应用网关共同组网,不同的链路使用不同的源地址,从而保证往返报文穿过同一条链路。
· 通过健康性检测,可以检查链路内任意节点的连通性,从而有效保证整条路径的可达性。
· 通过调度算法,在多条链路间均衡流量,并支持按照带宽进行负载均衡。
· 利用就近性算法动态计算链路的质量,将流量分发到当前最优链路上。
内网和外网之间存在多条链路时,通过Inbound链路负载均衡可以实现在多条链路上分担外网用户访问内网服务器的流量。Inbound链路负载均衡的典型组网如图14所示。
图14 Inbound链路负载均衡组网图
Inbound链路负载均衡包括以下几个基本元素:
· LB device:负责引导外网流量通过不同物理链路转发到内网,从而实现流量在多条物理链路上分担的设备。同时,LB device还需要作为待解析域名的权威名称服务器。
· 物理链路:运营商提供的实际链路。
· 本地DNS服务器:负责解析外网用户发送的DNS请求、并将该请求转发给权威名称服务器——LB device的本地DNS服务器。
Inbound链路负载均衡中,负载均衡设备作为权威名称服务器记录域名与内网服务器IP地址的映射关系。一个域名可以映射为多个IP地址,其中每个IP地址对应一条物理链路。
外网用户通过域名方式访问内网服务器时,本地DNS服务器将域名解析请求转发给权威名称服务器——负载均衡设备,负载均衡设备依次根据ACL策略、就近性算法、ISP表选择最佳的物理链路,并将通过该链路与外网连接的接口IP地址作为DNS域名解析结果反馈给外网用户,外网用户通过该链路访问内网服务器。
图15 Inbound链路负载均衡流程图
表6 Inbound链路负载均衡流程描述
步骤 | 说明 | 备注 |
(1) | 外网用户通过域名访问内网服务器时,首先要进行DNS解析,向其本地DNS服务器发送DNS请求 | - |
(2) | 本地DNS服务器将DNS请求转发给域名对应的权威名称服务器——LB device | - |
(3) | LB device根据DNS请求的域名、ACL策略、就近性算法、ISP表选择最优的物理链路,并将通过该物理链路与外网连接的接口IP地址作为域名解析结果 | 在Inbound链路负载均衡组网中,通常使用就近性算法实现外网到内网流量在多条链路间均衡 |
(4) | LB device按照域名解析的结果,将DNS应答发送给本地DNS服务器 | - |
(5) | 本地DNS服务器将解析结果转发给用户 | - |
(6) | 用户使用解析结果选择的链路,对内网服务器进行访问 | - |
· 可以和服务器负载均衡配合适用,实现外网用户访问内网服务器流量在多条链路间均衡的同时,也实现了流量在多台服务器间均衡。
· 通过健康性检测,可以检查物理链路的连通性。
· 利用就近性算法动态计算链路的质量,通过应答报文引导后续业务流量使用当前最优的服务器业务出口。
全局负载均衡基于本地负载均衡,其中每一台GLB设备与其实服务之间所遵循的都是服务器负载均衡的工作机制,全局负载均衡实现的是不同GLB设备之间的均衡调度。全局负载均衡可实现四至七层报文在全局范围内的负载均衡,其负载方式分为DNS智能解析、HTTP重定向、RTSP重定向和IP智能转发四种,下面将分别进行介绍。
当某应用在全球各个地点设置多个数据中心(站点)时,全局范围内即存在多个服务器同时提供服务,DNS智能解析可以引导广域网范围内的不同用户访问最优服务器,使流量正确分担到各个站点,实现全局各站点的负载均衡。
全局DNS智能解析负载均衡中,GLB设备作为DNS解析的权威服务器记录域名与全局所有虚服务器(包括本地和远程虚服务器)IP地址的映射关系。一个域名可以映射为多个IP地址,其中每个IP地址对应一台虚服务器。
用户通过域名方式请求服务时,要先进行DNS解析。本地DNS服务器将用户的域名解析请求转发给本地的GLB设备(即权威DNS服务器),本地GLB设备根据全局调度算法从全局下的所有可用虚服务器中选举出最优虚服务器,并将该最优虚服务器的IP地址作为DNS解析结果反馈给用户,用户向该IP地址请求服务。
图17 全局DNS智能解析负载均衡流程图
表7 全局DNS智能解析负载均衡流程描述
步骤 | 说明 | 备注 |
(1) | 用户通过域名请求服务时,首先要进行DNS解析,向其本地DNS服务器发送DNS请求 | - |
(2) | 本地DNS服务器将DNS请求转发给域名对应的权威DNS服务器——GLB设备 | - |
(3) | GLB设备根据DNS请求的域名,按照全局调度算法在全局所有可用的虚服务器中选举出最优虚服务器,并将该最优虚服务器IP地址作为域名解析结果 | GLB设备上的全局服务引用的虚服务的负载均衡深度可以为4层或7层 |
(4) | GLB设备按照域名解析的结果,将DNS应答发送给本地DNS服务器 | - |
(5) | 本地DNS服务器将解析结果转发给用户 | - |
· 全局DNS智能解析负载均衡能引导广域网范围内的用户访问最优站点,只要进行适当配置,就可以为全球不同地点的用户带来更好更快速的服务体验。
· 全局DNS智能解析负载均衡优先于本地Inbound链路负载均衡,但二者可以配合使用。当全局DNS智能解析负载均衡不可用时,本地Inbound链路负载均衡依然可以在本地站点中进行链路负载均衡,进一步增强全局各站点服务的可靠性。
GLB设备也可能不对外提供DNS智能解析,而是针对某种特定应用进行全局负载均衡,例如只对外提供HTTP业务的负载均衡或RTSP业务的负载均衡。由于全局HTTP重定向负载均衡和全局RTSP重定向负载均衡在实现原理上基本一致,故本文仅以全局HTTP重定向负载均衡为例进行详细介绍。
当用户通过IP地址向某站点服务器请求提供HTTP服务,而该服务器不能提供服务时,全局HTTP重定向负载均衡可将该HTTP请求重定向到全局中其他站点可用的最优服务器上,引导用户向最优服务器请求服务。
用户通过IP地址向某站点(如图16中的GLB device(Local))上的某虚服务器请求HTTP服务,首先客户端与虚服务器完成TCP三次握手,接着向该虚服务器发送HTTP请求报文。此时,GLB设备先根据本地服务器负载均衡策略选取为用户提供服务的服务器。若选取成功,则直接按照本地服务器负载均衡的流程处理;若选取失败,GLB设备将根据全局调度算法从所有可用的远程虚服务器中选举出一台最优虚服务器,并用该最优虚服务器的IP地址作为重定向的目的IP地址构造HTTP重定向报文反馈给客户端。用户收到HTTP重定向报文后,向选取出的最优虚服务器请求HTTP服务,先与最优虚服务器完成TCP三次握手,然后向其发送HTTP请求报文,由相应的GLB设备通过其本地服务器负载均衡策略选取服务器为用户提供服务。
图18 全局HTTP重定向负载均衡流程图
表8 全局HTTP重定向负载均衡流程描述
步骤 | 说明 | 备注 |
(1) | 用户通过虚服务IP地址向其本地GLB设备发送TCP连接建立请求,经过三次握手,成功建立TCP连接 | - |
(2) | 用户向其本地GLB设备发送HTTP请求报文 | - |
(3) | 本地GLB设备根据本地服务器负载均衡选取实服务,由于本地的实服务繁忙或不可用,选取失败,进入下面的全局负载均衡流程 | - |
(4) | 本地GLB设备根据虚服务IP地址匹配出相应的全局服务,按照全局服务中指定的调度算法从全局所有可用的远程虚服务器中选取出最优远程虚服务器 | 本地GLB设备上的全局服务引用的虚服务的负载均衡深度须为7层 |
(5) | 本地GLB设备向用户回复HTTP重定向报文,将选取出的最优远程虚服务器的IP地址作为重定向的目的IP地址 | - |
(6) | 用户收到HTTP重定向报文后,向位于远程GLB服务器上的新服务器地址发送TCP连接请求,经过三次握手,成功建立TCP连接 | - |
(7) | 用户向新服务器地址发送HTTP请求报文 | - |
(8) | 远程GLB设备收到HTTP请求后,根据其本地服务器负载均衡策略选取出可以提供HTTP服务的实服务 | 远程GLB设备上的全局服务引用的虚服务的负载均衡深度须为7层 |
(9) | 远程GLB设备将HTTP请求转发给选取出的实服务对应的实际提供服务的服务器 | - |
(10) | 服务器向远程GLB设备回复HTTP响应报文 | - |
(11) | 远程GLB设备将HTTP响应报文转发给用户 | - |
· 全局HTTP重定向负载均衡可以在用户访问的本地服务器不可用的情况下,正确地将用户请求重定向远程最优服务器上,有效保证了HTTP业务的持续性和可靠性。
· 全局HTTP重定向负载均衡巧妙地借助了HTTP协议固有的重定向功能,将通过全局调度算法从所有可用的远程服务器中选举出的最优服务器IP置于HTTP重定向报文中,并反馈给用户,实现全局范围内的HTTP重定向。
HTTP和RTSP报文重定向都只适用于特定的协议,而对于用户所需要的其他没有重定向功能的应用,则无法实现全局负载均衡。所以其他协议需要另外的方法处理来协助完成全局负载均衡功能的实现,IP智能转发便是一种有效的手段。
当某一站点服务器A(本地GLB设备)接收到用户的业务请求报文,而本地服务器无法为其提供相应服务时,本地GLB设备将根据全局调度算法从所有可用的远程虚服务器中选举出一台最优虚服务器,并将该业务请求报文通过GRE隧道转发给最优虚服务器所在的远程GLB设备。远程GLB设备收到转发过来的业务请求报文后,对其进行有效处理,并将业务应答报文的源IP填充为服务器A的IP地址,直接反回给用户。这样,用户便能获得相应的服务。
图19 全局IP智能转发负载均衡流程图
表9 全局IP智能转发负载均衡流程描述
步骤 | 说明 | 备注 |
(1) | 用户向本地GLB设备发送普通IP请求报文 | 目的IP为Local VSIP |
(2) | 本地GLB设备根据本地服务器负载均衡选取实服务,由于本地的实服务繁忙或不可用,选取失败,进入下面的全局负载均衡流程 | - |
(3) | 本地GLB设备根据虚服务IP地址匹配出相应的全局服务,按照全局服务中指定的调度算法从全局所有可用的远程虚服务器中选取出最优远程虚服务器 | 本地GLB设备上的全局服务引用的虚服务的负载均衡深度须为4层 |
(4) | 本地GLB设备通过GRE隧道将IP请求报文转发给最优的远程虚服务器所在的GLB设备 |
|
(5) | 远程GLB设备收到转发过来的IP请求报文后,根据其本地负载均衡策略选取出可以提供服务的实服务 | 远程GLB设备上的全局服务引用的虚服务的负载均衡深度须为4层 |
(6) | 远程GLB设备将IP请求报文转发给选取出的实服务对应的实际提供服务的服务器 | - |
(7) | 服务器向远程GLB设备回复应答报文 | - |
(8) | 远程GLB设备将应答报文转发给用户 | 源IP填充为Local VSIP |
· IP智能转发可以对任何业务报文进行智能转发,实现所有IP业务流量的全局负载均衡,增强全局各种服务的可靠性和连续性。
· IP智能转发虽然是一种“三角转发”模式(即“客户端>>本地GLB设备>>远程GLB设备>>客户端”),但其对于客户端具有高度透明性,客户端无须进行任何配置,用户在访问过程中也无须进行任何多余的操作。
无论是服务器负载均衡、网关负载均衡,还是链路负载均衡,LB设备均处于关键路径,LB设备的稳定性和安全性直接影响了网络的可用性。为了避免单点故障,LB设备必须支持双机热备,即在两台LB设备之间通过备份链路备份对端设备上的业务,保证两台设备上的业务状态是一致的。当其中一台设备发生故障时,利用VRRP或动态路由(例如OSPF)机制将业务流量切换到另一台设备,由于另一台设备已经备份了故障设备上的业务信息,业务数据流便可以从该设备上通过,从而在很大程度上避免了网络业务的中断。
LB双机热备方案支持两种工作模式:
· 主备模式:两台LB设备中一台作为主设备,另一台作为备份设备。主设备处理所有业务,并将产生的业务信息通过备份链路传送到备份设备;备份设备不处理业务,只用做备份。当主设备故障,备份设备接替主设备处理业务,从而保证新发起的负载均衡业务能正常处理,当前正在进行的负载均衡业务也不会中断。
· 负载分担模式:两台LB设备均为主设备,都处理业务流量,同时又作为另一台设备的备份设备,备份对端的业务信息。当其中一台设备故障后,另一台设备负责处理全部业务,从而保证新发起的负载均衡业务能正常处理,当前正在进行的负载均衡业务也不会中断。
以网关负载均衡为例,LB双机热备的组网如图20所示。
LB设备通常以直联和旁挂两种方式部署在网络中。
如图21所示,直联方式,即LB设备直接部署在网络的主干中,服务器和客户端之间的负载均衡报文直接由LB设备进行路由。
如图22所示,旁挂模式指LB设备不作为服务器和客户端之间的路由设备,而是旁挂在路由设备上。旁挂模式也可以结合OAA方案使用,在路由设备上部署一块具备LB功能的插卡,即可实现旁挂方式的负载均衡。在DR方式中,LB设备只能使用旁挂模式。
旁挂模式中,用于中转的路由交换设备上的配置至关重要。
从客户端至服务器的流量如果要达到LB设备,必须在路由交换设备上设置到VSIP的路由。
从服务器到客户端的流量如果不必经过LB设备,则可以通过中转设备直接返回客户端,如果需要返回LB,则有几种方式:
· 服务器和LB在同一个二层网络,服务器设置其网关为LB设备。
· 中转设备上配置策略路由,将从服务器返回的流量定向到LB设备。
· LB设备在转发客户端流量时进行源NAT。
调度算法指对需要负载均衡的流量,按照一定的策略分发到指定的服务器群中的服务器或指定链路组的某条链路上,使得各台服务器或链路尽可能地保持负载均衡。
负载均衡技术持丰富的负载均衡调度算法。不同调度算法所实现的负载均衡效果不同,可以需要根据具体的应用场景,采用不同的算法。
静态算法,即按照预先设定策略,进行分发,不考虑当前各实服务或链路的实际负载情况。算法特点:实现简单,调度快捷。
依次将请求分发到不同的服务器或链路上,使得各个真实服务器或链路平均分担用户的连接请求。
如:实服务群中包含三个实服务A、B、C,假设各实服务均未达到连接上限,最后分发给A、B、C的连接数之比为1:1:1。
适用场景:服务器集群中各服务器性能或链路群中各链路带宽相当,无优劣之分。
按照权值大小,依次将请求分发到不同的服务器或链路上,权值大的分配较多请求,权值小的分配较少请求。该算法可以解决服务器间性能或链路间带宽不一的问题,权值标识服务器间性能或链路间带宽差异。
如:实服务组中包含三个实服务A、B、C,其配置权值分别为:4、3、2。假设各实服务均未达到连接上限,最后分发给A、B、C的连接数之比为4:3:2。
适用场景:服务器集群中各服务器性能或链路集群中各链路带宽存在差异。
将请求随机分发到不同的服务器或链路上。从统计学角度看,调度结果为各个服务器或链路平均分担用户的连接请求。
适用场景:服务器集群中各服务器性能或链路群中各链路带宽相当,无优劣之分。
将请求随机分发到不同的服务器或链路上。从统计学角度看,调度结果为各个服务器或链路按照权值比重分担用户的连接请求,最后的比值和加权轮转一致。
适用场景:服务器集群中各服务器性能或链路群中各链路带宽存在差异。
通过一个散列(Hash)函数将来自同一个源IP的请求映射到一台服务器或链路上。
适用场景:需要保证来自同一个用户的请求分发到同一个服务器或链路。
通过一个散列函数将来自同一个源IP和源端口号的请求映射到一台服务器或链路上。
适用场景:需要保证来自同一个用户同一个业务的请求分发到同一台服务器或链路。
通过一个散列函数将去往同一个目的IP的请求映射到一台服务器或链路上。
适用场景:需要保证到达同一个目的地的请求分发到同一台服务器或链路。适用于网关负载均衡和链路负载均衡。
通过一个散列函数将UDP报文载荷中特定字段的内容相同的请求映射到一台服务器上。
适用场景:需要保证UDP报文载荷中特定字段内容相同的请求分发到同一台服务器。
按照优先级的大小以及指定的最小活动实服务/逻辑链路数,将请求分发到优先级较高的可用服务器或链路上。优先级相同的可用实服务或逻辑链路为一组,按优先级成组选取总数不少于最小活动实服务/逻辑链路数的实服务或逻辑链路,在选取的这些实服务或逻辑链路中以轮转的方式进行调度。该算法可以解决有主备之分的实服务或链路中,在主的实服务或链路可用时,请求只分给主的实服务或链路(优先级最大的实服务或链路),只有在主的实服务或链路不可用时请求才会分发给备的实服务或链路(优先级小的实服务或链路)上。
如:实服务组中有两个优先级为10的实服务和三个优先级为5的实服务,均可用,则当最小活动实服务数为2时,只有优先级为10的两个实服务参与轮转调度;当最小活动实服务数为3时,优先级为10和优先级为5的实服务都参与轮转调度。
适用场景:集群中的服务器或链路有主备之分。在主服务器或链路可用时,请求只分发给主服务器或链路(优先级较大);在主服务器或链路不可用时,将请求分发给备服务器或链路(优先级较小)。
相对于静态算法,动态算法根据各实服务或物理链路实际运行中的负载情况进行连接分发,分发效果更均衡。
负载均衡设备根据当前各服务器或链路的连接数来估计服务器或链路的负载情况,把新的连接分配给连接数最小的服务器或链路。该算法能把负载差异较大(连接保持时长差异较大)的请求平滑分发到各个服务器或链路上。
适用场景:服务器集群中各服务器性能或链路群中各链路带宽相当,无优劣之分,不同用户发起的连接保存时长差异较大。
调度新连接时尽可能使服务器或链路的已建立活动连接数和服务器或链路权值成比例,权值表明了服务器处理性能或链路实际带宽。
适用场景:服务器集群中各服务器性能或链路群中各链路带宽存在差异,不同用户发起的连接保存时长差异较大。
负载均衡设备根据不同链路的实际剩余带宽及权值,将新连接分发到剩余带宽最大的链路上。
适用场景:链路群中各链路状况(包括带宽、拥塞程度等)存在差异。
链路负载均衡支持就近性功能。
· 对于Outbound链路负载均衡,就近性功能是指对目的地址匹配就近性表项的报文,使用表项中的链路进行转发;如果没有匹配的就近性表项,则进行就近性检测,并生成动态就近性表项以指导报文转发。
· 对于Inbound链路负载均衡,就近性功能是指对源地址匹配就近性表项的DNS报文,使用对应物理链路所属DNS表项(域名匹配)的IP地址作为DNS解析结果;如果没有匹配的就近性表项,则进行就近性检测,并生成动态就近性表项以指导DNS解析。
链路负载均衡就近性检测是负载均衡设备利用健康性检测功能实时探测链路的状态,Outbound链路负载均衡是以报文的目的地址为目的进行检测,Inbound链路负载均衡是以DNS请求的源地址为目的进行检测。根据检测结果计算出最优链路,并通过最优链路转发业务流量。支持的健康性检测类型包括:
· DNS:通过DNS报文,检测远端DNS服务的可用性并获得就近性计算参数。只有Inbound链路负载均衡支持该检测类型。
· ICMP:通过ICMP报文,检测远端地址的可达性并获得就近性计算参数。
· TCP Half Open:通过建立TCP半开连接,检测远端地址的可达性并获得就近性计算参数。
链路负载均衡的就近性检测根据以下几个参数进行加权计算,得出链路加权数,并根据链路加权数的大小判断链路的优劣:
· 链路物理带宽:即链路的可用带宽值。
· 链路成本:取决于每条链路的成本值,比如租用联通10M链路每月1万元,租用电信10M链路每月1.5万元,则两条链路的成本比例为2:3,两条链路成本的取值应该满足该比例。
· 链路延迟时间(即RTT):通过健康性检测获得。
· 路由跳数(即TTL):通过健康性检测获得。
管理员也可以手工添加静态就近性表项。当同时存在匹配的静态就近性表项和动态就近性表项时,根据静态优先和深度优先原则优先使用最深匹配的表项。
全局负载均衡中,就近性是用于选取虚服务器的一种调度算法。它是指,根据收到报文的源IP地址查找就近性表项,使用匹配到的表项中的虚服务器提供服务;如果没有找到匹配的表项,则会先采用轮询的方式选取一个虚服务器来提供服务,同时触发每个虚服务器以收到报文的源IP地址为目的进行就近性探测,生成就近性表项用于指导后续的虚服务器选取。
全局负载均衡就近性检测是全局负载均衡设备利用健康性检测功能探测各站点虚服务器与客户端(对于全局DNS智能解析负载均衡,这里的客户端是指Local DNS服务器)的网络状况,以报文的源地址为目的进行检测。根据检测结果计算出最优虚服务器。支持的健康性检测类型包括:
· DNS:通过DNS报文,检测远端DNS服务的可用性并获得就近性计算参数。
· ICMP:通过ICMP报文,检测远端地址的可达性并获得就近性计算参数。
· TCP Half Open:通过建立TCP半开连接,检测远端地址的可达性并获得就近性计算参数。
全局负载均衡的就近性检测根据以下几个参数进行加权计算,得出服务器加权数,并根据服务器加权数的大小判断服务器的优劣:
· 链路延迟时间(即RTT):通过健康性检测获得。
· 路由跳数(即TTL):通过健康性检测获得。
· 服务器负载:即虚服务器当前处理的连接数除以其允许的最大并发连接数,再乘以100。
管理员也可以手动添加静态就近性表项。当同时存在匹配的静态就近性表项和动态就近性表项时,根据静态优先和深度优先原则优先使用最深匹配的表项。
所谓健康性检测,就是负载均衡设备定期对真实服务器或链路服务状态进行探测,收集相应信息,及时隔离工作异常的服务器或链路。健康性检测的结果除标识服务器或链路能否工作外,还可以统计出服务器或链路的响应时间,作为选择服务器或链路的依据。
负载均衡技术支持丰富的健康性检测类型,可以有效地探测和检查服务器或链路的运行状态。
· ICMP:向服务器集群中的服务器或链路上的节点发送ICMP Echo报文,若收到ICMP Reply,则服务器或链路正常。
· TCP:向服务器集群中服务器的某端口发起TCP连接建立请求,若成功建立TCP连接,则服务器正常。
· HTTP:与服务器集群中服务器的HTTP端口(默认情况为80)建立TCP连接,然后发出HTTP请求,若收到的HTTP应答内容正确,则服务器正常。
· FTP:与服务器集群中服务器的21号端口建立TCP连接,然后获取服务器上的文件,若收到的文件内容正确,则服务器正常。
· TCP Half Open:向链路上节点的某端口发起TCP连接建立请求,若成功建立TCP半开连接,则链路正常。
· DNS:向服务器集群中的服务器或链路上的DNS服务器发送DNS请求,若收到正确的DNS应答,则服务器或链路正常。
· RADIUS:向服务器集群中的服务器发送RADIUS认证请求,若收到认证成功的应答,则服务器正常。
· SSL:向服务器集群中的服务器发送SSL连接建立请求,若成功建立SSL连接,则服务器正常。
· ARP:向服务器集群中的服务器发送ARP请求,若收到正确的ARP应答,则服务器正常。
· IMAP:与服务器集群中的IMAP服务器建立连接,并且使用预先指定的用户名和密码能够成功登陆并打开相应的用户邮箱,则服务器正常。
· POP3:与服务器集群中的POP3服务器的建立连接,并且使用预先指定的用户名和密码能够成功登陆相应的用户邮箱,则服务器正常。
· RTSP:与服务器集群中RTSP服务器建立连接,然后发出OPTION报文,若收到正确的应答,则服务器正常。
· SIP:向服务器集群中的SIP服务器发送OPTIONS请求,若收到正确的应答,则服务器正常。
· SMTP:与服务器集群中的SMTP服务器的建立连接,然后发出HELLO报文,若收到正确的应答,则服务器正常。
· SNMP:向服务器集群中的SNMP服务器发送请求,若收到正确的应答,则服务器正常。
· UDPNORMAL:向服务器集群中服务器的某端口发送UDP报文,检测应用端口的可用性,只要不收到服务器返回的ICMP不可达等出错应答报文,就认为服务器的应用端口可用。由于UDPNORMAL类型的检测不要求服务器必须发回响应,因此在实际应用中,建议将其与ICMP类型的检测配合使用,通过ICMP检测确定服务器IP地址是否可达。
一次业务交互可能包括多个TCP连接,如FTP应用(包含一个控制通道和多个数据通道)和HTTP应用。这些TCP连接间有些存在显式关联关系,如FTP应用,数据通道的TCP连接是通过控制通道协商得来的;有些存在隐含的关联关系,如HTTP网络购物,多条连接组成一次业务应用,且多个连接并不像FTP应用一样有“父子”之分,能通过父通道(即控制通道)获取子通道(即数据通道)信息,但所有该业务的请求应发给同一服务器,否则可能造成无法完成所请求的功能,因为其数据报文中携带隐含关联信息,如Cookie。
将属于同一个应用层会话的多个连接定向到同一服务器的功能,就是持续性功能。根据持续性原则,建立持续性表项,保证后续业务报文都送往同一个服务器处理。比如使用源地址建立持续性表项,保证持续性。
显式关联关系持续性功能是指如果某种应用(如FTP)包括多个具有显式关联关系的TCP连接,子通道五元组是通过父通道协商得来的,则负载均衡设备逐包分析父通道报文,一旦发现子通道协商信息,就会利用该信息建立父通道会话关联表项,当子通道首报文到来时,根据关联表项和父会话表项建立完整的会话表项,从而保证父子通道登录同一台服务器。显式关联关系由负载均衡设备自动识别,无需配置策略。
基于源IP地址的持续性功能常用于L4服务器负载均衡和链路负载均衡应用中,用以确保同一个客户端的业务能分配到同一个服务器或链路上。
负载均衡设备接收到某一客户端的某一业务的首次请求时,建立持续性表项,记录为该客户分配的服务器情况,在持续性表项生存周期内,后续相同源IP地址的业务报文都将发往该服务器处理。
基于目的IP地址的持续性功能常用于链路负载均衡应用中,用以确保去往同一个目的地址的业务能分配到同一条链路上。
负载均衡设备接收到某一客户端的某一业务的首次请求时,建立持续性表项,记录为该客户分配的链路情况,在持续性表项生存周期内,后续相同目的IP地址的业务报文都将分发到该链路转发。
基于源端口的持续性功能常用于L4服务器负载均衡和链路负载均衡应用中,用以确保源端口相同的业务报文能分配到同一个服务器或链路上。
负载均衡设备接收到某一客户端的某一业务的首次请求时,建立持续性表项,记录为该客户分配的服务器情况,在持续性表项生存周期内,后续相同源端口的业务报文都将发往该服务器处理。
基于目的端口的持续性功能常用于L4服务器负载均衡和链路负载均衡应用中,用以确保目的端口相同的业务报文能分配到同一条链路上。
负载均衡设备接收到某一客户端的某一业务的首次请求时,建立持续性表项,记录为该客户分配的链路情况,在持续性表项生存周期内,后续相同目的端口的业务报文都将分发到该链路转发。
基于源IP地址和源端口的持续性功能常用于L4服务器负载均衡和链路负载均衡应用中,用以确保源IP地址和源端口均相同的业务报文能分配到同一个服务器或链路上。
负载均衡设备接收到某一客户端的某一业务的首次请求时,建立持续性表项,记录为该客户分配的服务器情况,在持续性表项生存周期内,后续相同源IP地址和源端口的业务报文都将发往该服务器处理。
基于目的IP地址和目的端口的持续性功能常用于L4服务器负载均衡和链路负载均衡应用中,用以确保目的IP地址和目的端口均相同的业务报文能分配到同一条链路上。
负载均衡设备接收到某一客户端的某一业务的首次请求时,建立持续性表项,记录为该客户分配的链路情况,在持续性表项生存周期内,后续相同目的IP地址和目的端口的业务报文都将分发到该链路转发。
基于Cookie的持续性功能常用于L7服务器负载均衡应用中,用以确保同一会话的报文能分配到同一个服务器上。根据服务器的应答报文中是否汇携带含有服务器信息的Set-Cookie字段,又可选择采用Cookie插入或Cookie截取的持续性方法:
· Cookie插入:服务器的应答报文中不携带含有服务器信息的Set-Cookie字段,负载均衡设备会在报文中添加含有服务器信息的Set-Cookie字段。这样,客户端就会在请求报文中携带含有该服务器信息的Cookie字段,负载均衡设备按照Cookie字段中的服务器信息将请求报文发给相应的实服务。
· Cookie截取:服务器的应答报文中携带Set-Cookie字段,负载均衡设备根据用户配置的Cookie标识截取应答报文中的Cookie值。对于后续客户端的请求报文,如果匹配保存的Cookie值,则直接将请求报文发给相应的实服务。
基于SIP报文Call-ID的持续性功能常用于L7服务器负载均衡应用中,用以确保Call-ID相同的SIP报文能分配到同一个服务器上。
负载均衡设备接收到某一客户端的某一业务的首次请求时,建立持续性表项,记录为该客户分配的服务器情况,在持续性表项生存周期内,后续相同Call-ID的SIP业务报文都将分发到该服务器处理。
基于HTTP报文头的持续性功能常用于L7服务器负载均衡应用中,用以确保HTTP报文头信息相同的报文能分配到同一个服务器上。
负载均衡设备接收到某一客户端的某一业务的首次请求时,建立持续性表项,记录为该客户分配的服务器情况,在持续性表项生存周期内,后续HTTP报文头信息相同的报文都将分发到该服务器处理。
基于RADIUS属性值的持续性功能常用于L7服务器负载均衡应用中,用以确保属性值信息相同的RADIUS报文能分配到同一个服务器上。
负载均衡设备接收到某一客户端的某一业务的首次请求时,建立持续性表项,记录为该客户分配的服务器情况,在持续性表项生存周期内,后续属性值Framed-IP-Address或User-Name(二者可通过配置选择其一)信息相同的RADIUS报文都将分发到该服务器处理。
基于DHCP属性值的持续性功能常用于L7服务器负载均衡应用中,用以确保属性值信息相同的DHCP报文能分配到同一个服务器上。
负载均衡设备接收到某一客户端的某一业务的首次请求时,建立持续性表项,记录为该客户分配的服务器情况,在持续性表项生存周期内,后续属性值Transaction ID或Client Hardware Address(二者可通过配置选择其一)信息相同的DHCP报文都将分发到该服务器处理。
L4服务器负载均衡在截取数据流以后,对数据包检查与分析的部分仅限于IP报头及TCP/UDP报头,而不关心TCP或UDP包的内部信息。而L7服务器负载均衡则要求负载均衡设备除了支持基于4层的负载均衡以外,还要解析数据包中4层以上的信息,即应用层的信息。例如,可以解析HTTP协议,从数据包中提取出HTTP URL或Cookie信息。
L7服务器负载均衡控制应用层服务的内容,提供了一种对访问流量的高层控制方式。与L4服务器负载均衡相比,L7服务器负载均衡具有如下优点:
· 可根据数据包内容(如判断数据包是图像文件、压缩文件或多媒体文件格式等),把数据流量引向相应内容的服务器来处理,增加系统性能。
· 可根据连接请求的数据类型(比如根据URL来区分是请求普通文本、图象等静态文档,还是请求ASP、CGI等动态文档),把相应的请求引向相应的服务器来处理,提高系统的性能及安全性。
· 可基于应用层载荷进行持续性处理,相对于L4负载均衡基于地址和端口的持续性处理方式更加精细。
由于L7服务器负载均衡对应用层协议进行深度识别,因此,对于每种应用层协议都需要有独立的识别机制,这大大限制了L7服务器负载均衡的应用扩展性,一般只是针对HTTP进行负载均衡。同时,深度识别应用层协议,对系统性能也会有很大影响。
负载均衡提供了灵活的实服务/逻辑链路故障处理方法。当实服务组/逻辑链路组检测到其中的某个实服务/逻辑链路发生故障时,可以有以下几种方法来处理故障实服务/逻辑链路上已有的连接:
· 保持已有连接:LB设备不主动断开与故障实服务/逻辑链路的连接,连接保持或断开由协议自身的超时机制决定。此方法一般用于服务器负载均衡和Outbound链路负载均衡。
· 断开已有连接:LB设备主动断开与故障实服务/逻辑链路的连接。此方法一般用于服务器负载均衡和Outbound链路负载均衡。
· 重定向已有连接:LB设备将连接重定向到实服务组/逻辑链路组中其他可用的实服务/逻辑链路上。此方法一般用于网关负载均衡和Outbound链路负载均衡。
在L7服务器负载均衡中,每个虚服务中可以包含多个由具有一些公共属性的服务器组成的实服务组。当LB设备收到用户向某虚服务发来的请求时,如果虚服务未应用持续性功能,或者应用了持续性功能但不存在匹配的持续性表项,虚服务会根据预先设置的实服务组匹配策略选择一个实服务组。
L7服务器负载均衡支持丰富的实服务组匹配策略。不同实服务组匹配策略所实现的负载均衡效果不同,可以需要根据具体需求采用不同的匹配策略。
根据HTTP协议报文头的不同内容进行实服务组的匹配,包括以下几种具体的匹配策略:
· Accept-Encoding:根据Accept-Encoding报文头定义的客户端浏览器所支持的压缩模式进行实服务组的匹配。适用于服务器分别提供不同类型压缩格式的组网场景。
· Accept-Language:据Accept-Language报文头定义的客户端浏览器所支持的语言编码进行实服务组的匹配。适用于服务器分别提供不同种类语言的组网场景。
· Host:根据Host报文头中携带的主机名进行实服务组的匹配。适用于服务器分别提供不同请求主机名的组网场景。
· Request-Method:根据Request-URI标识的资源上执行的方法进行实服务组的匹配。适用于服务器分别提供不同类型服务的组网场景,如设置GET服务器和PUT服务器使操作分离,简化组网环境的层次结构并降低成本的场景。
· URL-File:根据资源文件或文件类型进行实服务组的匹配。适用于服务器分别提供不同类型文件的组网场景。
· URL-Function:根据资源获取路径进行实服务组的匹配。适用于服务器分别提供不同资源获取路径的组网场景。
· User-Agent:根据User-Agent报文头中携带的客户端浏览器类型进行实服务组的匹配。适用于服务器分别支持不同类型浏览器的组网场景。
· 自定义:根据用户自行设置的其他HTTP协议报文头包含的任意字段进行实服务组的匹配。适用于服务器分别提供不同服务类型的组网场景。
根据RTSP资源获取路径(即RTSP的URL-Function)进行实服务组的匹配。适用于服务器分别提供不同RTSP资源获取路径的组网场景。
当要在集群中新增一台服务器或新增一条链路时,由于某些服务器或链路刚上线时无法立即承担大量的业务,可以对实服务组或逻辑链路组使能温暖上线功能,并指定准备时间和温暖上线时间。这样,在准备时间内,负载均衡设备不会向新增的服务器或链路分配业务。准备时间到达后,在温暖上线时间内,负载均衡设备会随着时间的递增逐步增加向该服务器或链路分配业务的量。在温暖上线时间也到达后,LB设备开始向该服务器或链路正常分配业务。
对于IPv4服务器负载均衡和链路负载均衡,当要将某服务器/链路从集群中撤出,或者暂时停止使用某服务器/链路时,可以对相应的实服务/逻辑链路设置立即停止服务或使能慢宕功能:
· 立即停止服务后,LB设备不会再向该实服务/逻辑链路分配任何流量。
· 使能慢宕功能后,LB设备将实服务/逻辑链路上原有业务的流量仍然分配给该实服务/逻辑链路处理,但不会再向该实服务/逻辑链路分配新的业务。当原有业务处理完后,即可将相应的服务器/链路从集群中撤出。这样可以避免服务器/链路的突然撤出而导致其上原有业务的中断,从而保证业务的连续性。
IPv6服务器负载均衡只支持使能慢宕功能,不支持立即停止服务功能。
在企业园区网络中,为了实现对企业资源服务器的快速访问,也需要采用负载均衡设备分担企业数据访问流量。在这种应用环境下,可以将负载均衡设备串接在网络中,服务器通过网络设备连接到负载均衡设备,服务器网关指向LB。
图23 企业园区网应用组网图
负载均衡设备直联服务器部署模式的优点是:
· 部署简单,是负载均衡设备的经典应用模式。
· 通过交换机连接负载均衡设备和服务器群,解决LB设备端口数量限制带来的扩展性问题。
数据中心和大型门户网站是负载均衡设备主要的应用场景,H3C推荐采用旁挂模式作为数据中心和大型门户网站的组网模式。组网图如图24所示。
LB设备与汇聚层交换机之间有两条链路或链路聚合组,这两条链路(组)分别为L3链路和L2链路,服务器网关指向LB设备,对于需要负载均衡的流量,汇聚层将VSIP的下一跳指向LB,而LB的缺省路由指向汇聚层交换机。
旁挂部署模式的优点如下:
· 数据路径清晰,易于运行维护、故障定位;
· 可以使用手工链路聚合,链路带宽易于拓展,并提供链路高可靠性及其链路负载均衡能力;
· LB设备旁挂,易于LB升级和扩展。根据用户服务器扩展情况,升级更高性能的LB设备或者增加LB设备;
· 业务部署灵活,对不需要负载均衡的流量可以旁路LB,避免对LB增加不必要负荷;
· 降低了对汇聚层交换机的要求,有助于网络稳定运行。