1、对虚拟存储管理不善

如果你平时不监控自己的IT基础设施，那么在无数的虚拟机之间分配存储阵列或子系统可能困难重重。那是因为，你根本不了解数据流动的实际情况。

要是没有数据来指导你，就为逻辑单元号(LUN)分配虚拟机，好比不研究交通情况，不去评估不同时段的流量大小，就盲目建造公路一样。你如何知道需要分几条车道才能适应真实的交通状况?

另外，假设一条四车道的公路早已存在，你的TB存储系统也已存在。要是不调查了解，交通工程师就无法知道路上有多少辆汽车。同样，要是不进行监控，也无法随时评估虚拟访客对存储的需求。

由于都在同一个LUN上，你可以限制最繁忙的10个虚拟机的活动。就像洛杉矶周围的交通在高峰期如蜗牛缓行，随着数据事务数量不断增加，响应时间会随之变长。

让这个问题如此复杂的一方面原因是，起重要作用的并不是虚拟机的数量，而是虚拟机的性质。有些虚拟机在频繁移动数据，就像有些汽车每天在公路上来回上下班。另一些虚拟机只是偶尔有要求，就像洛杉矶周末去圣巴巴拉短途旅行的居民。面临的挑战就是，将最活跃的虚拟机与最不活跃的虚拟机配对起来，以抵消存储需求。

2、为活跃应用程序分配的资源不够

如果你有一个输入/输出频繁的应用程序，没有正确地放在存储阵列里面，那么用户体验就岌岌可危。比如，如果一个Web应用程序在类型错误的存储设备上运行，或者没有足够的存储资源分配给它，客户试图购买衬衫时就会遇到延迟。如果网页很慢才打开，客户可能点击别的网页了。

3、存储设计有缺陷

如今可以使用几个存储池：0层、1层和2层。0层是速度最快的，1层介于中间，2层速度最慢。有时候，如果这些存储池未加以正确管理，就会导致诸多问题。

比如，一个Web应用程序可能在1层上，但它其实应该在0层上。如果客户点击查询，比如‘给我看看这件蓝色衬衫是啥样子’，应用程序调取图片很慢，客户就会跑到竞争对手地方。

另一个存储设计问题是可访问性――服务器如何通过SAN架构连接到存储系统。服务器无法以足够快的速度访问存储系统，可能是由于它不得不经历三路连接，而不是一路连接。

为了解决存储瓶颈，你就要监控LUN、应用程序和服务器的性能。监控可以帮助你设计出非常高效的存储系统，并且预料和调整流量大小。