基于软件定义网络的虚拟数据中心管理平台
开篇：润墨网以专业的文秘视角，为您筛选了一篇基于软件定义网络的虚拟数据中心管理平台范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！
摘 要：针对已有虚拟数据中心（VDC）管理平台具有代码固化、后续升级困难等缺陷，设计和实现一种基于软件定义网络（SDN）的VDC管理平台。该平台由VDC管理子系统（VDCM）、VDC计算资源控制子系统（VDCCRC）和VDC网络资源控制子系统（VDCNRC）组成，子系统之间通过RESTful API交互建立起松耦合架构。VDCNRC通过SDN控制器管理数据中心网络资源，VDCCRC通过开源云平台管理数据中心计算资源，VDC管理子系统中内置VDC管理算法框架，可快速开发适用于实际生产环境的VDC管理算法。使用Mininet、Openstack、Floodlight搭建了测试环境，验证了该平台可通过Openstack来控制虚拟机的启动、迁移和删除，可通过Openflow控制器实现VDC网络带宽资源隔离，并支持VDC创建、删除和修改等操作。
关键词：虚拟数据中心；软件定义网络；Openstack；数据中心网络
中图分类号：TP393.01
文献标志码：A
文章编号：1001-9081（2016）11-2998-08
0 引言
随着Openstack、CloudStack等开源云计算平台的出现，云计算得以迅猛发展。云计算中多租户（Multi-tenancy）[1]概念要求通过虚拟化技术将物理资源池化后，可以按需、动态分配租户的资源请求，同时这些资源也可以随时随地被租户撤销。在这种趋势下，每个租户的资源请求可抽象为一组虚拟机（Virtual Machine，VM）构成的虚拟数据中心（Virtual Data Center，VDC），每个VM对应一定的计算资源（包括CPU、内存以及硬盘等）；同时为了传递数据和中间文件，VM之间需要建立具有带宽保障的虚拟链路[2]。VDC为租户提供了描述自己资源需求更加直观的方式。
目前与VDC相关的研究，比如VDC映射算法[3]、VDC资源调整算法[3]和VDC动态整合算法[3]成为了新的研究热点。VDC映射算法解决的是如何以更高的资源利用率或更少的代价来把虚拟资源请求映射到物理资源的问题， 然后随着租户业务需求的变化，租户将提出增加或减少虚拟机计算资源需求、虚拟链路带宽资源需求等请求，此时就需要VDC资源调整算法来实现租户资源需求的变化。而在VDC动态整合算法的应用场景中，VDC具有生存周期属性，当VDC到期后需要从数据中心中撤销VDC所占用的物理资源，因此一段时间后，数据中心的资源配置将不再最优，此时就需要VDC动态整合算法来对所有VDC重新整合从而达到资源配置的最优状态。这三种算法都可以看作是VDC管理算法。
除了VDC管理算法外，另外一个重要研究方向是VDC管理架构[3]，目前VDC管理架构主要解决的是在生产环境中如何在VDC之间共享网络资源的问题。由于网络资源具有天然共享特性，不同VDC之间将竞争网络带宽[4]。在多个VDC共享整个数据中心网络的环境中，传统数据中心凸显出没有网络性能隔离的弊端[5]。这是因为传统数据中心的网络技术仅仅支持尽力而为的报文递交模式，无法做到VDC之间的网络资源隔离。已有的VDC管理架构SecondNet[3]将传统基于介质访问控制（Media Access Control， MAC）表的转发方式替换为基于源路由的端换（Port-Switching based Source Routing， PSSR）技术来为VDC中的虚拟链路预先分配满足其需求的带宽资源，从而实现网络资源隔离。然而PSSR技术的应用需要对交换机和Hypervisor程序进行升级，这种升级给传统数据中心的维护和管理带来了更大的挑战。
软件定义网络（Software Defined Network， SDN）是一种新兴的网络架构，它主张控制与转发分离、控制逻辑集中的思想[6]。SecondNet架构采用了类似SDN的思想，全局的VDC管理器统一控制转发路径，交换机也只具备转发功能。然而SecondNet架构需要在设备中加入固化的代码，很难灵活改变来支持新的功能。而SDN通过Openflow协议[7]屏蔽底层物理转发设备的差异，实现底层网络对上层应用的透明化，可以天然做到灵活支持新的网络应用；因此采用SDN技术来设计VDC管理架构可以避免SecondNet架构后续升级困难的缺陷。
目前SDN的应用还主要集中在改善流量工程和虚拟机迁移效率等方向，文献[8]首次提出了将SDN技术与VDC管理结合的思想，但是并没有给出具体的解决方案。本文设计并实现一个基于SDN的VDC管理平台（Software Defined Network based Virtual Data Center Management Platform， SVMP）。该平台使用SDN控制器来控制数据中心网络资源、开源云平台来控制数据中心计算资源、VDC管理算法来控制物理资源的调配，通过该平台可以快速开发适用于实际生产环境的VDC管理算法。
1 SVMP总体设计
SVMP将SDN融入SecondNet架构，只保留SecondNet中的VDC管理器角色，网络资源由SDN控制器管理，计算资源由开源云平台管理。利用SDN的优势可以降低VDC管理算法在生产环境中的部署难度，减少网络规则变更的时延，提高VDC管理的效率。而开源云平台有庞大的社区支撑，有简单易用的接口供第三方应用程序调用来管理计算资源。SVMP主要有3个核心功能：1）收集虚拟机和物理服务器的状态信息作为VDC管理算法的第1个输入条件；2）收集网络中物理路径状态信息作为VDC管理算法的第2个输入条件；3）VDC管理算法通过收集到的信息对底层物理资源进行管理和优化，从而完成VDC创建、删除、迁移等工作。
1.1 平台整体架构
平台整体架构如图1所示。整个架构由管理平面、控制平面和数据平面组成。管理平面负责资源的协调，并不实际操作资源，而是调用控制平面提供的接口来完成资源的调整；控制平面具有直接操作物理资源的权限，并提供管理平面所需的调用接口；而数据平面就是所有计算资源、网络资源的集合，流量在数据平面中从源端被网络设备转发到目的端。VDC计算资源控制子系统（VDC Computing Resource Control subsystem， VDCCRC）直接管理计算节点集群和通过运行在计算节点上的Hypervisor程序来控制虚拟机，因此处于控制平面。VDC网络资源控制子系统（VDC Network Resource Control subsystem， VDCNRC）直接通过Openflow协议管理Openflow网络中的所有网络资源，同样处于控制平面。VDC管理子系统（VDC Management subsystem， VDCM）仅仅使用VDC计算资源控制子系统和VDC网络资源控制子系统提供的API从全局角度来统一调度物理资源，因此处于管理平面。3个子系统之间通过RESTful API[9]建立起松耦合架构。
1.2 VDC管理子系统
VDC管理子系统（VDCM）是整个平台的访问入口，租户直接向VDCM发出VDC创建、删除、修改等请求。VDCM采用RESTful API的方式来为租户提供访问接口，通过RESTful API可以快速开发供租户访问的Web页面。VDCM中包含VDC管理算法研究人员开发的VDC管理算法，VDC如何调度对租户来说是透明的，租户不关心VDC如何被调度，只关心与VDC相关的操作是否成功。VDCM中包含1个VDC管理算法框架，它屏蔽了输入输出的实现细节，因此可以大幅减少新算法部署需要开发的代码量。VDCM根据算法运算结果通过计算资源控制模块（Computing Resource Control Proxy， CRCP）和网络资源控制模块（Network Resource Control Proxy， NRCP）来调用VDC计算资源控制子系统和VDC网络资源控制子系统提供的RESTful API接口以完成物理资源的实际调整。
1.3 VDC计算资源控制子系统
VDC计算资源控制子系统（VDCCRC）负责管理整个数据中心中虚拟化的计算资源（包括vCPU资源、内存资源和硬盘资源）。它收集计算资源使用情况，并具有分配和回收计算资源的权限，同时提供RESTful API供VDC管理子系统调用。VDCCRC基于开源云平台实现，它使用云计算平台提供的接口来完成计算资源的调整操作，比如当基于Openstack[10]来实现时，VDCCRC将调用Openstack提供的RESTful API来完成计算资源的调度。计算资源的调度主要包括：虚拟机的创建、删除、扩容和迁移等。
1.4 VDC网络资源控制子系统
VDC网络资源控制子系统（VDCNRC）基于SDN架构实现，主要负责管理由Openflow交换机组成的数据中心网络，其本质是利用Openflow控制器所提供的北向API开发的一个应用程序。VDCNRC使用Openflow控制器提供的流表控制功能将来自VDC管理子系统的RESTful API调用转换为网络中Openflow交换机上的流表规则变更。VDCNRC的主要功能包括：路径计算、虚拟链路映射、VDC网络资源隔离、虚拟机迁移感知等。
1.5 VDC请求处理模型
SVMP的核心功能是向租户提供VDC管理服务，因此需要处理来自租户的VDC操作请求。VDC创建请求的处理模型如图2所示。
VDCM处理VDC创建请求时，首先需要通过VDCCRC和VDCNRC获取计算资源和网络资源的使用情况；然后依据获得的资源使用信息执行VDC管理算法，其中需要包含VDC映射算法逻辑。VDC映射算法逻辑在需要时可以向VDCCRC发出请求来启动虚拟机，以及向VDCNRC发出请求来映射虚拟链路。
处理VDC更新请求的模型与处理VDC创建请求类似，处理VDC删除请求时无需获取资源使用信息。
2 VDC管理子系统设计
VDC管理子系统（VDCM）为租户提供申请/撤销VDC的接口，其中内置VDC管理算法对物理资源进行统一调配。VDCM的系统架构相对简单，主要由RESTful API服务器线程池、VDC管理算法框架线程组成。RESTful API服务器线程池负责提供与租户交互的RESTful API，并把创建、修改和删除VDC请求发送给VDC管理算法框架线程去处理。VDC管理算法框架线程执行VDC管理算法，算法输入的获取或输出的执行均是通过CRCP和NRCP完成。
VDC管理算法框架可以快速完成新算法的部署，该框架为研究人员屏蔽了输入输出的底层实现细节，并同时兼容VDC映射算法、VDC资源调整算法和VDC动态整合算法，即可以使用该架构同时进行这三个方向的研究。VDC管理算法框架伪代码如算法1所示。其中MsgQ是RESTful API线程用来存储租户VDC操作请求的消息队列，VDC管理算法框架线程将从该消息队列中获取租户的VDC操作请求。租户发出RESTful API请求后，VDCM需要回复一个表示请求已收到的响应，此时租户无法知道VDC操作请求是否成功。VDC操作请求的类型包括三种：创建VDC、删除VDC和修改VDC。随后租户可以通过调用查询VDC当前状态的RESTful API来查看VDC操作请求是否已经成功。使用MsgQ的好处是避免对于每个VDC操作请求都去执行VDC动态整合算法，从而提高VDC动态整合算法的执行效率。t表示算法框架每隔多少秒执行一次，从而可以控制VDC动态整合算法执行频率，执行越频繁，底层资源的配置将更加优化，但是消耗的服务器资源也就更多。
对于删除VDC请求，算法框架将直接调用CRCP和NRCP的接口来撤销VDC所占用的物理资源，而无需算法研究人员再去调用。VDC管理算法执行时，首先需要通过NRCP和CRCP获取计算资源和网路资源的使用情况；然后依次执行VDC资源调整算法、VDC动态整合算法和VDC映射算法，三者的顺序可以由算法研究人员自定义。SVMP支持的VDC资源调整操作包括：增加或删除虚拟机、增加虚拟机计算资源需求、增加或撤销虚拟链路、增加或减少虚拟链路带宽资源需求，但是还不支持减少虚拟机计算资源需求的操作，因为Openstack平台不支持。
3 VDC计算资源控制子系统设计
VDC计算资源控制子系统（VDCCRC）负责计算资源的监控和控制，VDCCRC将基于Openstack开源云平台设计并实现，下面介绍VDCCRC系统架构及关键技术。
3.1 VDCCRC系统架构
VDCCRC的系统架构如图3所示。
VDCCRC包含3个部分：1）Openstack云平台，包括Openstack控制节点和计算节点；2）计算资源监控程序；3）虚拟机操作协调程序。CRCP通过访问计算资源监控程序来获取计算资源监控数据，通过向虚拟机操作协调程序发送消息来执行虚拟机相关操作。Openstack本身并不对外提供查询计算节点状态信息的接口，也没有实现虚拟机计算资源监控功能。因此VDCCRC需要一个独立于Openstack的计算资源监控程序，详见3.2节。Openstack Nova组件提供的控制虚拟机的RESTful API返回成功并不代表与虚拟机相应的操作执行成功，比如在调用启动虚拟机RESTful API之后，Nova在发出启动虚拟机消息后会立即返回成功，但是此时虚拟机的启动才刚刚开始，之后还会经历虚拟机调度、镜像获取、网络配置、使用Hypervisor启动虚拟机等阶段，其中每个阶段都有可能产生错误而导致失败。因此为了知道虚拟机是否真正启动成功，常见的做法是不断调用显示虚拟机当前状态的RESTful API或查询数据库直到虚拟机的状态为成功或失败为止，这种做法极其消耗服务器资源且具有较大时延。因此VDCCRC通过虚拟机操作协调程序来提升这个过程的效率，详见3.3节。
3.2 计算资源监控
计算资源监控功能由监控数据RESTful API进程、监控数据汇总进程和监控数据采集进程共同完成，这些进程的部署与Openstack主从架构统一。监控数据RESTful API进程和监控数据汇总进程部署在Openstack控制节点，监控数据采集进程部署在Openstack计算节点。
监控数据采集进程周期性从本地计算节点及运行在本地的虚拟机上获取计算资源使用情况，然后通过消息队列monitor_queue发送给监控数据汇总进程。消息队列可以避免监控数据汇总进程维护多个与监控数据采集进程通信的TCP连接所带来的不必要开销。监控数据汇总进程需要将来自监控数据采集进程的计算资源使用情况写入到数据库中，以便CRCP通过RESTful API来访问数据库中的信息。通过数据库可以把CRCP查询监控数据的功能和后台收集监控数据的功能分离，从而可避免因后台收集监控数据耗时过长而导致CRCP一直处于阻塞状态，最终提高VDC管理算法效率。监控数据汇总进程从monitor_queue收到消息后需要通过消息中携带的reply_queue_id信息所指示的队列向监控数据采集进程发送一个响应来表示消息已收到。注意，在后文中如果涉及向接收请求的消息队列中发送响应，均是指通过消息中携带的reply_queue_id信息所指示的队列来发送响应。
计算资源监控程序也通过心跳机制检测虚拟机和计算节点存活状态。监控数据采集进程在发送计算资源使用信息的同时也发送代表当前时间的UNIX时间戳。监控数据汇总进程会把该时间戳写入到数据库中，监控数据RESTful API进程在收到CRCP请求后需要计算当前时间戳和数据库中记录的时间戳之间差值是否在一定范围内来判断是否存活。为了减少误差，需要在Openstack计算节点与控制节点之间完成时间同步。为了提高并发能力，监控数据RESTful API进程中将采用线程池来提供服务。
3.3 虚拟机控制
计算资源控制并不直接调用Openstack的RESTful API来操作虚拟机，而是通过消息队列向虚拟机操作协调进程（Virtual Machine Operation Coordinator， VMOC）发送对虚拟机操作的请求消息。VMOC需要使用两个消息队列：
1）vm_op_queue。CRCP通过vm_op_queue向VMOC发送关于虚拟机操作的请求消息，其格式如表1所示。目前支持的虚拟机操作包括：启动、删除、迁移和扩容。启动虚拟机时CRCP需要在请求消息中携带启动虚拟机的计算节点主机名，主机名可以唯一标识计算节点。迁移虚拟机时CRCP需要在请求消息中携带虚拟机将被迁往的目的主机名。VMOC收到请求消息后首先标记请求消息为还未回复状态并将请求消息记录在日志中，然后根据消息类型向Openstack发送相对应的RESTFul API，如果RESTFul API返回表示错误的HTTP状态码，则VMOC直接向vm_op_queue中返回一个虚拟机操作失败响应（Failed Operation， FO），响应的格式如表2所示。如果RESTful API执行成功，则VMOC需要立即向CRCP回复一个操作半成功响应（Semi-Successful Operation， SSO），VMOC需要等收到nova-compute进程（nova-compute进程是Openstack计算节点上的主进程，它会使用Hypervisor程序执行启动、迁移等虚拟机操作）发出成功消息后才向CRCP回复操作完全成功响应（Successful Operation， SO）。CRCP在发送虚拟机操作请求消息后需要设置超时值，如果超时则认为虚拟机操作失败。超时之后到达的响应会被直接丢弃。如果启动或迁移虚拟机成功，VMOC需要在回复CRCP的响应的extra_info字段中携带虚拟机当前网络位置信息，虚拟机网络位置是指一个元组〈虚拟机连接的虚拟交换机DPID， 虚拟机连接的虚端口号〉。DPID在Openflow协议中被用来唯一标识Openflow交换机。
2）vm_status_queue。nova-compute进程在虚拟机操作成功或失败后需要向vm_status_queue中发送成功或失败消息，消息中需要携带虚拟机ID、计算节点主机名、操作类型、操作结果和额外信息，其格式如表3所示。VMOC从vm_status_quque中获得成功或失败消息后，将消息与从vm_op_queue收到的还未回复的请求消息进行匹配，如果匹配成功且操作成功，则向CRCP回复SO，如果匹配成功且操作失败，则向CRCP回复FO。如果从vm_status_queue中收到的消息不能匹配任何一个从vm_op_queue收到的还未回复的请求消息，则将被直接丢弃。
VMOC判断启动虚拟机完全成功需要两步：第一步，nova-compute进程在为虚拟机配置好虚端口后，发送表示第一步成功的消息到vm_status_queue，此时消息中需要携带虚拟机的网络位置；第二步，nova-compute进程在虚拟机完全启动成功后，发送表示第二步成功的消息到vm_status_queue。VMOC判断迁移虚拟机完全成功也需要两步：第一步，目的nova-compute进程在为虚拟机配置好新的虚端口后，发送表示第一步成功的消息到vm_status_queue，此时需要携带虚拟机新的网络位置；第二步，源nova-compute进程将虚拟机迁移到目的计算节点成功后，需要发送表示第二步成功的消息到vm_status_queue。虚拟机操作协调进程只有在两步都成功后才能认为虚拟机启动或迁移成功。VMOC每次收到CRCP虚拟机操作请求消息首先将其记录在日志中，这样当断电重启之后可通过日志恢复来自CRCP的还未回复的请求消息。为了保证VMOC在断电重启后能获取虚拟机最新状态，VMOC在重启后需要读取nova数据库，并查看还未回复的请求是否已经成功，如果成功则向vm_op_queue回复SO，如果失败则回复FO。
通过VMOC来协调openstack中虚拟机的操作，CRCP可以采用阻塞或非阻塞两种模式来执行虚拟机操作。对于阻塞模式，CRCP在向vm_op_queue发送消息后需要阻塞直到收到SO、超时或错误发生；对于非阻塞模式，CRCP发送消息后只需要等待SSO后便可处理后续工作。比如在进行VDC映射时，可以先通过非阻塞模式启动VDC中所有的虚拟机，然后才开始准备接收来自vm_op_queue中的虚拟机启动SO，收到SO后即可进行虚拟链路映射。不过非阻塞模式虽然映射VDC速度更快，但是不利于快速发现错误，让故障处理变得更加复杂。
4 VDC网络资源控制子系统设计
VDC网络资源控制子系统（VDCNRC）是已有VDC管理架构SecondNet与SDN架构结合的核心。VDCNRC在SDN控制器Floodlight[11]上实现，通过Openflow协议控制由Openflow交换机互联构成的数据中心网络。下面介绍VDCNRC系统架构及关键技术。
4.1 VDCNRC系统架构
VDCNRC的系统架构如图4所示。整个VDCNRC由一个进程实现，其中包括4个部分：RESTful API服务器线程、核心线程、广播报文转发线程、路径计算线程。NRCP通过RESTful API来执行虚拟链路映射和获取网络中计算节点对之间物理路径状态信息。由于Openstack在启动虚拟机或创建租户网络资源时都会调用Neutron Floodlight插件向Floodlight传递一些信息，因此VDCNRC需要支持接收来自Neutron Floodlight插件的RESTful API调用。
4.2 路径计算
VDCNRC维护着物理网络中所有链路的状态信息，路径计算线程需要使用这些链路状态信息来计算计算节点对之间的所有物理路径，而不是最短路径。因为在VDC管理算法中，通常需要先获得计算节点对之间的所有路径，然后再根据路径的参数，比如跳数、剩余带宽等信息来作为权重自行计算最短路径。因此，为了让VDC管理算法更加灵活，路径计算线程不需要计算最短路径。
胖树[12]中可以使用PathAcquisition算法[13]来计算两个计算节点之间的所有物理路径，但是该算法是一个静态算法，并不能用于链路动态变化的场景。本文将提出基于胖树的所有计算节点对之间路径动态计算（Dynamic All Paths for Fat Tree， DAPFT）算法，其伪代码如算法2所示。DAPFT算法伪代码中EL表示当前已经被路径计算线程记录下处于活动状态的物理链路集合。EW表示当前已经被记录下处于活动状态的Openflow交换机集合。cl表示当前变化的物理链路，链路变化有两种状态：被删除链路或新增链路，链路变化可通过链路发现协议知晓。cw表示当前变化的交换机，交换机变化有两种状态：被删除交换机或新增交换机，交换机变化可通过SDN控制器与交换机的通信连接状态知晓。P表示当前已经计算出的计算节点对之间路径的集合，每条路径由从源计算节点到目的计算节点所经过的所有Openflow交换机DPID构成。CIP表示所有计算节点的标记IP地址集合，标记IP地址是指在胖树中用来指示交换机或计算节点所处位置的虚拟IP地址，并不是网卡上的IP地址。ITD表示所有交换机标记IP地址到其DPID的映射关系，计算节点上虚拟交换机的标记IP地址就是计算节点的标记IP地址。CIP和ITD通常由管理员写入到配置文件中，路径计算线程启动时读取该配置文件。如果要增删计算节点或交换机，则应同时修改该配置文件。k表示胖树的规模因子，胖树总共有k个容器，k个核心交换机，每个交换机有k个端口，每个容器内有k个交换机（其中汇聚交换机和接入交换机各占一半），k由管理员在配置文件中配置。
PathAcquisition算法的时间复杂度为O（k2），k是胖树的规模因子。因此，DAPFT算法的时间复杂度为O（k2・num2），其中num为计算节点的数目。
4.3 VDC网络资源隔离
VDC网络资源隔离主要分为两个部分：可达性隔离和带宽隔离。可达性隔离可以避免VDC之间相互知晓，从而避免不必要的恶意攻击；带宽资源隔离可以避免恶意租户大量侵占其他租户的带宽资源，从而可避免拒绝服务攻击的产生。只要保证广播报文只在VDC内部洪泛，单播报文只沿着为虚拟链路配置好的物理路径转发，则可以实现可达性隔离。而在映射虚拟链路时，使用Openflow计量表来进行限速即可实现带宽资源隔离。
VDCM通过VDCNRC的RESTful AP只能获取到虚拟链路将要被映射到的计算节点之间的物理路径，然而对于完整的从源虚拟机到目的虚拟机的转发路径而言，还需要源、目的虚拟机连接到的虚端口信息，因此虚拟链路映射必须在其两端虚拟机启动成功之后进行。
在Floodlight中，可以通过设备管理器来获取虚拟机网络位置，但是设备管理器只有在虚拟机主动发出报文时才能知晓其网络位置，因此时延较大，降低了VDC管理算法的效率。nova-compute进程启动虚拟机之前会先通过Neutron Floodlight插件阻塞调用VDCNRC的RESTful API来把虚拟机IP地址、MAC地址等基本信息传递给VDCNRC，而此时还并未为虚拟机创建虚端口，因此无法知晓虚拟机连在虚拟交换机的哪个端口上。当RESTful API返回后，nova-compute进程才会为虚拟机创建虚端口，然后通过Hypervisor启动虚拟机。因此，VDCNRC可以在RESTful API调用结束之后由另一个线程来获取虚拟机网络位置，此时常见的做法是周期性去查询nova数据库来获取，不过此方法的缺点是当VDCM知道虚拟机启动成功后开始映射虚拟链路时，VDCNRC可能还未获取到虚拟机的网络位置，从而导致虚拟链路映射失败。因此效率最高的方法是由VDCM从虚拟机操作协调进程处获取虚拟机的网络位置，然后在映射虚拟链路时，将虚拟链路要映射到的路径和虚拟机的网络位置同时发送给VDCNRC。
4.4 报文转发控制
报文转发控制主要包括广播报文转发和单播报文转发。单播报文的转发需要同时使用Openflow流表和计量表。流表用来控制单播报文的转发路径，计量表用来控制单播报文的转发速率。映射虚拟链路时会使用Openflow流表建立一条转发路径。根据转发路径上交换机数目的不同，转发路径所用转发规则将有区别，主要分为：单个交换机的路径和多个（大于1个）交换机的路径。单个交换机的路径所用转发规则如表4所示，多个交换机的路径所用转发规则如表5所示。需要注意，本文的实现中采用虚拟局域网（Virtual Local Area Network， VLAN）来作为VDC隔离标签，也可以直接替换成多协议标签交换（Multi-Protocol Label Switching， MPLS）标签。由于Openstack中创建虚拟机MAC地址唯一，因此在流表设计时采用MAC地址来唯一标识虚拟机。
在表4中，Openflow交换机的行为是对于从iport端口收到的报文，如果源MAC为sm，目的MAC为dm的报文，则使用meter_id计量表项进行限速，如果不超过速率上限，则从oport端口转发出去，否则丢弃。在表5中，源Openflow交换机的行为和表4中交换机的行为类似，只是在从oport转发出去之前，先增加VLAN标签，并设置VLAN ID为vlanid。表5中中间Openflow交换机的行为和表4中交换机的行为类似，只不过在执行流表匹配时需要匹配VLAN ID。表5中目的Openflow交换机的行为和中间Openflow交换机的行为类似，只不过在从oport转发出去之前，需要去掉VLAN标签。
根据表4和表5的流表设计，所有广播报文都不能匹配任何流表项，因此当Openflow交换机收到广播报文后将以PacketIn消息发送给SDN控制器。广播报文转发线程收到PacketIn消息后的执行广播报文转发的步骤如下。
步骤1 判断PacketIn消息携带的是否是广播报文。如果不是，则丢弃PacketIn消息，这意味着没有建立虚拟链路的两个虚拟机无法直接通信。
步骤2 如果是广播报文，则判断广播报文数据链路层源MAC地址是否属于某个VDC。Openstack启动虚拟机时，会通过Neutron Floodlight插件将虚拟机MAC地址告知VDCNRC，此时VDCNRC需要将虚拟机MAC地址加入其所在VDC。如果不是，则丢弃PacketIn消息，这意味着不同VDC之间的虚拟机无法进行通信。
步骤3 如果属于VDC a，则判断当前发出PacketIn消息的交换机是否连接着a内的其他虚拟机或动态主机配置协议（Dynamic Host Configuration Protocol， DHCP）服务器。Openstack中虚拟机要进行网络通信之前，必须将其配置到一个Neutron租户网络资源中，其中有DHCP服务器来为虚拟机配置IP地址。一个VDC将唯一对应一个Neutron租户网络资源。VDCM在映射一个新的VDC时，需要先调用Neutron的RESTful API创建租户网络资源，然后再启动虚拟机。租户网络资源概念只是为了方便对虚拟机进行集中管理，其中只存在虚拟机，不存在虚拟链路。VDCNRC获取DHCP服务器网络位置的方式与获取虚拟机网络位置类似，因此不再赘述。如果当前交换机有端口连接着a内的其他虚拟机或DHCP服务器，则拷贝一份广播报文通过PacketOut消息向这些端口转发出去。
步骤4 从Floodlight拓扑管理器中获取当前交换机可以广播的端口集合，然后拷贝一份广播报文通过PacketOut消息向这些端口转发出去。拓扑管理器会使用Dijkstra算法计算一棵广播树，只要保证广播报文只在广播树内转发，即可避免环路。
在步骤3中已经提到有DHCP服务器为虚拟机分配IP地址，虚拟机启动后会广播DHCP请求报文，而广播报文转发线程将对通过PacketIn消息被发送到SDN控制器的DHCP请求报文进行转发，因此虚拟机可以正常从DHCP服务器获得IP地址。
4.5 虚拟机迁移感知
虚拟机迁移感知的目的是当虚拟机迁移时，自动完成网络转发规则的迁移，当虚拟机迁移成功后，即可直接进行网络通信。VDCM在发起虚拟机迁移成功后，需要撤销与虚拟机相关的所有虚拟链路的映射，然后根据虚拟链路两端虚拟机的新网络位置，重新对虚拟链路进行映射，从而完成网络规则的自动迁移。
5 平台测试
SVMP实现时，数据库全部采用Mysql，消息队列服务由Rabbitmq消息系统[14]提供。Openstack使用H版本，Floodlight使用1.1版本，Mininet[15]使用2.2.1版本且使用Ofsoftswitch[16]来作为Openflow虚拟交换机。Openstack计算节点上运行Openvswitch[17]作为Openflow虚拟交换机。Openstack安装时需要修改少量源代码来支持通过RESTful API在指定计算节点上启动虚拟机和nova-comptute进程向vm_status_queue发送消息。
假设平台正常运行，虚拟机操作和虚拟链路操作不会产生失败。设置监控数据采集模块执行周期为5s，VDC管理算法框架执行周期为2s。
采用5台PC和1台千兆交换机搭建了测试环境，如图5所示。每台PC的配置为4GB内存，4核主频为2.0GHz的CPU，转速7200转/分钟的SATA硬盘，两块板载千兆网卡。运行Mininet程序的PC还需要安装3块pcie千兆网卡。图5中描述了Openstack虚拟机及DHCP服务器之间的通信网络，每个PC还需要和千兆交换机进行连接来形成Openflow交换机与SDN控制器通信、Openstack集群节点之间通信以及SVMP中各个进程之间通信的网络。
Openstack控制节点上除了运行Openstack本身的守护进程之外，还需要运行Mysql数据库、Rabbitmq消息队列服务器、NFS服务器、监控数据RESTful API进程、监控数据汇总进程、虚拟机操作协调进程、VDCM和VDCNRC进程。NFS服务器的作用是支持虚拟机快速迁移。Mininet中模拟规模因子k为4的胖树，每个容器分别连接一个节点。通过SVMP提供的RESTful API接口多次创建具有5个虚拟机和4条虚拟链路的星形VDC，虚拟机所需计算资源需求为512MB内存、5GB硬盘、1核CPU，虚拟链路带宽需求为200Mb/s。首先测试创建VDC平均消耗时间，然后分别统计虚拟机操作和虚拟链路操作平均消耗时间。VDC管理算法框架中实现1个用于演示的VDC映射算法：采用广度优先搜索遍历VDC，然后轮询计算节点来启动虚拟机，映射虚拟链路时选择剩余带宽容量最少且能满足带宽需求的路径。Openstack使用Cirros最简虚拟机镜像，其大小为14MB。测试结果如表6所示。
表6中虚拟机操作消耗时间是从CRCP向虚拟机操作协调进程发出消息直到收到SO所消耗的时间。由于虚拟链路正向和反向分开映射，因此虚拟链路操作消耗时间是两次从NRCP向VDCNRC发出RESTful API请求直到收到响应所消耗的时间。创建VDC消耗时间是从VDC管理算法框架开始处理VDC创建请求到VDC创建成功所消耗的时间，不算排队时间。从表6中可知当虚拟机迁移后，网络转发规则变更所消耗的时间为撤销虚拟链路映射耗时加上映射虚拟链路耗时，约为0.2s。
6 结语
传统VDC管理架构SecondNet在部署时需要对数据中心交换机和Hypervisor程序进行升级，给管理维护带来了更大的挑战。本文结合SDN技术在数据中心体现的优势，设计并实现了基于SDN的VDC管理平台（SVMP）。该平台使用SDN技术来管理数据中心网络资源，使用开源云平台Openstack来管理数据中心计算资源。通过Mininet、Openstack和Floodlight搭建了测试环境，对平台创建VDC、虚拟机操作及虚拟链路操作的平均消耗时间进行了测试。测试结果验证了SVMP具备VDC管理基本功能，VDC管理算法研究人员可以基于该平台开发能用于生产环境的VDC管理算法。在SVMP中，与虚拟机操作相比虚拟链路操作消耗时间极少，虚拟机迁移后只需0.2s即可自动完成网络转发规则迁移，这可以极大降低数据中心管理难度， 减少网络管理人力投入。本平台进一步的研究方向可以是为平台增加完善的容错机制，平台中各个子系统存在单点故障问题，一旦故障，数据可能发生丢失。
参考文献：
[1] DILLON T， WU C， CHANG E. Cloud computing： issues and challenges[C]// Proceedings of the 2010 24th IEEE International Conference on Advanced Information Networking and Applications. Piscataway， NJ： IEEE， 2010： 27-33.
[2] 左成， 虞红芳. 可靠性感知下的虚拟数据中心映射算法[J]. 计算机应用， 2015， 35（2）： 299-304.（ZUO C， YU H F. Reliability-aware virtual data center embedding algorithm[J]. Journal of Computer Applications， 2015， 35（2）： 299-304.）
[3] GUO C， LU G， WANG H J， et al. SecondNet： a data center network virtualization architecture with bandwidth guarantees[C]// CoNEXT 2010： Proceedings of the 2010 International Conference on emerging Networking Experiments and Technologies. New York： ACM， 2010： Article No. 15.
[4] 李丹， 刘方明， 郭得科， 等. 软件定义的云数据中心网络基础理论与关键技术[J]. 电信科学， 2014， 30（6）： 48-59. （LI D， LIU F M， GUO D K， et al. Fundamental theory and key technology of software defined cloud data center network[J]. Telecommunications Science， 2014， 30（6）： 48-59.）
[5] BARI M F， BOUTABA R， ESTEVES R， et al. Data center network virtualization： a survey[J]. IEEE Communications Surveys & Tutorials， 2013， 15（2）： 909-928.
[6] Open Network Foundation. Software-defined networking： the new norm for networks[EB/OL].[2012-04-13]. https：///images/stories/downloads/sdn-resources/white-papers/wp-sdn-newnorm.pdf.
[7] MCKEOWN N， ANDERSON T， BALAKRISHNAN H， et al. OpenFlow： enabling innovation in campus networks[J]. ACM SIGCOMM Computer Communication Review， 2008， 38（2）： 69-74.
[8] 吴强， 徐鑫， 刘国燕. 基于 SDN 技术的数据中心基础网络构建[J]. 电信科学， 2013， 29（1）： 130-133. （WU Q， XU X， LIU G Y. Construction of basic network in data center based on SDN technology[J]. Telecommunications Science， 2013， 29（1）： 130-133.）
[9] ELKSTEIN M. Learn REST： a tutorial[EB/OL].[2015-11-15]. http：///.
[10] Openstack Community. OpenStack cloud administrator guide[EB/OL].[2013-12-28]. http：///admin-guide-cloud/.
[11] Project Floodlight. Floodlight openflow controller[EB/OL].[2015-11-15]. http：///floodlight/.
[12] AL-FARES M， LOUKISSAS A， VAHDAT A. A scalable， commodity data center network architecture[C]// Proceedings of the ACM SIGCOMM 2008 Conference on Data Communication. New York： ACM， 2008： 63-74.
[13] SEO S. Dynamic traffic engineering for improving energy efficiency and network utilization of data center networks[D]. Pohang： Pohang University of Science and Technology， 2013： 71-72.
[14] Pivotal Software， Inc. RabbitMQ ― messaging that just works[EB/OL].[2015-11-15]. https：///.
[15] Mininet Team. Mininet an instant virtual network on your laptop （or other PC）[EB/OL].[2015-11-15]. http：///.
[16] FERNANDES E L. OpenFlow 1.3 software switch[EB/OL].[2015-11-15]. http：//cpqd.github.io/ofsoftswitch13/.
[17] Open vSwitch[EB/OL].[2015-11-15]. http：///.