完整验证NFV的性能

思博伦通信

思博伦技术专栏

完整验证NFV的性能

思博伦通信

编者按：网络功能虚拟化（NFV）可以提供许多优势，包括帮助网络和数据中心运营商实现潜在的成本缩减，以及通过敏捷性来发现实现更高营收的机遇。然而，由于基础设施的设计中可以有多种方案，因此这种敏捷性潜力也会在性能、可靠性和安全性方面产生更多的不确定性。在一个软件定义的云栈中，运营商要想实现NFV的成功部署，跨越所有边界的全局性和连续性验证必不可少。思博伦通信的《完整验证NFV的性能》一文对思博伦NFV解决方案进行了详细研究和介绍。思博伦NFV解决方案可验证所有的云栈层和待测NFV组件，并且可以通过隔离的方式精确查找问题的根源；可以帮助厂商和运营商提高其产品和服务的质量，并且在设计和集成过程中做出更明智的决策。由于需要测试的排列组合数量巨大，验证过程的自动化已成为必然的选择。只有利用协调被测组件和测试仿真接口的能力，才有可能在NFV环境中实现完整的自动化。

1 引言

网络功能虚拟化（NFV）可以提供许多优势，包括帮助网络和数据中心运营商实现潜在的成本缩减，以及通过敏捷性来发现实现更高营收的机遇。然而，由于基础设施的设计中可以有多种方案，因此这种敏捷性潜力也会在性能、可靠性和安全性方面产生更多的不确定性。在一个软件定义的云栈中，运营商要想实现NFV的成功部署，跨越所有边界的全局性和连续性验证必不可少。

2 简介

NFV可通过虚拟化计算基础设施提供网络功能。这些网络功能，在过去只能使用专用的硬件联网解决方案才能实现。在NFV拓扑结构中，部分或所有采用电缆连接的物理网络组件，均被虚拟计算基础设施中的虚拟机替代。在NFV术语中，提供每种功能服务的虚拟机便被称为虚拟化网络功能（VNF）。VNF被部署在一个商用或开源监视程序中，虚拟交换机来实现互联。这些虚拟网络设备也可以是开源或商用产品，并采用集成到商用市售（COTS）计算/服务器硬件中的物理网络适配器来实现互联。

路由、安全性和负载均衡等其它网络功能，都可以使用单虚拟机或多虚拟机服务链式拓扑结构中的虚拟机来实施。通用计算硬件与NFV软件结合在一起后，能够有效地降低成本，并且利用高密度网络适配器来扩大多核心处理器的规模，从而降低专用联网硬件的资本支出。由于NFV所承诺的敏捷性和灵活性，数据中心和网络运营商都有采用NFV的意愿。通过采用自动化来协调云环境中不同租户（客户）或系统（应用/服务）不同的网络拓扑结构，还有可能缩减更多的运营成本。

图1 虚拟和物理VNF互联

3 验证NFV环境

业界通常认为NFV可以应用于一系列的数据中心和传输网络互联。服务商和数据中心运营商可以使用NFV，以更大的深度和广度来验证各类服务。还可以对网络基础设施进行重新配置，利用融合了各类租户网络功能不同组合的NFV服务链，来满足弹性的随需式使用案例。数据中心、网络运营商和云供应商都可以使用NFV，来解决各类尖锐的云基础设施多租用问题，例如随需式数据中心互联、租户隔离/安全风险以及吵闹邻居造成的性能恶化。

图1显示的是服务链中VNF之间的互联，其中环形是下层虚拟设备的简略表示。VNF至物理网络接口卡（NIC）的连接被描绘会橙色，而且既可以类似于以蓝色显示的VNF之间的连接，也可以是一种允许VNF直接访问物理以太网接口的特殊接口类型。这种直接访问通常便于在包含虚拟设备的物理网络接口与VNF之间实现更高的包转发性能。这种直接访问所采用的技术包含PCI吞吐量（（IntelVT-d或AMD-Vi）和单个根I/O虚拟化及共享（SR-IOV）等技术，而且必须得到下层硬件（计算平台、网卡）和监视程序软件的支持。

图2取自OpenStack云管理员指南，在一个潜在的虚拟拓扑结构中描绘出了图上部的虚拟机（或潜在的VNF）之间的接口，以及图下部的物理以太网接口。实现虚拟机互联的替代方法还有很多。这些方法在很大程度上取决于所用的监视程序，并且可能采用监视程序固有的原生方法，也可以使用共享式设备（如Linux桥）或使用软件定义的联网（SDN）开源，例如Open vSwitch（OVS）或商用虚拟交换解决方案。图2显示的是在一个OpenStack上下文环境中使用OVS，其中VLAN封装用于在物理交换层进行分配。OVS可用于一个SDN设置中，通过明确控制转发表的内容，来对虚拟交换层进行动态控制。然而，它也可以用于静态环境中，而在此类环境中，虚拟交换机的运行方式类似于包含L2桥接域、MAC地址学习和VLAN标签等特性的物理交换机。在后一种场景中，OVS可充当一个标准Linux桥，但可以提供更多选择的优势（如可更方便地建立用于监视的端口映射）和可配置性。

图2中显示的虚拟设备详情已经超出了本文所讨论的内容范围。然而，采用该图的重点在于，突显该场景中虚拟机与物理网络接口之间的9个接口或边界。在读者看来，所有这些软件层所产生的影响都是再明显不过了－该场景中的包转发性能无法与高速以太网接口（10/40G以太网）上专门为处理小包尺寸下线速负载的物理网络相提并论。服务器计算的大趋势正在不断演化，而且随着Intel和AMD等计算厂商所提供的虚拟至物理接口技术不断进步，虚拟交换效率低下的问题正在所到改善。根据部署场景的不同，图2中的虚拟设备层也可以浓缩为一个Linux桥。

图2 一台虚拟机/监视程序中的客户操作系统与主机操作系统中共享式物理网络接口卡之间的各种Linux虚拟网络设备（资料来源：OpenStack云管理员指南）

4 NFV存在不确定性

尽管NFV可以为网络和数据中心运营商带来诸多好处，但在选择技术、配置基础设施、优化性能和强化性能方面，仍然存在诸多的不确定性。NFV的灵活性优势也会增加必须考虑的排列组合的数量，而且这种增加往往会以指数方式大量呈现。那些发布基于专有硬件联网产品的厂商，完全有能力将解决方案的数量限定在有限的使用案例上，并且可以对嵌入软件与运营商硬件组件之间的互动加以优化。在过去，验证核心功能的重任往往要由网络厂商来承担。今天的NFV大趋势正在将这种负担转移到部署NFV拓扑结构的运营商肩上，而网络厂商仍然需要承担在不同硬件（计算平台、物理交换层）和软件基础设施（监视程序、全局云栈、公共云等）中验证NFV软件的职责。

思博伦在COTS计算及NFV软件经验测试方面的成功经验表明，性能的巨大差异在所难免，而且取决于多个关键的变量，其中包括：

●分配给为VNF服务的虚拟机的计算资源，但分配得越多，并不一定就能转换为更高的性能。

●物理联网环境和虚拟网络组件（虚拟基础设施）之间的接口配置。

●连接VNF的虚拟联网替代技术的选择。

由于需要评估联网能力时否能在不同的云栈环境中正常工作，因此验证的任务已经超出了性能测试的范畴，而变得更为复杂。

云基础设施验证方面的挑战：

由于NFV通过一个包含众多硬件和软件层的云栈来提供，因此它会带来形形色色的多种验证挑战。典型的云栈如图3所示，其中的硬件组件以暗蓝色表示，而虚拟/应用软件组件以亮蓝色表示。根据部署场景和所用具体技术的不同，可能会有很大的不同，而且不一定会包含所以描绘出的组件。例如，为多个租户提供汇聚路由的运营商NFV使用案例可能不包含应用/db、客户操作系统存储虚拟化或NAS/SAN存储组件。但数据中心运营商的NFV使用案例则可能包含所有已描绘出的组件。

图3 NFV部署的云基础设施

在监视程序中会使用VNF来提供网络虚拟化。这些虚拟机将拥有分配到的计算和虚拟机镜像存储资源，并且可以通过驻留在中间件层中的OpenStack NovaCompute等云管理软件实现动态协调。其中，一部分VNF还可以具备SDN接口，例如使用OpenFlow协议来动态控制OVS实例的转发表。在本案例中，OpenFlow控制器还可以驻留在中间件层中。

VNF可以在应用/服务层之前的服务链中组合在一起，在云数据中心使用案例中提供安全性和负载均衡。除非应用/服务负载在计算结点上本地化，VNF将可以通过服务器网卡连接至外部物理交换结构，并且常常会使用VLAN或VXLAN形式的封闭，起到在物理结构上加快流量隔离和转发的作用。在大数据/数据分析等数据中心使用案例中，外部存储通常会被用于直连存储（DAS）之上，并且拥有自己的物理联网结构，尤其是用于光纤通道（FC）等块技术中。VNF不太可能使用外部存储，但其流量可能使用相同的网卡/融合有物理结构的以太网通道，因此必须在验证NFV部署的整个云栈环境时将其考虑在内。要想让验证解决方案能够跨越图3所示的所有边界进行测试，其测试解决方案必须具备物理和虚拟双重属性，并且在基础设施的内部和外部均拥有测试接口。云栈组件必须能够通过多维度仿真实现隔离，从而精确地找出功能和性能问题。另外，在执行系统测试时必须能够同时对多个层进行验证，找出复杂问题相互依存的根源所在。在验证驻留在VNF中并与物理交换结构相互作用的转发和IP服务时，需要用到L2/3主机和路由器仿真。存储和应用协议仿真能够在验证负载均衡和安全功能等有状态第4～7层VNF时发挥至关重要的作用。此外，还需要对NFV基础设施所服务的终端服务/应用进行验证。由于灵活性的缘故，NFV会增加必须执行的测试排列组合数量，而且远大于传统的专用硬件联网拓扑结构，因此如果在测试/仿真和协调层不具备自动化，则仅使用手动方法时根本不可能提供充分的测试覆盖能力。协调层的自动化使被测的云栈/NFV基础设施能够在被修改后，在开发和集成检查点期间连续运行大量必需的测试案例。

5 思博伦的NFV验证解决方案

（1）跨边界的NFV验证

在过去的20年中，思博伦所确立的一项关键核心竞争力就是，构建专用的硬件（基于FPGA），并使之能够在高速以太网测试接口上以线速实现第2/3层流量生成和分析。这样便可以对所有关键的第2/3层流量属性施加决定性的精确控制，其中包括帧尺寸、封装、主机仿真规模（数以百万计的MAC/IP地址）和负载。利用这些生成引擎，可以仿真出真实的IP多样性，并且可以与同样高性能的分析器引擎结合在一起，实现对每个流的高级跟踪和统计分析。SpirentTestCenter平台是一种统一架构，能够以不同规格的机箱和共享式测试模块，提供此项能力，并且长期用于测试专用的路由/交换网络设备。同时，这些解决方案也可以用于验证NFV基础设施。

图4显示的是SpirentTestCenter第2/3层测试模块如何用于测试一个映射到4个网卡接口上的简单的虚拟路由VNF。这种形式的测试使我们能够对容纳NFV的虚拟基础设施管道空间加以定性。通过在下层管道中暴露各种瓶颈，可以找出计算平台中——从服务器物理网卡，到被测VNF和跨越虚拟/物理边界的物理网卡——所具备端对端最大包转发/处理性能。这种形式测试的优势是，能够以确定性的方式测量入向（流来源）端口的负载，以及出向（流出口）端口的接收负载。单向（与往返相对应）包在时间上的时延、时延分布和时延变化，都可以得到精确的测量，且精度分辨率可达10纳秒，因此可以将NFV包转发性能与专用交换机/路由器硬件解决方案进行细致的对比。我们可以使用事实上的RFC标准方法，在不同的场景中对整个被测计算环境执行基准测试。这些场景包括：

●网卡至PCI-E插槽安装，并考虑PCI-E通道宽度和与CPU的互联。

●使用双向流量可对多端口网卡进行评估。

●不同包尺寸下的端口对、部分网格和全网格流量模式。

●分配给VNF的计算资源（逻辑CPU核心和内存），包括巨形页面等内存后备方案。

两坝肩测点水来源主要有两点，即库内入渗、山体渗水。库内入渗包括坝体渗水、坝体与山体接触渗水及绕坝渗水。山体渗水主要是岩体裂隙发育，降水入渗等形成的岩体内地下水发育。孔内水位高低受库水位影响小于降水影响，测点与库水位相关性等分析应剔除降水因素影响。本项目数据采取7月20日后汛期结束、库水位相对稳定的时段分析，工程所在地洪水以融雪性洪水为主降水稀少，其他类似项目的相关性分析应将降水纳入影响因子。

●至VNF的不同磁盘/存储映射（如果VNF需要从存储频繁读/写的话）。

●在启用输入/输出内存管理单元（IOMMU）时使用IntelVT-d的PCI吞吐量支持。

在许多情况下，由于所部署NFV拓扑结构的问题，或者是因为无出向物理网络接口映射的VNF至VNF互连的验证需求，使用第2/3层流量的端对端NFV验证并不适用。这一点在图5中有明确的显示。在这种情况下，被测的是相同的VNF虚拟路由器。然而，虚拟路由器在部署时右侧连接了额外的虚拟机，并连接至主机应用/服务层。蓝色圈表示虚拟机至虚拟机的互连，可以是共享的Linux或OVS桥接，而它们最终将会连接至应用/服务层。

图4 利用SpirentTestCenter第2/3层流量生成/分析技术实现的端对端验证

该拓扑结构使虚拟路由器能够以隔离的方式，跨越物理和虚拟设备（桥接）的边界获得验证。测试流量将从连接至物理网卡的物理SpirentTestCenter测试端口通过，并传至连接至共享桥接的虚拟思博伦测试端口。这样就引出了验证NFV过程中另外一个关键的思博伦解决方案组件—虚拟测试端口。思博伦可提供与虚拟机相同形式的生成/分析引擎。测试流量可以从物理至虚拟端口生成并获得分析，使NFV/虚拟基础设施能够以由外而内和由内而外的方式接受测试。

思博伦的物理和虚拟测试接口在特性集方面拥有接近的奇偶校验特性，唯一的主要区别就是包时延测量的分辨率有所下降。

图5 使用思博伦物理和虚拟测试端口的跨越虚拟桥接物理至虚拟验证

（2）多维度自动化

要确定主机计算环境的2/3层包转发性能，将上面章节中简要描述的虚拟设备和第3层VNF互联在一起至关重要，因为虚拟交换基础设施仍然缺乏专用路由器/交换机硬件设备所具备的性能，而且其在多种条件下的包丢失和时延也更加严重。但NFV验证需要仿真多种不同的控制层协议，并且使用多种拓扑结构下的4～7层应用协议。实现所有这些维度自动化的能力非常关键，因为不断变化的监视程序或虚拟交换参数可能急剧改变NFV的性能剖面。供应或协调下层NFV/虚拟基础设施的能力也非常有必要，因为如果不能以程序方式控制该维度，完整的自动化将无法实现。图6展示了另外一个需要4～7层应用流量生成的NFV拓扑结构。有状态防火墙等安全设备和负载均衡器等其它应用感知设备不会传送3层流量，因此需要真正的应用负载来对其加以验证。如图6所示，NFV服务链（连网VNF的序列）通常会包含这些类型的功能。在过去超过十年的时间里，思博伦一直在开发Avalanche平台，一种先进的应用协议仿真解决方案。该解决方案可以每秒同时生成数百万个有状态（TCP）连接或仿真用户。针对高性能场景，思博伦已经将Avalanche打包为一种基于硬件的设备形态，同时也提供所图6左侧所示的虚拟机形态。

有状态NFV服务链应当使用Avalanche平台进行基准测试，利用连接容量测试确定其用户扩展能力，测量出应用会话事务发生过程中，服务链可以保持的开放或并发连接总数。在验证的过程中，NFV服务链处理应用事务连接的速率至关重要，因为许多使用案例中都存在连接速率突然变化的终端用户流量，例如所有用户在上午同时登录，或发生新闻事件时用户发起的Web搜索风暴等。峰值测试案例可用于测量NFV服务链每秒可处理的最大连接/事务速率。

利用图6中的思博伦Avalanche，可以对NFV服务链（防火墙、负载均衡器和VNF互连）和终端应用/服务一起作为一个系统来验证。Avalanche可以仿真客户端及其在Web（HTTP）、文件、即时消息、流视频、存储和其它多种协议上的应用事务。Avalanche平台还包含高性能的应用服务器仿真，可在不使用真实应用服务器虚拟机（将图6中的右侧用Reflector实例替代）的情况下实现NFV服务链的隔离。

图6还显示了思博伦虚拟部署管理器如何协调或供应被测的NFV基础设施（NVFVNF或其它虚拟机）和思博伦虚拟测试接口（思博伦Avalanchevirtual或STCvirtual实例）。这样就为思博伦测试端口（物理或虚拟）支持的其它仿真维度添加了协调维度，实现了完整的自动化解决方案。利用基准测试案例实现的NFV服务链自动化安置，可以实现NFV基础设施最优化配置的融合。

图6 思博伦虚拟部署管理器可协调思博伦的测试虚拟机和被测NFV基础设施

图7 数据库复制使用案例的拓扑结构图示

图7显示的是思博伦测试接口如何在路由和SDN维度中实现控制层仿真能力，以便对更复杂的NFV拓扑结构加以验证。SpirentTestCenter虚拟接口（顶上）可以仿真SDN维度中的OpenFlow控制器，在数据库虚拟机互连池中，对带虚拟路由器VNF的的Open vSwitch（OVS）桥接的转发表实施控制。数据库复制可能以vRouterVNF的方式，发生在池中或不同的数据中心之间。商业逻辑将会控制哪些数据库实例处于活动状态，以及复制事件在实际部署过程中的何时发生。通过使用所描绘的测试拓扑结构，DevOps工程师可以认真考虑其商业逻辑是否适用。另外一个Spirent TestCenter虚拟接口（左侧）可用于仿真路由器，并将路由注入vRouterVNF。还有一个接口（底部）则可用于发送指向已公告路由的流量。此外，还可以评价vRouterVNF的控制层扩展能力，并对OVS/vRouter组合的第3层吞吐量执行基准测试。

图8再次显示了在图3中呈现过的云栈图，但也叠加了思博伦丰富产品组合所支持的所有数据层、控制层、协调层和攻击层维度。数据层仿真还扩展到了应用、存储和2/3层流量生成及分析能力上，并且以蓝色高亮显示。思博伦可以仿真控制层协议，包括SDN/ Openflow、路由，以及利用虚拟机迁移等监视程序事件，在基础设施上添加额外压力的能力。

图8 思博伦的多维度自动化，展示思博伦如何仿真所有必要的维度，对云栈中的NFV/虚拟基础设施执行全局性的验证

思博伦虚拟部署管理器可用于控制协调层，将NFVVNF和思博伦虚拟测试接口都融入NFV拓扑结构中。最后，Avalanche平台（虚拟/物理）还可用于控制攻击层，以及存储/应用协议。攻击层包含发起分布式拒绝服务（DDoS）攻击的能力，而这种攻击可能对网络基础设施和Web服务产生干扰。客户侧漏洞和恶意软件也可与合法流量一同注入，对防火墙、入侵阻止系统（IPS）和其它网络层安全设备的安全效能加以验证。这些威胁也可以瞄准以NFV基础设施为前端的应用和服务，使之得到强化并具备抵御跨站点脚本或SQL注入攻击等应用层漏洞的能力。

6 结束语

思博伦的NFV解决方案可验证所有的云栈层和待测NFV组件，并且可以通过隔离的方式精确查找问题的根源。它可以帮助厂商和运营商提高其产品和服务的质量，并且在设计和集成过程中做出更明智的决策。由于需要测试的排列组合数量巨大，验证过程的自动化已成为必然的选择。只有利用协调被测组件和测试仿真接口的能力，才有可能在NFV环境中实现完整的自动化。