存储统一从理论上来看是不错的。直连存储(Direct-attached storage，DAS)的效率低是出了名的，有些阵列的使用率只有40%。

　　为一个甲骨文数据库提供10000IOPS意味着需要集合数十块15000转的硬盘，除了数据库的容量能够达到数TB的情况外，大多数情况下都要浪费很多存储空间。

　　替代方案是使用共享存储，可能需要用到虚拟化技术和自动精简配置来分配物理磁盘容量以提高效率，或者还可能利用闪存或高速缓存来提升性能。

　　除了减少浪费，共享存储还可以提供其他的优点，比如减少管理点的数量。

　　但是如果你的某位客户或某个应用不能正常工作怎么办呢?如果它表现异常，不能发挥出共享存储的“共享”特点怎么办?

　　在很多系统中，很容易出现某一款应用占用大量存储空间的现象，这样留给其他应用的存储空间就非常有限了。

　　要素

　　NetApp的产品、解决方案和联盟营销主管约翰罗拉森(John Rollason)表示：“服务质量比人们所说的更重要。它看似小事，但是如果没有它，共享存储的很多价值就不复存在了。”

　　“如果你的共享存储平台上没有服务质量，你就无法在用户移动到虚拟化环境时保证整体服务质量。 虚拟化也会让I/O变得更加随意。”

　　Virtual Instruments的EMEA地区解决方案顾问主管亚历山大德安娜(Alex D'Anna)称，最常见的一个例子是当应用不是用于共享，而且有不同的访问方式时的情况。

　　他说：“真正有趣的使用案例是对服务需求很大的应用。” 他引用了一个客户的真实案例。尽管那位客户拥有大量的SAN容量，但他在安装关键SAP应用时仍然遇到了很多问题。

　　德安娜称：“SAP可以协助你生产，但是你还需要数据仓储和业务分析工具来辅助预测。我们认为最神奇的是客户拥有完全不同的读写方式，数据仓储完全把8Gbps的光纤通道SAN都占用光了。”

　　他补充说，一旦你进入云中，这个难题就被放大了。他说：“使用云存储，人们想要的是降低准备的要求。 我们是在共享最终将占据主流地位的假设之上工作的。在平台上，你需要知道正在发生什么情况。”

　　“例如，当出现性能问题的时候，人们会要求将它们推后到专用存储区去。但是在云中，你就不能那么做了。”

　　填饱饥饿的应用

　　富士通产品营销高级主管弗兰克赖卡特(Frank Reichart)也有同感。他说：“服务质量是存储统一的必要条件。 不可能不谈这一点。”

　　他说：“如果你什么都不做，那么需要大部分性能的服务器就会得到它，如果那是你的商业情报系统，那么对响应时间有很高要求的生产系统就会受到影响。 服务质量还会妨碍到受控于服务级协定的组织，如果你不能设置服务质量，那么使用简单应用的用户就遭殃了。”

　　商业情报问题是个大问题，因为越来越多的商业情报用户想查询生产数据，因为他们想了解建立一个专用数据仓库的成本和拷贝数据所需的时间。

　　试图使用那部分存储资源的其他人也许会受到影响，因为他们不能马上获得结果

　　这并不是特例。大量的数据库查询可能也会轻易地耗尽所有的I/O资源，从而影响到上网和收发电子邮件等活动。 谈到共享存储上的VDI启动风暴的影响，试图使用那部分存储资源的其他人也许会受到影响，因为他们不能马上获得结果。

　　这些问题都可能被公共云运营商遇到，它们的存在和收益与共享资源的能力息息相关。

　　而且这也越来越适用于IT部门，因为它们与公共云运营商一样，也必须为多个内部客户服务，而它们的收入却越来越少。

　　那么存储开发商怎么做才能处理好这个问题并且保证提供公平和适当的访问通道，而不用强迫你通过大把花钱增加存储空间来解决问题呢?

　　首先明显要添加服务质量机制，为所有的应用分配优先等级。阻止流氓应用或客户。 其中一种简单的做法是限制某些应用的I/O速率，让它们不能把所有的资源都占用。

　　Debriefing Software的首席技术官杰斯珀马蒂森(Jesper Matthiesen)说，那也可以很简单。他说：“我并不认为带宽节流是件好事，因为如果有存储容量的话，你就应该去使用它。”

　　另一种方法同时也是很多领先的开发商比如富士通、NetApp和NexGen等所选择的方法是，执行最低而不是最高的应用数据处理水平。

　　额外的部分

　　我的想法是，一旦对存储性能的总需求超过了系统能够提供的水平，那么系统就会按照先来后到的顺序去授权I/O要求，系统会确保每一台服务器都得到最低水平的IOPS。之后，它就会将剩余的性能分配给拥有最高优先权的工作负载。

　　添加闪存在实现存储服务质量上同样重要，因为当高速缓存中的项目被存在闪存中的时候，就有更多的IOPS能够分配给优先等级高的应用了。

　　最后的要素是自动化。赖卡特说：“实际上，设置服务质量的各项参数是一件完全不同的事。”

　　他说：“通常，那些指标会是响应时间，但是要想将响应时间降低到5毫秒以下，对于数据库来说那会是一件非常复杂的任务。你可能不得不设置20种不同的参数。 尽管那样，它也是个活动的目标，因为一旦你设置好你想要的服务质量，另一个应用就会闯进来，然后你就不得不从头再来一次。”

　　他继续说：“你想要的是自动化或半自动化的系统，它应该能够自动优化，那样管理员就只需要定义各项条件，然后让系统完成剩余的工作就行了。它还需要更多的报告和监控功能，比如哪些LUN在使用哪些存储资源，哪个应用在哪一级存储层上运行。”

　　“或者，人们也许可以放弃统一或寻找独立的解决方案，但那些解决方案显然效率低下，而且会导致过分预备。”

　　那意味着在规划容量和建模时要特别小心你的存储系统已经生成的所有性能数据。

　　从为物理工作负载容量建模开始，然后给主机建模，比如你可以说一台数据库服务器需要一定数量的I/O。

　　然后你就可以开始定义监控政策，将高性能主机迁移到高性能存储层级或将低性能主机迁移到低性能存储层级。

　　比较好的做法是将你的主存储器分成不同的层级，通常分为高、中和低性能3个层级。然后，你就可以为每个层级定义服务级协议，包括存储可以占用多少I/O，在延时上应该有什么样的限制，它应该提供何种水平的可用性等等。

　前方危险

　　如果一切顺利，你就会想让系统去完成尽可能多的重复性工作，幸运的是，这些都可以用工具来自动完成。

　　但是马蒂森警告说，虽然这些工序中的某些工序可以而且应该能够自动完成，但是所用的工具却是强大并且可能也是危险的。权力越大，责任越大，当然风险也越大。

　　例如，将一个主机从一个层级移动到另一个层级可能会涉及到数百MB的数据移动，需要使用大量的I/O资源，而移动那么多数量的数据将会对其他的系统造成影响。

　　马蒂森说：“你必须小心处理，因为这是贵公司的核心。移动数据有可能造成巨大的影响。 因此必须慎之又慎。”

　　“对配置进行重要变更仍然需要人类的知识，因为它需要了解业务以及具有技术上的见解。”