关于 VSAN

原文：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 与妻子和孩子们共同居住在马萨诸塞州的霍利斯顿。