近来，软件定义存储领域频频出现“收购”现象，新产品的发布消息也络绎不绝。这不禁让人发问，“软件定义存储”这个在2013年被频繁提及的IT热词，究竟会对我们产生怎样的影响？

　　虽然各大厂商都在宣传“软件能帮助数据中心存储摆脱硬件主导的束缚”，但用户始终还是需要搭建硬件平台来运行软件，辅助软件定义存储的工作。尽管眼下已经有趋势表明软件定义存储开始向商用模式迁移，它们与传统模式之间的差异仍值得我们注意。工作负载以及不同的基础设施和基础设施模式给实际效果造成的影响也不尽相同。

　　如今越来越多的产品推出了共享式DAS存储架构，意在从基础设施中移除SAN并降低整体复杂程度。不过其对复杂性的降低效果还有待商榷，它所起到的更多是一个转化的作用。实际上它并没有真正地移除SAN，只是对其进行改进。

　　用户对于存储厂商以各种形式演示的无共享集群架构已经见怪不怪，通常此类产品都属于软硬件集成的“打包”型解决方案。不过随着终端用户对部署自有硬件能力的需求愈发强烈，也催生了前所未有的新型机制。

　　一旦用户摆脱了供应商对底层基础设施的严格掌控，相应的存储软件必须更具智能化。而终端用户执行团队则需要学会像供应商的硬件团队那样审视设施、斟酌方案。

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

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

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

　　那么单一的计算或存储节点发生故障会造成哪些影响？多个计算/存储节点出现故障又是怎样的情况？

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

　　从理论上说，我们都希望自己的数据与处理机制间的距离越近越好。然而数据本身有持续性，需要长期占用空间。除非我们能创造出一套足以准确帮助计算机制寻找数据位置的动态基础设施，否则迁移工作也就在所难免。

　　此外，供应商们也需要进一步改进其硬件设备。而在这种复杂环境下的存储系统运行机制，可以说是谜样又晦涩难懂。为了与之相协调，软件复制功能与大规模商用基础设施也必须在当下的基础上更进一步，否则根本无法支撑起广泛的实践应用。

　　不过我们也看到多家厂商也在频频出新招，推出开源或闭源的解决方案，存储大型客户对此也表现出了极大的兴趣。存储变革将走向何方？让我们拭目以待吧。