是否应该在存储I/O中绕过Hypervisor管理程序

日期: 2011-07-25 作者:Stephen Foskett翻译:张瀚文 来源:TechTarget中国 英文

通过本篇你会了解到:你有多种途径可以在存储I/O过程中绕过Hypervisor管理程序,以及这样做或保持目前已有状态的利弊。 在架构虚拟服务器环境下的数据存储时,大多数IT专员会使用Hypervisor管理程序作为中介。无论使用光纤、iSCSI或NFS,存储会先提供给Hypervisor管理程序,而后再被分配给各虚拟机。当然也有其它选项,比如原始设备映射和VMDirectPath,以及软件iSCSI initiators和网络附加存储客户端。

不过是否可以让虚拟机绕过Hypervisor管理程序,直接连接存储呢? 存储I/O绕过Hypervisor管理程序的途径 从一般逻辑上看来,存储I/O通过……

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

通过本篇你会了解到:你有多种途径可以在存储I/O过程中绕过Hypervisor管理程序,以及这样做或保持目前已有状态的利弊。

在架构虚拟服务器环境下的数据存储时,大多数IT专员会使用Hypervisor管理程序作为中介。无论使用光纤、iSCSI或NFS,存储会先提供给Hypervisor管理程序,而后再被分配给各虚拟机。当然也有其它选项,比如原始设备映射和VMDirectPath,以及软件iSCSI initiators和网络附加存储客户端。不过是否可以让虚拟机绕过Hypervisor管理程序,直接连接存储呢?

存储I/O绕过Hypervisor管理程序的途径

从一般逻辑上看来,存储I/O通过Hypervisor访问存储会降低效率和增加延迟。毕竟,VMware ESX和Microsoft Hyper-V也是先将分配空间给到相应的文件系统(VMware的VMFS和CSV或Microsoft的NTFS)然后再提供用作虚拟机磁盘(VMDK)文件。因此绕开Hypervisor管理程序以及文件系统,直接将存储I/O和客户端虚拟机连接的想法也很自然。

有多种方式可以使得存储I/O绕开Hypervisor管理程序。虚拟服务器管理员很早之前就希望使用原始设备映射或直通式逻辑卷(VMware和Microsoft各自技术),不过在实际生产系统中采用的还是非常有限。VMware新近有引入了VMDirectPath技术,可以利用AMD公司的IOMMU技术或Intel公司的VT-d技术。这些选项利用Hypervisor管理程序独有的特性来确保数据块存储I/O不间断地传输。

通过在Linux和Windows客户端上广泛可用的软件(也被称为initiators)实现的Guest iSCSI也是一种方式。该理念并不要求特殊的Hypervisor管理程序特性。只要客户机可以在IP网络中看到iSCSI阵列,其就可以像如何物理服务器那样直接访问存储。

利用每种操作系统支持多种协议这一特性,使用NFS或SMB加载NAS装置也是类似的一种方式。虽然目前说将NAS用于高性能要求的应用还不多见,不过随着引入NFSv4,并行NFS以及SMB2.0和2.1,使用NAS作为各种类型的数据存储亦将成为可能。

绕过Hypervisor管理程序的理由

绕过Hypervisor的理由可以有很多。其中一个就是绝大多数的虚拟服务器仍依赖Hypervisor文件系统用于存储的提供方式。这些机制从理论上是更高效的,而且事实上也没有人可以证实有更加高性能的实践方式。此外,存储体系结构较单纯的性能也更为重要,灵活性和各类特性是考虑的首要因素。

不过还是有可能通过计算协议上的开销或测算降低延迟来证实绕开Hypervisor可能更为高效。光纤通道、以太网ATA以及无限宽带技术的支持者也提出类似的观点。但在实际测试中降低这部分开销似乎没有多大收益。由于摩尔定律,处理器内核,线程和时钟周期足以提供这部分额外协议开销所需的处理资源,这在今天的服务器中不是问题。测试显示VMFS和CSV的处理仅需要少于10%额外的处理器实践,而在最新的Hypervisor管理程序中的更新版则要求更少的处理时间。

另一种考虑因素就是在运营管理要上采用非常规的体系架构。虚拟化或存储管理员可以在其环境中应用Guest iSCSI,但在其他环境中是否也可以支持呢?考虑到将来的发展需要,这点非常重要。IT业内的人员流动非常普遍,而一个完全通用架构的系统显然更易于操作。

不过,RDM、VMDirectPath和Guest iSCSI很少被采用的最主要原因是Hypervisor管理程序所具备的各类特性。RDM使得vMotion和动态资源计划日程(Dynamic Resource Scheduling,简称DRS)的配置更为复杂,并且使得Storage vMotion完全没有计划。VMDirectPath则消除了vMotion和VMware容错功能,和快照功能一起,挂起或恢复可插拔设备。

由于绕开了Hypervisor管理程序,Guest iSCSI或NAS几乎不能使用任何Hypervisor的功能,这使得管理变得更为复杂。在物理服务器环境中管理iSCSI和NAS客户端非常常见,不过虚拟化操作和报告工具很少包括针对这类存储系统的管理。VMware vCenter Site Recovery Manager经常用于协调容灾恢复操作,但其不能配置Guest iSCSI或NAS。

此外,你还必须考虑效率以及和虚拟网络的集成度,此外还有使用Guest iSCSI和NAS访问时协议上的资源消耗。在今天Hypervisor管理程序中一般的虚拟网络交换机不像其在物理环境中所具有那样的可靠性和服务品质保证。这使得架构一个高可靠性的iSCSI SAN变得非常困难。同时,这些虚拟网络的性能也是需要考虑的一个方面,很多的研发投入都只是关注在存储I/O层而非虚拟网络层。

存储直连访问客户机是否是一项强制的选项?

从这点来讲,存储I/O绕过Hypervisor管理程序并非是强制的选项。由于所获得的性能提升非常有限,并且对功能性和可支持性的影响严重,虚拟服务器架构很少会采用这种方式。

不过IOMMU和VT-d这类技术在今后有可能变得非常普及并被广泛应用。这些技术或许会继承在今后发布的Hypervisor管理程序版本中,并且不会和高级特性产生冲突。不过存储直接连接访问客户机绝不可能是很有吸引力的方式。

作者

Stephen Foskett
Stephen Foskett

GlassHouse Technologies公司

相关推荐

  • 虚拟机的世界 存储将成焦点

    如果你放弃VMware而使用另外一种服务器hypervisor,或者不再使用hypervisor了,你并没有放弃很多东西,至少没少什么存储功能。

  • 你将选择哪种软件定义存储?

    随需求的不同,软件定义存储有着不同的类型。一个有着全副VMware配置的存储管理员可能更倾向于VMware的专用虚拟SAN,而管理一个支持多Hypervisor的通用基础设施的管理员则很可能选择第三方或虚拟存储选项。

  • SDS与存储虚拟化到底有何不同?

    随着越来越多的技术支持存储层的抽象,你真的了解存储虚拟化和软件定义存储之间的不同吗?

  • Docker存储和虚拟化存储 需求不同

    Docker容器和虚拟化代表了一部分相同的存储挑战,但相同的存储系统可未必适合于二者。