利用 Linux 通道捆绑来提升 IBM InfoSphere Streams 性能

look_w

概述本文探讨 Red Hat Enterprise Linux 上的通道绑定对 IBM InfoSphere Streams 吞吐量和延迟的影响。将介绍如何使用 Red Hat Enterprise Linux 系统设置和配置通道绑定环境，可从在此环境中运行的 InfoSphere Streams 应用程序获得怎样的性能改进。目标读者为熟悉 InfoSphere Streams 和 Linux 网络接口配置并具备相应技能的人群。
通道绑定是什么？通道绑定 (Channel bonding) 这个术词用于描述在两个网络接口之间拆分单个数据流，同时为应用程序层提供单个接口的过程。通过利用此技术，可实现更高的数据吞吐量，因为数据可同时在两个网络接口卡上流动。通道绑定可用于 InfoSphere Streams 支持的所有 Red Hat Enterprise Linux 内核。我们测试了一种通道绑定设置，并解释所观察到的结果。
请参阅  一节，获取有关通道绑定的 Red Hat Enterprise Linux 文档的链接。
设置通道绑定硬件要在 1Gbps 连接上通过通道绑定实现最佳的性能结果，请考虑以下硬件需求：

• 1Gbps 交换机或具有较高的过度订阅比率的更大交换机上的一个线路卡
• 具有两个 1Gbps Ethernet 连接的两个支持 Linux 的系统                            备注：如果使用的是刀片服务器，在机架中使用穿透 (pass-through) 模块。由于交换机中用于调解流量的算法的原因，交换机模块可能不具有最佳的性能。
  

在我们的测试环境中，Cisco 6509 交换机构成了私有集群网络的 1Gbps 主干网。为了实现各个系统的最大性能，我们使用了 WS-X6748-GE-TX 线路卡。这些线路卡是高性能卡（每槽 40Gbps ），为卡上的所有 48 个端口提供了接近 1Gbps 的速度。对于本测试，交换运行 Cisco 的 IOS 版本 12，线路卡具有最新的固件。如果您的 Cisco 交换机运行 NX-OS 或者使用另一家供应商的产品，这些命令可能需要修改或者可能完全不同。请向您的网络管理员咨询寻求帮助。
对于下面列出的性能数字，网络交换机中未使用任何特殊的配置。尽管一些供应商交换机支持链路聚合控制协议 (Link Aggregation  Control Protocol, LACP)，一种纯操作系统的绑定配置可获得更高的性能结果。因为现代的硬件可轻松处理一些问题（如重新排序乱序的包）而不会对性能造成任何显著的影响，所以没有必要依赖交换机硬件来执行此工作。
图 1. InfoSphere Streams 通道绑定测试配置软件从软件的角度讲，您需要的所有软件都已包含在 Red Hat Enterprise Linux 5 发行版中。要在您的环境为每台机器设置通道绑定，您需要调整网络配置并将链接聚合在交换机中。为了简化这些说明，我们将假设您将进行通道绑定的任何服务器配置了 Red Hat Enterprise Linux 5 并在构建时定义了两个网络接口中的一个。在我们的示例中，eth0 在最初设置，/etc/sysconfig/network-scripts/ifcfg-eth0 类似于清单 1。
清单 1. /etc/sysconfig/network-scripts/ifcfg-eth0

1 2 3 4 5 6 7 8 9 10 11 12 13 14

DEVICE=eth0 <br>   HWADDR=E4:1F:13:78:FE:98 <br>   ONBOOT=yes <br>   BOOTPROTO=static <br>   IPADDR=10.6.24.43 <br>   NETMASK=255.255.252.0 <br> DNS1=10.6.24.11 <br>

设置通道绑定软件涉及到 4 步：

• 更改 /etc/sysconfig/network-scripts 中的 ifcfg-eth0
• 更改 /etc/sysconfig/network-scripts 中的 ifcfg-eth1
• 在 /etc/sysconfig/network-scripts 中创建一个新 ifcfg-bond0
• 描述系统的 “绑定”

备注：最好在关闭接口时执行此工作。如果在接口运行时执行，系统将发出警告，因为 eth0 现在是一个从属服务器，但您将获得正确的网络配置。您将发现重新启动将花更长时间。
步骤 1：对于 ifcfg-eth0，将 BOOTPROTO 行更改为 none。我们将删除与 IPADDR、NETMASK 和 DNS 相关的行。此信息将保存在 ifcfg-bond0 文件中，所以不会丢失重要细节。针对 ifcfg-eth0 的新行如下所示：

1 2 3 4 5

MASTER=bond0 <br>   SLAVE=yes <br>   USERCTL=no

步骤 2：对于 ifcfg-eth1，我们将编辑系统在配置时建立的未使用的默认配置：

1 2 3 4 5 6 7

DEVICE=eth1 <br>   BOOTPROTO=dhcp <br>   ONBOOT=no <br>   HWADDR=e4:1f:13:78:fe:9a

再一次，我们像对 eth0 接口所做的一样更改 BOOTPROTO 行，添加从 MASTER、SLAVE 和 USERCTL 开始的 3 行。我们还需要将 ONBOOT 更改为 yes。
步骤 3：我们现在将通过新 ifcfg-bond0 文件定义绑定。使用相同的网络信息，此文件将类似于：

1 2 3 4 5 6 7 8 9 10 11 12 13

DEVICE=bond0 <br>   ONBOOT=yes <br>   BOOTPROTO=none <br>   IPADDR=10.6.24.43 <br>   NETMASK=255.255.252.0 <br>   DNS1=10.6.24.11 <br>   USERCTL=no

步骤 4：因为绑定将被视为一个具有自己的内核模块的新网络设备，我们需要为 Linux 提供一些有关此新 “设备” 的信息。我们将在 /etc/modprobe.d 中创建一个名为 bonding.conf 的文件。在该文件中，我们添加以下两行：

1 2 3

alias bond0 bonding <br> options bond0 mode=0 miimon=100

请参阅 参考资料 获取有关通道绑定的 Red Hat Enterprise Linux 文档。
测试结果环境我们使用两个运行 Red Hat Enterprise Linux 5.5 的机器实现一个通道绑定环境。每个机器拥有 8 个运行在 2.93 GHz 的 Intel Xeon CPU X5570 处理器。我们使用了两个 1Gbps NIC，并通过一个 Cisco 6509 交换机对它们进行通道绑定。请参阅 图 1。
因为我们的目标是测试性能，我们选择名为 Balance Round Robin (balance-rr) 的绑定方法。一种使用通道绑定模式 balance-rr 改进吞吐量的方法是更改 TCP 对无序传送的容错率。通过提高对无序传送的容错率，您可以减少 TCP 要求重传包的频率。对无序包的容错率可通过设置 tcp_reordering sysctl 参数来调整。对于此测试环境，我们将该值设置为 127，利用以下 Linux 命令：sysctl -wnet.ipv4.tcp_reordering=127。
将该值设置为 127，实际上完全禁用了重新传输。这样做的缺点是会提高 TCP 的 CPU 成本，并且 TCP 连接将会处于一种阻塞状态。
吞吐量吞吐量测试是一个简单的测试，一个机器上的用户定义的运算符将元组发送到不同机器上的接收运算符。接收运算符简单地统计传入的元组。除了统计，它还会在收到第一个和最后一个元组时存储当前时间戳。确定第一个和最后一个时间戳之间的间隔，可得出接收所有元组所花的时间。

吞吐量 = （元组数量）/（接收这些元组所花的时间）

IBM 使用 TCP 传输配置得到了以下测试结果。
图 2. TCP 传输的 InfoSphere Streams 吞吐量然后在（配置为利用在 TCP 上的 LLMRUM 传输的）InfoSphere Streams 应用程序上运行相同测试。
图 3. LLMRUMTCP 传输的 InfoSphere Streams 吞吐量从前面的图中可以看出，利用 TCP，吞吐量增加了大约 60%。利用 TCP 上的 LLMRUM，吞吐量增加了接近 40%。LLM 的吞吐量更低，因为 LLM 自己的调度可能会影响 TCP 对传输到两个 NIC 的流量的调度。
延迟结果延迟测试度量往返延迟，使用一个源运算符和相同机器上的一个接收运算符，以及不同机器上的一个函子 (Functor) 运算符，后者将来自源运算符的元组传递给接收运算符。延迟的计算方式为元组进入接收运算符的时间减去元组离开源运算符的时间。这两个时间的差非常准确，因为使用了相同机器的时钟来获取两个度数，因此消除了任何相对的时钟偏差。

往返延迟 =（相同机器上的元组结束时间 - 元组开始时间）

在测试期间，IBM 在以大约每秒发送 5,000 个元组的速度得到了以下延迟结果。
图 4. 使用 TCP 传输的 InfoSphere Streams 延迟图 5. 使用 LLMRUMTCP 传输的 InfoSphere Streams 延迟从上面的图中可以看到，对于较小的元组，通道绑定对延迟的影响很小。对于较大的元组，延迟会增加，原因可能在于无序包的重传。
结束语上面的实验表明，影响性能的关键因素是元组大小和传输配置。然而，在许多环境中，通道绑定可能是提高 IBM InfoSphere Streams 上的应用程序吞吐量的一个有用工具。