VMware的存储野心(下)：虚拟卷和闪存缓存

http://storage.chinabyte.com/187/12494187_2.shtml

在上一篇《VMware的存储野心(上):软件定义、分布式DAS支持》中，我们分别讨论了“何谓软件定义的存储？vSphere哪些方面仍待提高？”和“VMware分布式存储：应用场景、VSA对比”两个小话题。本文继续来谈谈未来计划中的Virtual Volume（虚拟卷）和Virtual Flash（虚拟闪存）。

Virtual Volume：基于vmdk的细粒度、灵活管理

　　首先，我们看一下Virtual Volume产生的背景，以及为了解决当前虚拟化环境中的哪些问题？

虚拟化已经对存储产生了巨大的影响

　　我们应该承认，基于虚拟化基础架构上的应用负载，在数据中心里所占的比例已经相当大。由于HA、故障切换以及像vMotion那样的虚拟机迁移等高级特性，增加了对共享存储的需求。此外还引入了一个新的数据存储容器（在VMware环境下就是vmdk文件），下一个增长点VDI（桌面虚拟化）对存储性能的需求也是相当强烈的。

　　而我们看到，由于vmdk和LUN/Volume的不匹配导致对磁盘空间不能充分利用；存储系统上提供的快照、备份等数据服务是和LUN而不是虚拟机绑定的；不同存储硬件有不同的管理工具；由于虚拟机迁移的原因，不能有效利用服务器本地DAS直连的SSD和HDD。

VMware提出以vSphere作为存储服务的平台——基于vmdk进行数据管理

　　从前的数据管理单元是LUN，用户希望有统一的管理方法和更细粒度的数据管理。而基于LUN或者datastore的粒度不够精细，效率不高也不够灵活。

在存储上实现针对每个虚拟机的服务

　　介于在vSphere和存储系统之间粒度不匹配的现状，VMware的目标是：给用户提供在存储上针对每个VM进行数据操作的选择，并创建一个架构把所有的针对VM的数据操作让存储完成。我的理解是，又会有一个类似于VAAI（vSphere阵列集成API）和VASA（vSphere存储感知API）那样的接口，支持将以虚拟机为对象的存储操作卸载到阵列上完成。

　　一个虚拟卷（virtual volume）是vmdk文件或者它的相关内容在FC、IP SAN存储中的可见对象。存储系统参与到虚拟机的生命周期，一方面应用程序和VM的需求可以传达给存储设备，另一方面策略（policy）设定在虚拟卷上。

Virtual Volume可扩展的连接——有VVOL功能的存储和Protocol Endpoint

　　这里我们又看到了2个新名词：VVOL和Protocol Endpoint（协议终点）。我简单查了一下相关资料，VVOL应该就是指虚拟卷，还与VMware API Program for I/O Demux（多路复用）有关。所谓“有VVOL功能的存储”应该就是指Virtual Volume Ready吧？

　　Protocol Endpoint（简称PE）是一个连接主机到存储系统的I/O通道。存储管理员为每个阵列创建一个PE，而不再是m*n个路径；PE可以用于SCSI（即光纤通道和iSCSI这样的块存储协议）或NFS（文件协议）；PE的作用是分离I/O的路径，因为多个VVOL（虚拟卷）会共用一个PE。

虚拟卷的容量管理

　　支持Virtual Volume的存储系统，能够在设备上管理容量和访问控制。“Storage Container（存储容器）”是一个逻辑实体，可以跨越多个存储系统，用来存储VM。

　　具体到存储设备提供商对虚拟卷的支持，Vendor Provider是一个存储端的插件，用来做策略的通信。使用VASA（vSphere存储感知API）作为传输机制，VM与策略绑定，一套新的存储API为主机和存储之间做策略通信。

　　简单总结下Virtual Volume：VMware想要把vSphere的数据管理单元从现在建立在LUN上面的datastore，或者文件系统卷，改变为以每一个vmdk容器为单元，策略绑定到虚拟机，进行粒度更细、更加灵活的分配和管理。不知我这样理解对不对？

　　在虚拟卷的合作伙伴中，除了我们熟悉的戴尔、NetApp、IBM、EMC、惠普、HDS、富士通和NEC之外，还看到了闪存初创厂商Nimble Storage、SolidFire、Pure Storage，以及计算+存储一体化的NUTANIX。

　　下面一页，我们将继续讨论Virtual Flash（虚拟闪存）。

Virtual Flash：闪存基础架构+第三方缓存软件？

VMware的目的是，让vSphere集群像管理CPU和内存一样管理SSD资源，并允许合作伙伴使用他们的缓存软件来利用SSD资源，提供一个可以支持vMotion和DRS（分布式资源调度）这些vSphere中其他特性的基础架构。

　　现有的挑战包括：目前vSphere还没有完全利用（控制）服务器端的SSD；作为vmkernel交换分区使用；以及没有对第三方合作伙伴开放的架构。

　　从上图左边的示意可以看出，Virtual Flash包含闪存基础架构和缓存软件两个组成部分。前者允许使用者以灵活的方式预留、访问和使用闪存资源，并有一种可以把第三方Flash服务融入vSphere中的机制；缓存软件则是对VM透明并且虚拟机感知的。

　　VMware虚拟闪存的Flash基础架构将服务器端的闪存资源池化，以虚拟对象（VM）为分配资源的单位，只有在VM开机的时候使用。管理方面，可以在不同的闪存资源使用者之间做协商；支持为单独VM或单独vmdk分配Flash资源；设定预留值——使用上限和优先级。

服务器端的缓存——不同的缓存模式

　　由上图，像EMC VFCache、NetApp Flash Accel和Fusion-io ioTurbine等第三方闪存缓存软件，都属于右边那种“虚拟机感知的Flash缓存”，即将闪存做为块设备分配给虚拟机（缓存软件位于VM上）；而被SanDisk收购的FlashSoft，Proximal Data的AutoCache则属于“对虚拟机透明的Flash缓存”，这种情况下缓存软件运行在Hypervisor上。下面我们来解释这2种的不同。

缓存软件——对虚拟机透明的缓存

　　对VM透明的Flash缓存，是工作在Hypervisor内核上的缓存模块，并且添加到虚拟磁盘的数据路径中。支持只读缓存和读写缓存两种模式。在进行vMotion虚拟机迁移时，可以选择如何处理缓存内容：迁移或者丢弃。

　　SanDisk FlashSoft和Proximal AutoCache，应该就是为了更好的实现vMotion和DRS等功能取消了GuestOS中的代理（缓存驱动）组件。VMware虚拟闪存是允许vSphere使用第三方Flash缓存软件的。

缓存软件——虚拟机感知的缓存

　　至于VM感知的缓存，闪存作为块设备直接分配给虚拟机，缓存算法由VM自己控制。这里我有一个问题，Virtual Flash接管了现有第三方闪存缓存软件中“Flash基础架构”的工作，而在VM上的客户端闪存管理驱动仍然依赖第三方？或者VMware自己也有提供？

EMC VFCache、NetApp Flash Accel和Fusion-io ioTurbine都是在虚拟机上需要安装驱动的。

　　至于缓存转态，“在vMotion和DRS时保存”也就是说可以将Virtual Flash随虚拟机一同迁移到目标服务器，当然这种情况的前提是目标端也需要有准备好的闪存。“在VM关机时不保存”，应该是由于关机时缓存软件失去对闪存的控制，那么虚拟机每次重新开机闪存缓存都要重新预热？

　　VMware新功能对存储管理员的影响

　　在vForum 2012大会分会场一“软件定义数据中心——VMware主题演讲: 软件定义的存储-VMware存储策略展望”结束时，来自VMware北京研发中心的同事和大家开了一个玩笑：“在场的存储管理员朋友不要担心会失去工作，因为我们介绍的功能特性（包括：软件定义的存储/分布式DAS、虚拟卷和虚拟闪存）都还在计划和开发中。”