Array服务器负载均衡解决方案

Array Networks

服务器负载均衡（SLB）解决方案Array Networks, Inc.

目录

一、应用系统概述及面临的挑战 (3)

二、应用系统现状及需求分析 (4)

2.1 应用系统现状说明 (4)

2.2 应用系统负载均衡需求分析 (5)

三、Array APV服务器负载均衡解决方案 (6)

3.1 应用APV系列产品满足应用系统的高可靠性和高可用性 (6)

3.1.1 APV系列产品在网络中的部署方式 (6)

3.1.2 Array APV SLB的工作模式 (9)

3.1.3 Array APV系列产品服务器负载均衡功能实现 (14)

3.1.4 SLB的负载均衡算法 (15)

3.1.5 SLB的负载均衡策略 (18)

3.1.6 Array的SLB健康检查 (19)

3.1.7集群（Cluster）功能实现 (21)

3.1.8端口冗余功能实现 (21)

3.1.9 Array的SLB的特点 (22)

3.2为应用平台提供更多的应用特性和性能增强功能 (22)

3.2.1 Array Networks基于SpeedStack核心技术 (22)

3.2.2 Array Networks基于SpeedCore核心架构 (22)

3.2.3提供状态检测防火墙和入侵防护功能 (23)

3.2.4 提供连接复用技术（Connection Multiplexing） (24)

3.2.5 提供Http压缩功能 (25)

3.2.6 Memory Cache功能 (26)

3.2.7 SSL加速功能 (27)

3.2.8 IPv6支持 (29)

3.2.9 虚拟化应用 (29)

四、解决方案为用户带来的益处 (30)

五、Array APV系列产品介绍 (32)

一、应用系统概述及面临的挑战

及时、灵活、优惠的应用服务是当前企业商务活动的基础，也是为用户提供全面高质量服务，提高市场竞争力的出发点。而随着应用系统应用的推广和访问用户的增多，传统应用系统将面临以下挑战：

1、系统应用服务器“多米诺”现象

在系统平台中，单台服务器设备的应用，会随着各种条件的影响，不可避免的出现单点故障等问题，而在系统的应用中，任何无备份系统的单点故障都将直接影响到业务的正常提供，造成极大的损失。

考虑到服务器的冗余备份，需要服务器冗余设置来处理和接管出现故障主机的工作。传统方式是通过一台或多台服务器，采用冷备份方式来实现，当主服务器出现故障时，进行人工切换到备份服务器上。但这样做，除了会产生实效性的问题外，还将无法同时利用所有服务器的资源，应用投资得不到充分保护。且当出现超过主服务器的负载情况时，所得到的将是“多米诺效应”，即包括冷备份服务器在内的服务器将依次被过高的负载压垮，直至无服务器可用。

2、处理能力有限且扩容能力有限

随着系统用户的增多和系统应用负载的增大，各个应用服务器，特别是前置服务器上所要处理的数据量将增大，从而影响针对使用者的响应效率，造成对访问者的请求回应越来越慢等严重影响系统服务质量的现象。在服务器端则直接表现为可容纳的连接数越来越小，系统性能严重下降。

此时，将需要考虑增加应用服务器和数据库服务器的数量来满足不断增大的应用负载需求。当仅通过服务器集群（Cluster）的方式实现扩容时，将存在成本较高，严重影响正常系统应用的提供等问题，且扩容能力有限，无法满足不断增长的系统应用的需要。

3、应用系统发展与网络结构调整的不平衡性

随着新功能的加入和用户数的增多，系统维护和网络拓扑的变化将随时有可能发生，完全依靠专业技术队伍通过更改服务器配置或网络拓扑等方式进行网络调整

的方式，将存在大风险、非实时性、缺乏灵活性等缺陷。如何能够在业务正常运行的情况下进行按需增长的、动态的、且对系统用户是透明的网络调整和更新扩容，已经成为系统应用中迫切需要解决的问题。

4、应用服务器“负载峰值”问题

系统应用处理过程中，各个应用服务器的负载存在“波峰”和“波谷”的规律或不规律的变化，即便在波峰时，负载的大小又是不规律的，这就很容易使服务器面临“峰值阻塞”的问题。传统方式是通过更换为具有更高处理能力的单台服务器主机的方式来满足峰值的负载访问请求，但这种方式投资成本极大，并存在很大的资源浪费情况。

5、系统维护升级等问题将给相关人员造成极大的压力

系统平台的稳定运行，离不开应用系统的日常维护，而在线系统的维护操作，将会给正常应用中的系统应用带来了安全隐患。在主机操作系统和应用程序的调整和升级过程中，将会由于需要重新启动正在提供服务的应用程序，甚至重新启动操作系统而使此类工作很难进行下去。有限的维护、升级时间，将对应用造成很大风险的同时，给各个方面的相关人员造成很大的压力。

二、应用系统现状及需求分析

2.1 应用系统现状说明

在当前运行的应用系统中，大部分是通过前台Web/APP应用服务器采用多个端口提供服务的方式满足所有用户的应用接入要求。

使用示意图如下所示：

2.2 应用系统负载均衡需求分析

使用如上图所述的系统，目前系统的分发存在以下问题：

（1）应用服务器负载不均衡的问题

（2）由于采用软件分发方式，将带来软件不稳定的问题

（3）提供服务端口较多，用户登陆不方便的问题

为了解决接入负载不均等所造成的应用系统的应用缓慢的问题，建议选用Array APV系列产品，通过对应用系统的负载均衡功能实现，来满足以上应用需求。

Array产品系列提供一个将诸多复杂Web设备化零为整的解决方案，可以完全解决网上应用系统存在的问题。它是第一个真正的将众多重要的网络功能合为一体的集成化应用系统，这些网络功能包括服务器负载均衡（SLB），全局服务器负载均衡（GSLB），SSL加速， WebWall安全，链路负载平衡（LLB），HTTP压缩以及

SSL VPN解决远程安全访问等。

三、Array APV服务器负载均衡解决方案

应用系统通常采用Web Server /Application Server/Database Server多层结构设计，支持前端浏览器访问或客户端访问方式。

在应用系统平台中，通过Array AVP系列产品的应用，在实现Web服务器组、应用服务器组的负载均衡功能的同时，还可以实现Web应用的加速功能。从处理能力、扩展能力、安全性、应用的便利性等方面提供了流量管理和性能增强功能，能够在满足系统应用平台对持续性和稳定性的需求的基础上，提高应用系统的处理能力，在同样主机及网络平台下满足更多用户应用的访问需求。

3.1 应用APV系列产品满足应用系统的高可靠性和高可用性

Array APV服务器负载均衡解决方案中所指的高可用性，同时也是确保应用系统正常运行所需考虑的，主要是指以下几点：

1.使数据始终以一个稳定、安全的方式处理，在应用系统平台中，即便存在

单台设备不能提供服务时，仍能保持数据的完整性。通过智能识别检查，使整体应用持续稳定运行，即便发生单点或多点故障仍然能够保证正常提供服务。

2.使整个应用网络环境能够更好的被管理，提供APV设备本身容灾集群

（cluster）功能、服务器集群共享、应用和后台服务器方便维护等特点。

3.使前期设备投入有更好的效益和最佳的扩充能力，即在保证数据完整性的

同时，提供应用系统持续运行的能力，并实现当用户量的增大的情况下，在不影响应用的情况下，通过增加服务器的方式，响应用户负载的增加，保证了原有企业投资具有很高回报。

4.即便在应用软件不够完善，如经常出现故障不能提供服务的情况下，仍然

能够持续保证应用系统持续在线能力。

3.1.1 APV系列产品在网络中的部署方式

可通过以下两种拓扑结构满足当前系统应用需求：

串联连接部署方式

（Array APV服务器负载均衡功能串联实现拓扑结构图）

如上图所示，将两台APV产品串联连接在网络中，所有访问后台服务器的数据必须经过APV系列产品处理，每台APV产品各使用两组端口分别与上下两组交换机相连，AVP的每组端口中包含两个物理端口，通过端口冗余功能提高链路的可靠性。

当三层架构的应用系统正常工作情况下， Web服务器、应用服务器组、数据库服务器组中的所有应用服务器均正常提供服务，Array APV设备对三层架构中的各个服务器组实现服务器负载分担功能和有针对性的性能增强功能，并能够隐藏后台服务器组的IP地址和拓扑结构，仅向访问用户提供有限的一个或几个IP地址和端口，以供用户进行访问。

例如：通过配置，通过两个Virtual IP（IP_A和IP_B）地址的配置生效，对最终用户通过APV上的Virtual Service（IP地址和端口）提供服务的所有功能，接受用户的访问请求。当客户端向APV上的Virtual Service发起访问请求后，APV能够根据后台服务器健康检查的结构（健康状况），将用户访问请求分配到后台不同服务器进行处理。

IP_A对应服务器1和服务器3上的提供服务的端口，对服务器1和服务器3的各个提供服务的端口及应用实现负载均衡功能。

IP_B对应服务器2和服务器4上的提供服务的端口，对服务器2和服务器4的各个提供服务的端口及应用实现负载均衡或热备的功能。

旁路连接部署方式

（Array APV服务器负载均衡功能旁路实现拓扑结构图）

如上图所示，可使用APV的两个端口将Array APV产品分别连接在两个核心交换设备上，以避免单台核心交换机故障时对应用造成影响。

APV在进行服务器负载均衡功能时具有两种可选工作模式（详见以下负载均衡功能描述）：“反向代理模式”和“透明模式”。

如选择反向代理工作模式，在保证应用的同时，后台服务器收到的从APV 转发过来的访问请求的源IP地址将是APV的端口IP地址，此时后台服务

器的默认网关无需进行特殊设置，只需要从APV到后台服务器的数据包路

由可达（或同一网段）即可。

此模式下的网络连接方式下，对现有的网络拓扑及后台服务器几乎不做更

改，仅在APV上配置Virtual Server，同时接收用户的访问请求即可提供

服务。同时对系统的维护及数据上传下载工作可实现不经过APV处理，而

直接经过交换路由实现。

如选择透明代理工作模式，在保证应用的同时，后台服务器收到的从APV 转发过来的访问请求的源IP地址将是真实的客户端IP地址和端口，此时

后台服务器的默认网关一定要指向APV（如Virtual IP），从而保证请求

的回程正确。

此模式下对后台服务器的IP地址不需进行更改，只需要更改服务器的网

关即可。

如应用系统必须得知访问客户端的源IP地址，在不影响应用的前提下，建议采用“透明模式”。

如应用系统对客户端源IP地址无要求，则建议采用“反向代理模式”。

（具体两种模式的工作方式描述，详见3.1.2中描述）

3.1.2 Array APV SLB的工作模式

Array APV的服务器负载均衡可以以三种模式执行：Reverse Proxy Mode（反向代理模式）、Transparent Mode（透明模式）和Triangle Mode（三角传输模式）。

（1）Reverse Proxy Mode（反向代理模式）

使用Array APV的反向代理服务可以将请求转发给内部的服务器，让Array APV将请求均匀地转发给多台内部服务器之一上，从而达到负载均衡的目的。这种代理方式与普通的代理方式有所不同，标准代理方式是客户使用代理访问多个外部服务器，而这种代理方式是多个客户使用它访问内部服务器，因此也被称为反向代

理模式。其传输流程如下所示：

反向代理模式的优点：

－可以采用One-armed的结构部署；

－可以通过连接池技术增强系统性能。

反向代理模式的局限性：

－服务器无法记录哪些IP的客户端曾进行访问

解决办法: Array TM可以在用户的HTTP包头中加入X-Forwarded-For字段，用它记录客户端的IP地址。

（2）Transparent Mode（透明模式）

Array APV 的透明模式是指Array APV在转发用户请求时，透明地将客户端的连接定向到特定的服务器上，即用户的源IP地址对服务器是透明的，服务器可以

知道哪个客户对其进行了访问。其传输流程如下：

透明模式的优点：服务器可以记录哪些IP的客户端曾进行访问。

透明模式的局限性：

－结构/路由设计必须保障从源服务器端来的响应必须经过APV；

－One-armed的结构有可能不能实现；

－由于每个请求的源IP地址都不一样，因此无法利用连接池技术改善系统性能。

（3）Triangle Mode（三角传输模式）

Array的三角传输模式是为那些低输入、高输出的应用系统而特别设计的，例如：VOD系统，从而能更好的提升服务效率。

三角传输模式保证了流媒体服务的高性能，在该模式下，用户请求通过Array APV被分担到某一个服务器上，而服务器返还的响应数据则可以不通过APV而直接

发送到客户端。其传输流程如下：

1.客户端经路由器向APV上的VIP（10.3.61.80）发送请求。

2.APV转发请求至后台应用服务器10.

3.60.11。

3.由于在服务器上同样配置了Loopback接口地址10.3.61.80，而且缺省网关

地址指向10.3.61.1，因此在收到客户端的请求后，将以10.3.61.80为源地址，直接经过路由器回送相应信息。

4.请求报文必须经过APV，而回应报文则不必经过APV，由服务器直接回应给

客户端。

注意：三角传输模式下的健康检测是基于服务器的真实地址做的，而不是Loopback地址。这就意味着，该服务器的健康检测是UP时，服务器所提供的真实服务并不一定是可用的。

3.1.3 Array APV系列产品服务器负载均衡功能实现

对于应用系统而言，访问时延和服务器的可靠性是非常重要的问题。而随着业务的增长，对拥有多台服务器的客户来说，不是全部服务器都发挥了其应有的效力。

在各个服务器组均能够正常提供服务时，客户端人员仅需向APV上的特定的对外提供服务的IP地址（VIP）和端口发起访问请求，既能得到所有应用功能实现。后台真实提供服务的IP地址和端口将被APV隐藏起来。

Array APV设备能够根据预先负载均衡功能配置，将用户访问请求发送到后台最合适的服务器上进行处理，在实现了将大量访问负载分担到多台应用服务器上进行处理的同时，还可以在今后通过增加应用服务器数量的方式提高整个应用平台的处理能力和响应速度。

在进行服务器负载均衡功能时（四层负载均衡功能、七层负载均衡功能），APV中提供了多种丰富的策略和算法以满足不同应用系统的特定需求。

Array APV提供的负载均衡服务（SLB），使每台服务器的处理能力都能得到充分的发挥。SLB可以实现如下的功能：

提供真正面向应用层的WWW等，以及基于固定端口的TCP/UDP等应用的负载均衡；

无需改动网络拓扑结构，即可实现功能；

功能强大，支持路由功能- 根据实际响应时间的负载平衡算法来实现真正的合理的流量分配。

使用特有的连接复用技术和连接池技术，有效减少后台服务器的负载，保护企业的投资成本。

Array APV系列集成了各种网络流量高速的管理功能，包括紧密结合的4~7

层服务器负载平衡（SLB）、全局服务器负载平衡（GSLB）、高速缓存（Caching）、链路负载平衡（Link Load Balancing）、SSL加速、HTTP压缩（HTTP Compressing）、集群（Clustering）、Webwall安全等功能。客户可以随

着自身的业务增加同步扩充系统规模，只需获取软件许可证即可迅速添加新的功能。

Array APV提供了功能强大的Web数据管理平台，使网络内容的传送更加快捷和顺畅。传统的解决方案往往由多个单功能设备组成，而Array APV则具备高性能、高可靠性和可扩充性特点，可以为客户节省大量的硬件、安装、维护、机架空间和人力方面的投入。

为了改善性能，Array Network 应用了突破性的SpeedStack TM 技术，采用高性能数据包处理内核，包括GB级TCP/IP和SSL处理，HTTP处理内核和全代理内核，IP 数据包对全部的网路功能仅需在TCP/IP堆栈中分析一次，可避免重复性的数据包处理工作。

Array APV安装非常简单，并具有用户友好的Web界面（WebUI）和命令行接口（CLI），CLI可以通过控制台或SSH提供。为确保系统管理员的访问是安全的，不允许采用Telnet登录方式。Array APV的管理工具包可以迅速配置和启动服务。此外，Array APV具有完整的SNMP和XML－RPC管理选项，为保护现有技术投资，Array APV非常便于补充或替代现有的网络设备。

3.1.4 SLB的负载均衡算法

SLB的负载均衡算法分为Policy 和 Method 两种，Policy 是指virtual service 和Group 的之间，对不同组的均衡选择算法，而Method 是指在一个组内部的多个服务器之间的均衡算法。

我们先看Method ，Array APV支持多种服务器负载均衡算法（持续性的、非持续性的、SNMP-Based），包括轮循算法、最少连接算法、最短响应时间算法、散列算法等等。此外实际服务器可以被分配不同的加权值来调整被分配的流量。可以使性能高的大型服务器支持更多的负载。为了避免服务器因过载而崩溃，可为实际服务器指定最大连接阈值来避免该服务器过载。任何服务器可被指定为另一台服务器的备份服务器或溢出服务器，从而进一步保证了应用可用性。

?非持续性算法（Non-Persistent）：一个客户端的不同的请求可能被分配到一

个实服务组中的不同的实服务器上进行处理。主要有：轮循算法、最少连接算法、响应速度算法等。

●轮循算法（Round Robin）：每一次来自网络的请求轮流分配给内部中

的每台服务器，从1至N然后重新开始。此种均衡算法适合于服务器组中

的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况；

●最少连接算法（Least Connection）：客户端的每一次请求服务在服务

器停留的时间都可能会有较大的差异，随着工作时间的加长，如果采用简

单的轮循或随机均衡算法，每一台服务器上的连接进程可能会产生极大的

不同。最少连接数均衡算法对内部中有负载的每一台服务器记录正在处理

的连接数量，当有新的服务连接请求时，将把当前请求分配给连接数最少

的服务器，使均衡更加符合实际情况，负载更加均衡。此种均衡算法适合

长时间处理的请求服务。

●最短响应时间算法（Response Time）：负载均衡设备对内部各服务器

发出一个探测请求（例如Ping），然后根据内部中各服务器对探测请求

的最快响应时间来决定哪一台服务器来响应客户端的服务请求。此种均衡

算法能较好地反映服务器的当前运行状态，但最快响应时间仅仅指的是负

载均衡设备与服务器间的最快响应时间，而不是客户端与服务器间的最快

响应时间。

?持续性算法（Persistent）：从一个特定的客户端发出的请求都被分配到一个

实服务组中的同一个实服务器上进行处理。主要包括：

A．基于IP的算法

●Persistent IP (pi)：基于用户IP地址来选择服务器。

●Hash IP (hi) ：基于用户IP地址的HASH值，来选择服务器

●Consistent Hash IP (chi)

B．基于报头/请求的算法

●Hash Header (hh)：基于用户请求报中HTTP报头来选择服务器；

●Persistent Hostname (ph) ：基于用户请求报中HTTP报头的

Hostname的HASH值，来选择服务器；

●Persistent URL (pu)：基于对URI Tag 和值的静态对应关系来选择服

务器。SSL Session ID (sslsid)：基于SSL会话ID来选择服务器。

●SSL Session ID(sslid): 这是基于应用服务采用的时ssl 协议,每个ssl

session 都有一个特定的ssl sessionID, 根据这个ID的保持行算法

就是SSLID

C．基于Cookie的算法

●Persistent Cookie (pc) ：选择服务器基于用户请求包用Cookie

Name / Value 的静态对应关系；

●Hash Cookie (hc) ：选择服务器基于用户请求包用Cookie Name /

Value 的Hash 值对应关系；

●Insert Cookie (ic) ：选择服务器基于Array 向服务器响应包中插入

Cookie；

●Re-write Cookie (rc)：选择服务器基于Array 向服务器响应包中重写

Cookie值。（必须为重写指定Cookie值的偏移量

●Embed Cookie: 选择服务器基于Array 向服务器响应包中嵌入

Cookie,它会见查会话已有的cookie；

?SNMP-based算法：基于特定的SNMP信息选择合适的服务器，例如：CPU利

用率，硬盘的型号以及内存的状态。

APV将定期发送SNMP请求到真实服务器，并根据服务器回应的数据从而实现服务器负载均衡的目的。

参与的后台服务必须安装有 SNMP 服务软件，并有相应配置。这个功能在保护后台服务地同时，极大地帮助了对客户请求的处理。

?基于优先级的算法：可以对每个后台服务器设定一个不同的优先级，正常情况

下，客户端的请求总选择一个优先级最高的可用后台服务器，优先级低的不接受请求。当优先级最高的后台服务器不能提供服务时，由次优先级的可用后台服务器接管，以此类推。

3.1.5 SLB的负载均衡策略

一个Virtual Service 可能对应多个组，SLB 的负载均衡策略时服务选择定义的组的策略,主要有三大类：基础性策略、保持性策略、QOS策略。

（1）基础性策略

●Static ：在Virtual service 和 Real service 之间建立静态的对应关系

●Default：缺省策略，在没有七层匹配策略时生效。

●Backup ：在匹配一条策略成功，但组内的real services比可用，或

组内的Method匹配失败时生效。

（2）保持性策略，同上一部分Method的匹配规则。须和Method 配合使用。

●Persistent URL

●Persistent Cookie

●Rewrite Cookie

●Insert Cookie

●Header

（3）QOS 策略：七层的负载均衡策略可以根据应用的Header进行更加智能的负载均衡策略

●QOS Cookie ：根据请求的Cookie的值进行均衡

●QOS Hostname ：根据访问的包头中的Hostname 包头进行均衡

●QOS URL：根据URL 字符串进行组的选择

●QOS Network ：根据客户端的源IP地址进行均衡。

●Regular Expression ：更灵活的表达式

●Header : 根据特定的包头进行均衡

●Redirect：将客户端的http request 从一个host 转向到另一个

host 。

3.1.6 Array的SLB健康检查

在进行服务器负载均衡功能的同时，Array APV能够实现对服务器应用的实时健康检查，当应用系统工作异常时，APV能够及时发现并将接下来的访问请求转发到其它能够正常工作的服务器上进行处理，以保证数据流量会自动绕过故障服务器或不可用服务器。当APV的健康检测机制，检测到服务器重新恢复正常以后，将使该服务器可以自动回到服务器群之中继续接收处理用户访问请求，且所有这些服务器故障的处理，对进行操作的用户是完全透明的。

Array APV对服务器的健康检查，可采用如下多种方式：

?适用于3层类型的应用服务检查：

●ICMP检查：利用ICMP可检查服务器的网络工作是否正常。

?适用于4层类型的应用服务检查：

●TCP检查：Array APV可与服务器之间，利用服务器的服务端口建

立TCP连接，检查服务器的服务是否正常。

●UDP检查：Array APV针对DNS服务进行检查，可及时判断DNS

服务是否正常。

●TCPS检查：对与Real services 的SSL 协议握手是否成功进行检查

?适用于7层类型的应用服务检查：

●HTTP检查：Array APV采用HTTP的检查，来验证服务器提供的服

务是否正常。

●Script TCP 和Script UDP检查：通过脚本检查TCP服务或UDP服

务工作是否健康，这种方法更加灵活。

●DNS 检查、Radius 检查：检查DNS服务器和Radius服务器的健康

状态。

?高级Script健康检查方式：

●Script TCP 和Script UDP检查：通过脚本检查TCP服务或UDP服

务工作是否健康，这种方法更加灵活。

?Web 页面的关键词检查：

●HTTP健康检查支持后台服务响应页面的关键词匹配。HTTP健康检

查模块在后台服务的回答中查找关键词，如果找到了，该后台服务

是好的，否则后台服务不正常。

通过这些机制，确保服务器为用户提供正确可靠的服务。用户再也不会得到这样请求的响应“404 Object Not Found”，或响应内容不正确。

通过服务器健康检查功能实现，当其中的任何一台或几台服务器需要离线进行维护或出现故障时，Array APV设备能够通过预先配置的多种智能健康检查机制，及时发现不能正常处理应用的应用服务器，并将接下来的用户访问请求发送到其它能够正常处理的应用的服务器上，从而避免了由于某台服务器的故障而影响了整体的应用业务的提供，保证了业务的高可用性。