参与调查：是什么影响了您虚拟化的的进程

    服务器虚拟化在数据中心领域中正得到越来越广泛的实际应用。经济因素与这一趋势密不可分。服务器虚拟化可减少服务器的数量，所需的制冷能力和功率都更小，同时也大幅增加了灵活性，因此可以有效地降低总体拥有成本（TCO）。对于业务和服务器团队而言，这的确是好消息，但对于网络的管理来说，它又会产生怎样的影响呢？事实情况是，它会使网络管理变得更加复杂。

服务器虚拟化会牵涉到两项重大的网络问题。首先是虚拟局域网（VLAN）的配置问题。网络管理者必须确认当物理服务器运行虚拟机时，同样的交换机端口也被分配给了虚拟机使用的虚拟局域网。

解决方法之一是，服务器虚拟化团队将虚拟机可能启动的每一台服务器告诉网络管理团队，并且对交换机端口进行预先配置。但这并不是理想的解决方案，因为这将导致在很大比例的交换机端口上定义VLAN。由于服务器团队可能并不清楚镜像启动时所用的所有服务器，特别在灾难恢复情况下他们要采取紧急措施的时候，情况将变得更加复杂。

第二个问题是指定服务质量（QoS）和执行网络协议，例如访问控制列表（ACL）。传统上，这项工作是在与应用所运行的服务器相连的网络交换机上完成的。当有了服务器虚拟化后，就出现了运行在物理服务器的 Hypervisor下的软件交换机，而非传统意义上的连接到物理服务器的物理网络交换机。

在软件交换机上执行协议还是很重要。例如，有两台虚拟机，我们本意是这两台虚拟机相互通信，但如果有人控制了虚拟机1，便可以打开与虚拟机2的连接并盗取数据。而我们如果对服务器上的软件交换机实施了访问控制列表，这种***活动便可被阻止。

在虚拟化之前，此类行为一般都可阻止，由于虚拟机1和虚拟机2运行在不同的服务器上，因而可以通过在网络交换机上定义访问控制列表来阻止这种通信。在软件交换机上执行这种协议可以保持安全性。但问题在于，如何让软件来实施协议。

要想使服务器虚拟化顺利开展，克服这些挑战将至关重要。目前，共有四种方法来解决这些问题。

虚拟化厂商的应对之法

市场上有多家提供虚拟化解决方案的厂商，例如VMware、思杰、微软、红帽等。不过，Vmware的解决方案应用最为广泛，因此我们以它来举例说明。

在图1中，VMware的vCenter控制着虚拟流程并指导虚拟机应在哪里启动。Hypervisor控制着服务器和运行在物理服务器上的虚拟机。 vSwitch是VMware提供的一种2层软件交换机。每台虚拟机都有一个虚拟网卡（vNIC）。vNIC使用的是来自虚拟化厂商的访问控制清单地址池，或者是企业建立和分配的访问控制清单地址。该图的目的并不是显示真实环境下所有可能的变化情况，它只是展示整个虚拟化流程是如何运转的。

步骤1是由服务器团队定义出虚拟机的所有网络特性和协议。操作员会告诉vCenter在步骤2中启动虚拟机2。该过程中，vCenter和服务器上的 Hypervisor之间会互相传递多条消息，例如，vCenter会将网络协议信息推送给Hypervisor。在步骤3中，Hypervisor会为 vSwitch配置正确的VLAN、QoS和协议信息。当虚拟机2上的应用开始发送包时，该协议会在vSwitch上实施（图1中的蓝点表示）。

这种方法解决了在vSwitch上实施协议的问题，但并没有解决网络交换机中的VLAN配置问题。虚拟化团队需要告诉网络管理团队，应在虚拟机开始发送流量之前，为VLAN配置交换机端口，这就要求进行快速协调或者对交换机进行预先配置。当虚拟化团队需要对虚拟机进行动态迁移时，协调问题会变得更加复杂。在移动服务器时，虚拟化团队需要与网络团队进行协调，而且网络团队需要在成功迁移后完全清除老交换机上的配置。

使用该方法最大的问题是，虚拟化和网络团队之间进行协调的工作量将很大。虚拟化团队必须对vCenter中的参数进行配置，例如VLAN编号、QoS和 ACL等，而这些参数又是由网络团队控制的。这意味着服务器虚拟化团队和网络团队之间需要不间断的良好协调。VLAN或协议中的任何变化都必须立即反映到虚拟服务器配置中，而这其实意味着一个潜在的故障点。

另外一个值得担忧的问题是，网络团队难以了解vSwitch内部的工作情况。因为vSwitch处在vCenter的控制下，而非传统的网络管理软件。此外，对网络团队而言，虚拟机的透明度也极低。一些网络厂商已经要求vCenter将变化或者对变化的抽样调查通知给网络团队，并将其与传统的网络数据一同显示出来。这些方法在一定程度上解决了可视性的问题。

四大方案破解VLAN配置问题

第一种方案是实现交换机与虚拟机管理软件的同步。Blade Networks目前提供了一种在其交换机上运行的应用，而Force10公司的下一版操作系统也可以解决VLAN的配置问题。这两家公司的交换机会对 vCenter进行查询，监测各种变化，也可以收到vCenter发出宣告变化的消息。如果交换机发现vCenter配置有变化，它会自动执行配置。虚拟化操作员不必与网络运营部门进行协调，因此能够使虚拟机的启动过程变得非常顺利。交换机查询间隔一定要小于一台虚拟机启动的时间，从而确保交换机能够以足够快的速度看到变化。在Force10的第一个版本中，它惟一监视的参数就是VLAN的参数。Blade Network则更进一步，根据vNIC或VM的UUID（通用唯一识别码）对网络交换机实施了全系列的协议。该解决方案仍然需要在vSwitch中实施协议。

第二种解决VLAN配置问题的方法是通过中间件协调控制虚拟机管理软件和交换机。例如，使用惠普或Juniper等厂商提供的协调软件，但这些软件只能在其原厂的交换机上运行。Scalent和CA等管理厂商也提供了自己的解决方案。在这种情况下，协调软件会与网络交换机和vCenter对话，并协调两个环境之间的配置变化。这种方法有一定的潜在优势，即能够广泛适用于众多交换机和虚拟化厂商。

第三种方案来自于思科。思科提供了一种称为"1000V"的软件交换机解决方案，用于替代vSwitch。1000V由两个组件组成：VSM（Virtual Switch Module）是虚拟交换机模块，用于替代运行在Hypervisor内的vSwitch软件；VEM（Virtual Element Manager）则用于配置和存储VSM网络协议。

图2显示的是该过程的工作原理。首先根据虚拟机的UUID或vMAC地址，在VEM中对虚拟机的VLAN和协议进行配置。在步骤2中，vCenter启动一台新的虚拟机或移动一台虚拟机。在步骤3中，Hypervisor向VSM发出通知。接下来，VSM在第四个步骤中从VEM中提取协议信息。如果网络交换机属于Nexus产品线，它也可以从VEM中提取必要的VLAN和协议信息。至此，Hypervisor中的交换机和Nexus交换机都获得了处理虚拟机2的正确信息。当虚拟机2 开始发送流量时，所有正确的协议都会在Hypervisor中的1000V交换机上开始实施（以蓝点表示）。

思科方案的好处与第一种方法相同。如果将1000V与已经为虚拟化做好准备的Nexus交换机一同使用，那么就可以解决网络交换机中的VLAN问题。该方案的另一个好处在于，可以移动在网络管理软件的控制下的 Hypervisor中的交换机，从而能够清楚地划分网络团队应担负的责任。当然，它也有不足的一面。目前，思科只能提供适用于VMware的解决方案，对于Xen和HyperV则无能为力。

第四种方法采用了一种以网络设备为中心的视角来解决问题。如附图3所示，在步骤1中，按照虚拟网卡在网络管理软件中对虚拟机进行了定义。在步骤2中，vCenter指导Hypervisor启动虚拟机。在第三个步骤中，Hypervisor会发送一个公告包，宣布它正在启动二号虚拟机。该公告中包含二号虚拟机的vNIC及其UUID。在步骤4 中，交换机发现了该公告并发送其VLAN和其它协议信息的请求。接下来，交换机会向进入网络的任何流量实施这些协议。

该方案的重点是交换机只在网络交换机中实施协议，以蓝点表示，而不会在vSwitch中实施。交换机还会监视来自Hypervisor的消息，这些消息表明虚拟机是否移动。如果发现此类消息，交换机便会清除与该vNIC相关的VLAN和协议信息。使用该解决方案的厂商包括Arista Networks、Blade and Enterasys，另外惠普和Juniper也在通过其协调方法使用该解决方案。Brocade等其它厂商也在计划提供该解决方案。Extreme Networks将该技术用于QoS和协议，但未用于VLAN。

这种方法努力想让虚拟化团队不再被牵连到网络协议的实施工作中来。然而，还有两个问题。首先是服务器虚拟化和联网团队仍然必须就VLAN的编号进行协调。目前，Enterasys可以向vSwitch自动提供VLAN编号，而Arista也计划在近期加入该功能。

这种方法最大的问题是，它没有在vSwitch上实施协议，因而使得同一服务器上的虚机之间的交通流量绕过访问控制列表和其它安全协议。为解决这一问题，Enterasys和Arista计划添加在vSwitch上实施协议的能力，如图3中A所示。

在未来，解决这一问题的办法之一是允许交换机做"180度急转弯"。这样，可对vSwitch进行配置，规定其将所有的流量，甚至包括虚拟机1至虚拟机2的流量，都直接发送给网络交换机。网络交换机接下来会实施协议并指定QoS。虚拟机1至虚拟机2的流量可以回传至vSwitch，由它将其发送至虚拟机2。

这将使vSwitch变成一个只担负转发职责的"哑巴"交换机。问题是，所有2层交换机对应的802.1D标准不允许从一个端口发出的流量沿原路返回到该端口。因此，在现行的规则下，网络交换机无法将从虚拟机1发往虚拟机2的包沿原路返回，因为这样是违反规则的。该规则的目的是防止出现回路。IEEE目前正在对802.1D进行修订，允许交换机执行"180度急转弯"，并且正在开展其它一些工作，实现"哑"交换机在Hypervisor中的标准化。当这种方式普及后，它将能够解决这一问题，并且可以免去网络和服务器团队之间绝大多数的协调工作。

Enterasys 目前还有一种变通办法，可以指导vSwitch将每台虚拟机安置在独立的VLAN中。即选择目前没有使用的VLAN编号，来预防任何潜在的问题。由于虚拟机处于不同的VLAN中，它们无法相互通信。当数据包到达网络交换机时，交换机会使用真正分配给虚拟机的编号来替换VLAN编号，让网络及其目的地以为虚拟机一直处于正确的VLAN中。

问题仍未彻底解决

另外，还有一个VLAN配置问题是上述技术仍然没有解决的。当向某个端口分配一个新的VLAN编号时，需要使用该VLAN编号连接所有其它的端口。这就要求聚集在这条在路径上的所有交换机都要对VLAN进行定义。

例如，如果VLAN 5支持某项应付账应用。所有支持该应用的虚拟机都位于一台机架式交换机上，且该交换机已经针对VLAN 5进行了配置。由于负载的原因，一台运行应付账应用的虚拟机需要被迁移到数据中心另外一个带有自己交换机的机架服务器上。

保留VLAN意味着所有的中间交换机都需要针对VLAN5进行配置；如果未对其进行配置，则等于破坏了VLAN。目前没有那个解决方案说清楚如何自动分配交换机中的虚拟局域网。这就意味着如果虚拟机可以在数据中心内部迁移，虚拟局域网数量必须在所有的核心交换机和集合交换机上事先进行配置。。此外，这个问题在近期内不太可能得到解决。

业界已经开发出一系列解决端口VLAN和协议问题的解决方案。但是，短期内，网络和虚拟化团队需要进行大量的协调工作，以保障工作的顺利运行。"180度急转"是最好的长期性解决方案，而且业界正在朝这个方向努力。由于目前市场上还没有出现能够适用于所有虚拟化解决方案的全系列解决方案，因此网络管理者们应当充分了解各种解决方案。

【深度点评】

为了更加全面地看待本文所探讨的问题，本报特地邀请服务器虚拟化方面的专家，对此文进行深度点评，期冀能给读者呈现更深更广的视角。

本文讨论的是网络厂商针对服务器虚拟化所做出的技术反映。文章讨论了4种技术方案，VMware的vSwitch（方案1）和思科的1000v（方案3）的基本思路是一致；方案2的orchestration类似于一种中间件，这符合惠普一贯的作风，不过他们擅长做管理软件吗？而且我不喜欢这种方式，层次太多更不好管理；方案4是较好的方案，更有可能在虚拟机管理软件和网络设备间建立一种标准协议，从而实现不同虚拟机厂商和网络厂商的兼容。

对这个问题，我希望的解决方案是这样的：

1.应该是以虚拟化管理软件为中心，这个软件管理的不仅是虚拟机和物理服务器，而且包括所有的网络设备；

2．传统上网络系统中链接主机的最后一条（last hop）是硬件交换机，而在虚拟化环境中一定是软交换机（如vSwitch或v1000）；

3．不论是软交换机还是硬交换机，要提供可编程的控制接口或者标准协议，所有网络设备由统一的管理软件（如虚拟化管理软件，类似vCenter或更上层的管理软件）进行管理。

总地说来，这篇文章很好，提的问题很实际，有一定深度。不过文章的标题看起来有点夸张，实际上虚拟化是未来的一种趋势，当一种技术带来更大的灵活性，使人们能够完成以前无法完成的任务的同时，必然会带来更大的复杂性。虚拟化是一种潮流，从处理器到服务器，然后将是网络，再接着是整个IT基础设施，再之后呢，无限的空间可以想象……

--中国移动研究院云计算研究员  张志宏

文中提到的由服务器虚拟化所引起的两个重大的网络问题，即虚拟局域网（VLAN）的配置问题以及服务质量（QoS）和执行网络协议问题，确实是一直以来困扰服务器虚拟化厂商和网络管理厂商的难题，也在某种程度上影响了服务器虚拟化的顺利开展。

针对这两个问题，文中提到了四种解决方案，但这四种方案都存在一定的局限性。

VMware通过对内置于Hypervisor中的vSwitch进行配置来解决实施协议的问题，但对VLAN的配置问题依然没有触及。

为了解决VLAN的配置问题，虚拟化组件群和网络组件群之间的协调是关键所在，Force10和Blade Networks通过在交换机上安装监控程序来监听vCenter的变化，惠普和Juniper等厂商也提供了协调软件，但这些软件只能在其自家生产的交换机上运行，Scalent和CA等管理厂商推出了会与网络交换机和vCenter对话的协调软件。

思科的解决方案与VMware有异曲同工之处，配合为虚拟化做好准备的Nexus交换机一同使用，也可以解决VLAN的配置问题，但该方法主要针对VMware的服务器虚拟化产品提出的，对其它服务器虚拟化产品则束手无策，局限性很明显。

第四种方法以网络设备为中心的视角来解决问题，主要体现在Hypervisor直接与网络交换机进行通信，仅在网络交换机上实施协议，支持厂商有 Arista Networks, Blade and Enterasys等。该方法旨在让虚拟化团队不再参与网络协议的实施工作，但同时也产生了两个问题，其一是服务器虚拟化和网络团队仍然必须就VLAN的编号进行协调，对该问题，Enterasys目前提供了一种变通办法；其二是由于没有在vSwitch上实施协议，使得同一服务器上的虚机之间的交通流量绕过访问控制列表和其它安全协议，该问题是一个非常重要的问题，Enterasys和Arista等都在寻求积极的解，甚至IEEE也参与到这一热潮中，正在通过对802.1D进行修订，以及对vSwitch的标准化来对解决这些问题提供支持。

从上面的解决方案及其演进过程中，我们不难看出，这些方法多是互联网和虚拟化团队在短期内协调各项活动，甚而是特定厂商特定产品之间的协调，而非长久之计。

--运软网络科技（上海）有限公司研究工程师 熊丽 博士