一、VIP 到底是什么VIP 写在 Keepalived 配置里的一个普通 IP只不过由 Keepalived 动态控制它挂在哪台服务器上。全称Virtual IP 虚拟 IP它本质上还是一个普通 IP只不过这个 IP不是长期固定属于某一台服务器而是可以在多台服务器之间漂移。在 Keepalived 架构中VIP 通常定义在/etc/keepalived/keepalived.conf的virtual_ipaddress配置块中。Keepalived 启动后会根据 VRRP 主备状态将该 IP 动态挂载到当前 MASTER 节点的网卡上当 MASTER 发生故障、BACKUP 接管后该 VIP 会从原节点移除并挂载到新的 MASTER 节点。因此VIP 本质上就是一个由 Keepalived 动态管理、可以在节点之间漂移的普通 IP 地址。VIP 在 Keepalived 中定义的一个预留 IP写上正确的/24等前缀和网卡即可默认网关继续使用服务器本身已有的网络配置不需要给 VIP 单独配置网关。例如Nginx-01192.168.10.11 Nginx-02192.168.10.12 VIP192.168.10.10应用始终访问192.168.10.10正常情况下 VIP 挂在 Nginx-01客户端 │ ▼ 192.168.10.10 VIP │ ▼ Nginx-01 192.168.10.11如果 Nginx-01 故障VIP 漂移到 Nginx-02客户端 │ ▼ 192.168.10.10 VIP │ ▼ Nginx-02 192.168.10.12客户端地址始终不变。一句话VIP 的核心作用就是给高可用集群提供一个固定不变的访问入口。二、VIP 是真的挂在服务器网卡上的VIP 虽然叫“虚拟 IP”但它不是虚构出来的。当前节点成为 MASTER 后执行ip a可能看到inet 192.168.10.12/24 inet 192.168.10.10/24 secondary其中192.168.10.12是服务器真实 IP。而192.168.10.10就是 VIP。区别只是真实 IP 一般长期固定配置VIP 通常由 Keepalived 动态添加和删除。三、Keepalived 是干什么的Keepalived官网 Keepalived快速入门https://keepalived.org/documentation/user-guide/quick-start/VIP 自己不会漂。真正负责谁是 MASTER 谁是 BACKUP VIP 当前挂在哪里 故障以后漂到哪里的是 Keepalived。Keepalived 常见配置文件/etc/keepalived/keepalived.conf核心配置类似vrrp_instance VI_1 { state BACKUP interface ens33 virtual_router_id 100 priority 100 virtual_ipaddress { 192.168.10.10/24 } }这里virtual_ipaddress { 192.168.10.10/24 }就是定义 VIP。Keepalived 启动以后通过 VRRP 维护主备状态Keepalived │ ▼ 判断 MASTER / BACKUP │ ▼ MASTER 持有 VIPMASTER 故障后BACKUP ↓ 成为 MASTER ↓ 接管 VIP所以可以简单记Keepalived 管 VIPVRRP 管主备。四、为什么一台 Nginx 一般不需要 VIP如果只有Nginx-01 192.168.10.11客户端直接访问192.168.10.11就可以。即使给它增加VIP192.168.10.10也没有真正解决高可用问题。因为Nginx-01 挂了 ↓ 没有第二台服务器 ↓ VIP 没地方漂所以单台 Nginx 一般直接使用真实 IP。五、两台 Nginx 为什么要考虑 Keepalived例如Nginx-01192.168.10.11 Nginx-02192.168.10.12如果应用直接连接192.168.10.11那么即使.12正常.11 故障 ↓ 应用依然访问 .11 ↓ 业务中断也就是说两台 Nginx 只是有了两个服务节点并不自动等于高可用。这时候就需要解决客户端到底访问谁最经典的办法就是Keepalived VIP架构变成客户端 │ ▼ VIP 192.168.10.10 │ Keepalived / \ / \ Nginx-01 Nginx-02 .11 .12应用只认192.168.10.10这样才真正解决了入口切换问题。六、两台 Nginx 是不是主备准确来说Nginx 本身不一定存在严格的主备关系。两台 Nginx 都可以正常启动 配置一样 独立处理请求真正的MASTER BACKUP通常是 Keepalived / VRRP 的角色。例如Nginx-01 Nginx 正常 Keepalived MASTER Nginx-02 Nginx 正常 Keepalived BACKUP所以更准确地说两台 Nginx 是两个可用服务节点在单 VIP Keepalived 架构下它们在“访问入口层面”表现为主备。七、Nginx 自己不能完成 VIP 高可用吗普通 Nginx 自身主要负责HTTP / HTTPS 反向代理 请求转发 负载均衡它并不负责两台服务器主备选举 VIP 挂载 VIP 删除 VRRP Gratuitous ARP所以两台 Nginx并不会自动变成一台挂了 客户端自动访问另一台这就是为什么要增加 Keepalived。一句话Nginx 管流量Keepalived 管入口。如果前面已经有硬件负载均衡、云 LB、LVS 等统一入口那么当然也可以不用 Keepalived。所以不是两个 Nginx 必须 Keepalived而是多个 Nginx 做高可用时必须考虑“统一入口如何高可用”Keepalived VIP 是最经典的一种实现。八、以 TDengine 架构为例理解 VIP假设一套 TDengine 环境Nginx-0110.10.10.11 Nginx-0210.10.10.12 VIP10.10.10.10 TDengine-0110.10.10.21 TDengine-0210.10.10.22 TDengine-0310.10.10.23整体架构用户 / 应用 │ ▼ VIP10.10.10.10 │ Keepalived │ ┌──────────┴──────────┐ │ │ Nginx-01 Nginx-02 10.10.10.11 10.10.10.12 │ │ └──────────┬──────────┘ │ Nginx 反向代理 │ ┌──────────────┼──────────────┐ │ │ │ TDengine-01 TDengine-02 TDengine-03 10.10.10.21 10.10.10.22 10.10.10.23这里有两层高可用思想。第一层Keepalived VIP解决当前请求应该进入哪台 Nginx。第二层Nginx解决请求进入之后应该转发到哪个 TDengine 后端节点。所以Keepalived 负责入口 Nginx 负责转发两者职责完全不同。九、故障切换到底发生了什么正常情况下VIP ↓ Nginx-01当 Nginx-01 或其服务异常Keepalived检测异常 ↓ Nginx-02成为MASTER ↓ VIP挂到Nginx-02网卡 ↓ 发送Gratuitous ARP ↓ 网络更新ARP ↓ 客户端继续访问原VIP所以用户仍然访问10.10.10.10不需要改成10.10.10.12这就是所谓客户端无感切换。十、MySQL 双向复制能不能使用 VIP可以但要把职责分清。应用 │ │ 3306 ▼ VIP192.168.20.10 │ Keepalived 管理 / \ / \ MySQL-01 ⇅ MySQL-02 192.168.20.11 双向复制 192.168.20.12假设MySQL-0110.20.20.11 MySQL-0210.20.20.12 VIP10.20.20.10两台 MySQL 做双向复制MySQL-01 ⇄ MySQL-02应用可以统一访问10.20.20.10:3306例如应用 │ ▼ VIP 10.20.20.10 │ Keepalived / \ / \ MySQL-01 ⇄ MySQL-02正常VIP → MySQL-01MySQL-01 故障后VIP → MySQL-02从连接入口高可用角度这是可行的。十一、MySQL 这里需要两个 Nginx 吗不需要。这一点非常重要。MySQL 是 TCP 数据库服务3306没有必要为了使用 VIP先经过Nginx-01 Nginx-02最简单的模式甚至可以直接应用 │ ▼ VIP │ ┌───────┴───────┐ │ │ MySQL-01 ⇄ MySQL-02Keepalived 可以直接部署在两台 MySQL 节点上让 VIP 跟随当前提供写服务的节点。如果数据库架构复杂也可以增加ProxySQL HAProxy MySQL Router这类数据库代理。十二、MySQL 双向复制 VIP 就等于数据库高可用吗不能简单画等号。即使双向复制正常还必须考虑一个核心问题同一时刻到底由哪台数据库对外提供写服务因为 Keepalived 解决的是应用连接到谁而 MySQL 复制解决的是数据如何同步两者不是一回事。比较稳妥的思路是MySQL-01 ⇄ MySQL-02 双向复制 但业务层面 同一时刻只有一个主要写入口例如应用 │ ▼ VIP │ ▼ MySQL-01 当前写库 │ ⇅ MySQL-02 同步节点主节点故障以后确认 MySQL-02 数据状态正常 ↓ MySQL-02 接管写角色 ↓ VIP 漂移到 MySQL-02这才是比较完整的思路。十三、为什么不能只看“复制正常”因为即使复制正常也可能发生两边同时写 主键冲突 数据冲突 复制报错 脑裂尤其双主双写架构更需要谨慎。所以数据库高可用实际上包含数据同步 角色切换 入口切换Keepalived VIP 只解决入口切换而不是全部。十四、以后看到高可用架构先问这几个问题以后不管看到Nginx MySQL PostgreSQL Redis HAProxy TDengine先问有几个节点客户端连接哪个地址当前节点挂了以后客户端是否需要改地址谁负责判断故障谁负责切换访问入口新节点是否真的有能力接管服务如果答案是Keepalived VIP那么它解决的主要就是入口高可用。十五、最终记住这几句话VIP一个可以在多个节点之间漂移的 IP 地址。Keepalived负责判断主备并管理 VIP 漂移。Nginx负责处理和转发流量本身不负责 VIP 主备漂移。单 Nginx应用 → Nginx真实IP通常即可。双 Nginx要考虑统一入口如何高可用经典方案Keepalived VIPMySQL可以MySQL复制 Keepalived VIP实现入口自动切换。但还必须保证数据同步正常 角色明确 避免双写冲突 新节点具备接管资格总结VIP 真正解决的问题其实非常简单服务器会切换 但是客户端连接地址不能跟着天天改所以需要一个稳定入口VIP再由 Keepalived 决定这个 VIP 当前应该挂在哪个节点最终可以压缩成一句话节点会变入口不变Keepalived 负责让 VIP 跟着当前可用节点走。而理解高可用架构时也一定要把两件事分开后端服务是否高可用是一层客户端访问入口是否高可用是另一层。把这两层分清以后再看 Nginx、TDengine、MySQL、PostgreSQL 等各种高可用架构思路就会清楚很多。