存储阵列中的运作机制就像是魔术般难以理解

在所谓软件定义存储——我向来喜欢直接称其为“存储”——领域近来又传出一系列新消息与收购活动。在种种乱象之下，我们不禁要问，这类方案会在真实世界中起到怎样的效果？

我认为最重要的是明确一点，即用户需要搭建硬件平台来运行这类软件。尽管眼下已经有趋势表明软件定义存储开始向商用模式迁移，但我们仍需注意到它所具备的一系列细微差异。在软件定义存储的道路上，我们需要始终关注工作负载状况以及不同基础设施与基础设施模式给实际效果造成的影响。

我发现已经有越来越多的产品为DAS赋予共享式存储资源的运作能力、从基础设施中移除SAN并降低整体复杂程度。虽然在我看来其复杂性降低效果还有待商榷，但它给基础设施带来的变革仍然值得肯定。事实上，它并没有真正移除SAN，只是对其进行改造。

如今我们对于存储供应商以各种形式演示的无共享集群架构已经见怪不怪；大多数此类产品都属于软件与硬件的“打包”型解决方案。不过随着终端用户对部署自有硬件能力的需求愈发强烈，软件定义存储的出现带来了新的纪元，让人们以前所未有的新型机制处理此类工作。

一旦供应商们放弃对底层基础设施严格掌控，软件就必然以更具智能化的形式补充而上，终端用户执行团队则需要学会像供应商的硬件团队那样审视设施、斟酌方案。

举例来说，数据中心的东-西流量模式就变得非常重要。大家可能会发现自己需要部署低延迟存储网络；新SAN不再遵循南-北模式而转向服务器-服务器（即东-西）模式。从传统角度看，这些工作原本是虚拟化技术人员才需要关注的内容。

再就是了解性能与故障方面的问题：我们在保护本地DAS时是该利用RAID还是将其改造为分布式RAIN（即独立节点冗余阵列）模式？如果大家有意将数据中心内的所有存储资源共同汇聚成一套庞大的资源池，那么单一节点发生故障会给全局体系带来何种影响？又会不会给整个资源池的性能造成拖累？

任何跟分布式存储模式打过交道的技术人员一定都有这样的体会：性能低下甚至出现故障的节点所带来的影响远超我们想象。有时候，其表现与当初的令牌环网非常相似，单一接口配置不当将导致整套体系的性能陷入泥潭。与此相比，重复IP地址造成的影响甚至可以忽略不计。

那么，单一计算/存储节点发生故障会造成何种影响？多个计算/存储节点出现故障又将如何？

过去，这些问题都该由存储硬件供应商负责，本地存储团队的实施阶段也无需用户介入。但现在我们需要制定一系列决策，思考如何保护数据、理解副本机制带来的影响等。

从理论上讲，我们希望自己的数据与处理机制间的距离越近越好。然而数据本身需要长期占用空间，因此迁移工作也就在所难免。除非大家能拿出一套足以准确帮助计算机制寻找数据位置的动态基础设施，否则数据本身必然要被挪来挪去并消耗掉管理人员大量时间。

供应商们也需要进一步改进其硬件设备。根据我的亲身经历，在这种复杂环境下的存储系统运行机制简直就像是在变魔术。为了与之相协调，软件复制功能与大规模商用基础设施也必须在当下的基础上更进一步，否则根本无法支撑起广泛的实践用例。

不过我看到多家厂商已经开始不遗余力地展开行动，拿出或开源或闭源的解决方案；大型存储客户们对此也表现出极大兴趣。这一切似乎预示着该领域终将出现一位赢得大奖的胜利者，但激烈的竞争也必然会令无数参与者半途而废。

存储正迎来一个有趣的时代，欲知后事如何、需待下回分解。