在老式的存储产品上很容易挑出毛病，特别是在公共和私有云部署整合的时候。然而当实施云框架时究竟需要什么是值得讨论的，因为存储被部署的方式与存储操作的传统模式是截然不同的。在本文中我们将要探讨为什么传统的存储管理方式需要改变，它将如何影响硬件的使用方式。这就引发了一个关于API的讨论，还有就是它们在高效进行云部署时是不可或缺的。

传统模式

在过去的十年左右，存储管理的传统模式包括多个存储管理员，使用GUI，CLI和/或脚本来处理商业用户的存储需求。这个过程是高度人工的，在需求者，存储管理员和其他诸如计费，变更控制，容量管理和工作调度的中间人之间有许多关联。这使得整个过程非常的人员密集和毫无意外的延长交付时间。许多最终用户还会有这种经历，就是他们具体需求的要求被告知他们只能有一些“现成的”东西——比如一个标准LUN大小和带有一个特定RAID保护的存储。这样做的原因很明显：首先大型阵列的配置取决于规划和确定的设计，通常在硬件安装时建立。一旦确定并投入使用，它就不能再改变了(或至少在没有显著影响和成本时改变)。其次，这也是行得通的，就是把需求降低到一个更小的子集，好让配置过程更为容易。还有死板的配置，许多传统的阵列都把LUN的创建和配置当成是一个罕见的任务。许多请求会被打包和批量执行，这样肯定不能轻松应对并发请求。尽管可以通过使用CLI和脚本来自动化一些配置过程，但这并不能解决创造即需型模型的实际需要。

新世界

当我们规模扩大到更大的IT部署，特别是在基于服务的或“云”配置下时，在配置过程中出现大量人工干预的思路就行不通了。我们需要转向一个“按需求存储”的模型上，在这里一个外部代理(用户或业务流程软件)可以作为一个入口请求存储，并能实时或至少几分钟或几小时内查看请求的处理情况。这种操作只在硬件被按目的设计好后才提供。在这之前，存储管理员在每个配置请求时都要参与，那些请求会在一个由管理员或存储架构师定义的配置框架内处理。

Framework

我们所说的Framework是什么意思?它就是在分配发生时建立一套参数。这可能包括：

LUN Size

弹性/可用性

性能

安全证书

快照策略

按需LUN的容量

架构师来选择满足要求的特定硬件组件。

还有一些使用局限：

并发请求的最大数量

每小时配置请求的最大数量

暂停或拒绝阵列配置请求的能力

按阵列容量限制请求

按容量准则限制用户请求

设置框架还需要自主异步工作能力;就是说，接受，处理和告知请求无需请求者与阵列一直保持会话。一旦请求完成，请求者就会被一个回调机制或人工告知请求是否完成。显然需要对监测框架进行整合，以便跟踪硬件和性能问题。

设计API

当然，有一个很大的问题，就是关于是否API可以替换现有的存储。以经典IT传统的答案是“这取决于”。毫无疑问，没有本地API功能的话，新的存储阵列就不应该发布。然后，让API迎合现有技术将取决于现有配置过程的灵活程度。创建一个API外包并在中间件层建立自动化是可行的。这也是像 iWave的Storage Automator这类产品的做法。然而对现有的存储产品增加这些功能代价是非常大的而且仍是一个不完善的解决方案。

存储架构师的观点

随着新的存储平台的发展，本地API支持是一种必然。存储管理员只需简单的部署基础设施并把它连接到更高的框架内，配置过程就会完全自动化。提供的这一级别功能的供应商将成为最有吸引力的服务供应商——使获取和管理存储的成本尽可能廉价。我们将看到一个存储管理方式的转变，也许再也不用存储管理员了。