天融信网络负载均衡系统白皮书.docx
- 文档编号:6784954
- 上传时间:2023-01-10
- 格式:DOCX
- 页数:25
- 大小:156.92KB
天融信网络负载均衡系统白皮书.docx
《天融信网络负载均衡系统白皮书.docx》由会员分享,可在线阅读,更多相关《天融信网络负载均衡系统白皮书.docx(25页珍藏版)》请在冰豆网上搜索。
天融信网络负载均衡系统白皮书
天融信网络负载均衡系统
白皮书
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.
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 天融信 网络 负载 均衡 系统 白皮书