当《五十度灰》在软件定义存储的世界里上演

引言

正如同《五十度灰》里人性背后隐藏着复杂深沉的阴暗面，软件定义存储世界也有着它的“五十度灰”。

时下，尽管软件定义存储（Software-Defined Storage，SDS）还没有严格的技术定义，但俨然已成为业内“模因”一样的存在。尤其在“传教士”们盛情的渲染下，我们似乎也迷醉了双眼，看到SDS完美得闪耀圣光，而轰下神坛的“传统存储”（如SAN和NAS）看起来一无是处。

模因（meme）：文化基因，与基因（gene）发音相近，指人类思想通过模仿、散播，像基因一样代代相承。

然而，“阳光越强烈，阴影就越浓郁。”正如同《五十度灰》里的男主，表面光鲜亮丽的背后，实则隐藏着五十道不为人知的阴暗面；软件定义存储在“闪耀”的背 后，其实也隐藏着它的“五十度灰”，需要我们去深入了解，仔细辨别。而对于拥有明智商业头脑的IT决策者来说，选择哪种存储架构，与其看它是否时下最热 门，不如回归传统考量标准——成本、可靠性和便捷性来得更有效。

“传教士”们究竟说了多少谎？

存储市场上，“传教士“们为SDS堆砌的华丽辞藻不绝于耳——“SDS将颠覆传统存储，开启存储进化新时代”…冷静想想，如果“存储进化”真的发生，它一定是从存储“孤岛”向存储“共享”的大方向演进。

想起了上世纪六七十年代，还是“内部存储”和“直连存储”的天下。所谓“内部存储”，即存储内置于服务器；“直连存储”则是磁盘阵列通过外部扩展的服务器主板总线连接到服务器机箱外侧。此后存储技术开始朝着两个方向发展：一是支持存储通过网络共享文件级数据，二是通过数据库和面向事务处理的系统共享块级数据。后来块级存储从“孤岛”架构演进为“共享”阵列，这意味着从前“内部存储和直连存储必须直连服务器，数据存取、共享、扩展十分困难”的日子结束了，共享阵列有很多端口，可以连接很多服务器主机。

然而当系统需要进一步扩展时，依然十分麻烦。这时工程师们想到引入一个交换机制，将存储阵列全部连接到交换机上，并使用光纤通道或iSCSI传输协议，这就是SAN架构。当初SAN架构的终极梦想是：底层存储可为上层全体应用所共享。

然而，一个开放异构的终极SAN终究没能在市场上问世。厂商为了确保存储设备的销量盈利，更愿将精力放在盘阵里专用控制器的功能扩展上，而对不同厂商品牌的 异构组件如何实施一致性管理并不上心。于是，专有控制器加上专有增值软件，通用管理策略的缺失，以及高精尖运维团队的需求，导致购买、部署、运营一套 SAN架构极为昂贵。

到了本世纪初，服务器虚拟化全面来临，上述SAN的困扰依然继续。对于提供服务器hypervisor技术的厂商来说，当更多应用负载整合到更少服务器上时，上层应用负载出现性能不足，厂商就把责任全归咎到底层存储的SAN架构上。

事实上，无论SAN或NAS本身有多少短板，服务器虚拟化负载只会让它们情况更糟。毕竟，当应用负载整合到更少服务器上之后，单个服务器发出的I/O数量将 急剧变化——每服务器平均增加7~16路I/O连接。Hypervisor执行计算任务时也会对网络、fabric互联及交换机系统的通信状态产生改变。

既然服务器虚拟化和传统存储杠上了，hypervisor厂商当然得想方设法灌输给用户“虚拟化技术的各种好”了：一来，虚拟机可在主机之间复制，形成高可用集群；再者，虚拟机还能在服务器之间迁移，实现高效负载分配和高可用性…

只是，以下事实怎么也回避不了：当单个服务器主机整合了大量虚拟机，且负载要在各物理服务器间实现自由迁移，必然给上层应用和底层存储之间的持续连接造成压 力。此外，当某个应用搬迁到新的服务器，通常需要管理员介入，为其设置新通道连接所分配的存储。而且，众多虚拟机共同向管理程序发送I/O数据流，在繁重 的工作负载下，I/O数据流可能连续产生，也可能比较随机，这会加重内存和磁盘的读写压力，增加延迟，最终导致上层应用负载性能下降…这种现象也就是业内 常说的“I/O竞争”（I/O blender effect）。

当 越来越多hypervisor用户开始抱怨“应用性能不足”，hypervisor厂商狡黠地将炮火齐刷刷对准了传统存储，还积极编排其“N宗罪”—— 成本高、扩展差、运维难…“是时候颠覆传统存储了！”于是，他们摇身变为SDS的“传教士”，热情奔向“软件定义存储”这颗存储界超级新星的怀抱。

“传教士”们诉说传统存储“N宗罪”之再审判

1. “传统SAN或NAS导致应用负载性能低下”

不好意思，他们说谎了。因为只要很简单看下存储I/O的队列深度，就能知道存储I/O路径是否导致应用延迟。很多时候，队列深度不是很重要（并没有数据在排 队等待写入磁盘）。当队列深度读操作与处理器周期相结合，CPU与内存间的通信路径很可能出现拥塞，这时，应用性能下降是由相关的应用代码或 hypervisor代码引起，而与存储一点关系也没有。

2. “专用存储导致高成本（包括OPEX 和CAPEX）”

传统存储意味着高成本，毫无疑问，过去是，现在也是。也许硬件厂商会争辩道，盘阵控制器上的增值软件及功能扩展增强了个性化竞争优势，然而现实就是赤果果，这些“增值扩展”增加的…反而是系统配置复杂度、管理难度以及高精尖运维团队的人力成本！

3. “传统存储架构缺乏灵活性”

专用存储在灵活分配和释放资源这方面的确比较苦手，但是，这对“应用性能”不会造成一丁点儿影响。

4. “DAS存储比SAN强”

这显然是假的，而且毫无意义，因为NAS和SAN本身也是广义的DAS。NAS是一种直连到精简型服务器的存储，且基于网络传输数据。而SAN是在DAS中加入物理或fabric层交换机，将服务器层和存储层既隔开又实现高速互联，给人一种网络附着的错觉。

“五十度灰”下，“你”（软件定义存储）的真实面目到底是什么？

话说回来，既然人性的阴暗面复杂深沉，定不能简单粗暴地盖棺定论，因此，“传教士”们给传统存储扣上这些“N宗罪”的帽子，究竟真相如何，我们也不必急着妄下断言。倒是他们宣扬的 “软件定义存储将掀起下一代存储革命”的观点很让人共鸣。

BTW，软件定义存储也属于DAS结构呢！存储直接从物理上连接虚拟服务器主机。它与从前的DAS唯一的区别是：存储增值功能（软件）不是安装在本地外接盘阵的控制器上，而是在服务器的软件层里；Hypervisor厂商则干脆将其封装到自家的软件堆栈中。

虽然软件定义存储还没有公认的确切定义，但它确实也算是一颗“万灵丹”——在软件定于数据中心（Software-Defined Data Center，SDDC）的世界里，因“传统存储”引起的疑难杂症，用上SDS，通常就能药到病除。虽然该“万灵丹”当前贴有各种厂牌，但本质区别就一条：“软件”定义在了哪一层？（或：存储智能化在哪一层实现？）是在本地盘阵控制器里？还是在服务器hypervisor软件堆栈里？

于是，当所有 SDS解决方案都可用以下两个标准来划分时，一切变得清晰明了起来。即：1. Hypervisor绑定与Hypervisor不感知；2. 硬件绑定与硬件不感知。

1. Hypervisor绑定与Hypervisor不感知

有 一类SDS解决方案是与hypervisor深度结合的。最典型的代表当属VMware的Virtual SAN（也称VMware vSAN），其与该公司专属hypervisor——VMware vSphere引擎紧密集成，深度融入VMware体系架构中。紧密程度稍微小一点的是微软的Clustered Storage Spaces，他们强调可与VMware共享存储。（只需将VMware工作负载转化为微软的VHD格式，再将其导入Hyper-V就行了）

与上述完全相反的另一类SDS解决方案是：很多第三方SDS软件不感知hypervisor。基于这类SDS软件搭建的基础架构通常支持异构hypervisor，有时还支持非虚拟化工作负载。

2. 硬件绑定与硬件不感知

不得不说，时下某些“软件定义”产品，尽管宣称是“软件定义”—— USE ANY HARDWARE U WANT（随心所欲使用硬件吧），但实际上对硬件组件及系统拓扑结构有着相当严格的要求。比如VMware的超融合架构EVO:RAIL，其绑定的 VMware vSAN就要求使用精致高端的硬件以及遵循严格标准的系统拓扑。

而与之相对的就是另一类对硬件不感知的SDS解决方案。既然说到超融合，就以天玑数据的超融合架构PriData私有云平台为例吧，其采用标准x86的商用硬件，通过软件来定义节点角色和管理任务，不仅对硬件无感知，而且支持异构hypervisor。

结束语

软件定义存储从诞生至今，争议伴随着发展前行。对于企业用户来说，需保持冷静睿智的商业头脑，从实际业务需求、架构部署及数据管理的策略目标、成本预算、员工技能及其它实际限制条件等出发，综合考虑，慎重挑选最适合自身的存储方案。