VMware VAAI的劣势与隐藏的第四大特性

VMware VAAI的劣势与隐藏的第四大特性

在本文的上半部分中，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的四个主要部分。

　　（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还是存储阵列方面的引入上，我们都应该有足够的风险意识，从而避免把自己陷入非常危险的境地。