标签：虚拟交换 除了 frame 框架 比特 注意 model 实现 操作
摘要—随着NFV在电信领域的推广势头强劲，需要支持VNF的自动化和高性能部署的方法来支持大规模部署。 本文提出了一个框架，该框架可以实现VNF的自动表征（特征显示）以及对资源类型，数量和已实现的性能之间的关系进行建模。 提出了工作负载表征方法，以在部署时识别要分配给VNF的最合适的资源类型。 使用机器学习建模来识别满足所需性能目标（例如网络吞吐量）的适当部署配置。 所提出的框架已基于OpenStack云环境中流量分类器VNF部署的优化进行了实验验证。
网络功能虚拟化（NFV）范式的出现吸引了电信领域的极大兴趣，并有望实现网络转型。这种发展是基于将网络功能从专有的固定设备方法转移到在标准大容量服务器上运行的虚拟化软件设备的。但是，以高性能方式交付此转换会带来许多重大挑战[1]。通过传统的固定设备方法，应用程序软件与其支持的硬件基础结构紧密耦合。这种紧密耦合为电信级网络功能提供了可预测的性能和可靠性。在NFV方法中，虚拟化网络功能（VNF）通常部署在运行于OpenStack等云计算环境中的主机虚拟机（VM）上。这些环境抽象了基础架构，并且支持智能布局决策的功能有限。智能放置决策可以描述为将最佳数量和类型的资源分配给最合适的物理节点上的VNF的放置决策。该决策还应考虑目标平台的动态行为，以确保工作负载的可量化性能和可预测行为。尽管虚拟化为企业IT带来了许多好处，例如工作负载合并，资源利用率提高等，但为VNF型工作负载实现这些好处却带来了新的挑战[2]。与裸机部署相比，虚拟化可能会导致性能下降。诸如英特尔?虚拟化技术（例如VT-x，VT-c和VT-d）之类的创新技术已被开发出来，以弥补与原来实现之间的差距[3]。为了提高VNF性能，还出现了软件和硬件数据包加速技术，例如英特尔的数据平面开发套件（DPDK）和单路输入/输出虚拟化（SR-IOV）[4，5]。例如，DPDK是一个软件库，它直接在用户空间中支持加速的数据包处理，并利用某些网络接口卡（NIC）中可用的硬件功能。 SR-IOV是PCI-SIG组织发布的标准规范，它允许外围组件互连快速（PCIe）设备（包括NIC）看起来像是多个分离的物理设备。 VM托管与网络相关的工作负载的主要优势是能够使用PCI直通功能直接访问SR-IOV网络设备，并为其网络流量分配了专用的物理通道，而无需依赖主机的驱动程序功能操作系统[6]。但是，虚拟资源和数据包加速技术的适当组成，配置和优化对于实现高性能部署至关重要。为了使NFV在实际应用中适当扩展，需要自动部署。从这个角度来看，需要在业务流程级别上适当考虑云环境中的性能优化，拓扑，弹性等注意事项[7]。 VNF和网络服务性能等部署目标对于电信环境中的编排变得越来越重要[8]。当前的方法是基于对承载VNF工作负载的节点使用预先配置的配置，然后简单地请求实例化该配置以使VNF投入服务[9]。该方法具有局限性，并且不一定使特定工作负载（例如，数据平面，控制平面，信号处理等）的特征与资源的优化分配（例如，分组加速技术）相匹配。随着云数据中心（DC）与由不同功能和提供不同硬件加速功能的附加设备（即PCIe）组成的各种计算资源的异构化变得越来越异构，这一挑战就大大增加了。在部署时做出自动分配决策，可以使VNF性能要求与动态资源环境保持一致，这也大大增加了VNF编排的复杂性。但是，在布局决策中增加更多的智能对于确保以良好的方式部署VNF且不受分配的资源类型或数量的不利影响至关重要。文献中已经报道了许多VNF / VM调度/编排策略的方法[9]，但是它们通常采用较高的层次来查看VM在网络功能虚拟化基础架构（NFVI）中的位置，以实现特定的目标，例如最大限度地减少内部-数据中心流量[10]。但是，这些方法不一定能解决资源到单个VNF工作负载的特征和需求的特定映射。 本文提出了一种可能的方法，该方法基于对部署时分配给VNF的资源的数量和类型的识别，从而解决了这一难题。 通过生成一个表示与特定性能级别相关的资源分配的模型，可以生成规则，Orchestrator可以使用这些规则在OpenStack等云环境中向VNF部署请求添加智能。
第一代VNF通常基于从网络功能的固定设备版本到虚拟化形式的软件移植。除了虚拟环境中资源分配的标准抽象视图（即虚拟CPU，RAM和存储的分配）以外，对于用于托管VNF的商用硬件环境的特性的关注很少。这种方法可能会导致性能下降，这是由于NFV提供的灵活性而使服务提供商愿意接受的。但是，随着NFV的扩散不断增长，VNF的性能将变得越来越重要，并期望它们将达到固定设备的性能水平，尤其是对于网络边缘功能（例如客户驻地防火墙，WAN加速器等）。将VNF工作负载的特性和性能与其托管基础结构相匹配，将在提高其性能和服务水平协议（SLA）保证方面发挥重要作用。但是，将VNF耦合到特定资源类型不能以失去虚拟化部署提供的灵活性为代价。
在最新版本的OpenStack [11]中已经出现了增强平台意识（EPA），作为一种解决与资源抽象有关的问题的机制，该问题可能会对某些VNF工作负载类型的性能产生负面影响。 这些工作负载可以从对某些平台功能的访问中受益，以提高其性能或提高其行为的可预测性和稳定性。 例如，具有密码相关功能的工作负载可以受益于在具有高级加密标准新指令（AES-NI）指令的CPU上进行调度，从而提高加密和解密任务的速度。 随着EPA在电信云环境中的发展，随着资源格局的丰富性和粒度的提高，它将带来巨大的好处。 这将有助于弥合资源抽象和VNF的平台特定要求之间的当前差距。
为了满足客户要求，服务提供商需要提供准确而可靠的性能指示，这些指示通常封装在SLA中。这些SLA包括与绩效预期各个方面有关的目标。为了避免与违反SLA的行为相关的惩罚，提供商通常会过度提供资源。这种方法通常会浪费宝贵的资源。其次，它没有考虑可用技术的性能特征，也没有以智能和最佳的方式将它们与性能目标相匹配。
因此，存在与匹配可通过EPA发现的平台资源的性能特征以满足SLA中定义的VNF的性能目标相关的明显问题。此外，任何给定资源的特定数量也应与期望的性能相匹配（例如，要分配给工作负载的虚拟CPU的数量或要使用的SR-IOV网络连接的数量，等等）。最后，任何解决方案都必须以自动化方式实施，以支持VNF部署流程的智能编排。
对于任何VNF类型的工作负载，从部署角度出发，详细了解性能特征和对物理资源的亲和力很重要，这样才能最大程度地提高性能并优化分配的资源数量。优化还可以通过优化资源分配来降低部署的财务成本（即减少资源的过度分配，或者不分配对部署的VNF工作负载的性能没有重大影响的更昂贵的资源）。有必要对VNF的关联性进行建模，以用于计算资源分配和平台特定功能。为了适当地映射这些相似性，需要部署各种计算资源分配案例，并使用嵌入式遥测以统计学上有意义的方式量化VNF的性能。即使对于在资源分配范围方面受约束的边界条件的相对简单的VNF，最初也需要数十或数百个不同的配置，这些配置可以快速增长到成千上万的部署，以确保数据的健壮性。手动部署数千种潜在的VM风味组合是不切实际且昂贵的。 因此，出于这项工作的目的，开发了一个框架，该框架可以自动化部署过程。该框架具有两个不同的功能：第一个功能是定量地使用不同的资源分配来表征VNF工作负载性能；第二个模型是模拟VNF性能与资源分配之间的关系。
开发的框架（请参见图1）基于Python实现，该实现会自动为给定的待测试VNF生成不同的部署配置。 模板代表给定值范围内选定参数的所有可能配置（例如vNIC配置，虚拟CPU数量，RAM数量等）。 该框架与OpenStack云环境进行交互，并以Heat模板的形式生成不同的配置，这些模板是基于Heat Orchestration模板格式的部署脚本[12]。 然后按顺序部署模板，并收集和分析每个部署中的数据，以评估给定部署配置对VNF性能的影响。 关键步骤如下：
1.每个模板都是通过OpenStack部署的（即Heat服务），该模板创建VM，安装VNF软件和遥测代理以1 Hz采样间隔测量内部指标。 遥测代理和支持后端的详细信息以前已有报道[13]。 2.部署阶段结束后，框架将启动数据包生成器，将网络流量发送到VNF；
3.流量由VNF处理，并转发到测试点目的地以进行性能评估； 4.在预定义的时间间隔后，将停止数据包生成器，并将实验过程中收集的所有数据保存到Hadoop数据库中。 5.删除已部署的测试用例，并重新初始化测试环境以准备下一个测试用例。
6.对每个模板重复步骤1-5。
然后使用机器学习方法分析收集的数据，以识别分配的资源的类型和数量与VNF性能之间的关系。 生成决策树，该决策树将特定的性能特征（例如网络吞吐量）与部署配置相关联。 第六节介绍了决策树的示例。 决策树将在服务提供商进行业务部署之前针对新的VNF进行验收测试期间生成。 然后可以对决策树进行编码，以供Orchestrator使用，以在自动化部署期间优化特定资源的分配。 最后，EPA用于识别具有必要资源的主机的位置。
使用的流量分类器（TC）VNF由两个虚拟网络功能组件（VNFC）组成，即流量检查引擎和分类转发功能。这两个VNFC在各自的VM中实现。流量分类器基于深度数据包检查（DPI）方法，该方法用于分析来自流的少量初始数据包以识别流类型。在流识别步骤之后，不再检查其他数据包。流量分类器遵循基于分组的每个流状态（PBFS），以便跟踪相应的流[14]。流可以定义为从一个应用程序发送到接收应用程序的一系列数据包。 PBFS方法使用一个表来根据为每个流维护的5元组（源地址，目标地址，源端口，目标端口和传输协议）来跟踪每个会话。由于一个应用程序流通常由多个数据包组成，因此一旦最初接收到的数据包已被标记为属于该应用程序，流中的所有后续数据包都将被类似地标记。 TC使用数据包头中的“服务类型”（TOS）字段来标识流类型。
两个VNFC可以彼此独立运行，但是为了使VNF具有预期的行为和结果，要求2个VNFC并行运行。
流量检查VNFC是VNF中处理最密集的组件。它实现了过滤和数据包匹配算法，以支持VNF的流量转发功能。该组件支持流表（利用散列算法来对流进行快速索引）和检查引擎以进行流量分类。用于这些实验的实现利用了nDPI库[15]。数据包捕获机制是使用libpcap实现的。该组件不会阻止未标识的流量，因为流量已镜像到两个VNFC。当DPI引擎识别到新的流时，将使用适当的信息更新流寄存器，并将其传送到流量转发VNFC，然后该流量转发将应用所有必需的策略更新。流量转发VNFC负责路由和数据包转发。它接受传入的网络流量，在流表中查询每个传入流的分类信息，然后应用预定义的策略（例如，服务类型/区分服务代码点（TOS / DSCP）标记），以将其应用于支持QoS的多媒体流量[ 16]）上的转发流量。假定使用默认策略转发流量，直到识别出该流量并强制执行新策略为止。预期的响应延迟可以忽略不计，因为仅需少量的数据包即可实现识别。在VNFC未部署在同一计算节点上的情况下，流量镜像可能会带来额外的开销。
TC VNF的预期性能取决于以下有关流量配置文件的因素，即（i）流量数量； （ii）持续时间； （iii）有状态协议匹配与静态端口。在这种情况下，由高流量和短命流组成的流量配置文件会消耗较高级别的计算资源（CPU和内存），以支持对新流进行分类。此外，影响VNF性能的其他因素仅取决于其配置和启用的功能。这些因素是：（i）与之匹配的协议数量，（ii）使用的正则表达式的数量，以及（iii）匹配算法的复杂性。在整个实验协议中，流量和VNF设置均采用相同的混合方式，以最大程度地减少上述因素的影响，这些因素可能会影响VNF的性能行为。这些实验中使用的流量配置文件基于NCSR“ Demokrito”网络中捕获的实际流量跟踪。总共捕获的流量包含利用28种不同应用协议的36726个唯一流。在实验过程中，使用能够达到10 Gbps线速的数据包生成器重播了数据包捕获（PCAP）文件。 PCAP文件中的数据包目标地址被重写并替换为多播目标地址。由于需要将网络流量镜像到两个VNFC，因此必须进行此修改。与在Open vSwitch级别（在计算节点上）执行流量镜像相比，此方法更为可取，因为它可能会引入额外的延迟并增加资源利用率，并且难以实现自动化。
图3中所示的实验配置的架构包括一个基于OpenStack Juno的云环境，其中包括：控制器（英特尔?酷睿?i7，@ 3.40GHz 32GB RAM），两个计算节点（双插槽英特尔?至强?E5 2680） v2 @ 2.80GHz，具有10个内核，64GB RAM）和流量生成器（Intel?Core?i7 @ 3.40GHz，32 GB RAM）通过10 Gbps交换机连接在同一网络域上。所有计算节点均使用英特尔?双以太网聚合网络适配器（X540-T2）。计算节点配置使托管VM可以使用以软件辅助网络解决方案的形式连接到开放式虚拟交换机的虚拟NIC（vNIC）和具有PCIe直通的物理NIC，并利用SR-IOV功能硬件辅助的解决方案。数据包生成器用于对被测VNF的性能进行压力测试。测试平台中的部署过程由工作负载特征和建模框架控制，这将在下一部分中进行描述。
工作负载特征和建模（WCM）框架可表征受测试的VNF工作负载。该框架的关键功能是通过不同的配置来衡量VNF的性能，并自动生成模型以支持在部署时自动选择最有效的配置。它以符合ETSI的虚拟网络功能描述符（VNFD）和一组配置参数范围作为输入，以调查不同的VNFC的配置。配置是作为参数和值列表（例如虚拟NIC的类型，vCPU的数量等）提供给框架的。配置文件还可以包含所需的网络性能：以每秒位数表示，表示VNF服务提供商要提供给其用户的目标比特率。例如，给定1 Gbps，5 Gbps和10 Gbps的网络吞吐量值，系统将创建一个模型来为这些性能目标中的每一个选择最有效的配置。该模型采用决策树的形式，其规则取决于作为框架输入提供的变量。
以下部分描述了应用框架的两个用例场景。
第一个用例场景侧重于OVS和SR-IOV网络连接之间的性能比较。该框架用于调查将OVS和SR-IOV网络连接分配给包含VNF的VNFC的效果。如图2所示，VNF具有5个网络连接，提供入口，出口和内部VNFC连接。为了进行比较，框架生成了两个Heat模板，反映了这两种配置，并且所生成的两个实例同时部署在两个不同的物理主机上。如图4所示，每个实例都有作为虚拟机实现的专用目标测试终结点（TP2和TP3），用于测量VNF能够转发的流量。第三端点目的地（TP1）通过拦截流量生成器发送的所有流量，充当网络吞吐量参考点。流量生成器[17]用于生成同时发送到VNF和TP1的多播流量。为了发送线性增长的流量配置文件（从1Mbps到9.6 Gbps），在运行时加快了流量速率。第六节讨论了获得的结果。
第二个测试案例研究了一种基于网络性能优化来支持VNF部署的方法。测试用例的主要目的是实现一个能够为VNF选择最小配置的自动化系统，该配置可以提供SLA中指定的所需性能水平。这涉及服务提供商希望通过使用不同的VNF版本向具有不同SLA的许多用户提供相同服务的情况。在这种情况下，味道的概念与OpenStack的VM味道明显不同。此处旨在定义VNF的所有组件的完整部署配置。除了vCPU，RAM和存储的必需分配之外，它还包括网络接口的配置，调度程序提示和实例化VM所需的其他元素。为了选择VNF风格，使用该框架进行了一组实验，以基于各种部署配置（SR-IOV分配和VM大小）收集和分析数据。选择了三个带宽SLA目标（400 Mbps，800 Mbps和3 Gbps）。使用C4.5机器学习算法对收集到的数据进行了分析[18]。具体来说，该框架调用WEKA机器学习平台的J48模块，该模块提供C4.5算法的实现并返回决策树作为其输出。该方法旨在根据客户的网络性能要求，支持自动构建VNF样式，选择可以满足所需SLA的最有效配置（就资源使用而言）。为了使性能优化与特定配置相关联，为每个配置定义并计算了效率函数，以比较它们并选择可以支持SLA的最有效配置。该函数的定义如下
对于每个样本：P是VNF的性能（出于用例的目的，吞吐量被专门解决）； N是分析考虑的变量数（在这种情况下为2，vCPU和RAM）； wi是服务提供商分配给每个资源的权重（所有wi的总和等于1）； ?Ri是在配置中分配的资源i的数量（对于具有较高值的资源（在这种情况下为RAM），这是最小/最大规格化的主题）。 Ri取决于分配的类型i的可用资源的数量。该数量在与具有最大可用资源数量的资源类型相关的值范围内进行标准化。例如，部署配置可以包括诸如处理器，内存等资源。例如，部署配置最多可以使用10个CPU和最大20 GB的内存。在此示例中，最小内存大小可能是1 GB。因此，20 GB的内存对应于20个内存资源，而10个CPU对应于10个处理器资源。因此，在此示例中，20是任何资源类型的最大资源数量。如果分配的CPU数量为5，而分配的内存量为5GB，则分配的CPU数量对应于可用CPU的50％（5/10 = 0.5），而分配的内存数量ununi对应于25 ％（5/20 = 0.25）;那么资源类型处理器的Ri为0.5 x 20 = 10，而资源类型存储器的Ri为0.25 x 20 = 5
# VI. RESULTS AND DISCUSSION
本节介绍与上一节中描述的测试用例场景有关的结果。
表征实验的结果如图5所示。在实验过程中，网络流量负载从1 Mbps线性增加到9.6 Gbps，持续时间约为200秒。 利用OVS的VNF部署表现出大约360 Mbps的网络饱和效应。 利用SRIOV的VNF部署比OVS表现出10倍的改进，饱和速率约为3.6 Gbps。 但是，结果还表明，转发VNFC实现的吞吐量与总流量负载之间存在显着差距。
VNF还会生成指标以监视其内部性能，VNF Manager（VNFM）通常使用这些指标在部署时管理VNF。 出于本测试用例的目的，已捕获了这些指标并将其集成到遥测平台中进行分析。 在图6中，显示了VNF每秒检测到的流量数。 VNF检测唯一流的能力受SR-IOV或OVS分配的影响很大，并且与图5所示的行为模式相对应。
为了探索不同的网络性能目标，研究了32种不同的配置，这些配置改变了SR-IOV和OVS与VNF的VNFC之间的网络连接类型。 使用该框架自动配置，测试和分析了测试场景，生成了所有可能的变量组合（5个vNIC，允许2个值）。 每个配置使用60秒的测试持续时间进行了3次测试。 使用J48算法[19]生成并分析了6000多个数据点，以生成决策树，如图7所示。
使用决策树生成的规则，可以自动选择VNF配置以实现给定的SLA。所提出的方法使用决策树来生成给定部署的需求配置。该算法通过导航叶子并选择与所需网络吞吐量相对应的叶子开始。简单地通过将树从所选叶遍历到根即可获得配置参数值的选择。例如，通过将SR-IOV分配给vNIC 4和vNIC 5，将OVS分配给其他接口，可以实现实现3 Gbps转发吞吐量的最小配置。对于给定的SLA返回多个配置的情况下，系统将根据第V节中定义的效率函数选择部署配置。通过这种方式，可以在避免过多资源分配的同时实现目标SLA。当框架使包括定义决策规则的决策树的生成在内的整个过程自动化时，只需要有限的用户干预即可。初始配置文件设置的设置是唯一的关键用户任务。对转发VNFC的各种形式进行了相同的实验，特别是更改了分配给VM的vCPU和RAM的数量。对于此实验配置，将SR-IOV通道静态分配给vNIC 1、4和5。分配给VM的vCPU数量在1和10之间变化，RAM分配在2 GB和8 GB之间，以1 GB为增量。此实验的可能配置总数为70。使用该框架在60秒的时间内对每种配置进行了3次测试。总共收集了14,000个数据点，这些数据点已用于WEKA中的模型生成。获得的结果并未表明对VM大小的任何特定依赖性，即VNFC不受CPU或内存的限制；因此，最小的VNF类型（1个vCPU，2 GB RAM）足以实现3 Gbps的流量吞吐量。当然，此结果特定于测试中的虚拟流量分类器和所使用的物理基础设施设置。 J48算法未返回任何决策树。
为了检查先前结果的有效性，生成并测量了基于大量资源分配的部署和基于框架的分配。 图8中显示了各个部署的端对端性能比较。两个部署所实现的网络吞吐量是相同的。 但是，在第二次部署中，结果是通过显着较小的资源分配来实现的，这为本文概述的方法提供了切实的支持。 本文描述的方法可以根据KPI目标进行推广。 在vTC用例中考虑了吞吐量，以演示开发的建模方法的应用。 如果需要，可以将该方法轻松扩展到其他VNF的不同KPI目标。
使用提供预先计划的部署配置的VNFD是当前行业中支持在云计算环境中自动部署VNF的方法。但是，从业务流程的角度来看，这是有局限性的，并且没有考虑到计算资源的未充分利用或特定资源类型的分配会降低工作负载性能。其次，随着NFV在网络服务提供商环境中的采用不断增长，必须维护数百或数千个模板，因此该方法将面临可扩展性挑战。为了解决此限制，已经研究了基于基础结构亲和性意识自动生成部署规则的潜力。通过在OVS和SR-IOV网络技术之间进行比较，已经证明了部署配置（即VNF风格）对性能的影响。另外，已经提出了一种自动选择最佳VNF风格的方法，并且已经设计和开发了一个框架来支持部署时的动态配置选择。业已表明，该方法可用于以自动化方式定义适当的部署规则，该规则可用于结合优化的网络相关性能和分配的资源的最小配置（即消耗最少的资源）来协调VNF的部署。例如SR-IOV通道数，vCPU数量，RAM数量等）。
如前所述，EPA的出现是为了支持在部署时将特定平台功能分配给承载VNF工作负载的VM，这可以使云环境中的VNF性能受益[20]。 EPA的贡献现在开始出现在OpenStack版本中，并且通过发现，跟踪和报告物理体系结构和外围设备中的增强功能而包括平台检测功能。此外，还具有使用已启用的功能将VM计划并部署到所选平台上的功能。通过允许在VNF部署期间适当安排部署规则中定义的请求资源类型，此功能将使协调器能够关闭循环。
计划进行其他工作以提高框架的功能并进一步扩展结果。从SLA的角度来看，迄今为止仅考虑了带宽。进一步的发展将包括更复杂的SLA的定义和自动评估，以考虑到抖动，等待时间数据包丢失等。从技术特性的角度，将研究其他平台功能，以确定其对VNF性能的单独影响和累积影响；示例包括核心固定，NUMA意识和庞大的页面。
Automated Generation of VNF Deployment Rules Using Infrastructure Affinity Characterization
标签：虚拟交换 除了 frame 框架 比特 注意 model 实现 操作
原文地址：https://www.cnblogs.com/Pan-xi-yi/p/11849854.html
