基于LINUX的链路聚合应用与实践

杨卫中 王军利

传统的linux主机在做网络配置时，主要采用bond方式，模式一般采用mode=1，实现链路冗余的目标。本文主要针对redhat的链路聚合技术的应用和实践，实现链路冗余的同时，主机单侧交换机速率将由原有10GB提升至20GB主备链路从而达到IO性能翻倍的目标。

一、研究背景

2019年是高质量发展、提升客户感知的一年。 BSS3.0成功上线让原IT架构由集中式升级为分布式，应用模型和基础设施架构较之前发生了巨大变化，如何让主机、网络、数据库等基础设施更好为上层应用提供支撑，如何提升基礎设施性能就成为一个必须解决的课题。

在去IOE的背景下众多oracle数据库业务已经从小型机迁移到了X86架构上，并且完成了向Oracle12c的版本升级。随着数据库新特性的增加以及业务量的增长，数据库主机的网络带宽面临严峻的压力。

为了更好的支撑业务需求，主流做法是采用万兆交换机接入。数据库主机业务端口分别连接两台万兆交换机，将单侧链路的带宽提升至10Gbps，同时为了保证高可用性，会在主机层面采用网络组的方式对链路做捆绑，即配置Bond，一般情况下会采用Mode=1（active-backup）的模式，即主备模式，两个10Gbps端口为主备工作方式，端口汇聚后流量经过主用端口转发，当主用端口故障后会切换备用端口，且端口汇聚后速率仍10Gbps。在前期的时候这样的速率是充分满足生产需求的，但是随着新特性的增加、新业务量的增长、备份策略的调整，10Gbps的带宽速率已经无法满足当前Oracle数据库大流量的生产需求，尤其是PDB（Pluggable Databases）的数据库迁移。为了解决端口流量带宽问题，需要对Oracle主机进行网络端口扩容，从原来的10Gbps带宽提升至20Gbps。

二、方案简介

（一）当前主机环境

操作系统：Red Hat Enterprise Linux 7.5 X86_64

数据库版本：Oralce12cforLinux

网络配置：每台主机配置4个10Gbps网口接口，分别两台万兆业务交换机和两台万兆心跳交换机。主机采用Bonding 内核模块Mode=1（active-backup）的方式配置主备链路从而达到高可用性要求。

（二）优化后主机环境

操作系统：Red Hat Enterprise Linux 7.5 X86_64

数据库版本：Oralce12cforLinux

网络配置：每台主机配置6个10G b p s网口接口，使用4个端口分别接入两台万兆业务交换机，剩余的2个端口接入两台万兆心跳交换机。主机采用teamdMode=4（802.3ad）的方式配置和交换机的聚合LACP方式配合单侧交换机速率将由原有10GB提升至20GB主备链路从而达到高可用性要求。

三、应用和实践内容

（一）了解网络成组

联合或合并网络连接，以提供具有较高吞吐量的本地连接或冗余的方式可称为“频道绑定”、“以太网绑定”、“端口聚合”、“频道成组”、“NIC 成组”、“链接合并”等等。这个最初在 Linux 内核中应用的概念泛指“绑定”。现使用网络成组（Network Teaming）代表这个概念的最新应用。

网络成组或成组旨在通过提供小内核驱动程序，以便使用不同的方法应用这个概念，实现数据包流的快速处理，并让各种用户空间应用程序在用户空间执行各种任务。该驱动程序有一个应用程序编程接口（API），即“成组 Netlink API”，可使用该接口进行 Netlink 通讯。用户空间程序库使用这个 API 与该驱动程序通讯。库指的是“lib”，可用来进行成组 Netlink 通讯及RT Netlink信息在用户空间的换行。同时还提供应用程序守护进程teamd 使用 Libteam 库。teamd 的实例可控制成组驱动程序中的实例。该守护进程通过使用附加代码（即“运行程序”）采用负载平衡及 active-backup 逻辑（比如轮询）。通过使用这个方式分离代码，可方便网络成组对负载平衡及冗余要求的扩展及延伸解决方案。例如：使用teamd 编写自定义运行程序应用新的逻辑可相对简单，即使 teamd 为自选程序，用户仍可编写其自己的应用程序以便使用 libteam。

teamdctl 提供一个用来控制使用 D-bus 运行 teamd实例的工具。它可为 teamd D-Bus API 提供 D-Bus 换行程序。默认情况下，teamd 使用 Unix 域套接字（Unix Domain Socket）进行侦听和通讯，但仍监控 D-Bus。这样做是保证能够在没有 D-Bus 或者尚未载入 D-Bus 的环境中使用 teamd。例如：引导 teamd 链接时不一定载入D-Bus。可在运行时使用 teamdctl 工具读取配置、连接监控程序状态、端口状态检查及变更、添加和删除端口以及将端口状态在 active 和 backup 状态间切换。

成组 Netlink API 通信使用 Netlink 信息与用户空间应用程序通讯。用户空间库 libteam 不会直接与这个 API互动，但会使用 libnl 或 teamnl 与驱动程序 API 互动。

总之，不会直接配置或控制内核中运行的成组驱动程序实例。所有配置均采用用户空间应用程序完成，比如 teamd 程序。然后该程序会根据需要指向内核驱动程序。

（二）端口聚合目标

将原有bond端口聚合模式变更为teamd聚合模式，并且将原有业务聚合的2个端口拓展至4个端口，业务端口速率由10GB拓展至20GB。

（三）teamd原理

Teamd和bond0功能类似，redhat7之前没有teamd，在redhat7.0以上版本中网络方面的相关服务被NetworkManager所接管，所以在配置多网卡绑定时，redhat专门提供了teamd工具来实现多网卡的绑定。Teamd不需要手动加载相应内核模块，具有更强的拓展性。

Teamd的种类：

broadcast（可将数据传送到所有端口）

round-robin（可按顺序将数据传送到所有端口）

active-backup（使用一个端口或链接时其他则处于备用状态）

loadbalance（使用主动 Tx 负载平衡及基于 BPF 的Tx 端口选择程序）

lacp（采用 802.3ad 链接合并控制协议）

此外还可使用以下链接监视程序：

ethtool（Libteam lib 使用 ethtool 监视链接状态变化）。若没有在配置中指定其他链接监控程序，则默认使用该程序。

arp_ping（使用 arp_ping 程序监控使用 ARP 数据包的远端硬件地址状态。）

nsna_ping（使用 IPv6 邻居发现协议中的的邻居播发和邻居请求给你监控邻居的接口状态。）

（四） 配置思路

停止oracle数据库相关服务。每台数据库主机增加一块新的2-port万兆網卡。每台数据库主机拓展两个10GB业务端口。将每台数据库主机上联的四个业务端口使用LACP做端口聚合。为每台主机安装teamd软件并将网口聚合模式由bond更改为teamd。如果是现网主机改造，需要注意聚合后的接口名称需要与原来的bond方式保持一致，否则数据库无法启动。全新配置的数据库主机不存在此问题。测试业务可用性，检查Aggregate ID配置是否正确。启用oracle数据库服务。

四、应用效果

（一）性能提升：可靠性、稳定性、IO性能

业务端口聚合后，对端口流量带宽进行测试，通过观察测试结果，4个业务端口通过teamd做聚合后，流量带宽达到20GB甚至更高，是原来的2倍。

原单链路升级为多链路，网络、链路都有多份冗余，可靠性和稳定性比传统网络有成倍的提升。

前端业务感知为：业务办理等提交的工单更快入库，数据查询达到实时回应。

（二）架构优化

该成果应用后，无需单独另外部署备份网络，由SAN（光纤网络）备份升级为LAN（IP网络）备份，节省了机房空间、网络布线、设备投资等多方资源。

原san网络需要特有的光纤交换机、om3规格的光纤，每次项目上线均需3个月甚至更久时间，采用新的架构后，数据备份等需求可根据需要在1天内完成，时间成本是原来的1%左右。为前端业务提供了更为优化的服务。

五、推广价值

（一）商业价值

该成果被成功推广后，原有SAN（光纤网络）备份方式将升级为LAN（IP网络）备份方式，备份网络将发生很大变化。新购SAN设备、光纤布线、机房空间等一系列工作将不再是棘手问题，底层数据备份等工作项目时间可由原来3个月甚至更久变为1周或1天完成，时间、人力等成本有明显降低。

（二）技术价值

Teamding功能主要由kernel里的teamd driver、用来作为通讯接口的libteamd lib和userspace的teamdd 三部分组成，teamding也支持不同的工作模式。

实质上teamding的目的就是要把网卡绑定的功能从kernel里搬出来，把这些功能放到userspace来解决，保持kernel的简洁，让它只做kernel应该做的事情。

采用teamd端口聚合具有以下几个方面价值体现：

1. 最多支持8块网卡聚合

2. 更好的冗错性

3. 提高吞吐量

4. 具有更好的性能以及扩展性

作者单位：中国电信股份有限公司河南分公司