网络系统方案的可靠性测试

网络
基于网络系统可靠性的设计思想,其相应的测试应如何考虑与实施?本文对网络方案可靠性测试的分类及内容做详细阐述。

网络系统方案的可靠性主要包括:网络系统的可持续性、可维护性、快速恢复机制。相应的,组网方案的可靠性测试,可归纳为以下几大类:

1、网络系统持续长时间、大压力高负荷、高频率震荡条件下的持续运行能力,即Duration测试。

2、网络系统告警管理功能、系统故障定位手段能力评估。

3、单点故障情况下系统自动恢复时间。

4、验证链路聚合、MSTP、RRPP、BFD、GR、VRRP、ECMP、IRF等HA(High Availability)特性的组合部署功能,并通过调整达到最佳的组合应用效果。

5、构造各类攻击,从端到端对网络系统进行攻击。此类测试往往可以融合在Duration测试中共同完成。

1网络系统持续运行能力测试

网络系统持续运行能力测试的目标是要通过更恶劣环境的测试,以确保网络系统在客户的网络环境中上线后,在各种冲击和压力下,仍旧能够保持稳定运行。测试方法很明确:在组网测试环境中对运营商或者行业客户网络的控制平面和数据平面模型进行模拟,保持环境在大压力并且震荡的条件下持续运行,同时监控网络各个整体运行状况作为测试结果数据。

测试参数的设计是保证测试效果的重点。其内容主要包括以下几部分。

1、测试组网设备参数。

以客户的原始组网模型进行组网测试是最理想的环境。但是考虑成本因素,实际测试投入中往往难以搭建相对真实网络1:1的测试网络环境。为实现测试目的,充分验证系统的可靠性,测试组网的抽象和取舍是重点。抽象简化组网规模的原则是:充分分析暴露网络系统的性能压力瓶颈,重点保留系统中的瓶颈关键节点。

例如,针对一个接入至核心层结构明晰的树形网络,常用的可行方案是在业务流量压力最大的核心层采用1:1组网测试。树形结构网络的核心层的设备数量较少,这也为测试环境的1:1组网提供了可能性。汇聚和接入层设备数量逐层递减,接入层设备采用几个分支模拟真实应用,其余分支使用高性能测试仪器的多个端口直接连接在汇聚层设备上模拟拓扑和流量。可根据被测试网络的控制平明和数据平面路径,灵活调整测试组网。

2、控制平面和数据平面参数。

即协议模型和流量模型。协议模型可以通过客户的组网的规划和行业抽象,得到较为明确的数据参数。由于应用系统与网络系统的维护技术人员之间的业务理解往往存在壁垒,并且在网络规划设计阶段,无法通过流量监控获取模型,所以流量模型难以准确界定,因此成为困扰组网方案测试的主要因素。比较有效的手段是针对行业特征进行分析,并结合以往的经验来设定普遍意义的参数。参数还可根据不同类型客户的实际上线预期进行加权预估。

3、振荡系数与方法。

针对控制平面和数据平面的振荡是Duration测试的基本要求之一。网络系统是一个动态的环境。来自网络系统边缘与出口的各类输入输出变化,会产生更大的压力和暴露更多的瓶颈。而通过剧烈高频度的振荡,营造比客户实际环境更加恶劣的网络,能够更快更充分暴露较深或者需要较长时间才能够发现的缺陷。通过振荡在测试网络中掀起的狂风巨浪,会让我们更加明确了解网络系统的健康可靠程度。

网络系统测试的振荡系数常用经验值为30%,即加载在测试系统的协议表项和流量在已设定的参数基础上,周期性上下浮动30%。并可根据需要调整以观察不同频率条件下的振荡结果,例如可分别以5分钟、10分钟、30分钟、1小时为一个周期。以路由条数为例,路由振荡导致整个网络系统中各个节点大量发布、删除路由信息,并引发流量路径的迁移,给予测试系统更大的不稳定性压力。实际测试时,还需要根据行业客户应用特征网络对系数进一步分析,灵活调整。例如,互联网行业客户,普遍存在搜索类业务突发,对流量振荡的要求更高。

振荡的模拟可通过业界常用测试仪器较为方便实现,本文不再赘述。

2网络系统告警管理功能、系统故障定位手段能力评估

网络系统必须具备系统风险预警功能和便利的故障定位维护功能。

网管系统对网络的实时监控,预先告警功能主要包括网络节点CPU、内存、端口流量、端口状态等参数的监控告警。当占用率或者端口流量持续超过阈值,即可触发告警,使管理员提前预知风险,进行分析维护。

系统故障定位手段为事后维护。一旦网络系统产生故障点,网络管理系统需记录网络切换事件,方便快速帮助管理员找到故障点,并保存故障信息和系统状态,便于后期缺陷复现定位。

维护类测试以功能测试为主,通过打入攻击CPU的流量、制造流量拥塞等方法构造各类预警条件,通过shutdown或者重启设备等命令行,插拔端口、关闭电源等手段检验网络系统对故障点的定位和告警信息是否完备。若设备支持可维护性测试特性,还可通过设备软件的可维护性测试命令,构造设备节点系统软硬件故障,查看系统保存的故障状态信息是否完备,以复现定位缺陷。

测试时,同样需在大压力复杂条件下执行,以检测告警、故障信息是否得到高优先级处理。

3单点故障情况下系统自动恢复时间

网络系统在出现单点故障情况下可快速恢复是高可靠网络设计的重点。恢复时间的要求在各类行业和各网络层有差异。目前,网络系统平均恢复时间低于500ms已经逐步成为主流要求。

与网络切换相关的各种组网模型故障模拟主要包括:链路故障、节点设备故障、单板故障、节点设备主备倒换、主备设备倒换、设备升级等。各类故障还需进一步细分,例如节点设备故障包含:设备命令行执行软件重启,设备断电、设备上电、主备控板全部拔出/插入等等。#p#

为精确计算各类故障导致的网络中断/恢复时间,组网如图1所示,测试方法如下:

图1 网络系统恢复时间测试示意

图1 网络系统恢复时间测试示意

1、基于网络测试环境,接入测试仪器,将流量发生器端到端接入网络系统。仪器端口分别连接网络系统的接入层和出口,以保证被测流量路径贯通整个网络。

2、在测试仪器的Port A端口设定速率稳定的流量,目的地址为Port B端口。在Port B端口设定速率稳定的流量,目的地址为Port A端口。由于上下行路径迁移时,上下行的路由等各类协议的热备表项不同,涉及的协议收敛也可能不同,所以务必设定双向流量,以检测上行和下行流量路径的恢复时间。

3、确保设定的上下行流量路径通过需要模拟的故障点节点,避免测试无效。

4、启动流量发送与接收,开始统计发送的流量和接收的流量。

5、模拟节点故障,网络系统自动检测并恢复。

6、停止发送流量。根据发送和接收的流量,计算得出系统流量路径恢复时间。

公式为:Time=(发送报文数量-接收报文数量)/报文发送速率(pps)。

注意:报文发送速率以M/G为单位时,计算需考虑以太网报文的前导码和帧间隙,公式为:Time=(发送报文数量-接收报文数量)*( 报文字节*8+8*8+96)/报文发送速率(M/G)。通过计算得出上下行流量路径的恢复时间。

测试时还需注意以下细节:

1、故障模拟操作方式要考虑全面。例如用命令行shutdown端口和拔掉网线操作导致的测试结果往往会不同;光纤的单通与通常的链路down表现也会不同等。

2、不仅要测试主设备/链路切换到备用,还要测试主设备/链路恢复正常后,网络系统的表现。

3、每项测试需至少测试三次得到平均值。并对得到尖峰和低谷进行分析,需要时重复更多测试以获取稳定数据。

4、始终关注测试流量路径是否经过故障节点,是否按照预期切换,保证测试结果的准确性。

4验证HA(High Availability)特性的组合部署功能

网络系统中的协议配置对系统的稳定性、负荷和恢复时间有重大影响。例如对OSPF的hello time设置过小,会加重网络中控制平面处理负担,并容易产生路由振荡。但是过大也会导致故障时系统恢复时间无法达到要求。因此在测试中可根据不同网络的要求,取得一个性价比最高的平衡。

当各类为保证网络系统高可靠运行的协议在一个网络系统中应用时,就使这种组合更加复杂,这些特性包括链路聚合、MSTP、RRPP、BFD、GR、VRRP、ECMP、IRF等。

因此,测试不仅仅需要验证这些特性是否在发挥作用,同时测试过程也是一个网络参数调优过程。在测试中通过不断调整协议配置参数,以获取网络系统可靠性最佳配置。这个调优过程既要计算获取网络故障恢复时间,又要监控网络系统各个节点的运行状况。例如在满足网络恢复时间要求基础上,监控参数配置会影响的CPU占用率、内存是否正常,Console是否能响应,转发是否正常,OSPF收敛及路由变化等等,综合得出结论。

5从端到端对网络系统进行各类攻击测试

此类测试往往融合在Duration测试中共同完成。使用测试仪器公司、开源软件、自行开发的各类异常报文攻击工具,可以实现对网络系统的安全漏洞、健壮性的综合测试。

结束语

网络系统方案的可靠性测试的所有测试内容,都需要在整网环境下执行,以保证网络系统的复杂关联性,互相影响得到充分验证。网络系统的可靠性测试是一种灰盒测试,不仅仅要进行端到端的测试,还要深入关注到各个节点的运行状态,流量和协议控制层面的脉络运行状态。要做好各类故障的分类分析,充分考虑客户环境的复杂性和客户行为,对网络系统的高可靠相关特性深入理解,在验证中优化配置参数,得到最优最可靠的网络系统。

 

责任编辑:佚名 来源: 51CTO.com
相关推荐

2011-08-19 15:59:40

2011-08-18 13:58:08

2010-12-28 20:04:10

网络的可靠性网络解决方案可靠性

2010-12-28 20:16:24

2011-04-18 14:05:15

可靠性系统测试嵌入式系统

2009-04-08 10:23:00

软交换网络可靠

2010-12-28 20:14:53

2013-11-04 17:05:37

银行容错

2010-12-28 19:50:21

可靠性产品可靠性

2010-07-28 18:58:54

东海证券负载均衡Array Netwo

2021-10-29 16:55:47

远程网络网络管理网络连接

2011-03-09 11:10:35

数据泄漏DLP

2010-10-09 10:06:39

UPS

2019-08-30 12:10:05

磁盘数据可靠性RAID

2020-12-06 14:51:23

物联网可靠性IOT

2010-12-28 19:55:20

软件架构可靠性

2023-06-27 17:50:22

2022-07-29 15:46:19

测试混沌工程

2011-05-25 19:31:07

Stratus信息化

2011-12-23 10:03:19

思科网络可靠性
点赞
收藏

51CTO技术栈公众号