HQY 一个和谐有爱的空间

原文： http://chucksblog.emc.com/chucks_blog/2013/08/considering-vsan.html

注明：本文内容基于 VMware VSAN beta 版本撰写，请访问 http://www.vmware.com/products/virtual-san/获得有关正式版本的更新信息。

      对于我们这些存储行业的人来说，VMworld 最引人瞩目的一条消息就是 VSAN 的问世（之前称为“VirtualSAN”），它不久就会推出测试版。

      虽然 VSAN 具备传统存储阵列的许多功能，但它并不是传统的存储阵列：而是一种基于软件的存储阵列，这种阵列将使用商用服务器硬件群集来完成工作。存储工作负载与计算工作负载在同一个资源池上运行。

      没错，该产品从许多方面来看只是一个雏形（这是预料之中的），但是，我们可以从团队已经完成的工作中发现一些独到的理念，值得我们进一步思考，我确信将来会有更多这样的新理念不断发展。

      基本信息

      关于VSAN 的私下讨论已有多时，现在终于揭开了面纱。使用这一名称可能稍显不当，因为实际上它并不是通常意义上的 SAN，也不会提供人所熟知的 LUN/块/卷抽象。

      我更愿意将它称为VMDK 存储服务器。

      对于我们这些具有丰富存储行业背景的人来说，VSAN 将促使我们重新思考我们长久以来所坚持的许多假设。就我个人而言，我发现这种重新定位可以给人以耳目一新的感觉。过去，我经常在搜索常用符号（如 LUN 和文件系统）时感到很失望，但我也发现了许多值得思考的新概念。

      软件定义的存储 --综览
      虽然业界尚未就什么是（以及什么不是）软件定义的存储达成一致，但在使存储像当今计算过程一样成为一个动态可编程的资源方面却达成了共识。

      理想情况下，计算体验和存储体验可在方方面面完全实现融合：包括资源池、置备、监控等。在这种模式下，存储不再是一个独立的领域；现在，就各方面而言，它只是虚拟环境的一部分。

      如果说这就是软件定义的存储的主要目的，那么VSAN 便从很大程度上抓住了这一点。反之，如果坚持从传统存储阵列的角度看待VSAN，就不会立刻看到其独到性和特殊性了。

      总之，VSAN可以与vSphere 紧密集成（应该可以，因为多个关键子系统都是基于内核的），并有效地利用在服务器虚拟化中使用的相同商用服务器资源池。

       VSAN -- 基本架构

      一个 VSAN 群集最初由 3到 8 个计算节点组成，每个节点必须至少有一个 SSD 和一个常用的SAS 磁盘驱动器。这些计算节点并不会专用于 VSAN：它们也会为各种正常的 vSphere 工作负载提供支持。

      VSAN 会在创建群集时“开启”；这样，新的存储资源就会像计算资源一样透明地添加到池中。

      运行VSAN 的每个服务器节点最多支持 5 个磁盘组。每个磁盘组最多可以有 7 个物理磁盘，但必须有一个相关的 SSD。这些磁盘可以是内部磁盘，也可以是通过JBOD 进行认证的外部磁盘。

      SSD充当分布式读写缓存，并不用于永久保存数据。在该版本中，每个磁盘组只支持一个SDD：70%的SSD 容量用于缓存读取，其余30% 用于写入。可以在取消向磁盘暂存之前，在两个或两个以上节点之间镜像缓存写入来对该缓存写入进行保护。也可以使用多节点镜像来防止发生磁盘故障和节点故障。

      VSAN 可在所有节点之间提供一个集中的数据存储，供虚拟机及其 VMDK 使用。可以在同一个 VSAN 数据存储实施多种策略（冗余、性能），无需预先创建常用的存储池：金级、银级等。

      VSAN 可对所需的策略进行监控，并且只要有足够的资源，也可以根据需要进行自我调整：条带化数据对象、使用更多 SSD 缓存等。

      在该版本中，没有专用于 VSAN 的数据服务，所有服务都由 vSphere 提供：快照、链接克隆、复制、vSphere HA、DRS、VDP，或者通过第三方技术合作伙伴提供。此外，VSAN 具有卓越的“节点撤离功能”，可以在关闭节点进行维护或更换之前，重新定位正在运行的进程及其相关存储。

      在 vSphere 群集中，并非所有节点都需要具有本地存储；没有磁盘的节点可通过网络访问 VSAN 数据存储。

      在内部，VSAN会在虚拟机和存储服务之间使用未来将要实现的VVOL 抽象。不久之后，其他存储提供商也会更普遍地支持VVOL，不过，了解一下VSAN，就可以预知未来将要发生的变化。

      为虚拟机实现功能
      功能是指 VSAN 可以基于可用物理资源提供的服务。例如，功能可以是面向性能的，也可以是面向保护的。

      策略是指一种有用的功能组合（例如，默认性能、有限的数据保护等）。

      对象通常是指一个 VMDK 及其相关快照。

      虽然听上去可能有些复杂，但置备过程非常简单。

      - 首先，根据功能确定一份策略清单：是使用现有的默认功能还是创建自己的功能。
      - 其次，在虚拟机置备期间，选择符合应用程序需求的策略。
      - 最后，完成整个过程，确保所选策略符合应用程序需求。

      可能用到的初始功能足以涵盖初始版本中的基本功能。例如，可以指示允许发生多少个节点故障，从而可以在更多节点之间放置更多的数据副本。

      要提高性能，可以预留读取缓存，并在节点上指定磁盘条带化，以提升后端磁盘速度。要提高效率，可以指定初始置备量，其余则保留精简置备。
      置备期间，VSAN 会检查其在所有节点中的资源清单并选择最佳资源。如果没有足够的功能，管理员可以无条件“强制置备”。置备后，VSAN 会对提供的服务级别进行监控，如果可能，还会进行自我调整。

      需要澄清的是：(1) 一个 VSAN 群集对于每个虚拟机可支持多个策略；(2) 存储资源不会预先置备到“策略池”中，所有操作都会在置备期间动态完成。

      价格/性能

      VSAN 团队分享了几张幻灯片来介绍对比价格和性能范围。虽然不能替代自行判断，但也确实反映了 VSAN 的大体情况。

      VSAN 的一个重要的应用实例是虚拟桌面 (VDI)，此处的对比针对的是一个使用链接克隆来节省容量的全闪存阵列，它使用的是一个中型三节点群集，可支持 288 个虚拟机。虽然不能完全准确地说明在定价模式中使用了哪些组件，但会非常有趣，尤其是在最终用户 VDI 性能与全闪存外部阵列相等时。

      第二幅图为性能图，显示了一个八节点 VSAN 群集中的原始IOPS。

      请注意：(1) 这些节点并不专用于存储，它们也支持应用程序虚拟机；(2) 八节点指的是当前的产品，未来的目标是使 VSAN 可以扩展至与DRS 群集相符。

      作为一名存储发烧友，我希望了解更多有关块大小、精确读/写混合、按序与随机等方面的具体信息，不过令我感到惊异的是：性能似乎超出了各种工作负载的需求。

     基本架构 -- 个人观点
     目前的八节点限制并不算什么限制，尤其对于初始版本的存储软件产品而言。

     不过，我确信存在精确的容量上限，例如，如果将五个磁盘组中的七个2TB 驱动器乘以 8 个节点，则在一个 VSAN 群集中会提供半个 PB 以上的原始容量。

      同理，一个磁盘组一个SSD 的要求也非常合理：因为大小和类型完全由您选择：如果有缓存，请转而使用 2TB 模式。由于在一个 VSAN 群集中，HCL 对不同服务器和存储类型的混合和配对没有体系结构上的限制，因此我只想简单介绍一下以避免出现操作意外。

      VSAN是在数据复制和条带化的基础上设计的；目前并未规划奇偶校验或擦除编码功能。

      最初我对于缺少标准的存储要素（例如NAS、iSCSI等）感到惊讶，但是，现在我发现在目前以虚拟机为中心的环境中，VMDK存储要素才具有很高的价值，当然，它也能使计算与存储在虚拟机边界上更好地对齐。

      可以发现，VSAN在众多以虚拟机为中心的应用实例中非常引人注目：VDI、开发与测试以及充当复制对的远端。分支机构和远程位置部署尤其引人注目：不再需要在多个位置安放单独的物理存储阵列。

     发展中的创意理念

     我认为 VSAN 有许多创意理念必定会在不久之后得到发展。

     首先是使用商用服务器硬件来提供存储服务。可以使用同一个服务器池同时提供计算服务和存储服务：一个组合资源池、一个综合管理视图等。在很多情况下，从资本支出和运营支出角度看，VSAN 更简单，性价比也可能更好。

      将 VSAN 作为 vSphere 核心的扩展进行实施可以实现一种有趣的模式：在这种模式中，存储资源和操作会全面融入到计算活动中。虽然可以通过插件之类的工具连接计算域和存储域，但从一开始就按照这种方式设计应算是首创。
      我很关注大家会对这种集成提出哪些反馈。

      从可用资源中获得多个存储服务级别并非一个全新理念；而在置备期间动态完成，无需预先分配和配置池 -- 这才是一个全新理念。这种按需置备服务级别的方式将比以前的方式更为普及。

      虽然现有产品还不具备这种功能，但我已经发现，将来可以创建各种丰富的数据服务，虚拟化管理程序可以直接支持（或调用）这些服务，并且这些服务完全符合虚拟机边界及其相关 VMDK 的要求。

      我认为有必要关注一下定价模式：与其他VMware 产品一样，它也会按插槽进行许可。我比较青睐这种模式，原因在于：(a)它不再受制于按容量对存储定价，我从来都不喜欢这种定价方式；(b)定价方式统一，易于理解。

      最后，将传统的外部存储方法（SAN、NAS）与 VSAN 结合使用不存在任何限制，也就是说，客户可以在合适的时间和场合使用VSAN。用多用少 --只是操作系统的增量功能与大存储决策之间的差别。

      还有改进的空间吗？
      我很自然地想到几个下一版可以改进的地方。

      首先是复制：我们需要实现与目前通常可以从阵列中获得的强大快照和远程复制功能（包括连续复制）相同的功能。无论这些功能是属于VSAN 产品的一部分还是由合作伙伴提供，都无关紧要。

      其次，最好能按照目前管理 VSAN 的方式将这些高级数据保护功能作为以应用程序为中心的计算扩展来置备、调用和监控。另外，最好能将这些操作持续呈现到使用门户（如 vCD）中。

      最后，这种无缝集成模式最好能扩展至其他存储堆栈：VMware 及其合作伙伴提供的存储堆栈。从集成的角度讲，最好不要将常用的存储产品视为二级要素。

      除此之外，还有一些通常要考虑的因素：更多容量、更多节点、更出色的低级别工具、备用保护机制等。

      发布测试版后，可以从 vsanbeta.com 获取。据早期测试人员评价，该版本启动和运行起来非常简便，并且能将置备体验完美地融为一体。

      我希望能有更多的人投入到其中，认真对待这种体验，并向团队提供反馈。这是一款精巧的存储产品，在许多方面都与众不同。

      业界反应如何呢？
      大家很容易认为，有了VSAN，VMware便可以公开地与其传统存储合作伙伴（如NetApp、EMC、HP 等）展开竞争。这个结论并不正确。

      首先，请记住，VMware 可以有力地与其他基础架构软件供应商（Microsoft、RedHat 等）相抗衡。

      这些供应商都在明确扩展其存储能力，而 VMware 当然也应该进行扩展。从这个角度看，VMware 在这方面明显脱颖而出。

      从更实际的角度讲，不难发现现行版本的 VSAN 实际上在很多重要方面都无法与常用的存储阵列相媲美。我们可以列出很多方面，常用阵列可以实现而 VSAN 却无法实现。反之亦然。

       尽管如此，VSAN 产品在很多方面仍然非常引人注目，我相信它必定会在不久的将来在存储市场赢得一席之地。

       不过，我的想法实际上并不重要。

       真正重要的是其他每个人的想法。

--------------------------------------------------------------------------------------------------------------------------------------------------

作者： Chuck Hollis

近日，ChuckHollis 加入了 VMware，担任存储与高可用性部门首席策略专家。在 Chuck Hollis 的领导下，VMware成功发布了一款领先的软件定义的存储解决方案－VSAN。期间，他将其在存储行业和 IT 生态系统方面的真知灼见引入了 VMware。加入 VMware 之前，Chuck Hollis 曾经在 EMC 任职 18 年，担任 EMC 全球营销首席技术官。他喜欢与客户和业内人士探讨各类技术话题。当然，也酷爱写博客。Chuck 与妻子和孩子们共同居住在马萨诸塞州的霍利斯顿。