iSCSI SAN RAID 10性能 – 糟糕的读取，良好的写入

首先要注意的是，您实际上并没有在这里testingSAN性能。 由于您的IO基准testing是在虚拟机的C驱动器上运行的，我猜测这是一个存储在这些2TB卷之一的文件系统（例如，存储在VMware VMFS数据存储区中的VMDK）内的虚拟硬盘驱动器。 如果这是您在此卷上运行的唯一testing，甚至是在此VM上，那么您在I / Opath中添加了许多不应用于testing的path。

我build议您给虚拟机直接iSCSI访问一个单独的testing卷，格式化音量，并在testing卷上再次运行testing。

其次，您需要确定磁盘上的IOPS负载是否是您的结果中的一个因素，假定此arrays已在生产并且具有正常的工作负载。 SAN总部由戴尔提供，不收取额外费用，前提是您对系统有一个有效的保证。 SAN HQ为您提供关于每个主轴IOPS的数据，并且可以向您显示在您运行这些testing时I / O是否严重排队。

使用16 x 7.2K主轴以及您拥有的MPIO /networking设置，您应该可以轻松地饱和该VM可用的单个千兆位链路（由于您的水平分割configuration，下面我将介绍）。 如果其他I / O正在使用该链路的任何一个带宽，这是另一个会限制或可能中断结果的因素。

在两个不同子网的两个eth端口上通过iSCSI共享

这肯定会导致性能问题 – Equallogicarrays不能用于多个iSCSI子网，并且完全不支持此configuration。 使用当前的configuration，EQLarrays一侧没有networking级冗余（如果EQL端的networking链路断开，一个子网会丢失所有iSCSI访问权限）。

最后要提到的是Hypervisor本身。 物理主机configuration或硬件的问题可能也是一个因素。 如果您能够完全排除磁盘IOPS工作负载和networking带宽可用性作为性能问题的罪魁祸首，则可能需要向支持提供商寻求帮助。 我强烈build议与Dell的Equallogic支持团队联系，特别是在使用VMware ESX时。

我发现了这个问题！

问题出在SAN中我的主机之间的networking层。 我首先直接将SAN连接到主机，我没有问题。 所以我把它挂了回去，开始对networking进行故障排除。 生成树协议明显地影响了这个特定的PS4000 SAN的stream量。 一旦我禁用与PS4000 SAN相关的端口上的STP，所有的一切都开始按照预期的方式工作。

感谢您给我的所有帮助，使我有所收获。