存储将如何向上堆叠？

为特定的应用建构而专门设计的存储，不仅可以在功能上充分满足客户端的需求，而且可以进行内部优化，以提供显着的性能和成本/容量优势。例如，Oracle ZFS Storage Appliance是对Oracle数据库的“应用设计”。它可以存储并把存储端的处理单方面地应用到数据库的数据上(例如，以混合列式压缩的格式)。它也支持能够使数据库直接地调试那些影响应用性能的存储端的参数的特定协议。　　

Arun在其专栏中指出：Tintri之类的很多以VM为中心的解决方案，运行VM是其首要建构。再进一步，我们可能考虑把Atlantis ILIO作为专门用于虚拟桌面基础架构(virtual desktop infrastructure，VDI)桌面机的存储服务。Actifio可能被定义成为一种针对管理“复制数据”建构的存储服务。我们甚至可能考虑使用Maginatics的MagFS之类的提供“文件系统”建构，此时该建构的首要用户是配置文件系统( “文件系统即服务”)，而不是访问文件的最终用户。　　

在所有这些情形中，存储解决方案都是应用感知的。它对应用建构了如指掌，并可以向对应用无感知的存储提供改善的管理、性能和效率。　　

敢问路在何方?　　

再看长远一点儿，我可以看到下一步的演变：存储不仅嵌入到应用建构、其元数据和静态的策略之中，而且嵌入到特定的动态行为、程序或者功能之中。想象一下数据库存储的过程或者面向对象的程序编写，此时单个的编程对象可以被“附加”各种(编程)方法。当然，如今存储基础设施正满载计算和存储能力，存储端可能很快会有充足的容量以执行嵌入到数据的功能。在将来，静止的数据可能很难与动态的应用截然分开，且可能永不停歇。　　

很多厂商一直大规模地在他们的存储阵列上无所顾忌地运行VM，向数据提供更直接的访问，或者运行病毒扫描之类的工作。如果你考虑已经把存储当成VM来运行的虚拟存储阵列的话，融合计算和存储似乎大势所趋。　　

请定义软件定义存储　　

存储厂商有三种处理未来基础设施的方法。第一种是融合统一存储。有些厂商会继续在一个大的核心平台上附加广泛的功能。第二种是创建专用的存储，为特定的应用进行设计和优化。我们看到很多着眼于此的始创公司。而第三种是可以按需动态地塑造的可编程或者软件可定义的存储。尽管EMC的ViPR等已经发布，但是这种方法的效果有待验证。　　

哪一种方法会获得最后的成功?我认为：下一代的存储平台将具备强劲、多用途、横向扩展的核心，具有可以动态地编程以支持各种各样的应用建构的专用模版。对以数据为中心的计算任务而言，这个平台马力强劲，从顶端俯瞰，彷如一个虚拟化的大数据集群。　　

存储将必然向上堆叠，更智能，与使用它的应用程序更密切。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友