VVOL、VASA — 为什么如此重要

      几乎每一个与存储或虚拟化打过交道的人都听过这些术语，或许您还知道这些概念的含义。

      但是并没有很多人知道这些正处于开发阶段的 VMware 技术为什么对存储用户和供应商如此重要。

      我承认，我当初对几个概念的初步认识也比较肤浅。但我在 VMware 工作期间，我对这个领域正在发生的事情以及它们为何如此重要逐渐有了更加深刻的认识。

      如果您已经这些内容了解得很深，可以跳过这篇博文。或者其他读者想继续阅读...

      问题陈述

      为简单起见，我们来设想一个典型的 IT 环境。

      我们有三个相关的组件。
 

      首先是任意数量的阵列，它们可能来自不同的供应商，而且每个阵列可能有不同的功能。

      其次是一套任意数量的应用程序，每个应用程序可能需要不同的功能，从理论上来说，这些功能可能由存储阵列提供。

      最后是一个预想中的 vSphere 环境，它能在应用程序的需求与阵列的功能之间进行仲裁。

      问题 — 您如何以一种简单、轻松、自然的方式将使用者与提供者联系起来？听起来容易，但事实证明，实现起来非常困难。


      第一种模式

      第一种方法是配置不同类别的阵列（高端、中层、NAS 等），并将给定应用程序的虚拟机与特定阵列静态绑定在一起，这种方法今天仍在使用。

      例如，所有重要的虚拟机在高端阵列上运行，所有不太重要的虚拟机在中层阵列上运行，所有非关键虚拟机在廉价阵列上运行。

      这不失为一个解决方法，但肯定不是最理想的。

      首先，这种方法假设一个给定的阵列只能提供一种级别的服务，目前这种情况并不常见。

      当今所使用的现代阵列具有广泛的灵活性，能够提供不同级别的性能、数据保护、分层、复制等。现代阵列上的给定数据存储具有很多不同的策略特征，有时甚至可以动态更改策略特征。

      其次，它在某种程度上迫使您仔细权衡应该购买哪些类型的阵列，购买多少个，什么时候购买。存储阵列是一种非常昂贵的设备，它们需要花很大的力气迁入和迁出数据，而且您肯定不想浪费自己购买的任何容量。

      因此，实际上这会导致阵列提供的资源和应用程序实际需要的资源发生很大的偏差。我们总是说，为了安全起见，就算犯个错误也是值得的，所以您会看到许多高端阵列会用来支持不太关键的应用程序。

      因此，它们肯定不像我们在今天的虚拟化计算环境中看到的那样高效和优化。


     第二种模式

      一旦人们认识到给定的阵列有可能提供多个级别的服务，并开始利用这一优势，事情就会向更好的方向发展。尽管还是不够理想，但比之前好多了。

      存储管理员会在给定存储阵列中创建不同的服务级别，比如典型的金牌、银牌、铜牌方法。现有的和新的工作负载可能会分配给一种静态服务级别，由存储管理员提前确定。

      如果服务级别要求提高或者降低，就需要将给定应用程序的数据存储移动到存储阵列的适当池中。没错，需要做一番努力，但不像其他替代方案那么麻烦。

      在这种模式下，我们取得了很大的进步，因为现在资源的合用程度更高，不再需要过多地进行提前规划了。

      然而，由于一些原因，我们依然没有达到理想状态。

      第一，当新阵列投入使用时，管理员仍然必须进行一次预测然后置备的规划过程。重新划分阵列资源并将它们用于一组不同的服务池的确不是一项简单任务。

      第二，我们依然没有满足各项应用程序要求，我们只是把它们随意放进便于使用、标准化和预定义的存储桶中，而且对于存储阵列的每项功能都是如此：性能、保护、远程复制、加密等。

      理想情况是，我们为每个应用程序都准备一个专用的存储配置文件，这种存储配置文件可以专门用于每个虚拟机（和每个应用程序。无需预先分配标准化存储桶。无需专门将给定应用程序映射到特定阵列。能够扩展或缩减。再次说明一下，最理想的情况就是利用每虚拟机粒度。

     而且，这正是 VASA 和 VVOL 努力实现的方面。


    第三种模式
    我们先回到前面提到的使用者/提供者模式。

      理想的情况是，每个阵列都公开一份可能调用的功能清单。

      假定我是一个阵列。这是我所拥有的容量。这是我使用闪存的功能 — 作为缓存或持久存储。这是不同的置备模式：精简置备、厚置备、预留置备等。这是我的存储保护模式：RAID 选项等。这是我的远程复制选项：同步、异步等。这是我识别一致性组的功能。这是我加密静态数据和执行重复数据消除的功能等等。

      这些功能全都以机器可读的格式公布，以便日后使用。

      现在，我们从使用者角度审视一番。

这是一个要置备的应用程序，显然是在虚拟机中。这是我认为我需要的容量、性能、首选置备、保护模式、复制、加密等。

      或许这已被简化成一个标准化配置文件，但如果需要，这些所需的功能都可以按每虚拟机粒度来表示。

      设想一下，正在传递给存储阵列池的请求（可能来自多个供应商）以及收到的答复：这是您的选择。包括如果您的请求无法满足，您会选择怎么办？

      假设请求可以满足，则会使用请求的属性（仅仅使用这些属性！）置备数据容器来满足应用程序数据存储的需求。如果需求发生变化（容量、性能、保护等需求增加/减少），也可以动态地表达并满足这些需求。

      存储管理功能基本瓦解，剩下的只是确保有足够的资源（指的是总资源量）可以满足使用者请求，并保持存储基础架构的总体运行状况。

      相反，存储置备现在变成了应用程序置备不可或缺的一部分，采用与 CPU、内存等其他置备资源相同的方式同时完成。

      很难想象有一个面面俱到的模式:)


      这正是 VASA 和VVOL 的意义所在
VASA (vSphere APIs for Storage Awareness) 是存储提供者和存储使用者之间的标准交流方式。

      目前正在使用的是 VASA 1.0，VASA 2.0 将进一步扩展生产者和使用者之间的交流范围。

      VVOL 是使用 VASA 置备的存储容器。它恰好与虚拟机边界完美契合。其中包含数据存储、一套预期的数据服务，并维护所请求策略的元数据。后一点很重要，比如当您需要考虑合规策略时。


      警告：前方障碍
      尽管这一切在理论上看起来十分理想，但实现起来需要面对许多实际挑战。

      首先，我们需要等待未来版本的 vSphere 提供所需的VASA 2.0 和 VVOL 支持，但这很快就能实现。

第二，VMware 的存储阵列合作伙伴需要完成一些繁重的工作。许多阵列在设计时并未考虑公开它们的各项功能以及动态使用这些功能，更不用说使它们与虚拟机边界契合了。

      我们需要看到有一些东西（比如丰富的 VASA 提供程序）来公开此前仅限于专有接口的许多功能。实施VVOL（使存储和服务与虚拟机边界契合）会带来更多挑战。

      但是，或许最具挑战性的障碍是，企业级 IT 厂商将不得不从多个方面发展其存储模式。简单地划分 LUN 池（或文件系统）不再凑效，这项工作会在使用者和提供者之间动态完成。这样，存储置备就会发生彻底改变。容量规划也会发生改变，性能管理也是如此。

      这是一个重大转变，尤其对于大型厂商。

      话虽如此，但我认为一旦适当规模的 VMware 厂商充分理解了新模式的意义，迟早会抱着强烈的热忱去实现这一目标。到那时，我确信我们会在不久之后看到一些激烈竞争的存储阵列提供商争论谁的 VASA 和 VVOL 实施得更好。最终，这些产品会迅速向前发展。


      前方道路？
      在 VASA 和 VVOL 的讨论中会涉及到真正颠覆性的创新理念：管理员可以大大减轻众多业务策略的工作负担，从性能和可用性等简单工作，到 HIPPA 合规性等更为微妙的内容。

      首先，这可以在应用程序置备期间完成，将那些需求与虚拟机本身联系在一起，然后统一将那些需求公开到支持基础架构。

      这种想法很激进，但如果您经过深思熟虑，显然也会产生这样的想法。它肯定会改变我们思考存储置备和运行模式的方式。

      没错，它是一次大胆的飞跃，但它需要去做。