关于服务器 SAN 和 SDS

原文：http://chucksblog.emc.com/chucks_blog/2014/01/of-server-sans-and-sds.html
注明：本文内容基于 VMware VSAN beta 版本撰写，请访问http://www.vmware.com/products/virtual-san/获得有关正式版本的更新信息。

我很高兴在 Wikibon 上读到了我的同事 Stu Miniman (@stu) 所写的文章，这篇文章首先提出了这一新细分市场 --“服务器 SAN”。

在当前各种行业分析中，Wikibon 的内容通常能让我从中获益（至少在存储方面），更不用说他们开放性、协作式风格带给人们的吸引力了。虽然我对他们发布的内容不会全盘接受，但 Wikibon 始终在我们的社区中扮演着举足轻重的角色。

尽管这篇文章开了个好头，但许多相关问题一直萦绕在我的脑海中。

是时候写篇博文了...

实现服务器 SAN 的不同途径
我们可以通过多种途径来实现 Wikibon 上所提到的“服务器 SAN”这一概念。一种途径是，我们需要提供一种可以替代其他模式的不同方案：这些模式包括常见的外部存储、简单的 DAS、Hyperscale、云等。但要清楚一点，服务器 SAN 主要用于替代外部存储阵列，并不完全适合云、Hyperscale 等。

因此，根据 Wikibon 的观点，大多数企业存储用户现在都有一个值得评估的替代方案：新型服务器 SAN 解决方案或为人熟知的外部存储阵列。这种途径非常直接。

但您也可以通过另一种途径来实现服务器 SAN，那就涉及到关于软件定义的完整讨论。无论您是从 SDDC（软件定义的数据中心）入手，还是从 SDS（软件定义的存储）入手，，您都可以沿着一个思路抵达同一个彼岸，尽管使用的是不同的标准。

我相信这些截然不同的动机会进一步细分最初的市场格局。

我们来谈一下控制层...
对于大多数小型和/或策略性存储部署环境，通常并不关心存储是如何管理和协调的。此时的要求一般都很直截了当：给我一个可用于置备、管理、报告和故障排除的简单存储接口。理论上讲，在这些不太大的环境中，您不会与存储进行非常频繁的交互，往往只是根据事件执行一些简单任务而已。
只需重新创建外部 SAN/NAS 需要执行的操作就足够了。

但随着我们开始考虑更大、更复杂且要求更高的环境，这一观点就会发生很大变化。
不仅存储会增加，而且在某种程度上与存储交互的利益相关者也会增加：服务交付经理、服务器管理员、数据库管理员、应用程序所有者和开发者、网络人员、业务连续性人员、安全群体、财务等。

哦，也就是所说的存储团队。

不经意间，控制层变成了一个非常重要的主题，特别是在 IT 即服务和云操作模式下更为如此。的确，环境越大越复杂，不同风格的管理就变得越重要。

截至目前，物理存储阵列已经很成熟，它可以提供良好的控制层，并逐渐与不同的控制点集成。但一个无法回避的事实是，这是一种“事后集成”。现在的外部存储不会与计算和网络共同视为必不可少的组件。

服务器 SAN 是否会表现更好呢？有可能，但要视情况而定。

如果服务器 SAN 只不过是常见的外部存储模式的重建（使用内部服务器 DAS 除外），我们就很有可能面临与现在相同的情况，至少在管理和控制层方面是如此。
只不过是新瓶装旧酒而已。
但如果能将服务器 SAN 软件功能与计算和网络融合在一起，我们就为更强大的全新模式奠定了基础。

对于未来，我可以很容易断定：如果可以融合基础架构软件功能，我们就为构建所需要的集成控制层奠定了更加坚实的基础。理想情况下，这种融合会在虚拟化管理程序中进行 -- 我最近写过的相关文章。
是的，我正在论证 VMware 的 VSAN。

数据服务...
现在，绝大多数常见数据服务（复制、分层、加密、去重复、快照、缓存、合规性、元数据等）都会嵌入到外部存储阵列中。购买一个阵列，您就可以做到这些。的确，看似相同的存储产品之所以能实现超群的速度和馈送，差异之一就在于此。

实现服务器 SAN 的一个途径就是，简单地重建这种嵌入式数据服务模式，只不过是在服务器软件中完成，而不是在外部硬件中完成。再次说明，对于不太大的环境，这种方法可能会受人欢迎，它可以将所有内容都封装在一起。

如果我们把重点转向更大、更复杂且要求更高的环境，则会更强烈地希望提供基于软件的数据服务，而与存储目标无关。例如，可以通过相同的方式实现快照和复制，而不管使用什么后端，也可以采用标准化的加密方法或标准缓存机制。

客户一定希望将他们的方法融入到数据服务中 -- 的确有这样的市场。但随着 Wikibon 关于服务器 SAN 观点的发展，提供嵌入式数据服务的产品与提供独立于后端数据存储的数据服务的产品应该清晰分明地归入不同的细分市场。

再说明一下，虚拟化管理程序是作为一个逻辑位置来提供这些数据服务的，因为它恰好位于应用程序与基础架构之间。

与计算和网络交互
即使我们仅仅去关注存储这一方面，它也会与计算和网络进行大量交互。存储节点要占用 CPU 和内存，从而会对性能产生极大影响，而它还要通过网络进行通信，同样会影响到性能和可用性。存储功能与应用程序和其他 IT 功能都会消耗同一个资源池中的资源。

我们不得不进行硬分区并分别配置和管理与存储基础架构关联的资源，而这必定会与智能交互动态基础架构资源池的理想情况相去甚远。我想这方面的融合会逐渐将 Wikibon 推崇的服务器 SAN 的范畴再次进行细分。
不过这一视角比较狭隘，它仅仅考虑了存储这一方面。

例如，当我想为新应用程序置备基础架构时，我希望一次性置备所有资源，从而能够实施反映业务优先级的策略。我一定希望软件能够处理在不同域之间发生的所有凌乱的交互操作和相互关系。如果出现问题，我希望基于软件的基础架构能够向我发出通知，并告诉我应该怎么做（如果它无法自行解决的话）。
这才是基于软件的基础架构融合的真正优势。

回到现实
也许我总是对未来想入非非，很多人都对我提出过指责。这也没什么不好。但现今的情况如何呢？
我想我应该这样总结一下：一种新的存储正在崭露头角，它可以利用服务器和软件来完成以前只能通过外部阵列完成的任务。
一些人可能会认为这是从战略上替代当前的工作方式：速度更快、效果更好、价格更实惠等，优势多多。

而另外一些人却未将视野局限在孤立的存储讨论之中，他们看到了使用软件与其他领域融合所蕴含的惊人潜力。

在此感谢 Stu 和 Wikibon 团队的出色工作 :)

欢迎在微博上关注我，这样在我发布博客文章后您就会收到通知，并可以让您了解更多有关 VMware 存储的信息：@VMware中国--------------------------------------------------------------------------------------------------------------------------------------------------
作者： Chuck Hollis近日，ChuckHollis 加入了 VMware，担任存储与高可用性部门首席策略专家。在 Chuck Hollis 的领导下，VMware成功发布了一款领先的软件定义的存储解决方案－VSAN。期间，他将其在存储行业和 IT 生态系统方面的真知灼见引入了VMware。加入 VMware 之前，Chuck Hollis 曾经在 EMC 任职 18 年，担任 EMC 全球营销首席技术官。他喜欢与客户和业内人士探讨各类技术话题。当然，也酷爱写博客。Chuck 与妻子和孩子们共同居住在马萨诸塞州的霍利斯顿。