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

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

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

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

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

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

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

这里我们又看到了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。

请继续阅读VMware存储策略：虚拟卷和虚拟闪存（下）。