☰

iSCSI 和 AoE 性能均低下

tag-icon • tag-icon ubuntu performance iscsi
iSCSI 和 AoE 性能均低下

我们正在寻找速度合理的存储。由于预算有限，我们决定使用软件 iSCSI 或 AoE 目标。在更改生产基础设施之前，我们会进行一些测试以选择最佳技术。

为了进行测试我们使用：

  • 富士通西门子 RX200 S4 作为目标
  • 富士通西门子 RX200 S4 作为启动器
  • NetGear 管理 1GBit 交换机
  • 板载 NIC（带 TOE 的 Broadcom）、EdiMax NIC、带 TOE 的 Broadcom NIC - 全部为 1GBit
  • 目标服务器使用带有 6 个 2TB WD Blue SATA 驱动器的 QLogic 控制器。
  • 目标和启动器操作系统均为 Ubuntu 16.04 LTS，包含所有更新。交换机专用于存储。我们测试了绑定和多路径。

我们的问题是读取速度太慢。我们使用dd40-100GB 的文件进行测试。

  • 目标服务器的本地读写超过300MB/s。
  • 通过 iSCSI 或 AoE 写入服务器的速度超过 200MB/s，这让我们很满意。
  • 从服务器读取的速度始终为95-99MB/s。

我们尝试过 ietd、aoetools、LIO。我们使用了 2 个 NIC 的绑定：balance-rr 和 LACP，使用 rr 进行多路径处理。使用普通帧和巨型帧。最后，我们甚至在目标和主机之间建立了直接以太网连接（无交换机）。

所有测试都给出大致相同的结果（当然，使用没有 TOE 和 iSCSI 的普通 NIC 会给出 20-30% 的更差结果）。

使用 iperf 测试网络显示传输速度约为 200MB/s (2GBit)。使用 bmon 观察目标上的 NIC 使用情况显示两个设备的利用率相同（每个设备的读取速度约为 50MB/s，写入速度约为 100MB/s）。

由于运气不佳，我们决定使用第三个 NIC（当然是两侧都使用）。结果很奇怪：

  • 2 个 NIC - 每个 50MB/s
  • 3 个 NIC - 每个 33MB/s

目标软件是否有任何限制来禁用高于 1GBit/s 的输出？

我们做错了什么？

答案1

要从 iSCSI 连接存储中获取最大性能，您应该使用巨型帧和 MPIO（而不是 LACP）。如果可以的话，建议使用 RDMA/iSER。

AOE（以太网 ATA）很旧，而且很糟糕。我们几年前就摆脱了 Coraid。我们正在使用 StarWindhttps://www.starwindsoftware.com/作为 iSCSI 目标已经有一段时间了，StarWind 要求我们将 Coraid 迁移到我们可以做的任何存储上。

因此，目前，我们非常擅长使用 StarWind 提供的 iSCSI 以及使用 Windows、ESX 和 SCSThttp://scst.sourceforge.net/在 Linux 上作为启动器。使用 RDMA/iSER 时，它可达到 10 Gbit，到目前为止非常满意。

答案2

您对以太网链路聚合工作方式的预期是错误的。

除了 balance-rr 之外的所有聚合方法（即：所有模式 > 0 的方法）都不是为您提供更大的单连接吞吐量；相反，它们会增加总可用带宽多个连接是从受影响的主机建立的。换句话说，对于这种单连接方案，LAG/LACP 不会给您带来任何好处。

唯一能够提供比单个接口通常拥有的更大的单会话吞吐量的聚合方法是平衡-rr，以循环方式分发数据包。您必须设置平衡-rr在两个都发起者和目标。然而大的问题是，这很大程度上取决于开关。

无论如何，如果您将目标和发起方都设置为 balance-rr，直接连接两台机器应该会提高性能。如果不行，您能否发布一个iperf带有 balance-rr 且两台机器直接连接（无交换机）的命令？另外，请发布dd您用于基准测试的确切命令。

答案3

注意：我这里只谈论 iSCSI。除了阅读有关 AoE 的文章外，我没有使用过它，而且无论如何我也不会在任何新的基础设施中实现它（它几乎已经不存在了）。

除了某些非常具体的点对点协议外，不要将 balance-rr 用于任何其他用途。在几乎任何类型的实际负载下，它的性能都很糟糕，并会导致大量网络问题（例如大量抖动）。绝对不要将它与交换机一起使用。

使用 MPIO 而不在启动器端进行任何绑定来实现负载平衡和容错。为了确保您的路径不会因将所有流量发送到一条路径而“混淆”，请将各个路径（在您的情况下是目标和启动器之间的千兆位 NIC）放在单独的子网上。

随意将目标端与 LACP 绑定每条路径（例如，两个路径的两个绑定，总共四个 NIC，作为目标端口配置的示例）。这很有效，并且可以平衡使用相同路径的多个启动器连接。如果可能，还可以使用巨型帧和 iSER。在目标上使用 LACP 将在多个 NIC 之间平衡与每个路径的连接。

仅在发起方同时使用多个目标门户连接时，在发起方上使用 LACP 才会有效（对于任何工作负载来说，这种情况并不常见）。即使您要在发起方上有效地按路径实施 LACP，在每个盒子上使用（例如）四个额外的结构也会很快成为布线噩梦。如果您需要单个发起方的吞吐量超过 ~2Gib/s，请考虑使用 10GiB/s 以太网。

答案4

我知道 LACP 适用于多个连接。测试它是无奈之举 :)

所有测试均使用 balance-rr 和两个 NIC 完成。

写入 iSCSI 目标：
dd if=/dev/zero of=/mnt/zero.bin bs=1M count=2000
2000+0 复制记录
2000+0 复制记录
2097152000 字节 (2,1 GB, 2,0 GiB) 已复制，10,1093 秒，207 MB/秒

从 iSCSI 目标读取：
dd if=/mnt/zero.bin of=/dev/null bs=1M
2000+0 已复制记录 2000
+0
已复制记录 2097152000 字节 (2,1 GB, 2,0 GiB)，16,1684 秒，130 MB/秒

网络速度：
iperf -c 172.16.10.80
------------------------------------------------------------
客户端连接到 172.16.10.80，TCP 端口 5001
TCP 窗口大小：325 KByte（默认）
------------------------------------------------------------
[ 3] 本地 172.16.10.70 端口 37024 连接到 172.16.10.80 端口 5001
[ ID] 间隔传输带宽
[ 3] 0.0-10.0 秒 2.30 GBytes 1.98 Gbits/秒

使用 iperf 和巨型帧测试得到相同结果。

我在启动器上运行后获得了一些读取速度：
hdparm -a 2048 /dev/dm-1
以前是 256，读取速度为 96MB/s
我的目标是实现大约 200MB/s 的读取速度。

编辑：
1. 我们不使用 LACP - 这是一次性测试。
2. 使用 balance-rr 和 MPIO 进行测试得出完全相同的结果。使用不同子网中的 NIC 测试了多路径。
3. 添加更多 NIC 不会提高读取速度，只会降低每个 NIC 的利用率。
4. 我们认为问题在于某些限制（驱动程序、模块？）不允许更快地读取。但我不确定它是目标端还是发起端。


编辑 2：刚刚做了一些额外的测试：配置相同的主机作为目标和发起程序以摆脱网络硬件问题。我很震惊：读取速度完全相同！130 MB/s！写入是 227 MB/s。

相关内容