天融信网络负载均衡系统白皮书Word格式.docx
《天融信网络负载均衡系统白皮书Word格式.docx》由会员分享，可在线阅读，更多相关《天融信网络负载均衡系统白皮书Word格式.docx（25页珍藏版）》请在冰豆网上搜索。
应用路由是为了满足特定的出口流量调度到指定的链路，实现特定流量分离，目前支持根据源地址范围、源端口范围、协议类型、拓扑区域、具体应用的条件分别调度，并支持引用多个应用规则，应用规则从上到下匹配，当所有规则都无法匹配的时候会跳出应用路由，在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健康检查
项目：
健康检查
分项目：
用例编号：
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.
测试负载均衡使用基于服务的健康检查方法对服务器的健康检查，能否发现服务器的服务已经停止、停机、网络中断等故障。
4.服务器均提供http:
//<
服务器IP:
端口>
index.html的web服务；
5.负载均衡器配置基于服务的健康检查，调整频率为每15秒钟检查一次，如果连续3次以上服务器没有回应就确认其停止服务。
2.将服务器A（其中一台）的http服务停止，观察负载均衡器的健康检查界面。
3.恢复服务器A的http服务，观察负载均衡器的健康检查界面，记录发现服务器恢复的时间，和将所有在线用户在一台服务器的访问重新负载均衡的时间，记录相关数据；
4.将服务器B（其中一台）提供http服务的路径变为http:
/abc/index.html;
5.将服务器B<
其中一台>
提供http服务的路径恢复为http:
/index.html
6.将服务器的服务端口号均变换为6666，重复步骤2-5.
1.抓包显示，负载均衡能够按照配置，周期性发送get请求检查服务器健康状态；
2.负载均衡器支持基于服务的健康检查；
3.步骤2中，负载均衡发现服务器故障，
4.步骤3中，负载均衡器发现服务器恢复
5.步骤4中，负载均衡发现服务器故障；
6.步骤5中，负载均衡发现服务恢复；
7.发现服务器故障时间应小于15*3=45秒，发现服务器故障恢复时间应小于15秒。
基于内容的健康检查（HTTP）
3.
测试负载均衡使用基于内容（http）的健康检查方法对服务器的健康检查，能否发现服务器的服务已经停止、停机、网络中断等故障。
index.html的web服务，并且页面上有“chinamobile”字符串；
5.负载均衡器配置基于内容的健康检查，检测网页中如果含有“chinamobile”字符串，则认为该服务器“健康”，否则反之；
6.调整频率为每15秒钟检查一次，如果连续3次以上服务器没有回应就确认其停止服务。
4.将服务器B（其中一台）提供http服务的页面内容中的“chinamobile”变为“chinamobile”
5.将服务器B（其中一台）提供http服务的页面内容中的“chinamobile”变为“chinamobile123”；
6.恢复服务器B（其中一台）提供http服务的页面内容为“chinamobile”.
1.抓包显示，负载均衡器能够按照配置，周期性发送get请求检查服务器健康状态；
3.步骤2中，服务器故障；
4.步骤3中，服务器正常；
5.步骤4中，服务器故障；
6.步骤5中，服务器正常；
7.步骤6中，服务器正常；
8.发现服务器故障时间应小于15*3=45秒，发现服务器故障恢复时间应小于15秒。
基于内容的健康检查（DNS）
4.
测试负载均衡使用基于内容（DNS）的健康检查方法对服务器的健康检查，能否发现服务器的服务已经停止、停机、网络中断等故障。
2.后台服务组（大于3）工作正常，提供DNS解析服务并确认可以回应ICMP包；
4.服务器上配置，将解析为“10.10.10.100”；
5.负载均衡器配置基于内容的健康检查，检测的解析结果是否为“10.10.10.100”，如果是，则认为该服务器“健康”，否则反之；
2.将服务器A（其中一台）的DNS服务停止，观察负载均衡器的健康检查界面。
3.恢复服务器A的DNS服务，观察负载均衡器的健康检查界面，记录发现服务器恢复的时间，和将所有在线用户在一台服务器的访问重新负载均衡的时间，记录相关数据；
4.将服务器B（其中一台）提供DNS服务中的解析地址变为“10.10.10.101”；
5.将服务器B（其中一台）提供DNS服务中的记录删除；
6.恢复服务器B中的记录，解析地址还原为“10.10.10.100”
1.抓包显示，负载均衡器能够按照配置，周期性发送DNS请求检测报文；
6.步骤5中，服务器故障；
3.1.4.1.2负载均衡算法测试
轮询法
负载均衡算法测试
5.
测试负载均衡使用轮询法对服务器进行负载均衡的访问分发，在服务器端造成的压力是否确实是均衡的。
1.负载均衡工作正常，配置健康检查算法为ICMP算法；
2.负载均衡器对外提供一个VIP，并配置负载均衡算法为轮询法；
3.后台服务器组数量为3，工作正常，提供WEB服务并确认可以回应ICMP包；
2.将使用仪表模拟客户端，以一定压力访问VIP；
a）仪表仿真7个IP地址作为源IP进行测试；
b）其中第一个源IP地址的访问速率为300页面/秒；
c）其他6个源IP地址的访问速率均为30页面/秒；
3.查看后台服务器业务的负载均衡情况；
1.负载均衡器将业务按请求到达顺序平均分给了后台的3台服务器，每台服务器的业务请求为160页面/秒（约数）；
2.抓包分析，每一个源IP地址发出的请求不能都分配给同一台服务器。
比重法
6.
测试负载均衡器使用比重法对服务器进行负载均衡的访问分发，在服务器端造成的压力是否确实是比重均衡的。
2.负载均衡器对外提供一个VIP；
4.并配置负载均衡算法为比重法，服务器A、B、C提供服务的业务量比例为3:
2:
1
d）仪表仿真7个IP地址作为源IP进行测试；
e）其中第一个源IP地址的访问速率为300页面/秒；
f）其他6个源IP地址的访问速率均为30页面/秒；
1.负载均衡器将业务按请求到达顺序平均分给了后台的3台服务器，业务请求分别为240、160、80页面/秒（约数）；
Hash负载均衡算法
7.
测试负载均衡器可以根据业务请求客户端的源IP和源端口号，通过一定的Hash算法将业务请求分配给后台的服务器。
4.并配置负载均衡算法为Hash负载均衡算法；
a）仪表仿真7个IP地址作为源IP进行测试，访问速率均为300页面/秒；
b）其中第一个源IP地址访问速率为300页面/秒；
1.负载均衡器将业务按预制算法分给了后台的3台服务器，业务请求服务数量并不一定均衡；
2.抓包分析，第一个源IP地址所有的请求均被分配到同一台服务器。
3.抓包分析，其余的每一个源IP地址发出的请求不能都分配给同一台服务器
基于源地址负载均衡算法
8.
测试负载均衡器可以根据业务请求客户端的不同源IP地址（范围），通过预置条件将业务请求分配给后台不同的服务器。
4.并配置负载均衡算法为基于源地址负载均衡算法，将192.168.1.0/24的IP地址访问分配给服务器A，将192.168.2.0/24的IP地址访服务器问分配给服务器B，将192.168.3.0/24的IP地址访问分配给C；
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页面/秒；
1.负载均衡器将业务按预制算法分给了后台的3台服务器，业务请求服务数量分别为100、200、300页面/秒；
2.抓包分析，对应源IP地址所有的请求均被分配到同一台服务器。
基于内容的负载均衡算法
9.
测试负载均衡器可以根据业务请求所包含的不同内容，将业务请求分配给后台不同的服务器。
3.后台服务器组数量为4，工作正常，提供WEB服务并确认可以回应ICMP包；
4.并配置负载均衡算法为基于请求内容的负载均衡算法，将请求URL中含有“CM1”的发送给服务器A，将请求URL中含有“CM2”的发送给服务器B，将请求URL中含有“CM12”的发送给服务器C，将请求URL中含有“CM21”的发送给服务器D。
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负载均衡算法
10.
测试负载均衡器基于Cookie的会话保持功能。
1.负载均衡工作正常，配置健康检查算法为ICMP算法，负载均衡算法设为轮询法；
4.负载均衡器启动会话保持功能，并设置为基于Cookie的会话保持，配置为InsertCookie模式，即服务器不下发Cookie，由负载均衡器添加Cookie；
5.负载均衡器为服务器A配置Cookie-1，为服务器B配置Cookie-2，为服务器C配置Cookie-3；
（Cookie-1/2/3表示不同的Cookie值，负载均衡器也可自动生成不同的Cookie值）
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.负载均衡器工作正常；
升级会员 