高性能服务器网络可伸缩性.doc

高性能服务器网络可伸缩性.doc

《高性能服务器网络可伸缩性.doc》由会员分享，可在线阅读，更多相关《高性能服务器网络可伸缩性.doc（26页珍藏版）》请在冰豆网上搜索。

高性能服务器网络可伸缩性

高性能可伸缩服务器的大量使用增加了网络和系统性能的复杂性。

在本文中，学习如何对多节点高性能Linux®系统进行优化（使用系统板载千兆以太网适配器，有1到4个节点）。

了解可能导致问题的网络可伸缩性场景以及避免问题的方法。

有许多资料讨论了网络性能、优化和调优，涉及各种硬件、平台和操作系统以及各种工作负载。

但是，高性能可伸缩服务器（比如IBM®eServer™xSeries®x460和IBMSystemx™3950）的大量使用毕竟增加了网络和系统性能的复杂性。

例如，对于可以通过添加完整的机架（或节点）来增加容量的可伸缩服务器，提高跨多节点系统的网络可伸缩性对总体系统性能非常重要。

系统配置

测试用系统（SUT）是一个4节点的IBMeServerxSeries460，运行SUSELinuxEnterpriseServer10forAMD64andEM64T（x86-64）。

每个节点的配置如下：

·系统：

IBMeServerxSeries460

·CPU：

4个64位Intel®Xeon®处理器70403.0GHz

·内存：

32GB（4个内存卡上各有8个1GBDIMM）

·以太网适配器：

Broadcom570410/100/1000dualEthernet/onsystemboard/64-bit266MHzPCI-X2.0

·网络驱动程序：

tg3c3.49

·网络类型：

千兆以太网

·线程化：

超线程技术

所有测试场景都使用IBMSystemp5™550系统，每个系统有两个IntelDual-Port以太网适配器，运行RedHatEnterpriseLinux4Update4。

4节点的绑定（bond）测试还包含一个2节点的IBMeServerxSeries460，运行SUSELinuxEnterpriseServer10forAMD64andEM64T（x86-64）。

SUT和驱动程序通过一个CiscoCatalyst3750G-24TS交换机网络。

回页首

测试方法

由于多种原因，我选用netperf基准（具体地说，是单向流测试TCP_STREAM）测试可伸缩性演示工作负载，原因包括它的简单性、可度量性、在Linux上的稳定性、广泛的应用以及能够精确地度量批量数据传输性能。

它是一个基本的客户机-服务器模型基准，包含两个对应的可执行文件netperf和netserver。

简单的TCP_STREAM测试从netperf系统到netserver系统的数据传输时间，以此度量一个系统发送数据和另一个系统接收数据的速度。

在执行时，netperf建立一个到远程系统的控制连接（通过TCP）。

这个连接用来在系统之间传递配置信息和结果。

使用另一个连接执行度量，在此期间保留控制会话但是没有通信流（除非某些TCP选项需要通信）。

在这里描述的所有测试中，当IBMeServerxSeries460执行网络发送（netperf）、网络接收（netserver）或同时执行这两种操作（双向）时，都度量网络吞吐量和CPU利用率。

在客户机发送端记录客户机和服务器之间的吞吐量，并由netperf基准报告记录的数据。

每个环境的完整测试对于从64字节到256KB的15种消息大小分别执行3分钟的流测试。

这个范围包含1460和1480字节的消息大小，所以在Linux将消息分割为小数据包发送到网络之后，总的数据包大小接近默认的最大传输单位（MTU）1500。

在SUT上度量CPU利用率并由sysstat包中的sar实用程序报告，这一信息表示为netperf测试期间的系统平均值。

所有CPU和中断信息也来自sar数据。

在可伸缩性演示中，修改了配置和参数来影响行为。

以各种组合启用和禁用它们将导致不同的结果。

通过设置SMPIRQ亲合位掩码/proc/irq/nnn/smp_affinity，可以指定允许哪些CPU处理特定的中断。

Linux在初始化期间将它们设置为默认值。

可以启动守护进程irqbalance，在处理器之间动态地分发硬件中断。

如果启用这个守护进程，它会反复修改smp_affinity位掩码来执行分发。

可以使用numactl程序将特定的进程绑定到特定节点上的CPU和/或内存。

Linux网络绑定提供多种将多个网络接口合并为一个逻辑接口的方法，对于多节点服务器，这是一个有吸引力的网络管理特性。

回页首

性能和可伸缩性结果

我们来看看以下配置的结果：

1.开箱即用：

不修改软件配置

2.开箱即用加上numactl：

与前一个配置相同，但是使用numactl将SUT上的netperf和/或netserver应用程序绑定到适当节点上的CPU和内存

3.以太网SMPIRQ亲合：

与第一个配置相同，但是将每个以太网适配器的中断处理绑定到适配器所在的节点上的一个CPU（不使用irqbalance）

4.以太网SMPIRQ亲合加上numactl：

这个测试环境组合了第二个和第三个配置

5.以太网绑定：

让一个大型多节点系统中的一些或所有以太网适配器共用一个IP地址

开箱即用配置

开箱即用测试在不修改软件配置的情况下运行。

在这个环境中，在Linux初始化期间默认启动irqbalance守护进程。

不修改SMPIRQ亲合，也不使用numactl和绑定。

第一个netserver可伸缩性测试在SUT的第一个节点的两个系统板载以太网适配器上各使用一个netserver实例。

每个netserver实例监听一个专用端口和IP地址；每个以太网适配器的IP地址属于单独的子网以确保专用的通信流。

远程驱动程序运行对应的netperf实例，从而按照远程netperf实例到SUTnetserver实例的一对一映射提供流通信。

完整测试使用15种不同的消息大小，对于每种消息大小执行3分钟的测试，并度量网络流吞吐量和系统CPU利用率。

第二个netserver可伸缩性测试使用前2个节点上的所有4个系统板载以太网适配器，第三个测试使用所有4个节点上的所有8个系统板载以太网适配器。

对于每个测试，相应地增加SUTnetserver实例和远程netperf实例的数量。

图1显示netserver可伸缩性测试的网络流吞吐量和系统CPU利用率，分别使用SUT中1、2和4个节点上的系统板载以太网适配器。

图1.采用开箱即用配置的SUT上的netserver

放大图1。

这里显示的吞吐量是每个测试使用的所有以太网适配器的吞吐量总和；CPU利用率是测试期间的系统平均值。

接下来，按照与netserver可伸缩性测试相同的方式执行netperf可伸缩性测试，惟一的差异是netperf在SUT上运行，netserver在远程系统上运行。

图2显示netperf可伸缩性测试的网络流吞吐量和系统CPU利用率，分别使用SUT中1、2和4个节点上的系统板载以太网适配器。

图2.采用开箱即用配置的SUT上的netperf

放大图2。

这里显示的吞吐量是每个测试使用的所有以太网适配器的吞吐量总和；CPU利用率是测试期间的系统平均值。

最后，按照与前面的netserver和netperf测试相似的方式执行双向可伸缩性测试。

但是，在这种测试中，只使用任何节点的第一个系统板载以太网适配器，而且只使用一个netserver实例和一个netperf实例。

再次重申，每个以太网适配器有两个基准实例（一个netserver和一个netperf），每个节点只使用一个以太网适配器。

对应的netperf或netserver远程实例在它自己的以太网适配器上运行，以确保尽可能完整地测试与SUT之间的通信流。

图3显示双向可伸缩性测试的网络流吞吐量和系统CPU利用率，分别使用SUT中1、2和4个节点上的系统板载以太网适配器。

图3.采用开箱即用配置的SUT上的netperf和netserver（双向）

放大图3。

这里显示的吞吐量是每个测试使用的所有以太网适配器的吞吐量总和；CPU利用率是测试期间的系统平均值。

对于每种消息大小，分别计算从2个适配器/1个节点到4个适配器/2个节点的吞吐量变化。

对于netserver可伸缩性测试，这些值的范围从1.647（比较小的消息大小）到1.944（比较大的消息大小）。

所有值的平均值是1.918。

同样，对于每种消息大小，分别计算从2个适配器/1个节点到4个适配器/2个节点的CPU利用率变化。

对于netserver可伸缩性测试，这些值的范围从2.770到1.623。

在这个环境中，所有值的平均值是2.417。

对于每种消息大小，还分别计算从4个适配器/2个节点到8个适配器/4个节点的吞吐量和CPU利用率变化。

吞吐量变化范围从1.666到1.900，平均值是1.847。

CPU利用率变化范围从2.599到1.884，平均值是2.386。

对于所有消息大小，从2个适配器/1个节点到8个适配器/4个节点的平均吞吐量变化是3.542。

对于所有消息大小，从2个适配器/1个节点到8个适配器/4个节点的平均CPU利用率变化是5.755。

表1给出netserver、netperf和双向测试的平均变化计算值。

表1.netserver、netperf和双向测试的变化计算值

测试

平均吞吐量变化，1到2节点

平均吞吐量变化，2到4节点

平均吞吐量变化，1到4节点

平均CPU利用率变化，1到2节点

平均CPU利用率变化，2到4节点

平均CPU利用率变化，1到4节点

netserver

1.918

1.847

3.542

2.417

2.386

5.755

netperf

1.940

1.732

3.371

3.109

2.537

7.973

双向

1.888

1.892

3.569

2.368

2.274

5.413

因为这组测试中没有使用SMPIRQ亲合，所以所有以太网中断都在默认的/proc/irq/nnn/smp_affinity值所指定的CPU上处理（在初始化时irqbalance会修改这些值）。

显示每个系统CPU的CPU利用率和中断数等信息的sar数据表明，无论以太网适配器是否在任何其他节点上，所有网络中断都在第一个节点的CPU上处理。

这导致了不必要的节点跳转延迟。

清单1给出netserver可伸缩性测试的部分sar数据（在所有4个节点上的所有以太网适配器上运行netserver）。

这组数据针对8KB的消息大小，可以代表这个环境中的所有测试。

所有值都是3分钟的测试期间的平均值。

清单1.开箱即用配置的sar数据

CPU%user%nice%