天融信网络负载均衡系统白皮书.docx

天融信网络负载均衡系统白皮书.docx

《天融信网络负载均衡系统白皮书.docx》由会员分享，可在线阅读，更多相关《天融信网络负载均衡系统白皮书.docx（26页珍藏版）》请在冰点文库上搜索。

天融信网络负载均衡系统白皮书

天融信网络负载均衡系统

白皮书

1产品功能描述

1.1负载均衡系统

1.1.1系统概述

随着云计算、虚拟化等技术的兴起，用户对负载均衡设备提供了更高的要求，负载均衡还要负担应用的优化加速、安全等功能，来提高用户体验，适应各种复杂的场景，比如适配数据中心，对数据中心的虚拟机进行管理等。

用户希望简化部署方式，根据应用所需性能增加或者减少服务器，增加数据中心的利用率，减少运营成本。

应用交付是负载均衡、广域网优化、WEB防火墙等技术的融合，通过这些技术来保证用户关键业务应用能可靠、安全的交付到用户手中。

天融信负载均衡设备能为用户提供数据中心的全套解决方案，包括单数据中心的链路负载均衡和服务器负载均衡、以及多数据中心的全局负载均衡。

支持直连、单臂透明、单臂反向、三角等组网模式，丰富的负载均衡方法，能适用各种场景下的服务负载均衡需求。

通过压缩、缓存、SSL卸载、HTTP优化等技术加速应用的处理，提供全方位防DDOS攻击、WEB应用防火墙等安全防护，为应用安全保驾护航，丰富的统计数据、定制化的报表，用户能实时了解应用运行状态。

通过全方位的负载均衡，增加了数据中心的服务器和网络的利用率，增加了应用的安全性和可靠性，从而减少了用户服务器成本和网络运维成本。

1.1.2功能描述

⏹页面加速

通过自动修改HTML页面及其引用的资源如CSS、JavaScript、图片的内容，利用精简、合并、嵌入原始文件内容，转换图片格式等手段来减少HTTP请求，从而加快整个页面的响应速度，最终提升用户体验

⏹丰富的服务器负载均衡算法

TopAD设备支持的负载均衡算法种类达到13种，这些高效实用的负载均衡算法，能够让用户根据实际的应用场景，选择最佳的负载均衡算法，从而合理分担各个服务器的负载，提高服务器的有效利用率。

⏹丰富的链路负载均衡算法

RoundRobin

按照轮询的方式返回虚拟服务映射中配置的链路,返回链路的个数由虚拟服务映射的配置决定。

最终所有链路的返回次数相等。

轮询算法的特点是简单、稳定、效率高。

⏹DNS代理

TopAD对于内网用户的OUTBOUND流量，采用了DNS代理技术做负载均衡，将用户的DNS请求按照用户指定的负载均衡算法选择链路发送出去，用户配置的DNS透明代理服务器（一主一备，支持健康检查，可将请求发送给状态正常的DNS服务器）进行解析，然后将解析结果返回给客户端，客户端会根据返回的解析结果发起应用流量请求。

DNS代理支持DNS缓存，减少用户DNS开销。

⏹应用路由

应用路由是为了满足特定的出口流量调度到指定的链路，实现特定流量分离，目前支持根据源地址范围、源端口范围、协议类型、拓扑区域、具体应用的条件分别调度，并支持引用多个应用规则，应用规则从上到下匹配，当所有规则都无法匹配的时候会跳出应用路由，在outbound对象默认策略中选路。

⏹多维度数据统计

从多个维度对负载均衡设备各个业务模块进行数据统计。

统计对象多样化，包括接口、会话、链路、虚拟服务器、服务器节点等。

统计内容多样化，包含流量、连接数、报文数、健康检查状态、访问次数、服务分布、带宽利用率、故障分析、性能分析等，各个业务模块还有自己特定的统计数据。

内容分析多样化，每个统计内容又包含了多个维度的分析，包括趋势分析、占比分析、排行分析、服务分布、故障分类、故障分布、性能分析、模块统计、地域分析、URL分析、IP分析等。

⏹定制化报表

报表可定制化，可自定义报表模板。

报表模板包括负载统计、决策分析、故障分析、前言后记等几大块内容。

负载统计又包括链路负载、虚拟服务器负载、服务器节点负载等；决策分析又包括来源、地域、运营商分析等；故障分析又包括链路和服务器节点故障分析。

每种统计又细分为多个维度的统计选项，比如流量走势、总流量占比、报文数走势、报文数排、访问次数占比、带宽利用率走势、服务分布、IP数量地域分析、访问次数地域分析，流量地域分析，IP数量的运营商分析、访问次数运营商分析、流量的运营商分析、来源分析等，可以根据需要配置不同的报表模板。

可以引用不同的报表模板并按照时间每天、周、月自动生成报表。

2产品硬件规格及性能参数

2.1负载均衡：

TopApp-81238-NLB-R

配置说明

2U机架式结构；；

标配10个10/100/1000BASE-TX接口；8个SFP插槽；2个SFPplus插槽

3个扩展卡槽位

缺省为双电源

性能描述

四层新建：

40W

七层新建：

80W

整机吞吐量：

10Gbps

最大并发连接数：

800W

硬件规格

尺寸（宽深高）mm：

426*570*89

净重：

12.46KG

毛重：

17.76KG

电压：

AC100~240V

频率：

47~63HZ

功率:

300W（MAX）

平均无故障时间（MTBF）：

超过60，000小时

运行温度：

0~40摄氏度

存储温度：

-20~75摄氏度

相对温度：

10~90%,非冷凝

符合的标准规范

环境保护GB/T9813-2000；

电磁辐射GB/T17618-1998；GB9254-2008

运输方式

快递、物流

其它要求

接地线的数量、线径：

1根,大于等于0.75平方毫米.

接地线数量、线径：

1根,线径大于等于0.75平方毫米.

接地电阻：

小于100毫欧

电源品牌：

亿泰兴

电源型号：

EFRP-2300

3产品测试方案

3.1负载均衡系统测试方案

3.1.1测试目的

本方案制定了负载均衡产品的测试环境、测试场景以及测试用例等，对负载均衡产品进行全功能测试。

3.1.2测试内容

本测试方案主要用于完成负载均衡设备的服务器负载测试，多链路负载测试、集群功能测试。

3.1.3测试环境

测试拓扑

图1：

图2：

图3：

3.1.4测试用例设计

服务器负载功能测试

3.1.4.1.1健康检查测试

ICMP健康检查

项目：

健康检查

分项目：

ICMP健康检查

用例编号：

1.

参考组网：

1.0

测试目的：

测试负载均衡使用ICMP的健康检查方法对服务器的健康检查，能否发现服务器的停机，网络中断等故障。

预置条件：

1.负载均衡工作正常；

2.后台服务组（大于3）工作正常，提供WEB服务并确认可以回应ICMP包；

3.有一定量的业务请求（大于1000TPS）；

4.负载均衡配置ICMP的健康检查，调整频率为每15秒钟检查一次，如果连续3次以上服务器没有回应就确认其停止服务。

测试步骤：

1.对负载均衡器与服务器之间的接口进行抓包；

2.拔掉一台服务器的网线，观察负载均衡器的健康检查界面。

3.连接网线，观察负载均衡器的健康检查界面。

预期结果：

1.抓包显示，负载均衡能够按照配置，周期性发送ICMP检查报文；

2.负载均衡器支持ICMP健康检查；

3.步骤2中，负载均衡发现服务器故障，记录发现服务器停机的时间，并将所有新发起的请求切换到其他服务器，记录相关数据；

4.步骤3中，负载均衡器发现服务器恢复，开始给其分配服务，记录发现服务器恢复的时间；

5.发现服务器故障时间应少于15*3=45秒，发现服务器故障恢复时间应小于15秒

测试结果

备注：

无

基于服务的健康检查

项目：

健康检查

分项目：

基于服务的健康检查

用例编号：

2.

参考组网：

1.0

测试目的：

测试负载均衡使用基于服务的健康检查方法对服务器的健康检查，能否发现服务器的服务已经停止、停机、网络中断等故障。

预置条件：

1.负载均衡工作正常；

2.后台服务组（大于3）工作正常，提供WEB服务并确认可以回应ICMP包；

3.有一定量的业务请求（大于1000TPS）；

4.服务器均提供http:

//<服务器IP:

端口>index.html的web服务；

5.负载均衡器配置基于服务的健康检查，调整频率为每15秒钟检查一次，如果连续3次以上服务器没有回应就确认其停止服务。

测试步骤：

1.对负载均衡器与服务器之间的接口进行抓包；

2.将服务器A（其中一台）的http服务停止，观察负载均衡器的健康检查界面。

3.恢复服务器A的http服务，观察负载均衡器的健康检查界面，记录发现服务器恢复的时间，和将所有在线用户在一台服务器的访问重新负载均衡的时间，记录相关数据；

4.将服务器B（其中一台）提供http服务的路径变为http:

//<服务器IP:

端口>/abc/index.html;

5.将服务器B<其中一台>提供http服务的路径恢复为http:

//<服务器IP:

端口>/index.html

6.将服务器的服务端口号均变换为6666，重复步骤2-5.

预期结果：

1.抓包显示，负载均衡能够按照配置，周期性发送get请求检查服务器健康状态；

2.负载均衡器支持基于服务的健康检查；

3.步骤2中，负载均衡发现服务器故障，

4.步骤3中，负载均衡器发现服务器恢复

5.步骤4中，负载均衡发现服务器故障；

6.步骤5中，负载均衡发现服务恢复；

7.发现服务器故障时间应小于15*3=45秒，发现服务器故障恢复时间应小于15秒。

测试结果

备注：

无

基于内容的健康检查（HTTP）

项目：

健康检查

分项目：

基于内容的健康检查（HTTP）

用例编号：

3.

参考组网：

1.0

测试目的：

测试负载均衡使用基于内容（http）的健康检查方法对服务器的健康检查，能否发现服务器的服务已经停止、停机、网络中断等故障。

预置条件：

1.负载均衡工作正常；

2.后台服务组（大于3）工作正常，提供WEB服务并确认可以回应ICMP包；

3.有一定量的业务请求（大于1000TPS）；

4.服务器均提供http:

//<服务器IP:

端口>index.html的web服务，并且页面上有“chinamobile”字符串；

5.负载均衡器配置基于内容的健康检查，检测网页中如果含有“chinamobile”字符串，则认为该服务器“健康”，否则反之；

6.调整频率为每15秒钟检查一次，如果连续3次以上服务器没有回应就确认其停止服务。

测试步骤：

1.对负载均衡器与服务器之间的接口进行抓包；

2.将服务器A（其中一台）的http服务停止，观察负载均衡器的健康检查界面。

3.恢复服务器A的http服务，观察负载均衡器的健康检查界面，记录发现服务器恢复的时间，和将所有在线用户在一台服务器的访问重新负载均衡的时间，记录相关数据；

4.将服务器B（其中一台）提供http服务的页面内容中的“chinamobile”变为“chinamobile”

5.将服务器B（其中一台）提供http服务的页面内容中的“chinamobile”变为“chinamobile123”；

6.恢复服务器B（其中一台）提供http服务的页面内容为“chinamobile”.

预期结果：

1.抓包显示，负载均衡器能够按照配置，周期性发送get请求检查服务器健康状态；

2.负载均衡器支持基于服务的健康检查；

3.步骤2中，服务器故障；

4.步骤3中，服务器正常；

5.步骤4中，服务器故障；

6.步骤5中，服务器正常；

7.步骤6中，服务器正常；

8.发现服务器故障时间应小于15*3=45秒，发现服务器故障恢复时间应小于15秒。

测试结果

备注：

无

基于内容的健康检查（DNS）

项目：

健康检查

分项目：

基于内容的健康检查（DNS）

用例编号：

4.

参考组网：

1.0

测试目的：

测试负载均衡使用基于内容（DNS）的健康检查方法对服务器的健康检查，能否发现服务器的服务已经停止、停机、网络中断等故障。

预置条件：

1.负载均衡工作正常；

2.后台服务组（大于3）工作正常，提供DNS解析服务并确认可以回应ICMP包；

3.有一定量的业务请求（大于1000TPS）；

4.服务器上配置，将解析为“10.10.10.100”；

5.负载均衡器配置基于内容的健康检查，检测的解析结果是否为“10.10.10.100”，如果是，则认为该服务器“健康”，否则反之；

6.调整频率为每15秒钟检查一次，如果连续3次以上服务器没有回应就确认其停止服务。

测试步骤：

1.对负载均衡器与服务器之间的接口进行抓包；

2.将服务器A（其中一台）的DNS服务停止，观察负载均衡器的健康检查界面。

3.恢复服务器A的DNS服务，观察负载均衡器的健康检查界面，记录发现服务器恢复的时间，和将所有在线用户在一台服务器的访问重新负载均衡的时间，记录相关数据；

4.将服务器B（其中一台）提供DNS服务中的解析地址变为“10.10.10.101”；

5.将服务器B（其中一台）提供DNS服务中的记录删除；

6.恢复服务器B中的记录，解析地址还原为“10.10.10.100”

预期结果：

1.抓包显示，负载均衡器能够按照配置，周期性发送DNS请求检测报文；

2.负载均衡器支持基于服务的健康检查；

3.步骤2中，服务器故障；

4.步骤3中，服务器正常；

5.步骤4中，服务器故障；

6.步骤5中，服务器故障；

7.步骤6中，服务器正常；

8.发现服务器故障时间应小于15*3=45秒，发现服务器故障恢复时间应小于15秒。

测试结果

备注：

无

3.1.4.1.2负载均衡算法测试

轮询法

项目：

负载均衡算法测试

分项目：

轮询法

用例编号：

5.

参考组网：

1.0

测试目的：

测试负载均衡使用轮询法对服务器进行负载均衡的访问分发，在服务器端造成的压力是否确实是均衡的。

预置条件：

1.负载均衡工作正常，配置健康检查算法为ICMP算法；

2.负载均衡器对外提供一个VIP，并配置负载均衡算法为轮询法；

3.后台服务器组数量为3，工作正常，提供WEB服务并确认可以回应ICMP包；

测试步骤：

1.对负载均衡器与服务器之间的接口进行抓包；

2.将使用仪表模拟客户端，以一定压力访问VIP；

a）仪表仿真7个IP地址作为源IP进行测试；

b）其中第一个源IP地址的访问速率为300页面/秒；

c）其他6个源IP地址的访问速率均为30页面/秒；

3.查看后台服务器业务的负载均衡情况；

预期结果：

1.负载均衡器将业务按请求到达顺序平均分给了后台的3台服务器，每台服务器的业务请求为160页面/秒（约数）；

2.抓包分析，每一个源IP地址发出的请求不能都分配给同一台服务器。

测试结果

备注：

无

比重法

项目：

负载均衡算法测试

分项目：

比重法

用例编号：

6.

参考组网：

1.0

测试目的：

测试负载均衡器使用比重法对服务器进行负载均衡的访问分发，在服务器端造成的压力是否确实是比重均衡的。

预置条件：

1.负载均衡工作正常，配置健康检查算法为ICMP算法；

2.负载均衡器对外提供一个VIP；

3.后台服务器组数量为3，工作正常，提供WEB服务并确认可以回应ICMP包；

4.并配置负载均衡算法为比重法，服务器A、B、C提供服务的业务量比例为3:

2:

1

测试步骤：

1.对负载均衡器与服务器之间的接口进行抓包；

2.将使用仪表模拟客户端，以一定压力访问VIP；

d）仪表仿真7个IP地址作为源IP进行测试；

e）其中第一个源IP地址的访问速率为300页面/秒；

f）其他6个源IP地址的访问速率均为30页面/秒；

3.查看后台服务器业务的负载均衡情况；

预期结果：

1.负载均衡器将业务按请求到达顺序平均分给了后台的3台服务器，业务请求分别为240、160、80页面/秒（约数）；

2.抓包分析，每一个源IP地址发出的请求不能都分配给同一台服务器。

测试结果

备注：

无

Hash负载均衡算法

项目：

负载均衡算法测试

分项目：

Hash负载均衡算法

用例编号：

7.

参考组网：

1.0

测试目的：

测试负载均衡器可以根据业务请求客户端的源IP和源端口号，通过一定的Hash算法将业务请求分配给后台的服务器。

预置条件：

1.负载均衡工作正常，配置健康检查算法为ICMP算法；

2.负载均衡器对外提供一个VIP；

3.后台服务器组数量为3，工作正常，提供WEB服务并确认可以回应ICMP包；

4.并配置负载均衡算法为Hash负载均衡算法；

测试步骤：

1.对负载均衡器与服务器之间的接口进行抓包；

2.将使用仪表模拟客户端，以一定压力访问VIP；

a）仪表仿真7个IP地址作为源IP进行测试，访问速率均为300页面/秒；

b）其中第一个源IP地址访问速率为300页面/秒；

c）其他6个源IP地址的访问速率均为30页面/秒；

3.查看后台服务器业务的负载均衡情况；

预期结果：

1.负载均衡器将业务按预制算法分给了后台的3台服务器，业务请求服务数量并不一定均衡；

2.抓包分析，第一个源IP地址所有的请求均被分配到同一台服务器。

3.抓包分析，其余的每一个源IP地址发出的请求不能都分配给同一台服务器

测试结果

备注：

无

基于源地址负载均衡算法

项目：

负载均衡算法测试

分项目：

基于源地址负载均衡算法

用例编号：

8.

参考组网：

1.0

测试目的：

测试负载均衡器可以根据业务请求客户端的不同源IP地址（范围），通过预置条件将业务请求分配给后台不同的服务器。

预置条件：

1.负载均衡工作正常，配置健康检查算法为ICMP算法；

2.负载均衡器对外提供一个VIP；

3.后台服务器组数量为3，工作正常，提供WEB服务并确认可以回应ICMP包；

4.并配置负载均衡算法为基于源地址负载均衡算法，将192.168.1.0/24的IP地址访问分配给服务器A，将192.168.2.0/24的IP地址访服务器问分配给服务器B，将192.168.3.0/24的IP地址访问分配给C；

测试步骤：

1.对负载均衡器与服务器之间的接口进行抓包；

2.将使用仪表模拟客户端，以一定压力访问VIP；

a）仪表仿真3个IP地址作为源IP进行测试；

b）第1个源IP地址分为192.168.1.20，访问速率为100页面/秒；

c）第2个源IP地址分为192.168.2.231，访问速率为200页面/秒；

d）第3个源IP地址分为192.168.3.111，访问速率为300页面/秒；

3.查看后台服务器业务的负载均衡情况；

预期结果：

1.负载均衡器将业务按预制算法分给了后台的3台服务器，业务请求服务数量分别为100、200、300页面/秒；

2.抓包分析，对应源IP地址所有的请求均被分配到同一台服务器。

测试结果

备注：

无

基于内容的负载均衡算法

项目：

负载均衡算法测试

分项目：

基于内容的负载均衡算法

用例编号：

9.

参考组网：

1.0

测试目的：

测试负载均衡器可以根据业务请求所包含的不同内容，将业务请求分配给后台不同的服务器。

预置条件：

1.负载均衡工作正常，配置健康检查算法为ICMP算法；

2.负载均衡器对外提供一个VIP；

3.后台服务器组数量为4，工作正常，提供WEB服务并确认可以回应ICMP包；

4.并配置负载均衡算法为基于请求内容的负载均衡算法，将请求URL中含有“CM1”的发送给服务器A，将请求URL中含有“CM2”的发送给服务器B，将请求URL中含有“CM12”的发送给服务器C，将请求URL中含有“CM21”的发送给服务器D。

测试步骤：

1.对负载均衡器与服务器之间的接口进行抓包；

2.将使用仪表模拟客户端，以一定压力访问VIP；

3.仪表仿真3个IP地址作为源IP进行测试，每个源IP地址访问http:

//VIP/CMCCCM1速率为50页面/秒，访问http:

//VIP/CMCCCM2速率为100页面/秒，访问http:

//VIP/CMCCCM1212速率为200页面/秒，访问http:

//VIP/CMCCCM2121速率为400页面/秒；

4.查看后台服务器业务的负载均衡情况。

预期结果：

1.负载均衡器将业务按预置算法分给了后台的4台服务器；

2.所有请求http:

//VIP/CMCCCM1业务均分配给了服务器A，访问速率为150页面/秒。

3.所有请求http:

//VIP/CMCCCM12业务均分配给了服务器B，访问速率为300页面/秒。

4.所有请求http:

//VIP/CMCCCM2121业务均分配给了服务器C，访问速率为600页面/秒。

5.所有请求http:

//VIP/CMCCCM1212业务均分配给了服务器D，访问速率为1200页面/秒。

测试结果

备注：

无

插入Cookie负载均衡算法

项目：

负载均衡算法测试

分项目：

插入Cookie负载均衡算法

用例编号：

10.

参考组网：

1.0

测试目的：

测试负载均衡器基于Cookie的会话保持功能。

预置条件：

1.负载均衡工作正常，配置健康检查算法为ICMP算法，负载均衡算法设为轮询法；

2.负载均衡器对外提供一个VIP；

3.后台服务器组数量为3，工作正常，提供WEB服务并确认可以回应ICMP包；

4.负载均衡器启动会话保持功能，并设置为基于Cookie的会话保持，配置为InsertCookie模式，即服务器不下发Cookie，由负载均衡器添加Cookie；

5.负载均衡器为服务器A配置Cookie-1，为服务器B配置Cookie-2，为服务器C配置Cookie-3；（Cookie-1/2/3表示不同的Cookie值，负载均衡器也可自动生成不同的Cookie值）

测试步骤：

1.对负载均衡器与服务器之间的接口进行抓包；

2.使用仪表模拟客户端，以一定压力访问VIP：

a）仪表仿真100个IP地址（10.1.1.10–10.1.1.109）作为源IP进行测试，并且IP地址采用随机方式（非顺序的）产生压力；

b）访问速率为900页面/秒，所有请求都不带Cookie，服务器响应请求的回应带有不同的Cookie；

3.查看后台服务器业务的负载均衡情况，并保持压力，并存储后台服务器A响应时所带的Cookie-1；

4.在步骤2的基础上，使用仪表模拟客户端，以源IP为10.2.1.10对VIP进行访问，并带上步骤3中存好的Cookie-1，访问速率为300页面/秒

预期结果：

1.步骤2中，负载均衡器将业务按轮询法平均分配给了后台的3台服务器，每台服务器的业务请求为300页面/秒（约数），并且返回的响应分别含有Cookie-1、Cookie-2、Cookie-3；

2.抓包分析，每一个源IP地址发出的请求不能都分配给同一台服务器：

3.步骤4中，源IP为10.2.1.10的请求因为其带有Cookie-1，因此业务请求都分配给了服务器A、服务器A、B、C的压力分别为：

600页面/秒、300页面/秒、300页面/秒。

测试结果

备注：

无

3.1.4.1.3应用加速功能测试

连接复用

项目：

应用加速功能测试

分项目：

连接复用

用例编号：

11.

参考组网：

1.0

测试目的：

测试负载均衡器是否支持连接复用功能

预置条件：

1.负载均衡器工作正常；

2.