我们在一台运行 iSCSI-Target 的 1U Ubuntu 服务器上设置了一个简易 SAN，该服务器有两个 300GB 驱动器，采用 RAID-0 结构。然后，我们将它用作虚拟机的块级存储。虚拟机管理程序通过专用 VLAN 和接口上的千兆位连接到 SAN。
我们只设置了一个虚拟机并进行了一些基准测试。如果我们hdparm -t /dev/sda1从虚拟机运行，从虚拟机到 SAN 的性能为 75MB/s，还算“不错”。然后我们基本上用./configure和编译一个包make。一切开始都正常，但突然间 SAN 上的平均负载增长到 7+，速度慢得像爬行一样。当我们通过 SSH 进入 SAN 并运行 top 时，负载当然是 7+，但 CPU 使用率基本上为零，而且服务器有 1.5GB 的可用内存。当我们在虚拟机上终止编译时，SAN 上的负载慢慢地回到 1 以下的数字。
这到底是什么原因造成的？我们如何进一步诊断？
这是高负载期间 SAN 的两张屏幕截图。
1> Output of iotop on the SAN:
https://i.stack.imgur.com/u0xt9.jpg
2> Output of top on the SAN:
答案1
在目标上启用写入缓存后，您应该会看到性能显著提升（细节取决于实现 - 您正在使用什么，tgt？）以及您的磁盘
hdparm -W 1 /dev/sda
hdparm -W 1 /dev/sdb
但是，这样做是有代价的：如果发生断电或 SAN 系统挂起，数据完整性将受到威胁（尤其是当您运行数据库时），因为原本应该永久写入磁盘的数据仅驻留在易失性 DRAM 中。为了降低这种风险，您应该使用带有 BBWC（电池供电的写入缓存）的控制器，这样数据在断电后可以保留一段时间（通常为 1-2 天）。
ESXi 的主要“问题”是它不断同步磁盘。需要将元数据写入 VMFS（如果有的话）使情况更加糟糕。每当人们使用没有写入缓存的控制器时，vmware 社区论坛上就会充斥着“我的磁盘很慢”的帖子。
答案2
在虚拟机中运行 iometer。
仅使用两个 7.2k rpm 驱动器，随机访问会对您造成伤害。您只能从它们获得有限的 iop。
尝试使用 iometer 运行两种场景：
1) 顺序读/写 - 这应该会给出不错的、丰满的数字。2) 随机访问驱动器 - 在这里你应该会感到痛苦。
设置一个足够大的测试文件，以强制将其推出虚拟机的缓存。
答案3
我建议尝试以下几件事：
- 尝试使用非 iSCSI 流量（例如
dd if=/dev/zero bs=1M | nc ...）进行一些吞吐量测试，并查看负载是否以相同的方式激增（比较负载和 CPU %s）。您可能应该尝试仅使用一个连接进行测试，以及同时运行大约 8 个这样的测试。并尝试在两个方向上发送和接收数据。 - 尝试使用不同的目标软件（例如 tgt Ubuntu 包）
- 将 SAN 上的内核更新到较新的版本，以防遇到内核错误。
- 在 iSCSI-Target 邮件列表中报告此问题，或者如果没有运气，也许Linux 内核邮件列表？
- 如果所有其他方法都失败了，并且如果这是您的选择，请尝试 NexentaOS 或 NexentaStor，看看是否能获得更好的结果。
我还偶然发现了一些iSCSI 性能调优指南最近，您可能会发现它们很有帮助，即使这些建议可能无法解决您遇到的特定问题。