最近，我把我们所有的 Dell Equallogic SAN 整合到同一个组中；以前每个 SAN 都在自己的组中。它们都装有 RAID 6 中的 15k RPM SAS 驱动器，因此我没费心对新整合组的存储进行分层，因为它们基本上都是一样的。
在此过程中，我将所有虚拟机都改为使用 VMDK 存储而不是 iSCSI，因为我相信这样性能会更好。
我现在被告知我们的 MS SQL 2005 服务器（目前是我们的主要 SQL 框）的磁盘 I/O 性能一直比执行这些操作之前更差，但我不明白这是怎么回事......它的磁盘（C - OS、D - MDF、E - LDF）现在跨越的读取头比以前多得多，我的理解是 VMDK 存储比 iSCSI 性能更好。
那么到底发生了什么？以下是 Solarwinds 数据库性能分析器的“总 I/O 等待时间”图表：
答案1
将这些 EQL 阵列组合成单个池时要记住的第一件事是，每个卷上的工作负载都有可能影响其他卷上的性能。您的 SQL 数据库（尽管现在驻留在更多物理主轴上）可能会因其他工作负载共享相同主轴而产生更多资源争用。
第二个主要因素是存储网络。如果成员位于不同的池或组中，几乎所有 iSCSI 网络流量都来自主机的 I/O。但如果成员位于单个组和池中，则必须考虑组内流量 - 主要是页面移动。页面移动使成员之间的使用容量保持均衡，并将“热”数据平衡到工作负载相对较低的成员。查看白皮书equallogic 负载均衡器了解更深入的信息。
如果您的交换机不符合以下标准，这种流量的增加很容易超出您的交换机的处理能力：戴尔存储兼容性矩阵（见第 19 页）
您可能还想阅读最佳实践VMware 和 Equallogic 的白皮书，以确保您的配置不会导致问题。
一些问题：
您对任何阵列都有有效保修吗？如果有，您确实应该从支持人员那里获得建议 - 有大量性能精明的资源可供协助。
不幸的是，我对任何阵列都没有有效保修。
您是否已安装 SAN Headquarters 并监控该组？如果没有...请安装并配置它（假设您有保修并可以获得它）。它提供了一些关于许多存储性能指标的重要见解，您需要了解潜在的根本原因。
但是我确实有 SAN HQ...您能详细说明一下我应该在其中查看什么以帮助确定这一点吗？
最简单的检查位置是“实验分析”，它为您提供了您的工作量与“估计最大 IOPS”的比较图。您可以查看整个组和单个成员的图表。您还可以在硬件部分查看单个主轴的 IOPS 和队列深度，但仅凭这些数字很难判断主轴是否超负荷工作。
- 您现在在同一个池中有多少个成员/阵列？
现在同一个池中有 5 个阵列
我强烈建议您考虑将它们拆分成两个池，每个池中的成员不超过 3 个。当卷未处于将容量重新平衡到其他成员的过程中时，它只会在 3 个成员之间分配（在快照不断更改使用空间的卷上，这种情况会经常发生）。将成员数量减少到最多 3 个将阻止整个卷切片在成员之间重新平衡的大量“流失”，因为在成员之间无休止地追求尽可能平等的使用容量。
除了所有这些信息之外......如果您无法自己弄清事情的底细，您可以考虑向戴尔支付一张支持票，让某人与您一起检查环境中的所有情况，以找出原因。
答案2
共享磁盘时，您可能会减少“缓存时间”
假设您有两个应用程序“A”和“B”：
应用程序“A”有一个只有 40GiB 的小型数据库，每天加载 1GiB，大多数查询都使用过去一周的数据。在具有 20GiB RAM 专用于磁盘缓存的服务器中，磁盘缓存中可能存储着接近 20 天的数据，大多数读取甚至不会移动磁盘头。
另一方面，应用程序“B”是一个 2000GiB 的中型档案库，每天加载 20GiB 的数据，大多数查询都按顺序读取整个档案库。它是一个档案库，主要执行难以索引的文本查询，并且顺序读取发生在一天之内，这对应用程序用户来说已经足够了。与许多档案库一样，它仅供不需要更快响应的听众使用。
如果您使用相同的 64GiB 缓存将这两个服务器的磁盘合并到同一个存储上，则应用程序“A”和“B”每天会移动 21GiB 数据。然后，缓存最多会保存 3 天的数据。合并之前，应用程序“A”的大部分查询都在 RAM 上执行，而现在，大多数查询都需要物理磁盘读取。合并之前，应用程序“B”在磁盘访问方面与应用程序“A”的并发性很小，而现在并发性很高。
明白了吗？
对磁盘缓存进行分段对于性能非常重要，因为 RAM 的速度比 15k 磁盘的随机访问速度快 4k 到 400 万倍。磁盘必须移动磁头才能获取数据，而 RAM 则不需要。15k RPM 磁盘是浪费钱。它们的随机访问速度大约是普通 SATA 驱动器的 2 倍，而价格却是 SATA 驱动器的 2 倍多。
关于 VMDK
我的服务器太大了，过去我们在 VMWare 上使用大型虚拟机（例如 700GiB RAM）时遇到过问题。我们还遇到了严重的性能问题和无法解释的崩溃。因此，我们转向了 KVM。当时我并不是虚拟化服务器的管理员，所以我说不出我们的 VMWare 出了什么问题。但自从我们转向 KVM 并且我成为虚拟化服务器管理员后，我们就不再遇到问题了。
我在物理设备上有一些虚拟机映像（SCSI 转发），还有一些映像是 .img 映像文件（类似于具有固定大小的 VMDK）。互联网上的人说 SCSI 转发速度更快，但对于我的使用模式来说，性能是一样的。如果有差异，那差异对我来说很小。唯一的问题是，在创建新虚拟机时，我们必须指示 KVM 不要在主机操作系统上缓存磁盘访问。我不知道 VMWare 是否有类似的选项。
我给你的建议
1.改变存储策略
通过内部磁盘交换存储。24 个内部 SATA 磁盘可实现大型 raid 10，这比大多数存储便宜得多，速度也快得多。还有一个附带好处，以更低的成本，您将在这些服务器上拥有多余的磁盘空间，可用于交叉备份和维护任务。
但不要将这些剩余空间暴露给您的用户。请自己保留。否则备份将非常困难。
使用储物柜来存放以下物品：
- 集中备份；
- 数据库/档案太大，无法放入内部磁盘；
- 数据库/档案的使用模式不会通过磁盘缓存加速，并且性能所需的磁盘头数量不适合内部磁盘或专用存储。
而且...甚至懒得购买具有大量磁盘缓存的存储。而是把钱花在增加使用存储的服务器的 RAM 上。
2. 如果可能的话，将 RAM 从存储缓存移到实际服务器
假设统一后您的存储中缓存 RAM 的数量相同，则您可能有足够的 RAM。尝试按之前的比例将 RAM 从存储缓存移动到实际服务器。如果 RAM 芯片兼容。这可能会奏效。
3. 关键任务数据库不支持 RAID 6
Raid 5 和 6 对数据库性能影响最差。请升级到 Raid 10。Raid 10 可将读取速度提高一倍，因为每个扇区都有两个独立的副本，可以独立读取。
4. 将数据库日志移动到专用的内部驱动器
我使用 postgres，将预写日志移至专用磁盘会产生很大的不同。问题是，大多数现代数据库服务器在将信息写入数据库数据区域本身之前先将信息写入日志。日志通常是一个循环缓冲区，写入都是连续的。如果您有一个专用的物理磁盘，磁头将始终处于写入位置，即使是低转速驱动器也几乎没有寻道时间。正如我在互联网上看到的，Mysql 使用完全相同的设计。
答案3
VMDK 和块级 iSCSI 之间的性能差异取决于工作负载类型，并且可能因应用程序而异。我强烈建议您执行测试，例如在两种类型的存储访问协议上运行一些应用程序，并查看其行为。由于 VMDK 是应用程序和存储之间的附加层，如果控制虚拟驱动器的主机负载过重，它可能会变慢。