我对 SAN 的经验很少，所以请原谅我这个新手。
我们的一个生产站点有一个 HP EVA8000 SAN，带有一堆磁盘（忘记具体有多少）。它已配置成一堆 raid5，并且 SQL 服务器使用一个 RAID 卷来存储数据，使用另一个 RAID 卷来存储日志。
到目前为止一切顺利。或者我是这样认为的
今天我进行了一些速度测试。在系统使用率很高的情况下，我使用 rdfc 在主数据磁盘上创建了一个 100 MB 的文件。这显示写入吞吐量在 5 到 20 MB/s 之间，我认为这有点偏低。然后我关闭了应用程序进行维护，并再次运行测试。这次在安静的系统上，我获得了 50MB/s 的写入性能。
这是否有点太低了？我的意思是，我的台式机上的 SATA 驱动器也达到了同样的效果。
然后我尝试将 500MB 写入一个驱动器（数据驱动器），同时将 500MB 写入另一个驱动器（日志驱动器）。这两个写入互相干扰。这是设置错误的迹象吗？
我不知道我期望的是什么，但我目前正在检查系统以尝试找出瓶颈。
所以，我想我的问题是。您期望使用光纤连接器的（可能）昂贵的 SAN 具有什么样的性能（读/写）？
（不，这不是那个小小的 Netear 东西；而是这个） http://h10010.www1.hp.com/wwpc/ca/en/sm/WF05a/12135568-12135820-12135820-12208992-12208992-12236532.html
答案1
我们有一台 EVA6100，所以我对类似的硬件进行了测试。如果我没记错的话，8000 是一个比 6100 更老的系统。
首先，您对 DB 卷和日志卷的写入很可能争用写入，因为它们听起来像是在 EVA 内的同一个磁盘组上。磁盘组是您在其上创建 LUN 的磁盘分组，每个 LUN 都是呈现给一台（或多台）服务器的磁盘。在一个磁盘组中容纳许多 LUN 并不罕见。如果您只有一个磁盘组，那么将日志 I/O 与 DB I/O 分开的好处会有所减少。
其次，如果该 DG 遇到真正的 I/O 争用，那么它将降低性能。从消费者的角度来看，这是很难检查的事情，这是 SAN 维护人员需要注意的事情。询问他们是否知道平均控制器 CPU 负载是多少，因为这将显著影响您的写入性能。
第三，了解您的 I/O 组合是否是衡量基准，而不仅仅是文件复制速度。如果您的数据库卷 I/O 是 80/20 读/写，那么您确实需要检查读取路径吞吐量。如果情况相反，那么您的写入性能才是您真正需要检查的指标。
答案2
通过简单地写入一个大文件，您无法衡量存储性能。您只是衡量写入大文件的性能。如果您认为在以下情况下会获得类似的结果，那您就大错特错了：在整个磁盘上随机写入、同时写入许多块、写入非常大或非常小的块。我向您保证，在一种类型的工作负载下，您可以从阵列中获得最大 1 MB/s 的速度，然后在另一种工作负载/设置下，您将轻松获得 800 MB/s（...前提是您的服务器可以处理这么多）。
如果您想了解这些，请使用适当的工具。我当时使用了 Intel IOMeter，从中学到了很多东西。现在可能有一些更好的工具。要注意的主要参数是队列大小和随机与顺序操作。阅读有关磁盘机制、为什么寻道时间如此慢以及 RAID5 如何运行的信息。
如果你想知道你的存储在实际生活中的表现如何，请在工作日查看 perfmon.exe 中的 PhysicalDisk 计数器。然后在你的实际应用并观察会发生什么。
答案3
另一个需要检查的重要事项是磁盘对齐是否正确。我不止一次看到未对齐的 LUN 是造成严重性能问题的根源。如果在格式化之前未设置分区上的偏移量，则可以看到 IO 性能下降 25%。
RAID 10 也是一个更好的选择，至少对于日志 LUN 而言。
最后，您可以将 LUN 上的读/写缓存比率调整为 100% 写入，因为 SQL Server 在读取缓存方面做得很好。
SQLIO 是一款出色的基准测试工具，但绝对不适合用于生产。它易于使用，可运行可变大小的顺序和随机读/写测试，并可作为与其他系统进行比较的良好基准。
答案4
看起来确实很低，但考虑到 EVA8xxx 盒子的易用性，它们的速度相当快。我们有很多这样的盒子用于各种用途，我有一个备用的 8100，带有 112 * 1TB 7.2k 磁盘，我可以轻松淹没 4Gbps FC 连接，即使在 RAID5 vDisk 上也是如此 - 大约 385MBps。
我认为有些事情发生了，我很乐意提供帮助，但可能需要一段时间，如果你与他们的关系足够好，你最好获得 HP。
让我知道你的情况如何。