服务器虚拟化使网络管理变得更复杂

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

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

首先根据虚拟机的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和协议信息。使用该解决方案的厂商包括AristaNetworks、BladeandEnterasys，另外惠普和Juniper也在通过其协调方法使用该解决方案。Brocade等其它厂商也在计划提供该解决方案。ExtremeNetworks将该技术用于QoS和协议，但未用于VLAN。

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

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

在未来，解决这一问题的办法之一是允许交换机做"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进行定义。

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

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

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

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友