就像死亡和税单一样，对于增加存储空间的需求在当下也是人生的必然之一。然而我们要面对另一个现实：由于不当的设计和混乱的管理，我们已经浪费了大量的空间。

　　对于存储空间需求不断加大的诱因，除了来自数据量的不断增长之外，大量的研究表明每个闪存设备或者硬盘上将近70%的空间都被那些令人厌恶的文件拷贝、大量从未被访问过的数据或者不知道从哪里写入的数据所占据了。

　　从设计角度看，我们所浪费的相当一部分存储空间是由于引入了软件定义存储策略所导致的，因为其至少需要三个存储节点来对所有节点上的所有数据进行交叉式的数据同步，或者是由于我们采用了过时的文件系统来分配空间——这些空间从来就没有存储过哪怕1比特的数据。甚至是由于我们在分配存储空间时采用的方法漏洞百出。向服务器管理员亲眼见证那些经典的存储空间分配方法，然后在部署到文件系统之后让他们自己决定，这些空间能否起到一定作用还是莫名其妙的“蒸发”了（也许是为了紧急情况使用，或者，算了，作者自己也编不下去了）。

　　存储空间利用率低并不仅仅是使用者的问题

　　数据存储行业在过去几年中向我们传达了两件事情：技术发展带来的奇迹以及以存储架构形式存在的为贪婪埋单的遗迹。从20世纪八十年代至今，硬盘空间大约每18个月就会翻番，而其成本，每12个月就会减半——这就是技术革新带来的好处。反观存储阵列的价格——一堆商业存储部件加上一块由类似服务器主板的东西作为控制器，最后在机架中堆叠而成——每年上涨近120%。

　　成本上升的很大一部分原因来自于不断革新的软件，这些软件也使得存储阵列厂商可以为自己的产品贴上独有的标签进而在市场中独树一帜，进而将那些客户继续使用自己的产品。基于将存储阵列回到原有的商业存储领域这一出发点，通过将所有附加的软件产品抽象成完全独立的软件服务层并部署到服务器中，软件定义存储在某种程度上是可以预见的。厂商们称之为革新，但是在我看来，它和大型机管理存储（mainframe system managed storage，dfSMS）的作用相似（dfSMS可以对批量的直连存储设备进行管理）。

　　软件定义存储策略能否降低存储阵列的成本还需要拭目以待，尤其是那些由领先的服务器管理程序厂商推动的软件定义存储的实现方法，从架构设计的角度来讲，这些实现手段的最终目的是要取代传统的SAN和NAS系统。由于存储是打包销售的，所以资本性开销（Capex）是庞大的。在今天，我们花在IT硬件上的每1美元中，存储部分就要占掉33美分到70美分，如果我们把这些硬件开销继续细分，例如维保合同、若干年的软件使用许可（还要考虑到维保以及使用许可的时间，毕竟我们的存储要长期使用下去）等等，那么最后的数字将会是相当庞大的。

　　找出巨额开销的真正来源

　　然而资本性支出（购买成本）仅仅占了一部分而已。如果想找出开销的全部来源，你就得考虑到经营支出（Opex），而这部分开销在大部分公司中都不一样。根据Gartner的分析，存储的年度总经营支出约为年化资本性支出的四到五倍。

　　经营支出包括备份和还原、计划性宕机、管理和维护以及设施开销（空间、电力以及空调等等）。这些数字往往都被人们忽略了而并没有被明确的标示出来。我们之所以知道这些数字的存在，就是因为有的时候我们无法高效率的管理存储架构，那时真正的经营支出将会变得相当巨大。

　　我们就不能好好地管理我们的存储吗？我们总是倾向于购买大量的Tier-1存储设备，它们低空间高性能的属性可以在部署当天就带来令人侧目的应用性能提升——当然无论这些应用是不是关键的。但我想说的是，这件事儿从一开始就做错了。

　　从传统意义上来说，不同类型存储的出现是有其原因的。有些设备是用来存储那些在短时间内快速累积起来的数据，因为它们可以满足交易系统对高性能的需求。而有些设备的设计初衷是存储那些定期或者偶尔更新或者修改的大量数据。还有些设备则是用来存储那些长期不被访问甚至几乎没有改动的海量数据。在一个良好的管理环境中，数据遵循由自动化分层存储管理或归档软件设定的策略在层与层之间移动。这也许就是我们能控制存储开销的唯一途径。

　　令人烦恼的是，要想使得分层机制有效地工作，你需要部署集成化的架构或者至少有一套通用的管理策略。在个别情况下，有些厂商将他们的产品与竞争对手的产品的协同工作弄的很复杂。有些存储附带软件会给日常管理带来额外的负担，而在个别存储阵列中，其自带的文件架构系统甚至会在同类存储平台上独占共享数据。

　　尤其是后者，它不仅仅存在于传统的存储阵列中。管理软件厂商通过“巧妙地”部署自己的SDS堆栈来阻止自己的存储资源共享到负载的处理过程中，而这些负载就是那些已经通过其他竞争对手的SDS模型完成虚拟化的部分。

　　关于“你们的”存储是如何变成“他们的”存储这个情况，其实你并不是第一个受害者。这些专属的障碍使得我们对数据进行自动化跨层级移动的能力大大减弱。这种障碍其实是一个副产品，它是在SDS向高性能计算集群借鉴经验的时候不小心出现的。众多SDS架构能够带来影响的关键就在于在每台虚拟服务器背后，都搭建了一套扁平的存储架构，而这些架构的配置和部署都是完全相同的。这些架构就构成了基础的模块——服务器、存储以及SDS中间件的超容和架构节点——他们可以进一步的扩展出很多空间并且快速地部署，进而来满足业务的需求以及需求的不断变化。需要在ERP中再增加50个位置？仅仅需要扩展出三个额外的基础模块就可以满足对计算、网络以及存储空间的需求。

　　这听起来就像是一条通往真正意义上的敏捷部署的大路，直到你发现它们背后架构的秘密。为了热点数据而准备的既昂贵空间又低的存储层级是不存在的。同理，为访问频度相对较低的数据专门设计的价格相对低廉而空间更大的存储层级也是不存在的；当然，为冷数据以及归档数据设计的大容量低成本的存储层也是没有的。对于存储层级以及数据跨层级移动的管理失误往往会在很大程度上提高存储的总体开销，而失误的原因还是在于管理本身。

　　围绕SDS以及存储空间说开去

　　软件定义存储允许客户将存储服务集成到服务器的软件层。这种做法很好，因为SDS将软件从原有的存储控制器中抽离出来，使得它们的功能得以进一步的发挥而不仅仅局限在单一的设备中。将数据去重功能或者是精简配置局限在单一的硬盘上与把其扩展到全部存储平台层面相比，前者实在是没有什么太大意义。在这一点上，SDS的从业者们并没有拖大家的后腿。

　　真正给大家带来误导的地方是：将这些软件集成到服务器端的软件堆栈当中会成为存储管理的万能良药。然而它并不会。

　　除了存储服务之外，存储管理将存储资源的管理细分成了以下几个方面：存储物理架构、存储运行状态以及存储空间的分配与回收。如果存储节点上的硬盘或者闪存设备出现故障，并且没人能够发现，那么镜像功能就不会起到任何作用，最后导致的结果就是数据复制服务的管理形同虚设。更糟的是，如果存储无法根据变更的需求对后台的数据进行整合，那么所谓的敏捷部署也无法得到实现。

　　当你考虑到这些问题的时候，你会发现存储资源管理无法并入到管理软件厂商所钟爱的SDS堆栈中的唯一原因就是双方的关系并不是那么融洽。如果我们可以将存储架构虚拟出来，即抽象出来的东西不仅仅是那些软件，还有那些资源空间的管理部分，那么存储资源就可以像软件定义存储的服务一样，更好地实现分配、回收以及分层。

　　存储虚拟化并不是什么新鲜的东西。DataCore Software在这一领域已经做了十多年，而IBM 的SAN Volume Controller又对这一领域带来了新的力量。尽管通过创建共享存储资源这种做法可以使得存储资源与SDS相互结合，让数据运行在适合的存储设备与服务上，进而优化数据的使用以及存储的开销，但是当今的业界领先公司似乎对其并不是很感兴趣，。

　　如果你想利用SDS来驯服存储开销这头野兽，那么软件定义存储、超融合架构以及过时的存储阵列网络都不会是万能的良药。当你将存储服务集中起来的同时，你也需要考虑将存储空间虚拟出来。只有这样，你才能够以一种有效的方式保留既定的层级移动策略并且在所有数据中共享存储空间以及存储服务。