VAAI:让特定的储存作业可以无需透过ESXi主机执行，而由储存设备来担纲
【TechTarget中国原创】目前，VAAI虽然已经成为虚拟化领域的标准语言之一，但是大多数人可能并不了解它还有隐藏的第四大特性，VMware曾经提到过设计思路但是最终没有被包含到vSphere 4.1中。这是一个非常有趣的故事，它在另一方面也提醒我们在厂商之间的合作伙伴关系并不如表面看起来那么地和谐。在本文中，TechTarget中国的特约专家Mike Laverick将介绍什么是VAAI，然后向大家讲述关于这第四大特性的“达芬奇密码之旅”。
VAAI是“vStorage APIs for Array Integration”的缩写。从中我们可以理解最基本的一点就是在vSphere 4.1中，VMware已经预先植入了新的软件代码，用以支持存储厂商可以和vSphere 4.1进行智能地整合。这也就是说存储阵列已经成为“vm-aware”。这一点看起来就如同处理器厂商在CPU中加入的用于改善虚拟化性能和安全属性的Intel-VT或AMD-V技术一样，存储厂商所做的内容也类似（在它发挥作用后，我们可以把VAAI想象成用于支持硬件存储设备的软件助理）。现有的VAAI中包含了三项用于改善性能的新特性，而原本应该有四大特性的存在。
特性一：Full Copy或Copy Offload
第一项特性被称为Full Copy，而部分厂商也把这项称为Copy Offload。现在vSphere 4中，当我们从模板来创建一个新的虚拟机时，无论是FC、iSCSI或NFS系统中，都需要对其中存储的源数据文件从头到尾进行一次全读取操作，然后再重新写入到新的目标地点。这样的过程会极大地增加ESX宿主机的CPU负载，而且会导致新虚拟创建的过程去占用大量原本应该用于支持现有生产虚拟机运行的宝贵的IOPS资源。
即使是在现今的瘦虚拟磁盘技术下，新虚拟机的部署也会涉及对冗长的状态栏的读取过程。VAAI的Full Copy或Copy Offload功能，则可以通过在磁盘阵列内部实现从一个卷到另一个卷的智能拷贝过程来消除这种影响。VMware宣称这样的一项技术可以实现10倍到20倍的性能提升，同时为虚拟桌面架构的应用铺平道路，新虚拟机创建时间相比之前的方式可以大幅地缩短。
所有需要启用容错（FT）功能的虚拟机，它们的虚拟磁盘必须从原来的thin disk 或zeroed thick disk方式，转化为称为eager zeroed thick disk的磁盘格式。这个转化过程会占用大量的时间，因为这个转化过程同安全擦除操作类似，需要涉及对虚拟磁盘中每个扇区的清零操作。
最后一点，其它的一些存储相关操作，例如Storage vMotin（实现虚拟机从源站点到目标站点的迁移过程），在采用VAAI技术后都可以在阵列端实现明显的性能提升。
特性二：Block Zeroing
第二项属性被称为Block Zeroing。这一功能依然和克隆的进程紧密相关。在虚拟磁盘文件内部同时存在着数据区（写有数据的扇区）和等待写入的空白区（空扇区）。
从本质上看，我们可以把虚拟机的克隆过程作为一个完整的文件拷贝过程来对待。整个过程就是组成虚拟机的磁盘文件被从源数据区拷贝到目标地点。在之前的版本下，假设我们需要拷贝40GB大小的虚拟磁盘文件，其中有10GB的数据区。那么在部署过程中，在为10GB数据的移动占用IOPS的同时，还需要发送大量重复的SCSI命令，用于完成对组成该磁盘文件的大量空白扇区的迁移和写入。
Block Zeroing 技术可以节省大量的从ESX主机发送到磁盘阵列的SCSI命令。Block Zeroing也使得VMware FT过程的启用变得相对简单而快捷。所有需要启用容错（FT）功能的虚拟机，它们的虚拟磁盘必须从原来的thin disk 或zeroed thick disk方式，转化为称为eager zeroed thick disk的磁盘格式。转化过程会占用大量的时间，因为这个转化过程同安全擦除操作类似，需要涉及对虚拟磁盘中每个扇区的清零操作。结合VAAI的Block Zeroing技术后，可以极大地节省该过程所需的SCSI命令数量。
特性三：Scalable Lock Management
第三项特性称为“Scalable Lock Management”。其实早在ESX 2.x起，VMware就开始在它的文件系统VMFS（Virtual Machine File System）中通过采用SCSI Reservation Lock技术，来实现多个ESX主机对同一个数据源文件的共享访问。这种锁定技术允许来自不同ESX主机上的多个访问可以到达同一个数据文件，而更重要的一点是可以避免发生冲突。例如，避免有两个VMware管理员同时尝试在同一个卷上创建一个完全相同的虚拟机。在虚拟机启动后，它的文件就变成锁定状态。如同在共享系统中被打开的文档处于锁定状态一样。通过这种处理可以防止发生一些低级的管理员事故，例如可以防止在虚拟机启动（或使用）时对虚拟机（或文档）进行删除操作。
本质上VMFS是一个共享文件系统，之前在一些特殊应用中，如VMotion，对于VMFS的使用是强制性的。在VI3.0发布之后，VMware引入了 对NFS协议的支持，包括一些同样基于SCSI Reservation Locks技术支持的新功能：High Availability 和 Distributed Resource Scheduler。
多年以来，VMware编写和重新修订了很多VMFS驱动，希望可以降低由于SCSI reservations操作带来的性能影响。这些SCSI reservations操作带来的影响，在一些文件系统需要面临大量变化的时候会表现得非常明显，VMware把这种情形统称为：“VMFS Metadata”升级。其中包括了VMotion、创建新的虚拟机、启动或关闭虚拟机、删除虚拟机或者是做快照等等多个任务。
这些都是在VMware环境中很常见的事件，它们中的每一个操作都需要进行强制锁定。现在，很重要的一点是我们决不能夸大这种锁定过程带来的影响，因为多数的用户都没有明显感觉到。这就是VMFS的优势所在。换句话，所有可以减少或去除ESX主机所需锁定进程的改善都是有意义的。所以这项特性，我们可以称其为"Hardware Assisted Locking"，而它绝不应该被忽略。
总之，VAAI引入了大量的新选项和终端作为其内在优势。在ESX主机端，VAAI默认是被启用的，如果阵列端无法支持VAAI，那么这些相应的选项就不会出现。如果想了解更多关于这些新特点的设置问题，请参考：“VMware's vStorage APIs for array integration FAQ”。
在本文的上半部分中，TechTarget中国的特约专家Mike Laverick介绍了什么是VAAI，并且详细描述了VAAI的三个特性。下面，我们将分析VAAI的劣势以及缺失的第四大特性。
VAAI的劣势
所有的这些新特性都是非常不错的，而且显示出VMware的工程师们在跟存储厂商合作伙伴的合作开发中举得了很大地成就，在虚拟化管理程序层和存储层之间提供了大量进行性能改善的途径。然而，这种改善依然带有一定的局限性。
首先，客户现有的存储阵列可能无法支持VAAI。或者至少需要进行阵列控制器端的firmware升级操作。在多数情况下，这种升级是无缝地，从而不会对业务造成影响：控制器A首先升级，在此期间控制器B接管所有的生产任务直到控制器A完成升级。然后进行对控制器B的firmware升级操作。然而，值得我们关注的一点就是，也有大量的事故先例产生于这样的操作过程。如果firmware的升级没能达到预期的效果，可能会导致卷或者是LUN的丢失，甚至是整个阵列无法工作。
还有一种更为糟糕的情形就是，现有的阵列可能是32位的，而供应商提供的VAAI版本仅能够支持64位的硬件平台。在这种情况下，您确实需要首先考虑购买新的阵列或者是等待现有的存储设备生命周期结束，然后才能享受到由VAAI带来的新功能。在多数的应用中，这并非客户的痛点问题之一，这样的过程取决于客户环境中存储设备所处的更新阶段。需要强调的一点是，在设备发送到客户端之前，需要及时地提前进行新firmware的升级操作。
如果您想检查现有的阵列是否可以支持VAAI，可以使用由virtuallyghetto.com的William Lam编写的脚本程序：
vaaiHWAccelerationMgmt.pl
如果阵列可以支持VAAI，将会输出正向的显示结果：
如上我们提到了VAAI的三大新特性，此外还有一个隐藏的第四大特性。在VMFS卷的属性中，我们可以看到一项称为Hardware Acceleration的栏目：
其次，在现有的版本下，VAAI只能支持数据块级的存储访问方式（FC或iSCSI阵列），也就是说使用NFS协议的用户是无法享用VAAI技术的。根据我和多个不同存储厂商的沟通来看，如果想享用这些新的增强属性，看起来NFS的用户需要等待下一版vSphere 5的发布。
很多业内专家也会对这个问题进行相应的讨论，看起来VMware对NFS的支持依然大幅落后于其它的存储协议。这或许也从一个侧面说明，尽管NFS在VMware领域的应用获得了极大发展，但是大约80%的VMware用户依然使用在数据块级访问的存储设备（FC或iSCSI协议）之上。而VMware为了保证其产品的高质量要求，就需要首先把对前沿技术的探索精力集中于最核心的用户层需求基础之上。
缺失的第四大特性：Thin Provisioning Stun
现在是时候讨论缺失的第四大特性了。之前在VAAI的规划中曾经出现过第四个主要的组成部分，称为Thin Provisioning Stun。Thin Provisioning Stun曾经出现于VMware、Cisco和EMC在2009年中的各种介绍材料中。事实上，如果您通过Google检索一下关键字段“Thin Provisioning Stun”，依然会找到很多文档，可以帮助我们了解具体情况。而且，当我还是北加州用户委员会一员的时候，我们依然讨论的是关于组成VAAI的四个主要部分。
<SCRIPT src="http://player.ooyala.com/player.js?height=337&embedCode=Bod2RoMTonZk07qHqS6y_4mIC9hgfZ_a&deepLinkEmbedCode=Jld2RoMTqcut_lgDyFZ_fxG19AocorR6&width=400"></SCRIPT>
（VAAI讨论的时间大约在20到36分钟之间。）
Thin Provisioning Stun功能的设计目标是为了帮助客户避免发生物理磁盘空间溢出的情况。Thin Provisioning Stun和其它三个组件有着本质的区别，因为从根本上它不是为了改善性能而设计的——它的主旨是为了对使用自动精简配置的卷进行更加有效地管理和控制，以避免可能发生的错误。精简卷面临的问题之一就是可以支持对存储空间的超额分配，从而可以超出卷物理空间的限制去创建更多的虚拟磁盘文件，从而支持超出负荷能力的更多虚拟机运行。而这一点也一直被认为是其固有的优势。通过释放客户在物理空间购买上受到的限制，使得客户无需为暂时不会用的磁盘空间付费，从而节省成本。它可以向ESX主机分配2TB的存储空间，而事实上只保留了1TB空间。关于这一点，需要考虑的问题就是当这些瘦虚拟磁盘开始大量写入数据时，您才会发现总体所需的存储空间已经超出了物理磁盘的容量。
我经常采用While E Coyote的故事来向客户解释这个问题。众所周知，当狼去追逐走鹃而到达悬崖边的时候，才会发现原来所在的地面已远不是熟悉的草原。在之前的VMware ESX版本中，如果这种情况发生了，虚拟机的IOPS请求就会堆积起来，最终导致蓝屏死机或内核崩溃的情况发生。vSphere 4.1中，在阵列支持VAAI的情况下，Thin Provisioning Stun会自动发送“stun”命令来停止虚拟机。这种功能的背后是存储阵列可以把它的TP State或者是溢出信息主动发送给ESX主机知晓。如果这种情况发生了，ESX主机会stun或暂停受影响的虚拟机。然后，管理员可以去增加存储空间，并重新恢复该虚拟机。
这种情况的发生会在vSphere Client中触发如下所示的弹出窗口信息：
很有趣的是，这四大特性只有在指定厂商提供的、可以全面支持VAAI的存储阵列基础之上才能实现。虽然这些特性很早之前就有了相应的定义，但是只有几个厂商进行了存储端的开发工作，从而实现对所有四个特性组件的支持。
我个人的理解是，在今年2月份拉斯维加斯举办的的PEX（VMware Partner Exchange）大会中，一些存储厂商原本计划展示对所有四个组件的支持，而还有一些厂商只能支持一部分。对于VMware而言这是一个极大地惊喜，因为他们原本期望存储厂商对其中的三项进行支持。这种差别导致部分存储厂商悄悄修改了其展示内容，只包含了其中的三项组件而不是对全部组件的支持。本来，这种变化是为了防止让部分厂商感受到VMware对某些合作伙伴的偏爱，从而感到不愉快。然而，看起来这似乎是一种由于VMware及其合作伙伴之间的沟通不畅导致的，而并非由于VMware存在偏袒。
表面上看起来，这并不是一个大问题。日常沟通中，各个供应商都承诺了对W,X，Y和Z的支持，而最终仅仅提供了对X,Y和Z的支持。这个有趣的现象从一定程度上体现出在VMware和它的存储合作伙伴之间已经存在一定的裂痕。因此，在您采购的新存储品牌内，它或许已经存在或者还没有加入这项，可以帮助用户实现更佳管理以及提前预见空间溢出的新功能。VMware定义的API以及对存储供应商提供的要求是这样的，但是VMware自身却没有完成对所有API的QA流程的建设，因而无法宣布第四个特性的支持。通用版本已经发布，但是VMware却在这一点上保持了沉默。
当一些存储厂商的工作完成地非常好的时候，看起来VMware却放弃了对第四个组件的支持，从而导致了部分存储合作伙伴的困惑甚至会有小的摩擦。我希望在今年的晚些时候会有新的产品升级发布，从而揭开第四个组件的神秘面纱。同时，希望所有的存储厂商都可以提供正确的firmware版本供升级，而且VMware可以完成QA流程的建设。从而使得第四个组件，可以展现它的本来面目。
当然，对于用户而言，无论在vSphere还是存储阵列方面的引入上，我们都应该有足够的风险意识，从而避免把自己陷入非常危险的境地。
vSphere 5.0存储特点三-VAAI
- 当虚拟机被删除或从一个存储迁移时，阵列不会自由得获取这些块。这就导致阵列管理工具报告比实际情况更多的空间消耗。
- 在我的数据存储空间不足 （OOS） 运行时，会发生什么？在过去，一个OOS的状况可能导致在OOSTP的数据存储上的所有虚拟机受到影响。
- 如果一个精简资源调配的数据存储达到 100%，只有需要额外的存储空间块的这些 Vm将暂停，同时对数据存储的其他虚拟机，不需要额外的空间继续运行。
- 新的 VAAI 基元 （使用 SCSI 取消映射命令） 允许 ESXi 告诉存储阵列可以回收被一个虚拟机占领（无论它被删除或迁移到另一个数据存储区） 的空间。这允许一个阵列来正确报告精简资源调配数据存储区中的空间消耗，并允许用户正确地监视并正确地预测新的存储需求。
- 如果自动精简配置的数据存储达到75％时就会在vCenter通过VAAI的浮现警告，如以下屏幕截图。这允许管理员主动添加更多的存储空间，来延长磁盘或数据存储 vMotion一些虚拟机，以避免OOS的情况。
- 克隆全部文件 - 类似“完全复制”这种原始克隆虚拟磁盘的NAS设备，通过硬件加速提供原始的阵列块。
- 本机的快照支持 - 允许被卸载的阵列创建虚拟机快照。
- 扩展的统计信息 - 启用 NAS 数据存储区的可见性，尤其是使用自动精简配置时。
- 预留的空间 - 允许在NAS上较大的虚拟磁盘文件的创建，而以前在NAS上只可以创建唯一支持VMDK类型的较小的磁盘文件。请注意下面的截图显示，选择NAS数据存储上的lazy-zero或eager-zero磁盘：
if (ATS==supported) VAAI = SUPPORTED else if (ATS==notsupported && ZERO==notsupported && CLONE==notsupported) VAAI = UNSUPPORTED else VAAI = UNKNOWN |