我是你爱情的俘虏:解决服务器虚拟化带来的管理难题

来源:百度文库 编辑:偶看新闻 时间:2024/05/09 10:27:28

解决服务器虚拟化带来的管理难题(The Dark Side of Server Visualization)

韩菊 编译,计算机世界,2010-07-20

服务器的虚拟化在数据中心变得越来越普及。推动服务器虚拟化普及的最大推动来自于经济方面上的节约:服务器的虚拟化减少了物理服务器的数量,降低了冷却功耗,同时提高了灵活性。这有利于所有的业务部门和服务器管理部门,但它对网络管理有何影响呢? 事实是,它使网络管理变复杂了。具体来说,服务器虚拟化带来两个大的网络问题。首先是VLAN(虚拟局域网)的配置。网络管理员需要确保虚拟机(VM)使用的VLAN和运行虚拟机的物理服务器可以分配相同的交换机端口。

 对于服务器虚拟化的管理人员而言,一种解决方案是告诉网络设备管 理组每个虚拟机上可能启动的每一个服务器,并预先为这些服务器配置交换机端口。这不是一个完美的解决方案,因为它可以导致交换机端口上配置太多的 VLAN,而服务器管理组可能不知道这个物理服务器上运行有这么多的虚拟服务器,这就使得网络管理变得更加复杂,特别是在紧急情况下需要采取措施快速恢复系统时,这一情况更为严重。

 第二个问题是确保QoS和网络访问策略得到执行,如访问控制列表(ACL)。以前,访问控制策略是由和应用服务器相连的网络交换机来执行。而服务器虚拟化之后,这个工作改由Hypervisor下面的软交换机来完成,而不再由与物理服务器相连的物理网络交换机来完成了。

 访问控制策略的执行对软交换机中仍然是重要的。例如,即使运行在同一个物理服务器上的两个虚拟机不允许互相通信,但控制了虚拟机1仍然有可能与打开虚拟机2的连接,窃取虚拟机2上的数据资料。而如果访问控制列表是由服务器中的软交换来实施的,这就可以被阻止。在采用虚拟化技术之前,虚拟机1和虚拟机2运行在不同的物理服务器上,物理交换机将根据访问控制列表阻止两个虚拟机之间的通信。软交换机也必须通过这些策略来维护网络安全,现在问题是如何通过软件来执行这些策略。

 解决上述两个问题对于服务器虚拟化的顺利进行是非常重要的。如果供应商们制定出一个统一的标准,适用于所有不同的虚拟化厂商那就很好了。实际情况是,由于虚拟化这门新技术还处在迅速发展之中,这种标准也并没有出现。目前,行业内有四种途径来解决这些问题。

 虚拟化厂商的解决方案

引领服务器虚拟化市场的厂商是VMware,除此之外市场上也存在其他许多虚拟化产品,包括Citrix的Zen、微软的Hyper - V的、红帽的KVM和其他许多小供应商的产品。当然,最广泛使用的产品还是VMware的产品,因此,这里以VMware的产品为例说明解决办法。

 VMware的vCenter控制虚拟化的整个过程,并指示在哪里安装虚拟机。Hypervisor控制服务器和在物理服务器上运行的虚拟机。 vSwitch是VMware提供的一个软件形式的2层交换机。每个虚拟机有一个虚拟网卡(vNIC),该虚拟网卡的MAC地址要么使用虚拟化厂商提供的 MAC地址池中的一个,要么使用由企业为之分配的MAC地址。访问控制策略的配置过程如下:

1、  由服务器管理人员定义虚拟机的所有网络设备的属性和安全策略。

2、  操作人员通知vCenter启动VM2。在这个过程中vCenter和服务器上的Hypervisor之间要进行多次通信,其中一个重要内容是把网络策略信息推送给Hypervisor。

3、  Hypervisor根据正确的VLAN、QoS和策略信息配置虚拟交换机(vSwitch)。当VM2上的应用程序向外发送数据包的时候,vSwitch将执行这些访问策略。

 

  

图1 虚拟化中心的控制

 这解决了在第一个交换机上应用访问控制策略的问题,但它并没有真正解决网络交换机上VLAN的配置问题。在虚拟机开始向外发送数据包之前,虚拟化管理人 员需要告诉网络管理人员在交换机端口上配置VLAN。这需要快速协调并迅速完成或者预先配置好。当虚拟机根据虚拟化管理人员的安排在多个物理服务器之间迅 速迁移时,这种协调变得更加复杂。此时,如果虚拟化管理人员要迁移虚拟机,它就要与网络管理人员进行沟通;一旦迁移完成,网络管理人员还需要把原来交换机上的那些配置信息全部清除。

 这一解决方案最大的问题是需要虚拟化管理人员和网络管理人员之间的协调。虚拟化管理人员必须配置 vCenter参数,而这些参数由网络管理人员掌握,例如VLAN号、QoS和ACL策略。这意味着服务器虚拟化和网络化管理人员之间需要一直保持高度的协调。否则,虚拟局域网或访问策略有任何改变都可能会导致另一个故障点的出现,为此任何改变必须立即反映到虚拟服务器的配置中。

 另一个令人关注的问题是,服务器虚拟化管理者对由网络管理人员管理的网络组件vSwitch中正在发生的事情不了解(可视性不足)。 vSwitch在vCenter的控制之下,但它不是传统的网络管理软件。此外,网络管理人员对于虚拟机也几乎毫不知情。不过,目前上述问题已得到解决,一些网络厂商通过让vCenter通知网络工作团队这些变更或对网络配置变更情况进行轮询,然后和传统的网络数据一起显示出来,这将大大有助于网络问题的解决。

 其他四种解决方法

 Blade网络公司在其交换机上安装了一个新的应用以解决VLAN的问题,而 Force10在它的下一个交换机操作系统中也承诺会解决VLAN 问题。这些交换机对vCenter进行轮询以发现可能做的任何更改,或者持续监听vCenter发送的配置更改信息。如果交换机发现这些信息有任何改变, 它会自动进行重新配置。这样虚拟化管理人员就不需要与网络管理人员就这些变更进行协调就可顺利地启动虚拟机运行。轮询间隔必须比启动虚拟机的时间更短,这可以确保交换机能第一时间发现变化。在Force10的操作系统第一个版本中它监控的唯一参数是VLAN。Blade网络公司更进一步,它根据vNIC或 VM的UUID把各种访问策略应用到网络交换机上。所有这些策略最终都由vSwitch来实施。

 解决配置问题的第二种方法是利用交换机供应商提供的Orchestration软件,这种软件运行在交换机上。惠普和Juniper都有这样的软件,另有一些管理软件厂商也提供类似的解决方案,如Scalent和CA。Orchestration软件的作用是在网络交换机和vCenter之间担当中介,协调两个环境之间的配置更改。这种方法的优点就是,让更多交换机厂商和虚拟化厂商的产品能够一起工作。

 思科也推出了自己的解决方案,它用自己开发的1000v软交换机来替代vSwitch。1000V有两个组成部 分:虚拟交换机模块VSM,它替换vSwitch软件运行在Hypervisor中;虚拟元素管理程序(VEM),它是VSM进行网络策略配置和存储的地 方。工作过程如下所示:

1、  根据VEM中的虚拟机的UUID或vMAC地址配置虚拟机的VLAN和策略,VCenter启动一个新的虚拟机或进入下一步(迁移虚拟机)。

2、  进行虚拟机的迁移。

3、  Hypervisor通知VSM。

4、  VSM从VEM中检索策略信息。如果网络交换机属于Nexus产品线,它还要从VEM中检索必要的VLAN和策略信息。此时,无论是Hypervisor 中的交换机还是Nexus的交换机都有了关于如何处理VM2的正确信息。当VM2开始发送数据包,所有的策略都会在Hypervisor中的1000V交 换机上得到执行。

  

图2 思科的虚拟化方案

思科的做法的好处与第一种方法相同。未经允许,它会阻止两个虚拟机之间的任何通信,并且在数据包到达交换机的第一时间采取适当的策略。如果运行 1000V的交换机是支持虚拟化的Nexus交换机,这将在网络交换机上解决VLAN问题。它的另外一个好处是,把交换机放到Hypervisor中并置 于网络管理软件的控制下,使得对网络管理管理人员的审计工作非常清晰。不足是,目前思科仅为VMware提供了解决办法,而没有为Xen和Hyper-V 提供解决方案。

 第四种解决办法是对网络设备进行集中管理,参见图3。

 1、  网络管理软件根据虚拟网卡对虚拟机进行定义。

2、  vCenter指示Hypervisor启动虚拟机。

3、  管理程序发送广播包告知它正在启动VM2。该广播包包含VM2的vNIC及其UUID信息。

4、  交换机收到广播包后回复一个请求,询问VM2的VLAN以及其他的策略信息,随后交换机对过往的流量执行规定的策略。

 最关键的一点是这些访问策略只在网络交换机上执行,而不是在vSwitch。该交换机还会监视Hypervisor发出的消息,看虚拟机是否已经迁移,如果是就要删除与虚拟网卡有关的VLAN及其策略信息。包括Arista Networks、Blade、Enterasys等网络设备供应商都采用了这种解决办法,而HP 和Juniper除了它们的Orchestration软件也提供这种解决方案。另有厂商也计划提供这种解决方案的厂商,例如Brocade,而 Extreme网络把这项技术应用到QoS及其策略上但不针对VLANs。

 

  

图3  交换机供应商方案

 这种方法的一个重要目的是可以避免让虚拟化管理人员介入到与网络策略有关的工作中。但是,这里仍然有两个问题没有解决。第一个是服务器虚拟化和网络管理人员仍然必须协调VLAN的编号。目前,Enterasys公司已能自动提供带有VLAN号的vSwitch,而Arista计划在短期内增加这一功能。

 这种方法最大的问题是,它不能把网络策略应用到vSwitch上,这就为服务器虚拟机之间的流量绕过ACL和其他安全策略提供了可乘之机。 Enterasys和Arista计划通过把这些策略应用到vSwitch的能力来解决这个问题。

 为了克服这个问题,未来的方法是由交换机来完成所有策略的执行。此时的vSwitch被配置成将所有的流量,甚至包括VM1到VM2的流量,都直接发送 到网络交换机,由网络交换机来决定采取适当的策略以及保证QoS,然后再把VM1到VM2的流量回送到vSwitch上,最后将它传送到VM2。

 这将使vSwitch成为只有一个转发功能的“哑巴”交换机。问题是,802.1d这个所有第二层交换机都遵循的桥接标准,不允许来自于某一个端口的数 据包又被送回到同一个端口。因此,根据现行的规则,网络交换机不能把从VM1送给VM2的数据包返回给VM1,因为这样做会打破这种规则,形成循环。 IEEE正在修订802.1d,允许交换机担当总执行的角色,同时,Hypervisor中的哑交换机的标准化工作也在进行之中。如果这种标准被普遍推广 之后,上述问题就会迎刃而解,将消除网络和服务器管理者之间的大量协调工作。

 Enterasys有一个折中的解决办法,就是让 vSwitch把每一个虚拟机放进一个单独的VLAN中。它们选择那些没有用过的VLAN号,以防止可能出现问题。由于每个虚拟机都位于不同的VLAN 里,它们不能互相通信。当数据包到达网络交换机时,交换机用真正分配给虚拟机的编号来替换 VLAN号,从而使得它在网络上可见,并保证发送的目标总是在正确的VLAN中。

局域网的连接问题

还有另外一个关于VLAN的配置难题迄今为止没有得到解决。当一个新的VLAN号被分配到一个端口,它需要用这个VLAN号与其他所有端口进行连接。这就要求在这条路径上的所有汇聚层交换机都要有关于这个VLAN号的定义。

目前,业界为VLAN端口和策略方面的问题提出了非常多的解决办法。不过,并没有什么神奇的绝对有效的好方法。大 多数方案都需要网络管理人员与虚拟化管理人员之间在短期内协调一致,从而使该工作进行顺利。现在看来,由交换机来完成所有策略的执行可能是最好的长期解决 方案,而业界正朝这方向发展。

正是因为到目前为止,我们在市场上还不能找到一套非常全面的方案来应对全部的虚拟化。因此,网络管理人员必须了解如何使用各种不同的解决方案来满足不同虚拟化供应商的要求,在实践中根据自己的需要选择最合适的解决方法。