存储虚拟化和其它存储“超级－控制器”都朝着更好的管理进了一步，但它仍不是一个集成化的过程。

　　在早前的一个专栏中，笔者曾讨论过存储架构管理的革新和存储服务被集成起来为某些特定的数据集和工作流程简化它们的应用的多种方式。

　　管理存储架构的主流方式远远算不上优雅或者经济。首先，供应商已经把它们的阵列控制器板进化成了功能齐备的通用服务器，通常运行常见的操作系统以及特殊的存储应用，包括专有的文件系统以及RAID软件，以及更加高级的算法例如精简配置（thin-provisioning）或重复数据删除（deduplication）。结果就是一个“存储即硬件”模式，其优势包括建立了一个整洁的、自成体系的“存储岛”，每个都用它自己的元素管理软件进行管理，但是带来的缺点是随着存储规模的扩大而越来越难以管理。

　　从工作内容和数据角度看，存储硬件更多地被设计为直接连接特定的数据而不是在不同的任务之间共享。一个Oracle数据库需要它的专用存储，而微软Exchange也是，以此类推。这种一个一个应用的模式在数据增长超出硬件的容量前都运行的不错。安装另一个硬件需要招聘一个新的存储管理员来配置、优化、管理和维护新的存储岛。

　　在这些情况下，数据存储架构管理——管理一系列的这类存储硬件——以前（现在也好不了多少）很难自动化；所以，它是劳动力密集型的而且不管从资产投入（专用硬件的成本）还是运营开销（人力成本）来说都很昂贵。

　　一个可选的方案是虚拟化硬件层，关掉盒子里的软件功能，并把这些服务转移到可以控制基础架构里全部磁盘的软件或者一个超级控制器硬件上。我上次曾提到几个以存储虚拟化软件包（或者以最新的名词来说“存储hypervisors”）形式存在的、基于软件的超级控制器。我还提到了一个来自“Tributary Systems”的超级控制器硬件“Tributary Storage Director”（Tributary 存储控制器）。

　　在这两者之间，基于软件的存储hypervisor和基于硬件的存储服务管理设备获取了存储阵列上的内置增值软件，再把它们包装成可以被映射为策略并选择性地应用于数据的服务。存储虚拟化软件模型提供了一个集中的方式来做这个事情，变成了一个“服务增强的卷部署引擎”或者一个“存储路由器”，其功能是把数据放在需求的服务可以高效地应用的磁盘上。

　　Tributary Systems的方式则更为整合。由于该公司的存储控制器可以集群（来提供更多的接口来连接更多的客户系统和存储阵列），你可以根据存储I/O流量在你的存储架构中建立多个存储控制器，来满足基于策略为选择的数据提供存储服务。在这个配置中管理存储需要轮询各个存储控制器。

　　超级控制器的好处是它把增值功能从硬件中抽象出来，从而降低了硬件的成本以及对特定供应商的依赖。而且它使得从全局层面管理“存储即服务”成为可能，提供整体上管理容量、性能和数据保护的方法。类似“私有存储云”和“软件定义存储”等市场推广名词实际上也在含蓄地暗指这种管理架构。

　　尽管这种新的面向应用的、以服务为中心的管理方式由来已久，它还不是全部。在服务、容量和性能层以下，是硬件层，这里线会断、HBA卡会坏、硬盘可能挂掉而固态硬盘也可能会冒烟。有些集成存储设备和存储hypervisor或者其它超级控制器的人还认为RAID需要在硬件实现，所以RAID在硬件设备或者磁盘级别控制和管理而不被服务级别的管理所涉及。

　　这就引起了存储管理上的分歧：集中的服务需要在超级控制器上管理和部署，但是有人需要使用传统的存储资源管理（SRM）软件工具——通过私有的API、SNMP MIB或者SMI-S源来连接到特定的设备上——在作为最后的手段去查看实时的I/O情况并统揽架构的内部管道。如果你注意到了，那是两个管理目标，而没有统一机制来收集和呈现信息以便使管理向更强的自动化发展。

　　如果每个厂家都能够在实现开放的REST协议来管理它们的阵列方面就好了，他们几年前就已经表现出这方面的兴趣。在2009年，IBM公布了“零计划”来支持REST，不过这个名字刚好也是他们目前的进度。EMC、惠普、微软和其它的存储市场的玩家也在发展规划图中强调了REST，可是只有少数真的实现了（例如X-IO），XIO展示了SRM和存储服务管理如何通过World Wide Web Consortium标准协议结合在一起。

　　总之一句话，没有基于开放标准的统一服务和管道管理的方式，管理复杂的存储架构会非常困难。云存储和软件定义存储市场这些市场名词都是用来吸引眼球的，统一的存储管理（跨不同厂商）要远比“统一存储”重要得多。