问iSCSI SAN上的慢读写性能

EN

SAN硬件是为Vmware认证的，因此得到您的支持来查看它。性能不佳的常见原因是SAN硬件接口过载，因为如果您有到同一个SAN的多个连接，并不是所有的连接都能以最高速度提供。

此外，在您的设置中，您的本地磁盘总是比SAN快，因为即使是SATA磁盘也将最大带宽为3Gb/s，因此SAN将永远无法与本地磁盘的速度相匹配。您可能也在使用以太网而不是光纤，这也无助于性能的提高。

您使用SAN不仅是因为速度，而且是为了有一个中央管理的位置，您可以将所有重要数据放在其中，并确保应用了合适的RAID级别。还有一些特性，比如复制，这是SAN的优点之一。

这种设置应该能够提供合理的性能，根据我所能收集到的信息，即使对于小块随机IO，数组也可以维持每秒60-70兆字节。我没有使用它们的经验，但是规范表明，它应该能够轻松地处理您的需求，而很少的搜索结果会将其抛出。

不管怎么说，如果我是你，我会先退一步。摆脱多路径(最初)，并确保您可以获得一条路径(在VMware侧)以保持良好的性能。假设您有一个8驱动器单元，充分填充了10k SAS驱动器，一个热备用设备和一个7驱动器RAID 5包，它应该能够轻松地在一个良好的专用Gbit LAN上提供超过100 sec/秒的顺序读写，甚至可以承担所有的ip\tcp和iSCSI开销。对与SAN或SAN之间的大型文件副本(比数组上的写缓存大得多的东西)进行简单的批量测试，以检查您是否看到了这一点。如果你正在读和写的SAN卷，那么性能将不超过一半的BTW。如果没有，你会想看看所有常见的嫌疑人：

• 首先，确保SAN的缓存配置正确
• 确保所有驱动器都是健康的
• 确保交换机是健康的，而不是忙于其他事情-理想情况下，您应该隔离您的SAN流量到它自己的交换机，如果你不能这样做，把它放在自己的VLAN。
• 绝对不要把它放在一个便宜的开关，是非常忙的其他东西。
• 检查所有端口(ESX、交换机和SAN)的双工和速度设置
• 避免干扰Jumbo框架和ESX，直到您知道其他一切都在工作。
• 一定要在交换机上启用硬件流控制。

在测试时，请确保ESX主机或SAN都没有忙于其他任何事情。

一旦您成功地在单个上行链路上获得超过100 sec/秒的连续通信量，那么您可以考虑查看multipathing是否会产生影响。对于iSCSI on ESX4，它可以，但不太可能，除非存储数组与ESX 4一起正确地支持它--我将向数组供应商寻求有关这方面的指导。

多点可能会引起你的问题。您是否能够并且尝试过禁用multipathing，只需要一个1Gb的连接到SAN？VMware在加载时可能会因为链路不好或数据包传送延迟而导致路径混乱。

顺便说一下，如果SAN和ESXi主机是链路上仅有的两个设备，那么1Gb链接的最大吞吐量将是~30 30MBytes/秒.