嗯，这是个长期存在的问题，在某些情况下， 数百万美元的问题。 有很多因素要考虑，以下我们列出其中的几个。

备份

        集中在储使备份更易于管理。当所有数据都存储在个地 方时，可以只备份SAN,只要确保已经确认过了所有的数据都在。这简化了问题，例如“你确定我们要备份所有的数据吗? :此外，某些设备有如连续数据保护(CDP)以及强大的快照功能等功能，使得备份更容易、更灵活。

简化容量规划

        不确定需要多大容量吗? SAN可以提供这种能力一购买大容量存储、 分享给很多应用，并且可以调整大小并按需求重新发布。

存储整合还是服务器整合

        某些CIO盘点数据中心运行了哪些东西时，可能会得出结论说大量的1/0容量被浪费了，这是把存储空间和I/0容量混为一-谈了。毫无疑问的是，如果集中存储可以确保更好地利用存储资源，但这样做将会如何影响使用存储的系统?典型的数据库操作在性能上可以达到数量级的差异，因此可能会发现，如果集中存储可能需要增加10倍的服务器(或更多)才能处理原来的工作。尽管数据中心的I/O容量在SAN上可以更好地被利用，但是会导致共他系统无法充分被利用(例如数据库服务器花费大量时间等待I/O、应用程序服务器花费大量时间等待数据库，依此类推)。在现实中我们已经看到过很多通过分散存储来整合服务器并削减成本的例子。

高可用

        有时人们认为SAN是高可用解决方案。之所以会这样认为，可能是因为对高可用的真实含义的理解出现了分歧。

        根据我们的经验，SAN经常与故障和停机联系在一起， 这不是因为它们不可靠，它们没什么问题，也确实很少出故障一只是因为人们都不愿意相信这样的工程奇迹其实也会坏的，因而缺乏这方面的准备。此外，san有时是一个复杂的、神秘的黑盒子，当出问题的时候没有人知道该如何解决，并且价格昂贵，难以快速构建管理SAN所需的专业知识。大多数的SAN都对外缺乏可见性(就是个黑盒子)，这也是为什么不应该只是简单地信任SAN管理员、支持人员或管理控制台的原因。我们看到过所有这三种人都错了的情况:当SAN出了问题，如出现硬盘驱动器故障导致性能下降生26的案例。这是另一个推荐 使用sysbench的理由: sysbench可以快速地完成一个I/O基准测试以证明是否是SAN的问题。

服务器之间的交互

        共享存储可能会导致看似独立的系统实际上是相互影响的，有时甚至会很严重。例如，我们知道一个SAN用户有个很粗放的认识，当开发服务器上有I/O密集型操作时，会引起数据库服务器几乎陷于停顿。批处理作业、ALTER TABLE、备份一任何一个系统上产生大量的I/O操作都可能会导致其他系统的I/0资源不足。有时的影响远远比直觉想象的糟糕，一个看似不起眼的操作可能会导致严重的性能下降。

成本

        成本是什么?管理和行政费用?每秒I/0操作数(IOPS) 中每个I/0操作的成本?标价?有充分的理由使用SAN,但无论销售人员说什么，至少从MySQL需要的性能类型来看，SAN不是最佳的选择。(选择一个SAN供应商并跟它们的销售谈，你可能听到他们一般也是同意的，然后告诉你他们的产品是一个例外。)如果考虑性价比，结论会更加清楚，因为闪存存储或配置有电池支持写缓存的RAID控制器加上老式硬盘驱动器，可以在低得多的价格下提供更好的性能。关于这个话题，不要忘了让销售给你两台SAN的价格。至少需要两台，否则这台昂贵的SAN可能会成为故障中的单点。有许多“ 血泪史”可以引以为戒，这不是试图吓唬你远离SAN。我们知道的SAN用户都非常地爱这些存储!如果正在考虑是否使用SAN,最重要的事情是想清楚要解决什么问题。SAN可以做很多事情，但解决性能问题只是其中很小的一部分。相比之下，当不要求很多高性能的随机I/O，但是对某些功能感兴趣的话，如快照、存储整合、重复数据删除和虚拟化，SAN 可能非常适合。因此，大多数Web应用不应该让数据库使用SAN,但SAN在所谓的企业级应用很受欢迎。企业通常不太受预算限制，所以能够负担得起作为‘奢侈品” 的SAN。(有时SAN甚至作为一种身份的象征! )