问MSSQL I/O性能在SAN合并后下降？

EN

将这些EQL数组组合到一个池中首先要记住的是，每个卷上的工作负载可能会影响其他卷的性能。您的SQL数据库(虽然现在驻留在更多的物理纺锤体上)可能由于其他工作负载共享相同的纺锤而具有更多的资源争用。

想到的第二个主要因素是存储网络。使用独立的池或组中的成员，几乎所有的iSCSI网络流量都是从I/O到/来自主机的。但是，对于单个组和池中的成员，您必须考虑到组内通信量--主要是页面移动。页面移动保持在成员之间甚至在使用中的容量，并且平衡“热”数据给工作负载相对较低的成员。查看均衡负载均衡器上的白皮书以获得更深入的信息。

如果交换机不符合戴尔存储兼容性矩阵中描述的标准，流量的增加很容易超过交换机的能力(见第19页)。

您还可能希望阅读最佳做法白皮书中的VMware和Equallogic，以确保您的配置不会引起麻烦。

一些问题：

1. 你对任何一个数组都有有效的保证吗？如果是这样的话，这确实是你应该得到的支持投入-吨的性能精明的资源，以协助。不幸的是，我对任何数组都没有有效的保证。
2. 你是否安装了SAN总部并对该小组进行监控？如果不是..。安装并配置它(假设您有保修并且可以获得它)。它为您了解潜在的根本原因所需的许多存储性能指标提供了一些至关重要的洞察力。不过，我有圣总部.你能详细说明一下我应该在里面看些什么来帮助把这件事记下来吗？

最容易检查的地方是“实验分析”，它给出了与“估计的最大IOPS”相比的工作量图表。您可以为整个组和单个成员查看此视图。您还可以在硬件部分看到单独的纺锤体IOPS和队列深度，但是仅从这些数字就很难判断纺锤是否过度工作。

1. 现在在同一个池中有多少个成员/数组？现在在同一个池中有5个数组

我强烈建议您考虑将它们分成两个池，一个池中的成员不超过3个。一个卷只在3个成员之间分配，而不是在另一个成员的再平衡容量(这将经常发生在卷上，快照不断变化的使用空间)。削减到3个成员的最大限度将停止大量的“搅动”从整个卷片之间的成员之间的再平衡，在获得尽可能平等的成员之间的使用能力无休止的追逐。

除了这些信息..。如果你不能自己弄清楚事情的真相，你可能会考虑与戴尔一起支付一张支持票，让别人和你一起穿越环境中的每一件事来隔离原因。

VMDK和块级iSCSI之间的性能差异取决于工作负载类型，不同应用程序之间可能存在很大差异。我严格地建议您执行一个测试，比如在两种类型的存储访问协议上运行一些应用程序，并看看它是如何工作的。由于VMDK是app和存储之间的一个附加层，如果控制虚拟驱动器的主机负载很重，它可能会慢一些。