虚拟化厂商的应对之法

　　市场上有多家提供虚拟化解决方案的厂商，例如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将变化或者对变化的抽样调查通知给网络团队，并将其与传统的网络数据一同显示出来。这些方法在一定程度上解决了可视性的问题。