云计算网络中多租户虚拟网络隔离的分布式实现研究

严立宇 祖立军 叶家炜* 周雍恺 吴承荣

1(复旦大学计算机科学技术学院 上海 200433)2(网络信息安全审计与监控教育部工程研究中心 上海 200433)3(中国银联股份有限公司电子支付研究院 上海 201201)



云计算网络中多租户虚拟网络隔离的分布式实现研究

严立宇1，2祖立军3叶家炜1，2*周雍恺3吴承荣1，2

1(复旦大学计算机科学技术学院 上海 200433)2(网络信息安全审计与监控教育部工程研究中心 上海 200433)3(中国银联股份有限公司电子支付研究院 上海 201201)

近年来，随着网络虚拟化技术的快速发展，云服务提供商可以将一套物理网络抽象成多套相互独立的虚拟网络提供给租户。在多租户网络环境中，需要保证租户网络的安全隔离，确保租户数据不会遭到来自其他租户以及外部网络的非法访问。相比传统物理网络的边界，虚拟网络的边界定义更加模糊，需要更细粒度的网络隔离；当前以OpenStack为代表的主流开源云平台采用集中式部署网络边界节点的方式实现虚拟网络的隔离，虚拟机流量大多集中到单一物理节点上，存在单点故障的隐患。提出分布式实现虚拟网络隔离的方式，把原本集中的虚拟网络边界分布到各台物理服务器，从而将原本集中于同一节点的网络流量分摊到各物理服务器，降低单点故障造成损失的可能性。最后经过实验证实了分布式部署的有效性，同时能够降低虚拟机通信的网络延迟。

多租户虚拟网络隔离 虚拟网络边界 虚拟路由器 分布式 单点故障

0 引 言

随着虚拟化技术的快速发展，云计算在大型数据中心网络中已经得到大规模应用，对网络的性能要求和安全要求也越来越高。与服务器虚拟化类似，网络虚拟化技术的发展使得云服务提供商能将物理网络设备抽象成虚拟的网络设备提供给租户，并允许每个租户创建自己的虚拟网络，结合租户申请的虚拟机资源定义网络拓扑，对虚拟网络进行管理[1]。

对云服务提供商而言，虚拟网络的基本需求是：允许网络中多租户共存，即在同一套物理网络环境中，支持创建多套具备独立服务模型、拓扑和IP地址空间的租户虚拟网络[2]。而从租户的角度来看，不仅要求能够创建一套独立的虚拟网络，在其中运行业务，而且要求确保租户数据的隔离和安全性，保证数据不会遭到来自其他租户以及外部网络的非法访问。

在传统物理网络环境中，不同网络之间的隔离通常由部署在网络边界处的路由器和防火墙完成。同样，虚拟网络的隔离也应当在虚拟网络的边界处实现。但相比之下，虚拟网络环境中的网络边界更加模糊，缺乏明确的定义，因此为租户虚拟网络提供路由及防火墙服务也更为复杂。同时，租户虚拟网络到实际物理网络拓扑的映射是相对分散的，同一租户控制的虚拟机很可能分布在多台物理服务器上，可见租户虚拟网络的边界可以细化到各物理服务器的边缘，需要更加细粒度的网络隔离。

结合典型的虚拟网络应用场景来看，虚拟网络中的边界可分为以下几类，如图1所示：

(1) 不同租户的虚拟网络之间的边界；

(2) 同一租户虚拟网络下，不同虚拟子网之间的边界；

(3) 租户虚拟网络与外网之间的边界。

图1 虚拟网络的边界分类

在当前主流的开源云平台中，已经有针对虚拟网络安全隔离的解决方案，通过为租户网络创建虚拟路由及防火墙的方式实现虚拟网络的安全隔离[3]。在现有架构下，所有租户的虚拟路由器及防火墙设备都位于同一物理节点，涉及租户网络边界的流量都被集中到该节点上进行处理，存在引发单点故障的隐患，同时也增加了虚拟机通信的网络延迟。

1 相关工作

1.1 相关研究进展

上文提到虚拟网络的边界更模糊，需要更细粒度的网络安全隔离措施。学术界针对虚拟化环境下的安全隔离问题有不少研究，并结合网络功能虚拟化(NFV)的概念，将虚拟防火墙一类的网络设备定义为网络中间件(MiddleBox)。文献[4]提出NetVM平台，将防火墙、路由器一类的设备部署在虚拟化层，相比预先部署在专用硬件设备的方案更具灵活性；同时，NetVM利用Intel的DPDK库和零拷贝技术，提升了虚拟化层的网络速率和吞吐量，并实现网络高性能。文献[5]围绕网络功能虚拟化的概念，提出ClickOS虚拟化平台，在其中部署高性能的中间件平台，包括虚拟防火墙、NAT、负载均衡器等，优化中间件的数据包处理，提供了一种通过软件实现网络中间件的方案。文献[11]则重点关注虚拟网络性能，提出Pulsar平台来为租户提供虚拟数据中心(VDC)的抽象模型，并保证虚拟网络性能达到租户的需求。

可见学术界多数研究的重点关注集成、管理和扩展中间件部署的能力和虚拟化I/O问题，旨在提升数据包通过虚拟机与物理机之间的速率，提高中间件平台的可用性。此外，CloudMB项目[6]关注虚拟网络服务初始放置的优化，期望在物理拓扑和流分布可知的情况下，通过启发式算法计算出虚拟网络服务部署的合理位置，避免可能导致性能瓶颈的机架间流量。文献[2，10]都为多租户提供独立的IP地址空间，采用数据包封装技术来区分并隔离不同租户。

而在工业界，针对虚拟网络层面的安全隔离问题，有不少解决方案试图通过定义虚拟网络的边界，并在相应边界物理节点部署虚拟路由及防火墙的方式来实现隔离。云计算环境中提供的服务范围越来越广，防火墙即服务的概念也已产生，虚拟防火墙及路由器以服务的方式提供给租户，租户可以为自己的子网申请虚拟路由器及防火墙，并为虚拟网络的防火墙添加策略和规则。

在安全隔离的部署架构方面，以VMWare的NSX[7]为代表的商用虚拟网络解决方案中已经提出了分布式逻辑路由，以及分布式虚拟防火墙的概念。该方案采用位于物理网络边界的集中式节点处理南北向流量(租户虚拟机与外部网络的流量)、位于各物理服务器内部的分布式虚拟路由/防火墙处理东西向流量(跨物理机的虚拟机之间的流量)。

而在主流开源云平台(如OpenStack)[3]中仍然采取集中部署虚拟路由器及防火墙的方式，即专设一台服务器(或专用硬件网络设备)作为网络节点，在该网络节点上为每个租户部署虚拟路由器，并配置虚拟防火墙作用在虚拟路由器上。这种部署方式的思路就是将虚拟网络的边界集中到统一的节点，所有涉及租户网络边界的流量都被集中到网络节点上进行处理。但这样的实现方式容易引发单点故障，下一节将具体分析其中存在的问题。

1.2 集中式虚拟路由的问题

上文中图1给出了虚拟网络边界的3种场景。OpenStack允许租户分别创建各自的虚拟路由和虚拟防火墙，不同租户的虚拟路由器之间默认没有关联，无法相互访问，因此可以达到隔离多租户虚拟网络的目的，但在处理(2)、(3)两类网络边界场景时，存在不合理之处。

图2是OpenStack实现虚拟网络隔离的路由模式，其中网络节点是OpenStack专设的实现虚拟网络功能的物理服务器节点，所有租户的虚拟路由器均部署在网络节点上，虚拟防火墙的规则作用在相应虚拟路由器上，而计算节点则是部署了虚拟机管理程序(Hypervisor)及虚拟机资源的物理服务器。为便于说明问题，假设租户A创建了一套虚拟网络，配置了两个子网，子网下的虚拟机分布在不同计算节点上。

图2 OpenStack虚拟网络隔离的路由模式图

在同租户不同子网边界方面：由于云计算的一大特点是东西向流量增大，业务运行时，跨物理机的虚拟机之间经常进行通信。在现有的网络架构下，跨子网的网络通信流量都需要通过网络节点上的虚拟路由器进行转发。图2中深色箭头对应的路径是租户A不同子网下的虚拟机之间通信时的数据包路径，其中位于子网1的虚拟机VM1与位于子网2的虚拟机VM2通信，数据包经过位于网络节点的虚拟路由器和虚拟防火墙。

在租户与外网边界方面：虚拟机与外部网络之间的通信流量也需要经过网络节点，通过网络地址转换(NAT)和防火墙规则的过滤，如图2中浅色箭头所示。租户A的虚拟机数据包在通往外网的过程中经过网络节点，通过部署在虚拟路由器上的NAT规则进行IP地址转换，获取外网IP资源，同时也经过部署在虚拟路由器上的虚拟防火墙规则进行过滤，防止与外网间的非法通信。

因此，在多租户的场景下，现有的虚拟网络隔离实现模式会导致租户虚拟机的大部分流量都经过单一物理节点，对网络节点造成极大的负载压力。如果采用集中式部署的虚拟网络隔离架构，将网络节点作为实现网络功能和服务的单一节点，很容易引发单点故障问题；同时，由于租户网络隔离机制需要采用基于VXLAN的覆盖网络协议，对虚拟机网络数据包进行封装(在第2节详细介绍)，虚拟机数据包在不同物理节点间的转发都会经过封装与解封装的过程。数据包统一经过网络节点处理，进一步增加了通信的网络延迟。因此现有的虚拟网络隔离架构存在引发单点故障的隐患以及网络延迟的问题，不具有高可用性和可扩展性。

虚拟网络边界相比传统网络而言更加模糊和复杂，需要更明确的网络边界节点定义以及更合理的网络边界隔离的解决方案。针对虚拟网络的高可用性问题，文献[2]采用的解决方案是关键组件集群式部署，即发生故障时可切换到集群中的备用设备，从而保证高可用。而本文则是从路由模式的角度出发，针对开源云平台中存在的问题，提出了一种分布式实现多租户虚拟网络隔离的解决方案。

2 虚拟网络隔离的分布式实现

2.1 总体架构

与当前主流云平台(如OpenStack)的虚拟网络隔离方式不同，本文提出了一种虚拟网络安全隔离的分布式实现方式，将租户虚拟路由器和防火墙分布到每个计算节点中。总体思路是把原本集中到单一物理节点的虚拟网络边界分散到各台物理服务器，从而将原本集中于同一节点的网络流量分摊到各物理服务器，降低单点故障造成损失的可能性。即使在某个节点上出现故障，也只影响这台服务器上的虚拟机通信，网络中的其他虚拟机仍可以正常通信。

图3的路由模式图给出的是同一租户的虚拟网络(包括子网和分布式虚拟路由)。本文的方案在支持多租户方面，允许每个租户创建相互独立的虚拟子网和虚拟路由器，即同一台物理服务器上可能包含多个租户创建的虚拟路由器和防火墙，利用Linux内核的网络命名空间技术解决可能存在的多租户IP地址冲突问题。此外，图中的内部数据网包括计算节点间的物理网络设备(交换机、路由器等)。

可以对比图3分布式实现的路由模式与图2中OpenStack集中式实现的路由模式。在通过分布式实现的模式中，虚拟机与外网之间的通信，直接通过其所在Hypervisor上的分布式虚拟路由器通向外网；跨子网的虚拟机之间的通信，也直接通过分布式路由进行处理。这两类流量直接由计算节点上的分布式路由处理，无需通过统一的网络边界节点。

图3 分布式实现虚拟网络隔离的路由模式

图4是本文分布式路由的物理架构图。本文采用的虚拟交换机为Open vSwitch，部署在所有物理服务器上，其中虚拟交换机br-int连接Hypervisor上的所有虚拟机。而虚拟交换机br-tun作为处理VXLAN协议的端点VTEP(VXLAN-Tunnel-EndPoint)，对虚拟机出物理服务器的流量进行VXLAN封装，通过数据网网卡转发；对于接收到的VXLAN数据包，则进行解封装处理，转发给连接虚拟机的br-int处理。此外，虚拟交换机br-ex的作用是连接外网网卡，能够处理虚拟机与外网之间的通信。

图4 分布式虚拟网络隔离的物理架构

虚拟路由器利用网络命名空间技术配置，主要由子网网关端口构成，这些子网网关端口可在虚拟交换机上配置对应端口，起到连接虚拟交换机和虚拟路由器的作用。本文部署虚拟路由器的模式是：根据租户虚拟机的分布，在所有包含该租户虚拟机的物理机上为配置分布式虚拟路由器，这些分布式虚拟路由器包含租户下所有子网的网关端口。

为便于说明，设定以下场景：租户A的虚拟网络包含两个子网(子网1和2)，虚拟机分布在两个计算节点上，图4中VMx-y代表计算节点x上属于子网y的虚拟机，两个计算节点各包含两台虚拟机，分别属于租户A的子网1和子网2。两个计算节点的分布式虚拟路由器上均配置了子网1和子网2的网关。

下一节将结合三类虚拟网络边界场景，具体描述分布式虚拟网络隔离的部署模式，并分析对比分布式路由与集中式路由的路由模式。

2.2 虚拟网络安全隔离分析

引言中已经结合实际应用场景，将虚拟网络的边界分为三类，图1列举了这三类网络边界。本文的分布式虚拟网络隔离充分考虑了这三类虚拟网络边界，并有针对性地采用了相应的网络虚拟化技术。本节分别分析本文的分布式实现方案在这三类边界场景下的实际流程和相关技术。

2.2.1 多租户网络之间的边界

网络虚拟化技术使得云服务提供商能够将一套物理网络虚拟化成多套虚拟网络，分别提供给不同的租户。从租户的角度考虑，一个重要的需求就是确保租户网络的安全隔离盒独立性，防止自己的数据遭到来自其他租户的非法访问。

OpenStack现有的实现方式能够很好地支持多租户网络安全隔离，因此本文在隔离多租户虚拟网络方面基本沿用了OpenStack的思路，并将集中式路由改为分布式。在实际部署上，将原先集中部署在网络节点的租户虚拟路由器和防火墙分布到租户虚拟机所在的计算节点上，即所有包含租户A的虚拟机的物理服务器上都部署属于租户A的虚拟路由器和虚拟防火墙。

同一计算节点上可能包含多位租户所创建的虚拟路由器，连接各自的虚拟子网与外网。由于这些虚拟路由器之间默认没有关联，未配置相关联的路由规则，因此租户之间的虚拟网络无法相互访问通信，从而达到不同租户虚拟网络边界安全隔离的目的。

此外，考虑到多租户虚拟网络中，不同租户可能采用相同的内部IP地址资源，从而引起系统中路由、NAT及防火墙规则配置的冲突，因此需要使用Linux的网络命名空间技术。该技术允许在操作系统中定义多个虚拟空间，每个空间可相互独立、透明地进行网络操作，从而能很好地支持多租户虚拟网络的需求。同一物理服务器中多租户虚拟路由器的创建和管理配置正是基于网络命名空间技术实现的。

2.2.2 同租户不同子网之间的边界

传统网络中常使用VLAN技术对网络进行逻辑上的划分，但随着数据中心网络规模以及虚拟机数量的飞速增长，VLAN暴露出一些问题。近年来，VXLAN[8]协议应运而生，能够解决以下几方面的问题：

• VLAN规模限制

当前的VLAN协议中，使用12位数据作为VLAN标签，最多支持4094个子网。随着数据中心规模的扩大以及租户虚拟网络增多，这一数量不足以提供必要的传播的独立性。而在VXLAN中，引入了VNI(虚拟网络标识符)的概念，从12位扩展到了24位，支持超过1600万个子网。

• 多租户支持

数据中心托管多个租户，而每个租户需要流量隔离。这种隔离处于第二层，正如VLAN所提供的。在三层网络的情况下，有可能有两个租户使用相同的三层寻址方案，需要以不同的方式提供隔离。VXLAN可以在现有的基础设施上运行，使用VNI封装虚拟机的数据包，建立VXLAN隧道，区分不同的虚拟子网。

• 交换机的虚拟机数量

在大二层网络环境下，数据流需要通过明确的网络寻址以保证准确到达目的地，因此网络设备的MAC地址表项大小，成为决定云计算环境下虚拟机的规模的上限的因素，限制了整个云计算数据中心的虚拟机数量。而通过VXLAN将虚拟机数据封装在UDP数据包中后，对网络只表现为封装后的网络参数，即VXLAN隧道端点(VTEP)的地址，因此，对于承载网络(特别是接入交换机)的MAC地址规格需求极大降低。

在本文方案中采用基于VXLAN协议的覆盖网络技术，在不同计算节点之间建立VXLAN隧道，对虚拟机之间通信的数据包进行封装，并通过VNI划分不同虚拟子网。

同租户跨子网的虚拟机之间的通信，根据虚拟机的位置分布，可以细分为同一物理机和跨物理机两种情况。在原有的集中式路由模式下，同一租户下跨子网的虚拟机之间的通信都需要经过网络节点上的虚拟路由处理。即使两台在同一物理机上的虚拟机之间通信，由于不处于同一子网，也没有本地的路由关联，因此必须先发送到网络节点。这样的步骤是十分繁琐的，不仅增加了通信中的网络延迟，也带来了引发单点故障的隐患。

通过图5说明本文的分布式路由如何处理同租户跨子网的东西向流量。

图5 跨子网虚拟机通信场景

这里以不同物理机上跨子网虚拟机通信为例，即图5中VM1-1与VM2-2之间的通信。两台虚拟机分别属于子网1和子网2。

在原先的集中式路由模式下，VM1-1发出的数据包在本地没有匹配到路由规则，需要转发到网络节点上的虚拟路由进行处理，具体步骤如下：

1) VM1-1发出数据包，目的地址为VM2-2；

2) 计算节点1的虚拟交换机br-int收到数据包，加上子网1的内部VLAN标签后转发到VTEP(br-tun)；

3) 计算节点1的br-tun将内部VLAN标签转换为子网1对应的VXLAN标识VNI，并从数据网卡通过VXLAN隧道把数据包转发到网络节点；

4) 网络节点的VTEP(br-tun)对数据包进行解封装处理，将子网1的VXLAN标识转换为内部VLAN标签，并转发到虚拟交换机br-int；

5) 网络节点的br-int把数据包交到虚拟路由处理，因为目的地址属于子网2，根据路由规则，数据包通过子网2网关端口转发，回到br-int；

6) 网络节点的br-int把数据包加上子网2的内部VLAN标签，转发到br-tun；

7) 网络节点的br-tun将内部VLAN标签转换为子网2对应的VXLAN标识VNI，并通过VXLAN隧道把数据包转发到计算节点2；

8) 计算节点2的VTEP(br-tun)对数据包进行解封装处理，将子网2的VXLAN标识转换为内部VLAN标签，并转发到虚拟交换机br-int；

9) 计算节点2的br-int将数据包转发到VM2-2对应端口，VM2-2接收到数据包。

可见这是一个复杂的过程，而本文在建立分布式路由后，可将跨子网虚拟机通信简化为以下步骤(与图5中的序号对应)：

1) VM1-1发出数据包，目的IP地址为VM2-2；

2) 计算节点1的虚拟交换机br-int收到数据包，把数据包交到分布式虚拟路由器处理，根据路由规则，将目的地址为VM2-2的数据包通过子网2网关端口转发，回到br-int；

3) 计算节点1的br-int把数据包加上子网2的内部VLAN标签，转发到VTEP(br-tun)；

4) 计算节点1的br-tun将内部VLAN标签转换为子网2对应的VXLAN标识VNI，从数据网卡通过VXLAN隧道把数据包转发到计算节点2；

5) 计算节点2的br-tun对数据包进行解封装处理，将子网2的VXLAN标识转换为内部VLAN标签，并转发到虚拟交换机br-int；

6) 计算节点2的br-int将数据包转发到VM2-2对应端口，VM2-2接收到数据包。

以上通信步骤直接在计算节点间进行，无需经过网络节点处理。

在实际应用场景中，同一租户的不同虚拟机之间也存在访问控制的需求，要通过配置虚拟防火墙的方式实现。与分布式虚拟路由类似，本文的虚拟防火墙同样将原有集中式部署改为分布式部署，防火墙规则通过iptables的形式作用在分布式虚拟路由器对应的网络命名空间中。

2.2.3 租户网络与外网之间的边界

这里以虚拟机VM1-1与外部网络的通信为例，对比集中式路由与分布式路由。子网1的网关记为GW1，虚拟路由器上的外网网关记为EG1。

OpenStack原有的实现方式需要通过网络节点上的虚拟路由器，具体步骤如下：

1) VM1-1发出数据包，目的地址为外网的IP地址；

2) 计算节点1的虚拟交换机br-int收到数据包，加上子网1的内部VLAN标签后转发到VTEP(br-tun)；

3) 计算节点1的br-tun将内部VLAN标签转换为子网1对应的VXLAN标识VNI，并从数据网卡通过VXLAN隧道把数据包转发到网络节点；

4) 网络节点的VTEP(br-tun)对数据包进行解封装处理，将子网1的VXLAN标识转换为内部VLAN标签，并转发到虚拟交换机br-int；

5) 网络节点的br-int把数据包交到虚拟路由处理，因为目的地址属于外部网络，使用NAT规则把数据包源地址改为外网网关端口EG1的地址；并根据路由规则，从EG1转发到外网虚拟交换机(br-ex)上；

6) 网络节点的br-ex通过外网网卡把数据包发送到外网。

与OpenStack原有的方式相比，本文的分布式路由模式在处理虚拟机与外网之间的通信时更为直接。

如图6所示，在计算节点上设置了租户分布式路由器，并配置了外网网卡。虚拟机与外网间的通信不再像原先那样必须通过网络节点，而是通过宿主机上的分布式虚拟路由，从外网网卡直接访问外网。

下面是虚拟机VM1-1访问外网的过程(与图6中的序号对应)：

1) VM1-1发出数据包，目的地址为外网的IP地址；

2) 虚拟交换机br-int收到数据包，把数据包交到分布式虚拟路由器处理，在租户虚拟路由的网络命名空间中，配置了基于iptables的NAT规则，将数据包源地址从VM1-1的私有IP地址转换到外网网关EG1的IP地址，如：

iptables-A POSTROUTING-s 192.168.30.0/24-j SNAT-to-source 10.10.88.51

即数据包源地址转换为外部IP(如10.10.88.51)；

3) 根据虚拟路由的默认规则，确定数据包从外网网关EG1转发到外网虚拟交换机(br-ex)上；

4) 网络节点的br-ex通过外网网卡把数据包发送到外网。

作为隔离过滤外部非法访问的重要手段，本文的虚拟防火墙基于iptables规则配置，与上面的NAT一样，把规则作用在虚拟路由器所在的Linux网络命名空间中。

图6 虚拟机与外网的通信场景

3 部署与实验

3.1 实验环境

本文的实验环境部署在4台物理服务器上，搭建了基于OpenStack Juno版本的环境。Dell服务器的操作系统为CentOS 7，多网卡，其中控制节点使用单网卡(管理网)，计算节点和网络节点使用三网卡(管理网、数据网、外网)，管理网网段10.10.82.0/24，数据网网段10.10.87.0/24，外网网段10.10.88.0/24。

根据本文的分布式实现虚拟网络隔离方式，在这套实验环境中通过租户admin创建了一套基于本文分布式架构的虚拟网络，包括两个子网和4台虚拟机，虚拟机的详细信息(所在物理机、所在子网)见表1所示。

表1 实验环境虚拟机分布信息

租户admin的两个子网IP端分别为192.168.30.0/24和192.168.40.0/24，对应VXLAN标识分别为5和7，两个计算节点上都有两台属于两个不同子网的虚拟机。

根据图4的物理架构，本文的实验环境运用Linux的网络命名空间技术，在两个计算节点上都创建租户admin的分布式虚拟路由器和防火墙，这两个虚拟路由器在配置上是相同的，端口包含两个子网的网关(IP地址分别为192.168.30.1和192.168.40.1)，以及外网网关(IP地址10.10.88.51)。

同样，通过租户admin利用OpenStack原有的方式也创建一套类似的虚拟网络，在配置与虚拟机分布方面与表1相同，便于实验对照。

3.2 网络延迟对比

在本文第2节中，已经通过对比集中式虚拟网络隔离与分布式虚拟网络隔离，分析了分布式架构可以避免虚拟机流量集中到单一网络节点，降低单点故障的可能性；也从理论上分析了本文分布式虚拟网络隔离方案在路由步骤上更加简洁，可以减少跨子网虚拟机通信的网络延迟。本节将给出实验环境中的对比，分析OpenStack原有集中式路由与本文分布式路由在几种不同场景下的网络延迟对比。

根据上文的分析，集中式路由在处理同租户不同子网之间的边界、以及租户虚拟网络与外网边界时存在不合理之处，即租户虚拟机跨子网通信和虚拟机与外网通信这两种情况。其中租户虚拟机跨子网的通信还可以根据虚拟机在计算节点的分布，细分为同一物理机和跨物理机两种。

表1中的虚拟机VM1与VM2位于计算节点1(compute1)，分别属于30和40网段，它们之间的通信属于跨子网同物理机情况；VM1与VM4分别位于计算节点1(compute1)和计算节点2(compute2)，分别属于30和40网段，它们之间的通信属于跨子网跨物理机情况；而VM1与外网的通信则属于虚拟机与外网通信，本文以虚拟机访问www.fudan.edu.cn为例。

图7是本文针对三类不同场景的网络延迟实验结果对比图。柱状图中白色表示OpenStack原有方式下的网络延迟，阴影部分表示本文采用的分布式架构下的网络延迟。可以看到在三类不同场景中，分布式路由模式能有效降低虚拟机的网络延迟。

图7 不同场景下虚拟机网络延迟对比(单位：毫秒)

在以上三类场景中，分布式比集中式的虚拟机网络延迟低的原因是，相比OpenStack原有的集中式虚拟网络路由模式，本文的方式更为直接。不论是虚拟机跨子网通信，还是虚拟机与外网通信，数据包无需专门经过网络节点进行处理，而是直接由所在宿主机上的虚拟路由处理，从而简化了虚拟机数据包在网络中的路由步骤和流程，降低网络延迟。

实验证明，在分布式虚拟网络隔离模式下，虚拟机的数据包直接由宿主机上的分布式虚拟路由器进行处理，减少了虚拟机通信的网络延迟，从而提高虚拟网络中的效率。另一方面，避免虚拟机流量集中到同一个节点，也降低了单点故障的风险。

4 结 语

当前主流开源云平台(如OpenStack)中，虚拟网络隔离采用集中式部署虚拟路由器/防火墙的方式实现，存在单点故障的隐患。本文采用分布式实现虚拟网络隔离的方式，将原先集中部署在单一节点的虚拟路由器/防火墙分布到各计算节点，从而将虚拟机通信流量直接交给宿主机上的分布式虚拟路由器处理，降低发生单点故障影响整个网络通信的可能性。即使在某个物理节点上出现故障，也只影响这台服务器上的虚拟机通信，网络中的其他虚拟机不受影响，仍可以正常通信。实验验证了本文分布式部署架构的有效性，并根据集中式路由与分布式路由的虚拟机网络延迟对比，证实本文的分布式路由可以简化虚拟机的通信流程，降低网络延迟。

本文的部署模型将租户虚拟路由器/防火墙部署在所有相关计算节点上，属于一种静态部署的方式，而云网络中虚拟机迁移与变更时常发生，虚拟路由和防火墙也面临相应的变更。下一步的研究计划是动态确定虚拟网络边界节点的位置，将分布式路由/防火墙部署到相应边界节点(即部分计算节点上)，从而降低虚拟机迁移造成的影响，提高分布式配置的效率。

[1] Jain R, Paul S. Network virtualization and software defined networking for cloud computing: a survey[J]. Communications Magazine, IEEE, 2013, 51(11): 24-31.

[2] Koponen T, Amidon K, Balland P, et al. Network virtualization in multi-tenant datacenters[C]//USENIX NSDI. 2014.

[3] OpenStack[EB/OL].[2015]. http://docs.openstack.org.

[4] Hwang J, Ramakrishnan K K, Wood T. NetVM: high performance and flexible networking using virtualization on commodity platforms[C]//11th USENIX Symposium on Networked Systems Design and Implementation (NSDI 14). Seattle, WA: USENIX Association. 2014: 445-458.

[5] Martins J, Ahmed M, Raiciu C, et al. ClickOS and the art of network function virtualization[C]//Proc. USENIX NSDI. 2014: 459-473.

[6] Gember A, Grandl R, Anand A, et al. Stratos: Virtual middleboxes as first-class entities[J]. UW-Madison TR1771, 2012.

[7] VMware NSX Network Virtualization Design Guide[EB/OL].[2015]. http://www.vmware.com/files/pdf/products/nsx/vmw-nsx-network-virtualization-design-guide.pdf.

[8] Mahalingam M, Dutt D, Duda K, et al. Virtual extensible local area network (VXLAN): A framework for overlaying virtualized layer 2 networks over layer 3 networks[J]. Internet Req. Comments, 2014.

[9] Open vSwitch[EB/OL].[2015]. http://openvswitch.org.

[10] Mudigonda J, Yalagandula P, Mogul J, et al. NetLord: a scalable multi-tenant network architecture for virtualized datacenters.[J]. Acm Sigcomm Computer Communication Review, 2011,41(4):62-73.

[11] Angel S, Ballani H, Karagiannis T, et al. End-to-end performance isolation through virtual datacenters[J]. Osdi14 Usenix Symposium on Operating Systems Design & Implementation, 2014.

RESEARCH ON DISTRIBUTED VIRTUAL NETWORK ISOLATION IN MULTI-TENANT CLOUD-COMPUTING NETWORK

Yan Liyu1,2Zu Lijun3Ye Jiawei1,2*Zhou Yongkai3Wu Chengrong1,2

1(SchoolofComputerScience,FudanUniversity,Shanghai200433,China)2(EngineeringResearchCenterofCyberSecurityAuditingandMonitoring,MinistryofEducation,Shanghai200433,China)3(InstituteofElectronicPayment,ChinaUnionPayCo.,Ltd,Shanghai201201,China)

In recent years, with the rapid development of network virtualization technology, cloud service providers can provide virtual networks abstracted from one set of physical network for tenants. In the multi-tenant network environment, tenants should be guaranteed that their virtual networks are isolated and won’t be accessed illegally from other tenants or outer networks. The definition of the virtual network borders is more obscure than physical network borders, so more fine-grained network isolation is required. Mainstream open source cloud platforms like OpenStack uses centralized network border to realize the isolation of virtual networks, and most traffic of VMs (virtual machines) is converged into single physical node, which may lead to SPOF (single point of failure). Thus, a distributed realization of virtual network isolation is proposed, which distributes the centralized border to each physical server, and the network traffic is distributed to physical servers so that the possibility of loss caused by SPOF will be reduced. Finally, experiments prove the availability of the distributed deployment and the lower network latency of VM communication in the distributed realization.

Multi-tenant virtual network isolation Border of virtual networks Virtual routers Distribution Single point of failure

2015-09-22。严立宇，硕士生，主研领域：信息安全，网络虚拟化。祖立军，工程师。叶家炜，工程师。周雍恺，博士生。吴承荣，副教授。

TP393

A

10.3969/j.issn.1000-386x.2016.11.022