在linux环境中构建可靠的网络服务需通过网络接口绑定和keepalived实现故障转移。1. 网络接口绑定（bonding/teaming）用于物理链路层冗余，常用模式包括active-backup（保障故障切换）、balance-rr（轮询负载均衡）和802.3ad（lacp标准，支持负载均衡与容错）。2. keepalived基于vrrp协议管理虚拟ip漂移，主节点持有vip并发送心跳，故障时备份节点接管，配置中需定义vrrp_instance、优先级、认证及健康检查脚本，以确保服务连续性。
在Linux环境中构建一个真正可靠的网络服务，核心在于实现网络故障转移。说白了，就是让你的服务在某条网线断了、网卡挂了，甚至整个服务器都歇菜了的情况下，依然能保持在线。这通常通过网络接口绑定（bonding或teaming）来处理物理链路层面的冗余，再结合Keepalived这类高可用软件来管理虚拟IP（VIP）的漂移，从而确保服务持续可用。
要实现Linux网络的高可用故障转移，我们通常会组合使用几个关键技术：网络接口绑定（Bonding/Teaming）和Keepalived。
网络接口绑定（Bonding/Teaming）是解决物理链路层故障的利器。它能将多块物理网卡虚拟成一个逻辑网卡，当其中一块网卡或连接的交换机端口出现问题时，流量会自动切换到其他正常工作的网卡上。对于故障转移，我个人最常用的是active-backup模式（mode=1），因为它简单直接，一块网卡活跃，其他作为备份，故障时立即接管。配置起来，无论是使用nmcli还是直接修改网络配置文件都行。
例如，使用nmcli创建一个名为bond0的active-backup模式绑定，并添加eth0和eth1作为成员：
nmcli connection add type bond con-name bond0 ifname bond0 mode active-backup ip4 192.168.1.10/24 gw 192.168.1.1 nmcli connection add type ethernet con-name eth0-slave ifname eth0 master bond0 nmcli connection add type ethernet con-name eth1-slave ifname eth1 master bond0 nmcli connection up bond0
这基本上就搞定了物理层面的冗余。
但光有物理冗余还不够，如果整个服务器挂了怎么办？这时就需要Keepalived出马了。Keepalived通过VRRP协议实现IP地址的自动漂移。它会在多台服务器之间选举出一个主节点（MASTER），主节点持有虚拟IP（VIP），当主节点出现故障时，备份节点（BACKUP）会迅速接管VIP，从而保证服务对外提供的IP地址始终可用。
Keepalived的配置核心在于vrrp_instance，你需要定义一个虚拟路由实例，指定虚拟IP、优先级、预留模式以及最重要的——健康检查脚本。这个脚本能帮你判断服务是否真的“活”着，比如Nginx进程还在不在，数据库端口是否监听等。
为什么需要Linux网络故障转移？
说实话，在当今这个“永远在线”的时代，任何一点服务中断都可能带来巨大的损失，无论是用户流失、业务停摆还是品牌信誉受损。在我看来，网络故障转移不是一个“锦上添花”的功能，而是构建任何稳定服务的基础。想想看，一块网卡突然“罢工”，或者交换机端口意外损坏，甚至更常见的是，一根网线被不小心踢松了，这些看似微小的意外，都可能让你的整个服务瞬间瘫痪。
我记得有一次，一个核心业务系统因为单点网卡故障，导致了长达半小时的服务中断，那次事件的后续处理成本远超提前做好冗余的投入。所以，我们谈论网络故障转移，实际上是在为业务的连续性买保险。它能有效应对各种物理层面的单点故障，比如网卡损坏、线缆断裂、交换机端口失效，甚至是服务器本身的硬件问题。通过提前规划和部署，当这些不可避免的意外发生时，系统能够自动、快速地将流量切换到健康的路径或服务器上，最大限度地减少服务中断时间，保障业务的正常运行。这不仅仅是技术上的考量，更是对业务稳定性和用户体验的承诺。
Linux网络接口绑定（Bonding/Teaming）有哪些常用模式？
Linux网络接口绑定（Bonding）或者说Teaming，是实现物理网络冗余的基石。它能把多块物理网卡“捆绑”成一块逻辑网卡，对外只呈现一个接口，但内部却有了多条通路。至于模式，常见的有好几种，每种都有它适用的场景。
Mode 1 (Active-Backup): 这是我个人在做纯粹的故障转移时最偏爱的模式。它的原理很简单：只有一块网卡是活跃的，负责所有流量，而其他网卡则处于待命状态。一旦活跃网卡出现问题，系统会立即将流量切换到下一个可用的备份网卡上。这种模式配置简单，理解起来也直观，而且不需要特殊的交换机配置（除非你希望有更复杂的链路聚合）。它的优点是可靠性高，但缺点是带宽没有叠加，因为一次只有一个链路在工作。不过，对于我们追求的“故障转移”目标，它简直是完美的选择。
Mode 0 (Balance-rr - Round Robin): 这种模式会将流量在所有可用的网卡上轮流发送，实现负载均衡。虽然能提升带宽，但它对数据包的顺序没有保证，在某些应用场景下可能会导致问题。而且，它通常需要交换机支持链路聚合（LACP）。
Mode 4 (802.3ad - LACP): 这是业界标准，也是我遇到需要同时实现负载均衡和故障转移时会考虑的模式。它需要交换机也配置LACP，通过协商来管理多个链路。这种模式不仅能提供更高的聚合带宽，还能在链路故障时自动切换。但相对来说，配置会比
active-backup复杂一些，需要网络团队的配合。
总的来说，如果你仅仅是想实现网络链路的故障转移，确保服务不中断，那么active-backup模式就是最省心、最有效的选择。
如何使用Keepalived实现IP地址高可用？
当物理网卡通过Bonding解决了链路层面的故障后，我们还需要一个机制来应对整个服务器宕机的情况，或者更细致一点，某个关键服务（比如Nginx、MySQL）崩溃了，但服务器本身还在运行。这时，Keepalived就派上用场了，它主要负责虚拟IP（VIP）的自动漂移，确保对外服务的IP地址始终指向一个健康的节点。
Keepalived的核心是VRRP（Virtual Router Redundancy Protocol）协议。它通过在多台服务器之间发送心跳包来判断彼此的健康状况，并选举出一个主节点（MASTER），其他节点作为备份（BACKUP）。主节点会持有VIP，对外提供服务。一旦主节点的心跳停止，或者健康检查脚本判断主节点上的服务不健康，备份节点就会提升为MASTER，并接管VIP，从而实现服务的无缝切换。
一个典型的Keepalived配置大致是这样的：
假设我们有两台服务器，node1（MASTER）和node2（BACKUP），共享一个VIP 192.168.1.100。
node1上的/etc/keepalived/keepalived.conf：
vrrp_instance VI_1 {
state MASTER # 这台是主节点
interface bond0 # 监听的网卡，这里就是我们之前配置的bond0
virtual_router_id 51 # VRRP实例ID，同一组机器必须一致
priority 100 # 优先级，MASTER要比BACKUP高
advert_int 1 # 心跳间隔，秒
authentication {
auth_type PASS
auth_pass your_password_here # 认证密码，确保安全
}
virtual_ipaddress {
192.168.1.100/24 dev bond0 label bond0:0 # 虚拟IP地址，注意dev和label
}
track_script {
chk_nginx # 关联一个健康检查脚本
}
}
# 健康检查脚本定义
vrrp_script chk_nginx {
script "/usr/local/bin/check_nginx.sh" # 你的脚本路径
interval 2 # 每2秒执行一次
weight -20 # 如果脚本失败，优先级降低20
fall 2 # 连续失败2次才算不健康
rise 1 # 恢复1次就算健康
}node2上的/etc/keepalived/keepalived.conf：
（基本同上，但state为BACKUP，priority要低于MASTER，比如90）
vrrp_instance VI_1 {
state BACKUP # 这台是备份节点
interface bond0
virtual_router_id 51
priority 90 # 优先级低于MASTER
advert_int 1
authentication {
auth_type PASS
auth_pass your_password_here
}
virtual_ipaddress {
192 
