软件定义的存储 - 我们的方向在哪里？

原文：http://chucksblog.emc.com/chucks_blog/2013/06/software-defined-storage-where-are-we.html

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

      如果您从事与虚拟化或任何形式的 IT 基础架构相关的工作，您可能会（也应该会）关注 SDDC（基于软件的数据中心）的概念。

     它代表着一套强大的理念：将智能抽象到软件中，IT 世界会变得更美好：更灵活、更可控、更高效。基础架构行为并非预先规定，而是要由现实中的应用程序工作负载来决定。

     一旦三类核心基础架构穿过 SDDC 虫洞，它们就不可避免地会发生改变。

      例如，五年之前我们想到的物理世界中服务器的样子与现在完全不同：现在的服务器是抽象、动态、可调整大小且可以重新定位的虚拟实体 -- 这一切要归功于虚拟化。

      与几年前服务器和计算所经历的情况相同，现在，网络和存储也在走向这相同的视界。不久的将来，它们将呈现为另外一种样子。

      行业存储供应商也注意到了这一必然性。迄今为止，EMC、NetApp 和 HP 均就软件定义的存储发表过许多观点，我相信 HDS、IBM 甚至 Dell 最终都会参与到这一话题的讨论之中。当然，嗅到机会的不乏一些小型灵活的初创公司。

      我们的方向在哪里？不同观点能否达成一致？不同供应商的观点如何叠加？未来我们会看到什么？

      在这篇博文中，我将斗胆尝试做一个公正的行业观察者。不过，我坚信会在这场比赛中找到我心仪的马匹 …

      基本 SDS 概念

      如您所料，关于软件定义的存储究竟是什么几乎还没有什么共识。意见不一可能会令某些人沮丧，但这是不可避免的。不过，随着时间的推移，一个完美的定义必将浮出水面。

      顶层概念非常简单：就是把我们常见却又很复杂的存储与保护环境重新设计为可编程的虚拟化软件实体。

     关于 SDS，我认为有三个核心挑战摆在我们面前。

      第一，所需技术尚不完备 -- 但种种迹象表明此类技术的发展速度很快。到明年市场中应该会有数款优质产品进入实际评估阶段。

      第二，我们必须发展原有资源。例如，VMware 并没有要求您必须购买新的服务器来运行 ESX，SDS 也应该这样做。话虽如此，在计算和虚拟化的推动下，服务器设计发生了巨大变化，我期待着在 SDS 和 SDN 的推动下，存储和网络设计也会发生这种变化。

      第三，要想利用新的功能，我们的组织形式也必须有所突破。如果我们仍然像 1999 年那样来管理存储，任何一种新技术都无法为我们带来益处。


      向特性超集出发
      虽然权威定义还有待发布，但我们可以将已经知道的各种特性放在一起来获得更清晰的认识。

      警告：将所有特性汇总在一起会非常多；但并非每一个特性对每个人都重要。

      在大多数 SDS 描述中，经常使用的一个属性是可编程性：是否可以通过基于 REST 的 API 调用所有服务、更改行为以及获得管理信息？

      设想的模式要求所有与存储相关的服务都由一种具备应用知识的实体（而不是传统的存储管理员）来协调，因此每个有效的定义都应该包括这一点。

      将这一概念延伸开来，对于经过扩展的 SDS，一方面就是应该能够根据具体角色和需要（VMware 管理员、DBA 和财务人员等）访问各种使用门户 -- 而这些门户既可以打包提供，也可能根据需要来创建。

      与可编程性相关的是硬件抽象，它包括以下两方面：(1) 能否让所有设备合用资源和功能，(2) 能否以标准方式发现并调用服务而不管底层设备如何？每一件事分别使用一套独立的 API 是一回事，而每一件事仅使用一套 API 完全是另一回事。

      除了使用方便之外，这种标准的存储 API 层经证实可以作为大多数云堆栈的一个主要组件。

      而这势必会引起关于丰富存储服务的讨论：数据表示、复制、缓存、分层、QoS 以及无中断移动性等。理想情况下，任何一种 SDS 定义都应该一致地记录和反映清单中可用的底层数据服务，即使底层设备不提供这些服务，SDS 层本身也可以提供自己的服务。

      在这一讨论中，比较吸引人的部分是可以使用商用硬件 -- 具体而言就是，无需专用阵列硬件就可以实现数据预留（例如，持久性存储以及相关功能等）-- 能够使用标准商用服务器作为存储目标。这意味着使用基于软件的存储，这种存储可以仅使用商用硬件来模拟常见阵列的许多属性。

      由于 SDS 是一种基础架构，因此，我们必然希望获得大量管理信息：通过以下各种门户实现标准化，并易于使用：硬件清单、配置、利用率、性能、监控等 -- 可以放在一个聚合中，也可以为每个租户提供。

      而抽象的概念在这里也非常有用 -- 假如 SDS 层以标准化的方式收集并呈现它所接触的每个对象的信息，则用处会更大。

      另外，基于标准服务目录建立基于策略的协调这一概念也非常重要 -- 将高级别的请求（如Oracle 数据库的黄金服务级别）一路转化为置备和配置存储容量、路径、数据保护以及现实存储服务定义中可能包括的任何内容。

      因为找不到一幅比较好的通用示意图，因此我就自己画了一张。肯定还有改进的余地，希望您不吝赐教！

     

     读到这里，您就会发现我们对软件定义的存储的理想定义包括以下特性：
     -- 合用资源和功能，无论使用什么具体设备

     -- 可以通过一组基于REST 的标准 API 对每个对象进行发现和编程，而无论您使用什么物理存储。
     -- 能够访问丰富的存储服务，无论这些服务是由底层存储平台提供的，还是由 SDS 层提供的，甚至在理想情况下是由这两者提供的。
    -- 既可以将数据存储在传统存储设备上，又可以将其存储在基于商用硬件构建的新型软件存储目标上
    -- 标准化的综合管理信息流，内容非常丰富，并具有多个角色视图，包括适用于特定租户的视图。
    -- 具有一个协调引擎，可通过策略将高级别的服务请求转化为一系列有效的置备任务。

      当然，这一切都以软件产品的形式提供，而不是一个坚硬的金属外壳 :)

      虽然并非所有供应商都接受所有这些内容，但所述方法的差别依然很大。您可以自己决定哪一项相对更好。


      我对 NetApp 的SDS 视角的理解
      自从 EMC 公开发布这一软件以来，NetApp 一直在煞费苦心地向所有人表明他们一直在从事这方面的工作 -- 不过 SDS 本身还是一个非常新的概念。如果不对这一营销主张进行评论，NetApp 如何跟得上这一扩展标准的发展呢？

      NetApp 将 ONTAP 作为在 NetApp 环境下实现大多数SDS 功能的资产。偶尔也会谈到 OnCommand 资产，但其重要性不可同日而语。

     可发现性和可编程性：我确信每一种 NetApp ONTAP 资产都可以通过API 来发现和编程，但我仍有以下两个疑问：我应该如何对非 ONTAP 资产进行发现和编程呢？即使我所在的环境只使用 ONTAP，所有资产及其功能的通用存储库是什么呢？OnCommand 仅适用于小型的NetApp 环境，因此这里似乎无法进行编程。如果客户决定在可预见的未来只使用 NetApp 产品和服务，那么这在一定程度上也是可行的。

      访问丰富的存储服务：尽管 ONTAP 自身提供了一套丰富的存储服务，但它并未涉及该环境中可能存在的任何其他服务。没错，可以在块存储设备前端插入一个 NetApp 文件管理器头，但该后端设备只能用作非常呆板的存储。这样一来，就只能使用 NetApp 实现的存储服务，而对其他存储服务则无从下手。

      传统存储和商用存储：尽管 ONTAP 营销方案可以选择支持传统存储设备（NetApp 阵列或在 ONTAP 后端用作呆板容量的外部阵列），但现在绝大多数 ONTAP 都只在 NetApp 硬件上运行。

     丰富的管理信息：ONTAP 可以为自己的设备提供丰富的管理信息，但对于该环境中的其他设备却无法呈现和/或汇总任何信息。OnCommand只能为 NetApp NAS 设备创建简单的视图，但该视图无法进行合用。

     基于策略的协调：到目前为止，我认为这场重量级竞赛的赢家会留给云环境可以提供的上层协调引擎，例如，VMware、OpenStack等。

      不过我相信，对于任何供应商而言，这一答案并不充分 -- 事实上，任何不具有存储协调能力的供应商要想了解设置性能、保护和可用性等策略的实用知识，还有很长的路要走，可谓任重而道远。

     总结：没错，NetApp 明确表明自己要加入这一行列。需要付出的努力可想而知：他们需要在商用服务器上运行 ONTAP，还要专门在存储管理和协调领域投入不菲的资金，而这些领域不仅限于 NetApp FAS 设备 -- 也许还要经历一些收购？最难的可能是要接受多供应商存储环境的现状。


      我对 HP 的SDS 视角的理解
      借最近举行的 HP Discover 活动的东风，HP在“软件定义的存储”旗帜下发布了许多存储公告。尽管您会看到他们在媒体说明会中频繁使用的词语，但我觉得要确定他们的基本定义和关联功能真的很难。

      Dave Donatelli 在“存储软件”、多供应商和开放性的意义以及在合适的时间将合适的数据移到合适的位置这种能力方面谈了很多。

      我不能否认其中的任何观点，但是，HP 的说明以及他们的产品组合如何让他们适应当前环境呢？

      可发现性和可编程性：我不能在此发表过多评论。尽管具体的 HP 存储产品偶尔可能具有类似于 API 的接口，但要使他们的“所有”存储产品都可以进行发现和编程，HP 还有大量工作要做。这还不考虑非 HP 产品，更不用说对客户的所有内容仅使用一组 API 了：这些内容既包括HP 的，也包括非 HP 的。

      访问丰富的存储服务：3PAR 等具体 HP 产品确实可能提供丰富的存储服务，这一点毋庸置疑，但所采用的方式是以硬件为中心的传统方式。产品组合中似乎还没有哪款产品可以对各种存储服务进行抽象，并使其可以轻松使用，而不用考虑提供这些服务的实体。

     传统存储和商用存储：HP 拥有一些有趣的资产，分别是 StoreVirtual VSA（收购前称为Lefthand）以及用于备份的 StoreOnce VSA。这两者都已定位为可在虚拟机上运行的软件存储目标。这是一个良好的开端，但是 ...

      丰富的管理信息：我没法对提供哪些信息进行评论。HP 利用 OpenView管理基础架构的历史悠久，但这些历史传统有多少会转化为软件定义的存储尚不明确。无论是传统存储还是新型软件定义的存储，当谈到在企业环境下进行复杂的存储管理时，可以从当前产品组合中找到的合适产品并不多。

      基于策略的协调：我仍然没法做过多评论。没有任何证据表明 HP 在以存储为中心的协调方面有任何值得关注的重要功能。与 NetApp 非常相似，真正有吸引力的是负责该任务的上层云协调引擎，但这个理想与现实之间还存在很大差距。

      总结：HP 已经开始滔滔不绝地说，但还需要实实在在地做，他们还有很长的路要走。尽管在他们的产品组合中有一些非常不错的基于软件的存储资产，但对于我所描绘的宏伟蓝图，这只是杯水车薪。在某种程度上，他们要走的路比 NetApp 还要漫长。


      我对 EMC 的SDS 视角的理解
      鉴于 EMC 最近在 EMCWorld 上发布了 ViPR，我们需要重点关注这一部分。

      在本文讨论的三个供应商中，EMC 做得最好并且最符合要求，但仍有差距需要弥补 -- 至少在我眼中是这样。
      ViPR 是一款令人惊叹的产品，我提出的所有 SDS 功能类别在此都能找到。

     可发现性和可编程性：这是 ViPR 的核心功能。它可以发现现有存储资产并依据其功能进行归类，并可以使用一个基于 REST 的 API（不论存储设备是什么）在带外沿着堆栈向上公开信息并向下发送命令。可以使用大量的使用门户。

      尽管最初的目标很自然是 EMC 阵列，但其意图却是为 NetApp 提供一日支持，并按顺序处理其他非 EMC 阵列。设备适配器可由 EMC、阵列供应商或有兴趣的第三方来创建。

      访问丰富的存储服务：ViPR 非常与众不同的地方是，它既可以在其目录中公开底层阵列和基础架构服务功能，又可以通过一个框架提供自己的软件存储服务（而不管使用什么底层硬件）。最初的版本包括 HFDS 和基于现有NAS 的对象，不过据说将来还会提供许多新功能。

      传统存储和商用存储：ViPR 可以为传统存储阵列（至少是 EMC 的阵列）提供充分支持，但对于非 EMC 阵列还有很多工作要做。ViPR 还支持在商用硬件（如 Atmos、Avamar 等）上运行现有 EMC 存储堆栈。EMC还没有主动倡导在商用硬件的虚拟机上运行存储目标这一理念。

      丰富的管理信息：ViPR 的另一个强项是，开箱即可获得运行存储即服务所需的一切，并可为聚合以及每个租户进行完整度量和测量。其中有很多功能都是通过 EMC 的多次收购而实现的。

      基于策略的协调：这是 ViPR 另一项非常强大的功能。置备存储服务不只是简单地分配容量：您可以置备性能、数据保护、可用性、访问路径以及其他可能的特性。它可以创建一种与您所选择的云协调框架（VMware、OpenStack等）完美搭配的高级别服务结构。

      总结：在这场竞赛初期，我认为 EMC 在软件定义的存储方面处于领先地位 -- 虽然并非尽善尽美。虽然明确计划要增加可以发现和协调的传统阵列产品组合的数量，但还没有很多人公开谈到要将存储软件阵列堆栈带到单独采购的商用硬件上。


      我们将何去何从呢？
      任何技术供应商都不愿意放过任何相关的行业趋势 -- 软件定义的存储以及我们常见的存储供应商团体当然也不会例外。瞄着临近的 SDN（软件定义的网络）领域发生的事，并盘算着在我们的狭小世界中可能会发生什么。

      然而，追捧那些流行的词语和切实实现客户可以在其环境中使用的功能是两码事。

      照此算来，此刻的比赛就像是一个供应商的竞技。未来十二个月可以确定，EMC 以外的存储供应商是否会在支持技术方面进行必要的投资，并帮助客户以智能的方式使用新功能。

      不过，我相信还有一批我们可能知之不多的行业供应商 -- 云堆栈供应商：VMware、OpenStack、RedHat、Microsoft 等。这些供应商会从完全不同的角度（云服务集成的角度）参与这一竞争。尽管他们没有过多的存储领域经验，但他们不会受现有业务模式的羁绊。

      有一件事是可以肯定的 -- 这种解决方案确实存在着实际需求。这种需求不是“我今天买明天用”，而更准确表述应该是“这个东西对我们非常重要，我们最好关注一下该领域供应商的实施情况”。

      比较前卫的 IT 企业都知道，基础架构模式正在飞速发展，而潜在的优势会非常巨大。

      而且谁都不想落在后面。:)

     欢迎在微博上关注我，这样在我发布博客文章后您就会收到通知，并可以让您了解更多有关 VMware 存储的信息：@VMware中国

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

作者： Chuck Hollis

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