Ubuntu 22.04网卡绑定实战：使用Netplan配置balance-rr模式实现高可用与负载均衡

单线网络总是让人提心吊胆，一旦断网，关键业务就可能中断。为了提高网络可靠性，我们通常会在网络设备上配置链路聚合（Link Aggregation）。

而在服务器层面，我们也有对应的技术——网卡绑定（bonding）。它通过将两个或多个物理网卡绑定成一个虚拟的逻辑接口，来实现网络接口的聚合。

配置网卡绑定后，可以显著提升网络冗余，实现高可用性。当其中一块网卡发生故障时，流量能无缝切换到其他正常工作的网卡上，确保网络连接不中断。此外，结合不同的工作模式，它还能实现负载分担或增加有效带宽，在优化资源利用率的同时提升网络容量。是时候为你的服务器网络增加一道保险了！

之前，我们演示过在CentOS 7.9上配置网卡绑定，也介绍过Windows Server的NIC组合配置。今天，我们将目光转向Ubuntu，通过一个简单的实战案例，手把手教你如何使用Netplan配置网卡绑定。

本次实验环境为两台Ubuntu 22.04.3 LTS服务器，内核版本为6.5.0-44-generic。

两台服务器的两对网卡直接互联：ens7接ens7，ens8接ens8。

网卡绑定的七种模式

在配置之前，我们先快速回顾一下网卡绑定的七种工作模式，它们通过mode参数来指定：

1. mode=0 (balance-rr)：轮询均衡策略。数据包在所有从属（slave）接口间轮询发送，实现负载均衡，但不保证连续性。
2. mode=1 (active-backup)：主备模式。仅一个网卡处于活动状态，另一个作为备份。活动网卡故障时，备份网卡立即接管。
3. mode=2 (balance-xor)：XOR哈希策略。基于源和目标MAC地址的哈希值选择发送接口，也可实现负载均衡。
4. mode=3 (broadcast)：广播模式。所有流量同时通过所有从属接口发送，用于特殊的数据复制场景。
5. mode=4 (802.3ad)：IEEE 802.3ad动态链路聚合。需要交换机支持LACP协议，可动态增减链路，常用于增加带宽和高可用。
6. mode=5 (balance-tlb)：传输层感知负载均衡。无需特殊交换机支持，但仅在出站（服务器到客户端）方向做负载均衡。
7. mode=6 (balance-alb)：自适应负载均衡。balance-tlb的增强版，增加了基于ARP的接收负载均衡功能。

通常，服务器与支持LACP的交换机对接时，我们会选择mode=4。而在服务器直接互联的场景下，mode=0的轮询负载模式则是一个简单有效的选择。因此，本次我们将使用Netplan配置balance-rr（即mode=0）模式的网卡聚合。

实战配置步骤

首先，在两台服务器上创建Netplan配置文件 /etc/netplan/99-bond.yaml。请注意：若系统默认使用NetworkManager管理网络，则需在配置中指定 renderer: NetworkManager 或留空以继承默认设置。切勿强制指定 renderer: networkd，除非你确认并已启用 systemd-networkd 服务，否则可能导致网络管理混乱，连接断开。

服务器 171 的配置文件如下：

nano /etc/netplan/99-bond.yaml

network:
  version: 2
  renderer: NetworkManager
  bonds:
    bond0:
      dhcp4: no
      addresses:
        - 172.16.1.171/24
      interfaces:
        - ens7
        - ens8
      parameters:
        mode: balance-rr
        mii-monitor-interval: 100
  ethernets:
    ens7:
      dhcp4: no
      optional: true
    ens8:
      dhcp4: no
      optional: true

服务器 172 的配置文件如下：

network:
  version: 2
  renderer: NetworkManager
  bonds:
    bond0:
      dhcp4: no
      addresses:
        - 172.16.1.172/24
      interfaces:
        - ens7
        - ens8
      parameters:
        mode: balance-rr
        mii-monitor-interval: 100
  ethernets:
    ens7:
      dhcp4: no
      optional: true
    ens8:
      dhcp4: no
      optional: true

配置文件编辑完成后，在两台服务器上执行以下命令以应用配置：

chmod 600 /etc/netplan/99-bond.yaml
netplan apply

验证配置

应用配置后，除了使用 ip address show bond0 命令查看bond接口的状态外，我们还可以通过查看 /proc 文件系统中的信息来确认绑定模式及从属接口的状态：

cat /proc/net/bonding/bond0

接下来，测试两台服务器之间bond接口的连通性。

高可用性与负载测试

理论配置完成，实际效果如何？我们通过iperf3进行打流测试，并在测试过程中模拟故障——直接断开 ens7 的互联网线。

从打流结果可以看到，在断开一条物理链路时，总带宽虽然有所波动，但网络连接并未中断，业务流量通过剩余的 ens8 链路继续传输。

由于测试环境基于虚拟化平台，底层链路删除后操作系统感知到的接口状态可能没有立即变化，但从带宽曲线的瞬时抖动，我们依然可以清晰地看到链路切换的发生。

总结

通过这次动手实践，我们验证了在Ubuntu 22.04上使用Netplan配置网卡绑定的可行性与价值。对于承载关键流量的服务器、数据库服务器间的直连网络等场景，花费少量时间配置Bonding，就能为网络稳定性加上一道坚实的“安全锁”，这无疑是运维工作中性价比极高的投入。

你的生产环境中是否也存在重要的单线网络需要加固？不妨参照本文的步骤动手试一试。如果在配置过程中遇到问题，或者有更佳实践，欢迎在云栈社区与大家交流分享。