☰

SAN 与 iSCSI 目标性能惨不忍睹

tag-icon • tag-icon ubuntu storage-area-network iscsi
SAN 与 iSCSI 目标性能惨不忍睹

我们在一台运行 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:

http://imgur.com/2doVP

2> Output of top on the SAN:

在此处输入图片描述

答案1

这看起来非常像典型的存储规格不足的情况。虚拟机管理程序（尤其是 ESXi/vSphere）发出同步写入的频率比您在 Linux 等操作系统的裸机安装中看到的频率要高得多 - 在 Linux 中，绝大多数写入请求都是异步的（除非您搞砸了文件系统设置）。再次，同步写入需要存储确认操作已完成并已提交到永久存储。如果您只有 2 个磁盘，这将是一场艰难的游戏 - 您会看到结果。

您的选择：

  1. 使用带有自己的电池或闪存支持的缓存的 RAID 控制器，以便它可以在数据写入缓存后立即报告完成
  2. 欺骗虚拟机管理程序，使其认为数据已提交到永久存储，但实际上并没有，方法是启用IOMode=wbietd.conf 中的 LUN 定义

请注意，我们不建议使用后者，因为它可能会导致您的 Hypervisor 的数据存储、客户机文件系统和事务数据库在断电或存储服务器崩溃时损坏（IET 确实可能偶尔崩溃），但它非常适合在编译时快速检查同步写入是否导致了您的负载和糟糕的性能数字。

答案2

瓶颈。可能在启动器端、两侧的网络、目标软件或目标磁盘子系统。根据描述，我将从网络开始，确保卸载已关闭（ethtool -K {tso, gso, lro} off）

答案3

hdparm是一款非常差劲的 IO 性能基准测试工具。您应该考虑使用bonnie++或更适合特定应用程序的工具之一。

在执行您的./configure; make 过程时，您最终会进行一系列读取和写入，大小可变，很可能分布在整个磁盘上而不是连续的区域。

一旦您更好地了解了您的 IO 系统性能，您就可以着手找出根本原因。

直接写入磁盘时 iSCSI 目标上的性能是否正常，但通过 iSCSI 通信时性能是否不正常？如果是，可能与网络有关（卸载、mtu、双工/速度不匹配等）。如果不是，可能与控制器/磁盘有关（写入缓存等）

相关内容