[转]数据中心网络虚拟化 主流平台产品介绍

http://www.sdnlab.com/12076.html SDNLAB

为了对数据中心网络虚拟化有个初步的认识，本文将对当前比较主流的几款商业平台进行介绍，包括VMware公司的网络虚拟化技术，IBM公司的Dove及开源的OpenDove平台， NEC公司的virtual-network-platform和VTN平台,以及Cisco公司的Nexus虚拟化平台。

1.Vmware公司的网络虚拟化技术

VMware在虚拟化领域的领导地位使得我们必须首先介绍一下他们的网络虚拟化技术NSX。然而需要说明的是，网络上有关NSX的技术资料（广告除外）并不多，因此在很多技术细节上我们也无能为力。我们首先关注到VMware公司云计算架构工程师Steve Flanders写的一篇技术博客[1]，其主要内容是介绍VMware公司网络虚拟化技术的发展历史，相信这对于大家了解技术的发展有很大的帮助。然而这篇博客的问题在于几乎没有技术细节，从而使得读者对技术的理解不够深入。为了弥补这个缺陷，本文将在Steve文章的基础之上进行必要的扩充，尽量使得大家能够对VMware的网络虚拟化技术有更深刻的理解。VMware公司的网络虚拟化技术经历了vSwitch,VDS,vCNS,收购NVP,到最终演变为NSX。根据每种技术的不同侧重点，早期的vSwtich和VDS（虚拟交换机）是构建虚拟网络的基础，vCNS和NVP实际上是VMware和Nicira公司各自的虚拟网络平台，而NSX则是在收购Nicira之后VMware推出的统一平台并被寄予厚望。本节的后续部分将按照这种历史顺序进行介绍。

1.1.虚拟交换机

最初的虚拟化技术大多关注于主机端，从而实现对处理器、内存等物理资源的共享。随着虚拟化技术的发展，虚拟机之间以及虚拟机与外部如何通信的问题获得了更多的重视。为了解决这些问题，VMware首先推出了vSwitch技术。顾名思义，vSwitch就是一个虚拟交换机，其主要功能就是实现数据包的交换。换句话说，当网卡接收到数据包时，vSwitch将负责将数据包转发给正确的虚拟机。vSwitch可以简单的认为是一台交换机，因此当系统规模扩大后，如何实现对数万乃至数十万台vSwitch的高效管理成为一个必须解决的问题。

为此，VMware提出了vSwitch的替代方案，即VDS（vNetwork Distributed Switch）。简单来说，如果vSwitch是一个交换机，那么我们可以将VDS看作是一整套网络解决方案，包括交换机和管理系统。如图 1所示，VDS包括数据平面和管理平面。数据平面负责数据的转发和相关操作，而控制平面则负责制定数据平面的规则，这一点与SDN的思想是一致的。特别的是，VDS通过增加一个抽象层可以将整个网络抽象为一个聚合资源来处理。例如，我们可以将一个租户的虚拟机连接到一个虚拟分布式交换机上。从而，对该租户的所有网络配置都可以通过对这一台分布式交换机的配置来完成。假如一个租户有500台虚拟机，并且不幸的是这500台虚拟机分布在500台物理机上。那么，如果采用vSwitch方案，管理员需要分别配置500台虚拟交换机。然而使用VDS方案，这500台虚拟机交换机可以被一台虚拟的分布式交换机所取代，此时管理员只需要配置一台交换机就可以了，这对降低管理复杂度起到了非常重要的作用。另外，VDS为了方便管理员监控和调试网络，提供了对NetFlow和SNMP等传统手段的支持，这大大平滑了网络管理员的学习曲线。然而VDS也存在一些局限性，即VDS主要集中于底层的配置，例如VLAN，虚拟端口以及端口的流量策略等等。对于上层的网络应用，例如流量均衡和防火墙，则没有太多的支持。为了解决这个问题，VMware又推出了vCNS。

图1 VMware VDS架构图[2]

*个人随记

每一台虚拟交换机可以连接一个物理网卡，以及多个虚拟交换机端口组，虚拟机则连接到虚拟交换机端口组中，完成组网操作，并同组内的虚拟机直接通信，也能同物理网络中的host进行通信。不同端口组内的虚拟机数据通信路径是什么样的？

一台ESXi有多少个物理网卡，就能创建多少个可同物理网络通信的虚拟机换机。虚拟交换机可以不连接物理网卡，只组成本地的虚拟局域网。

在一个端口组内的所有虚拟机可统一改变组内虚拟机的网络属性，比如安全设置，流量调整设置，VLAN设置，这可能是端口组的主要作用。

如果虚拟机分布在多台ESXi上，需配置不同的虚拟交换机，复杂。使用VDS将多台虚拟交换机联合起来，组成一个逻辑上的虚拟交换机，并在VDS中配置端口组，这样就可以把不同ESXi上的虚拟机集中到一个端口组中，网络配置会更加方便。

虚拟交换的网络依然是工作在二层网络中的，如果没有VLAN的设置，虚拟机之间的通信是可以被其他虚拟机监听到了。没有网络隔离机制。

VDS的工作就是将分布式的虚拟交换机配置，逻辑上集中了一下。

参考 http://www.07net01.com/2014/09/106670.html

1.2 vCNS

vCNS（vCloud Network and Security）,顾名思义其主要解决的是云环境中的网络和安全问题，其可提供的服务包括虚拟防火墙、VPN、负载均衡和基于VXLAN的虚拟网络扩展等等。如图 2所示，vCNS可以实现为不同的租户构建虚拟数据中心（VDC），并且不同的VDC可以采用完全定制化的网络和安全策略。简单来说，vCNS是由一个个虚拟装置（appliance）构成，例如虚拟防火墙、虚拟DNS服务器等等。为了实现VDC的定制化管理，管理员可以通过配置，实现网络负载流经不同的虚拟装置。在vCNS中存在两种基本的虚拟装置，边缘网关装置（Edge Gateway）和应用防火墙（App Firewall）。其中，边缘网关装置为进入和离开VDC的数据流建立一个网关，并且提供防火墙、IPsec VPN、NAT、静态路由、DHCP和DNS等服务；应用防火墙则直接为某个负载（workload），例如虚拟机，提供保护。vCNS提供两种虚拟装置类型，大大提高了系统配置的灵活性。例如，当只需要对某个负载进行保护时，应用防火墙可以快速的为这个负载建立起保护。此时，管理员并不需要关心数据来自哪里。当需要对某个虚拟域进行管理时，则可以使用虚拟边缘网管设备，从而对进出该域的数据进行管理，而对域内的数据流动不做任何限制。另外，vCNS还支持通过REST API接口来集成第三方的服务，因此具有较好的灵活性。如果大家对NFV的服务链比较了解就可以发现，vCNS实际上已经具备了构建NFV服务链的能力。

图2 VMware vCNS架构图[3]

1.3.NVP

上面的这些技术都是针对于VMware自身平台。实际上，最近几年OpenStack项目非常活跃。VMware显然对于这个巨大的市场也很感兴趣，因此斥资12亿美元收购了由Martin Casado、Nick McKeown和Scott Shenker联合创办的Nicira公司，而该公司的主要产品即是NVP（Network Virtualization Platform）。NVP的主要目的是实现“租户的工作负载无需经过修改就可以迁到多租户数据中心”的愿景。首先，NVP使用隧道技术，在服务器的hypervisor间建隧道，这样做有两个目的：一方面是为了加速虚拟机的迁移，包括实现从原企业网向云端的无缝迁移和数据中心内部不同子网之间自由迁移；另一方面，使用隧道技术亦有助于减少网络设备需维护的网络状态（如与虚拟机MAC、IP相关的信息）。其中，隧道的创建和管理由中央控制器集群——NVP控制集群（NVP Controller Cluster）负责。其次，NVP采用软件实现的虚拟交换机将虚拟机接入网络。NVP平台最终实现的效果是在物理网络上构建虚拟网络，且虚拟网络对物理网络透明，物理网络中设备所见到的不过是物理服务器之间普通的网络流量而已。

如图 3所示，NVP的架构包括两大部分：NVP控制集群和传输节点（Transport Nodes）。NVP控制器逻辑上可分为：OpenFlow控制器（OpenFlow Controller）和配置管理器（Configuration Manager）。

图3 NVP架构[6]

其中，OpenFlow控制器通过OpenFlow协议实现对虚拟交换机内数据转发的管理。由于NVP平台采用Open vSwitch作为虚拟交换机，因此与OpenFlow控制器进行通信的实际上是ovs-vswitchd（OVS守护进程），NVP与Open vSwitch间的交互如图4所示。配置管理器则通过OVSDB管理协议（Open vSwitch Database Management Protocol）来实现对数据库ovsdb的管理。Ovsdb主要用于存储虚拟网络的配置信息，例如虚拟机与hypervisor的对应关系和隧道等相关信息。传输节点包括三种类型：网关节点（Gateway Nodes）、服务节点（Service Nodes）和虚拟交换机。其中，网关节点指数据中心内虚拟网络与外界通信的连接点，可位于数据中心或远程的企业网中。服务节点是可选的，其主要用于为虚拟网络提供多播和广播服务。首先由需要进行多播和广播的主机将数据包发给服务节点，然后由服务节点进行复制并发给对应的目的主机。虚拟交换机（位于Hypervisor内）为虚拟机提供网络接入，并构成网络边缘层（Network Edge）。目前，NVP只控制网络边缘，而核心的物理网络则由专用的物理交换机构成。

图4 NVP与Open vSwitch交互图

NVP采用STT技术（Stateless Transport Tunneling Protocol，无状态传输隧道协议）来构建隧道。一般来说，选择隧道技术时，我们希望它的开销尽可能小。由于STT技术支持一些网卡加速技术（NIC offload），如CKO（Checksum Offloading）和TSO（TCP segmentation offloading），故而基于STT构建隧道一般具有较好的性能。基于NVP技术，建立虚拟网络包括以下三个步骤：

1）hypervisor和网关节点通过OVSDB管理协议为NVP控制集群提供虚拟网卡的位置信息，并当虚拟机发生迁移时更新这一信息。

2）服务提供商通过NVP API配置系统。NVP提供了面向OpenStack的北向接口，可由Openstack提供对网络的配置要求。当有新租户加入系统或已有租户的配置发生改变，或者系统底层的物理配置发生变化，均会触发步骤3）

3）控制器为OVS计算流表和数据库表项（比如数据库中和隧道相关的表项）。然后将计算所得的转发状态（即流表项和数据库表项）通过OpenFlow协议和OVSDB管理协议送到传输节点上。

为了简化上述过程，NVP提出一种新的计算模型，nlog。Nlog是一种声明式语言，因此用户只需告诉NVP要做什么（给出声明），而如何实现则完全由nlog自动完成。Nlog直观看来就是输入到输出的一个映射。输入为配置目标和位置信息，经过nlog计算后得到输出，即流表项和数据库表项。Nlog的声明实质是数据记录查询，每个查询就是对一些数据表的连接（join）操作，最终得到head表。Head表是nlog定义的一种特殊的表，它能将表项导出到nlog的运行时引擎中进行计算。nlog采用增量计算方式，即当参与连接操作的表发生变化时，会对受影响的部分所在的表重新做连接操作。

1.4.NSX

NSX的核心思想是将网络服务化。如图 5所示，如果把虚拟机看作是一个计算服务的容器，NSX创建的虚拟网络则是一个网络服务的容器。这些以软件形式存在的服务则可以是逻辑交换机、逻辑路由器和逻辑防火墙等等。为了构建一个虚拟网络，云管理平台（CMP）首先通过NSX控制提供的RESTful接口发出服务请求；接受到请求之后，NSX控制器将抽象的网络服务分解到相应的虚拟交换机上，并且这些服务（虚拟交换机）与负载（虚拟机）进行逻辑连接。为了与负载进行连接，虚拟网络与传统的物理网络工作原理是相同的，唯一的不同在于虚拟网络中的网络服务实际上是一个分布式软件模块的逻辑实例。这些实例可以直接运行在hypervisor中，从而可以降低实施服务的开销。

图5 NSX网络虚拟化示意图[4]

NSX可以认为是VMware收购Nicira之后将vCNS和NVP进行整合之后的产物，因此NSX具有vCNS和NVP的大部分功能。对于这些重复的内容，我们在这里就不再赘述了。相比较前面的产品而言，NSX一个显著的特点在于它的兼容性。NSX提供了一个可扩展的平台,基于这个平台可以运行任何应用、任何hypervisor、任何的网络基础设施以及任何的网络管理平台。对于用户来说，抽象出来的虚拟网络与物理网络没有什么不同，因此应用不需要为使用虚拟网络做任何修改。另外，NSX已经实现了对Xen、KVM和VMware ESXi等hypervisor，以及CloudStack、OpenStack和VMware vCloud Automation Center的完美支持。因此，NSX是一个开放的平台，并不会导致用户被锁定在VMware自身的平台上，而这一点一般是客户选购产品时非常关注的。

2.IBM公司的网络虚拟化技术

IBM虚拟化平台Dove，全称分布式虚拟覆盖网络（Distributed Overlay Virtual nEtwork）[6]。DOVE为商业版本，IBM为Opendaylight项目提供了相应的开源版本Open Dove。Open Dove基于IBM SDN VE GA 产品和DOVE技术，目前作为虚拟化解决方案之一，被整合在Opendaylight的Hydrogen虚拟化版本中。如图6所示，一个典型的Open Dove虚拟网络平台包括以下部件：

图6 Open Dove架构图[7]

oDMC：Open DOVE管理控制台（Open DOVE Management Console，简称oDMC），用户通过oDMC所提供的REST API来管理虚拟网络、配置Open DOVE网关（此处与NVP中的网关含义相同），用来配置与外部非虚拟化网络的连接。

oDCS：Open Dove连接服务器（Open DOVE Connectivity Server ，简称oDCS），向Open DOVE交换机（简称dSwitch，是对Open vSwitch的扩展）提供地址和policy信息。因为oDCS是Open Dove的核心部件，为保证高可用性及处理性能，Open Dove通过一个轻量级的簇协议（Cluster Protocol）协调多个oDCS实例，即oDCS实为一个服务器集群。为解析policy请求，oDCS需要维护所需的全部信息，而这些信息将以下面5种数据表的形式存在：

1).DOVE虚拟网络表。此表是一张全局表，包含所有当前存在的虚拟网络，oDCS中只有一张。后面的四种表为局部表，每个虚拟网络都维护自己对应的表。

2).DOVE策略域表。指明每个虚拟网络里的策略域（Policy Domain）情况。Dove将一组性质相似的机器（指可以使用同样策略的机器）划为一个策略域，一个源策略域和一个目的策略域定义一个策略（Policy），使用策略域目的是为了对策略进行分类整合，从而减少需维护的策略数量。

3).DOVE策略表。指明每个虚拟网里的所有策略。策略的属性包括：过期时间（Cache Sec）、策略动作、更新次数。

4).DOVE终端表。此表包含虚拟机的ID、名称、所在策略域、IP和其所在物理服务器IP。oDCS中虚拟机相关地址信息的来自后面将要介绍的虚拟交换机，dSwitch。dSwitch通过监测虚拟机发出的包，获得虚拟机的地址信息，并在发生变化时动态更新oDCS。由于dSwitch是通过监测虚拟机发包获得这种对应关系的，所以若一个虚拟机从来没有发过数据包，dSwitch是无法得到该虚拟机地址信息的，即其不知道它所桥接的虚拟机是谁。当oDCS收到策略请求，查其终端表发现目的物理IP域为空，oDCS会执行DOVE地址解析（DOVE Address Resolution），向那些有未知虚拟地址的所有dSwitch发送地址解析包，该包携带虚拟机IP和虚拟网络标识。dSwitch收到后再向与其连接的虚拟机广播ARP请求，相应的虚拟机响应ARP请求，自此oDCS就知道了该虚拟IP与其所在服务器的物理IP的对应关系。

5).DOVE策略动作表。包含每个动作对应的具体配置（Config），及执行这个策略动作的网络设备的IP（在使用源路由方式控制路径时使用）。

oDCS对dSwitch发来的策略请求进行解析、并生成策略的过程就是查询上述数据表的过程。oDCS首先使用终端表获得目的虚拟机对应的物理主机地址，以及该主机对应的策略域ID。然后利用从策略请求中提取的源策略域ID，与刚才获得的目的策略域ID一起查策略表，找到策略项对应的策略动作ID。紧接着，查询策略动作表获得物理网络设备可以识别的具体的配置信息（类似于SDN中的流表项），生成并发送策略回复包（Policy Reply Packet）。DOVE交换机（dSwitch）应该支持所有策略所需的包处理功能，比如流整形，数据通路控制，QoS处理等等。

Open DOVE vSwitch：DOVE虚拟交换机，简称dSwitch。dSwitch是IBM对Open vSwitch做了用户空间扩展后的产品。为了构建隧道，dSwitch同样使用VXLAN的封装格式，但不必像VXLAN采用IP多播来学习虚拟机MAC地址与VTEP IP地址的对应关系，因为其可以依靠oDCS来获取目标地址信息。

Open DOVE Gateway：DOVE网关，这里所谓网关与NVP中网关的含义相同，是指用来连接虚拟化网络与非虚拟化网络的转换器。每个虚拟网络至少要有一个全局的公共IP地址用来连接外部，该IP是在向网络虚拟化平台提供虚拟网络的配置要求时一起指定的。

下面通过一个例子来说明Open Dove的工作原理。如图7所示，现有虚拟机VM-1需要向虚拟机VM-3发送数据，那么数据的具体流动路径如下：

1).VM-1发送的数据到达Host1上的dSwitch

2).dSwitch检查本地缓存，看是否有VM-1到VM-3对应的策略。如果没有，则要向oDCS（此图中为DOVE Policy Service，两者实则为同一组件，只是DOVE Policy Service为DOVE原型系统中的叫法）发出策略请求，并等待oDCS 的回复。回复的策略包括两方面：VM-3所在的主机Host 2的地址，即为VXLAN中需要的VTEP IP；路径控制信息，指定数据包向目的端传输需经过的网络设施。

3).源端dSwitch依照2）所得的信息对包进行封装，然后将数据包发出并经过策略中指定的各网络设备（此处为先FW-I后IDS），DOVE采用源路由方式来实现路径控制。

4).包到达目的dSwitch后，首先进行解封装，并根据虚拟网络标识（Virtual Network Identifier，简称VNI ）及目的地址，将其送给VM-3。

图7 Open Dove工作流程[7]

当虚拟机发生迁移时，新的宿主机dSwitch会通知oDCS关于虚拟机的新的物理位置。但是由于一些主机上存储了虚拟机的旧地址信息，因此还会有数据包被路由到虚拟机的原始宿主机。当dSwitch发现接收到的数据包的目的虚拟机已经发生迁移时，会立即向源端dSwitch发送位置无效信息（Location Invalidation Message）。这时源端的dSwitch就会向oDCS发出请求，并更新其缓存。

3.NEC公司的网络虚拟化技术

NEC公司有两套虚拟网络平台，一个是基于开源控制器Trema[8]的 virtual-network-platform，另一个基于ODL的VTN。两者在实现网络虚拟化的技术也不同，virtual-network-platform采用了目前较热门的VXLAN协议，而VTN则没有采用分装技术。我们并没有找到关于两个平台的官方解释，因此不清楚其商业意图。在此，我们将只对其技术进行讨论。

3.1.NEC virtual-network-platform

为租户提供云服务，必须要保证用户的信息安全和服务质量。NEC从这两方面着手构建了一个中央管理平台，名为virtual-network-platform。该平台可以实现对网络边缘进行控制，并通过使用VXLAN封装技术，实现租户间的安全隔离。另一方面，与IBM的Open Dove不同，NEC在网络核心同样部署Open vSwitch交换机，在其Trema控制器中提供了名为“Sliceable_switch”的应用，通过对网络中心的Open vSwitch进行控制，从而实现性能隔离。

图8 NEC virtual-network-platform架构示意图[9]

如图 8所示，NEC网络虚拟化平台包括虚拟网络控制器(virtual network controller)、虚拟网络代理（virtual network agent）、虚拟交换机（OpenFlow Switch）和VXLAN TEP构成。下面，我们逐一对这些部件进行介绍：

虚拟网络控制器运行在开源的OpenFlow控制Trema之上，其可以进一步分解为配置前端（Configuration Frontend）、后端数据库（Backend Database）和虚拟网络管理器（Virtual Network Manager）。其中，配置前端实际上是一个web服务器，对外提供REST接口，并与OpenStack相兼容。通过这个接口，用户可以创建和删除虚拟网络，并将交换机的端口（提供虚拟机所在虚拟交换机的ID和虚拟机tap设备MAC地址）加入虚拟网络或从虚拟网络删除。基于MySQL的后端数据库可以用来存储虚拟网络的配置信息和OpenFlow交换机及虚拟网络管理器的操作状态。虚拟网络管理器实际上是负责管理虚拟网络的应用。它从后端数据库中获取配置信息，远程配置OpenFlow交换机和VXLAN TEP。

虚拟网络代理、虚拟交换机和VXLAN TEP运行在虚拟机的宿主机中。虚拟网络代理用来接收并处理来自虚拟网络管理器发送来的配置和管理消息，例如配置VXLAN隧道和OpenFlow虚拟交换机。虚拟交换机实现虚拟机之间以及虚拟机和外界的数据交换，而VXLAN TEP则实现VXLAN数据包的封装和解封装。

3.2.NEC VTN

NEC VTN（全称Virtual Tenant Network）是NEC为Opendaylight提供的开源网络虚拟化解决方案，集成在Opendaylight的Hydrogen虚拟化版本中，也集成在Opendaylight的Helium版本中。VTN基于NEC 的ProgrammableFlow GA产品。其与Open Dove均为Opendaylight网络虚拟化解决方案。与Open Dove采用overlay方式实现网络虚拟化不同，VTN采用hop-by-hop的方式，完全通过OpenFlow协议实现网络虚拟化。

VTN由两部分组成：VTN Coordinator和VTN Manager。前者独立于Opendaylight存在，对Opendaylight来说是一个外部应用，后者为Opendaylight的组件（在Hydrogen版本中通过“-virt vtn”选项在启动odl 控制器时启动；在Helium版本中，只需在安装时安装VTN Manager及相关feature，之后启动控制器即可启动VTN）。VTN Coordinator有两个关键的作用：1）提供VTN的REST API接口，与VTN Manager交互实现用户配置, 2）协调多个odl控制器，使得可以跨越控制器实现一个大虚拟网络（VTN）。VTN Manager为实现网络虚拟化的部件。

VTN将底层的物理网络抽象出一系列的虚拟节点（vNode），例如如vBridge、vRouter、vTunnel等等。VTN中最基础的虚拟节点即vBridge，它并不是一个真实的bridge ，而是一个2层域。如图9所示，这里的vBridge实际是从Host1到Host3间的三个交换机构成的一个2层物理网络。在VTN中，用户首先定义一个VTN，即一个虚拟网络（如VTN1），然后将物理网络通过端口或VLAN映射的方式映射到一个虚拟网络中。与Host1连接的交换机端口被映射到vBridge的一个虚拟接口（vInterface），与Host3连接的端口被映射到vBridge的另一个接口。即Host1与Host3看起来是直接连接在同一个交换机设备上（此处的vBridge）。经此，一个复杂的网络就被抽象成一些vBridge等基本元件连接的简单网络。为上层应用和操作者提供简单的网络接口而掩盖底层物理网络的复杂性。

图9 NEC VTN抽象的vBridge[10]

如图 10所示，VTN实现网络隔离的原理解释如下：MAC1（指mac地址为MAC1的虚拟机）向MAC2发送数据包，数据包到达Switch-A后发送packet_in给odl控制器，控制器收到此packet_in后通知VTN Manager，VTN Manager通过这一packet_in消息判断发送此数据包的端口是被映射到哪个vBridge中的。VTN Manager为每个vBridge都单独分配一张MAC-PORT表，并在收到数据包后只在对应的vBridge中查找转发信息，从而与别的vBridge（虚拟网络）相隔离。VTN从此vBridge的MAC-PORT表中查到目的MAC地址位于哪个交换机的哪个端口上，然后将查找结果，即（源交换机，源交换机端口，目的交换机，目的交换机端口），送于控制器，由控制器算得相应的路由路径。可见VTN Manager是靠在OpenFlow控制器中为每个虚拟网络维护各自的网络视图来实现网络虚拟化的。

图10-VTN工作原理图[11]

4.Cisco Nexus Virtual Services Appliance

Cisco Nexus Virtual Services Appliance是Cisco的专用硬件虚拟化平台，其是一个系列产品，有：Cisco Nexus 1010, Cisco Nexus 1010-X, Cisco Nexus 1110-S, 和 Cisco Nexus 1110-X。其上运行对应的虚拟化软件服务产品Cisco Nexus 1000V virtual service blades，简称VSB。VSB包括Cisco Nexus 1000V Virtual Supervisor Module (VSM), Network Analysis Module (NAM), Virtual Security Gateway(VSG), 以及Data Center Network Management Module (DCNM)等。Cisco为了提高虚拟化平台的性能，将软件虚拟化产品以“可插拔”的形式运行在专用的高性能硬件平台上，一个Cisco Nexus Virtual Services Appliance上可运行6-10个VSB（产品名称后加-X的为可运行10个）。 在Cisco Nexus Virtual Services Appliance 的bootflash库中，有VSB的ISO或OVA文件，通过它们来创建VSB。

思科的虚拟化平台中使用的虚拟交换机为 Cisco Nexus 1000V，它包含VEM（virtual Ethernet module）和VSM两部分，其中VEM运行在ESXi服务器上取代VMware原有的虚拟交换机，VSM是单独运行在一台虚拟机上（此处作为一个VSB运行在Cisco Nexus Virtual Services Appliance上）。VSM提供了命令行接口，用于管理和配置整个虚拟交换机，1个VSM对应多个VEM，即所谓分布式虚拟交换机。思科数据通路与其硬件管理平台间的联系是通过虚拟服务数据通路（Virtual Service Datapath，简称vPath）实现的。vPath是Cisco Nexus 1000V交换机的VEM模块实现的一个功能，它的作用是可以在交换机将数据包下发到虚拟机前将数据包重定向到提供虚拟服务的节点。

服务平面（Service Plane）：为交换机到虚拟服务节点间通过GRE、VXLAN-GPE等隧道技术建立隧道形成的服务平面。虚拟服务节电可以如防火墙、负载均衡等服务。这些服务节点可硬件可软件，可以是运行在Cisco硬件虚拟化平台上，也可以是运行在虚拟机上。Cisco为不同租户定义不同策略，而策略实质上即是一条服务链。服务链包含两层意思：1）此租户的数据包要经过哪些虚拟服务2）该租户的数据包以怎样的顺序经过这些虚拟服务节点。为了实现正确的路由，故在VXLAN的封装头之后原始包之前加入了另一个头，称为网络服务头（Network Service Header，简称NSH）。NSH头包括两部分内容：1）服务路径相关信息（服务节点要利用它来选择服务路径上的下一个服务节点），2）为途径的网络设备和服务设备提供所需的元数据。NSH服务头是由具有服务分类功能的设备或应用添加，该设备或应用可以确定哪些数据包需要服务，需要哪些服务，相应地经过怎样的服务路径。并且Cisco还实现了NSH代理（NSH Proxy）。该代理作为gateway用于为数据包去掉或插入NSH 头，从而与其他网络服务节点相兼容。

在物理网络中，实现网络服务（如服务器的负载均衡，防火墙等）通常方法是在服务器间的物理通路上放置中间盒（MiddleBox，即网络服务设备）。与Cisco vPath相比，这样的网络服务拓扑称为静态服务拓扑，它有明显的缺点：1、拓扑改变频繁。当我们需要改变流量经过的服务或服务的顺序时必须改变拓扑，因此，当服务要求改变频繁时，拓扑也得随之频繁改变；2、不区分流量。在这样的拓扑中，所有的应用无论需不需要某个服务都得严格的按照拓扑顺序经过拓扑路径上的所有服务。

Data Center Network Management Module (DCNM) （本质上是一种VSB，相当于其他平台的中央控制器）为网络虚拟化提供了中央管理。DCNM中的模块，中央管理点（Central Point of Management ，简称CPOM)），负责制定policy。DCNM还提供接口与云管理平台OpenStack 、Cisco UCS Director、VMware vCloud Director (vCD)集成。总之，Cisco采用的硬件虚拟化平台的概念是：将实现网络虚拟化的各个模块及网络服务都以VSB的形式运行在此硬件虚拟化平台上（当然部分部件也可运行在虚拟机上），由vPath指导数据包在这些部件间流动。

5.总结

综上所述，目前各大公司都在围绕自身的平台开发了相应的虚拟网络管理平台。这些平台的功能类似，即通过一个集中式的控制器实现对虚拟网络的管理和配置，例如哪些虚拟机属于一个虚拟网络、以及这些虚拟机与物理机的对应关系等。为了实现不同虚拟网络之间的数据隔离以及便于虚拟机的迁移，这些虚拟平台（除了NEC VTN）都采用了一定的封装技术，例如VXLAN。NEC VTN没有采用隧道技术，而是采用维护vBridge的方式来隔离不同虚拟网络的流量。这样做的好处在于可以在网络上进行更细粒度的流控，但是同时也增大了网络设备的负担。Cisco的Nexus虚拟化网络方案与其他方案有些不同，他提供了专用的高性能虚拟化物理平台，并且将虚拟化服务以VSB的形式运行其上。Cisco这样做肯定有很多原因，但是我们认为其希望维护自身的“垄断”地位也应该是一个非常重要的原因。笔者认为，基于标准的X86平台进行网络功能虚拟化，应该是大势所趋，这也是NFV的核心思想。开放的OpenStack就是一个例子，上述的虚拟化平台都提供了相应的支持或扩展方法，即使WMware也不例外。

参考文献
[1]Steve Flanders，The History and Future of VMware Networking，http://sflanders.net/2013/09/04/history-future-vmware-networking/
[2]Distributed Switch, http://www.vmware.com/cn/products/vsphere/
features/distributed-switch.html
[3]VMware vCloud Networking and Security Overview,

https://www.vmware.com/files/pdf/products/vcns/vmware-vcloud-networking-and-security-overview.pdf

[4]The VMware NSX Network Virtualization Platform

http://www.vmware.com/files/pdf/products/nsx/VMware-NSX-Network-Virtualization-Platform-WP.pdf

[5]DOVE: Distributed Overlay Virtual nEtwork Architecture

http://domino.research.ibm.com/library/cyberdig.nsf/papers/D7D93A33CF54F46585257A4C004947BD/$File/H-0315.pdf

[6]Network Virtualization in Multi-tenant Datacenters

https://www.usenix.org/system/files/conference/nsdi14/nsdi14-paper-koponen.pdf

[7]Open Dove, https://wiki.opendaylight.org/view/Open_DOVE:Proposal
[8]Trema, http://trema.github.io/trema/
[9]Trema/Virtual-Network-Platform

https://github.com/trema/virtual-network-platform

[10]VTN,How to configure L2 Network with Single Controller

https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_%28VTN%29:VTN_Coordinator:RestApi:How_to_configure_L2_Network_with_Single_Controller

[11]OpenDaylight Network Virtualization and its Future Direction

https://wiki.opendaylight.org/images/3/30/ODL-MiniSummit-Virt-Final.pdf