CM板卡测试交换机路由器的应用层拥塞性能.pdfVIP

CM 板卡测试交换机/路由器的应用层拥塞性能测试 周启玄 互联网技术的高速发展及人们对信息处理的迅猛需求加速了数据中心在各个行业的部署与应 用，数据中心这种集中式的应用便利了数据的存储与共享、增强和整合业务系统的应用、网络安 全管理、数据容灾与备份等。但在部署数据中心解决方案时，有一个重要的问题不容忽视——拥 塞控制：用户的随机访问性使得某一条链路或某一路服务产生拥塞，拥塞的结果就会使得业务应 用变慢，甚至失败。 数据中心及拥塞机制分析 数据中心应用的典型特征就是业务应用的汇聚与集中，利用高性能的交换机/路由器构建数据 转发与交换核心及接入网络，连接起终端用户和业务应用系统。数据中心部署中，应用系统处理 能力可以预计且加以增强，数据通信及交换系统也可以扩充以增加更多的带宽，但是仍然无法避 免多路用户访问而造成网络拥塞，这种拥塞是随机的且不可避免：一些用户可能通过交换机的在 下载文件，另外一些用户也可能通过同样的端口在进行数据计算，当需求的带宽超过端口的转发 能力时，拥塞就会产生。 数据中心分层模型（图 1） 当拥塞产生时，用户的直接感受就是业务应用或资源访问变慢，甚至失败；从传输层 TCP/UDP 来看则就是报文延时、重传甚至丢失；而在 MAC 链路层，数据包因为拥塞就会被缓存、排队， 也可能因为队列满而被丢弃。因此，由于拥塞不能避免，对于交换机的缓存管理及拥塞处理能力 要求相当重要，它能使拥塞发生时，对业务及用户的影响风险减到最小。 交换机/路由器拥塞分析 交换机/路由器端口间的链路通常都能达到线速，常规的 L2/L3 测试已经覆盖了这些项目，但 如果访问存在多对一的情况如，12 个 GE 端口的入口流量流向 1 个 10GE 出端口，出口会发生拥 塞，在 L2/L3 的测试表现上，出口带宽还是在 10G 的速率上；但在应用层的表现上，应层业务的 有效带宽肯定会明显降低。当 DUT 因为拥塞发生丢包时，应用层业务如 TCP 就会存在等待、延 时及重传等相关的数据保护措施，这些重传及等待不仅造成有效带宽降低，产生了大量的无效带 宽，而且使得 L2/L3 的转发能力降低，浪费了链路的带宽。而且，拥塞越严重，有效带宽降低越 明显。 拥塞产生场景（图 2 ） 目前的交换机/路由器设备，基本上是属于存储转发方式（Store and Forwarding/LIFO ），报文 进入设备后，从一个芯片的缓存转发到其它芯片上的缓存（如果基于 NP/CPU 转发，就会多了一 层 CPU 的队列转发) ，再从缓存中进入转发队列，并从目的地端口上转发出去；缓存的分配包括 配置到端口的缓存及公共缓存。设备缓存的大小及队列调度能力会体现在对于拥塞的处理能力上。 这种能力不仅仅表现在拥塞的处理上，而且报文在缓存中的排队效率也会影响应用层的性能。通 过增加缓存当然可以减小拥塞时处理能力，但这方面会增加硬件成本，另外，过多地缓存会增加 报文转发的时延，从而也会影响应用层的性能。还有缓存及漏斗的粒度控制也会对不同帧长度的 报文转发存在不同的影响。缓存的分配与队列管理要基于效率与公平的原则，既要保证端口拥塞 处理的性能需要，也要保证严重拥塞产生时，不相关的端口被阻塞甚至得不到调度而饿死。 拥塞处理能力评估 如何评估测试设备的拥塞处理能力及队列调度能力？传统的测试方法包括 RFC2544 的 Back-to-Back ，还有RFC2889 的Congestion Control Test，但这些传统的L2/L3 测试手段，首先只 能是局部地测试设备的几个端口，另外测试结果也只是一个量值，无法将其跟真实的业务表现关 联起来，而且难以与同类产品进行比较； 在数据中心的实际应用中，最重要的是用户体验，也就是用户的真实感受。传统的测试情况 下，设备测试结果的是一个测试很好的指标，而到用户真实应用时，可能会是一个糟糕的情景。 因此改正测试方法，直接采用真实的业务进行测试，尽量接近的用户行为和体验，让测试实变得 更加真实，是一个发展方向。通过真实 FTP/Http L4 －L7 层业务，根据测试的最终有效带宽就可 以得出设备在真实应用中的转发性能情况，所见即所得。事实上，目前在数据中心的验收或选型