双机热备集群配置
场景概述
如需1台主引擎与多台辅助引擎共同处理业务，请参考一主多辅XDP集群配置。两种模式的成员作用、接口要求和切主方式不同，应先确定目标模式再规划网络。
管理节点 HA 保护 Web 管理和配置入口；转发引擎 HA 保护业务流量入口。本章介绍两台转发引擎组成主备流量组，通过业务浮动 IP（VIP）提供服务。管理节点的 VIP 不应直接当作业务 VIP 使用。
| 类型 | 保护对象 | 对应文档 |
|---|---|---|
| 管理节点 HA | 管理平台、配置管理 | 部署高可用双管理节点 |
| 转发引擎 HA | 业务监听地址和流量转发 | 本章 |
主备切换后，客户端仍访问同一个业务 VIP，但已有 TCP 连接、TLS 会话和应用登录状态不一定保留。不能由“VIP 切换成功”推断业务完全无感知，应分别验证新请求和已有长连接。
整体流程
- 将两台转发引擎加入同一转发引擎集群。
- 核对两台引擎的业务接口、本地 IP、路由和心跳连通性。
- 创建主备流量组，规划 VRRP ID，选择并排列转发引擎。
- 创建浮动 IP，关联刚创建的流量组，核对每台引擎对应的接口。
- 创建对象类型为“流量组”的虚拟服务，监听该组的浮动 IP。
- 保存并执行必要的配置变更，验证访问、切换和恢复。
流量组中选择引擎，浮动 IP 中选择流量组，虚拟服务再选择流量组及其浮动 IP。只创建流量组不会自动生成业务 VIP 或虚拟服务。
第一步：配置转发引擎集群
进入【平台系统 → 基础设施 → 转发引擎集群】，将两台状态正常的引擎加入同一集群，并核对所选集群网络策略是否适合实际网络。
两台引擎均需具备到客户端和后端的网络路径。只有当前主引擎能访问后端时，即使 VIP 切换成功，业务仍可能失败。
第二步：配置本地 IP
以下为同一业务网段的示例，部署时替换成实际分配的地址：
| 对象 | 示例地址 | 用途 |
|---|---|---|
| engine-A 业务接口 | 192.0.2.11/24 | A 的本地地址 |
| engine-B 业务接口 | 192.0.2.12/24 | B 的本地地址 |
| 流量组浮动 IP | 192.0.2.100/24 | 客户端访问的业务 VIP |
在每台引擎的设备页面中核对接口及本地 IP。使用 VLAN 或 Bond 时先配置并验证对应接口；接口列表未显示实际的 ethX/Y 等接口时，先执行页面的接口刷新，再核对名称，不要凭旧列表绑定。
本例两端业务接口位于同一网段，VIP 未被其他主机占用。不要把 VIP 同时手工配置为两台引擎的普通本地 IP。详细步骤见网络地址与路由管理。
第三步：创建主备流量组
入口：【平台系统 → 基础设施 → 流量组管理 → 流量组】→ 新增。
| 配置项 | 设置与核对 |
|---|---|
| 转发引擎集群 | 选择前面创建的集群 |
| 类型 | 选择“主备流量组” |
| vrrp id | 页面支持 1–255 及范围输入；按网络规划分配，避免与同一二层网络内其他 VRRP 实例冲突，包括管理 HA 使用的 ID |
| 是否单播 | 按网络是否允许组播选择；开启单播后仍需确认双向心跳连通 |
| 转发引擎及排序 | 将两台引擎移到已选列表；靠前的引擎优先成为主引擎 |
VRRP ID 应按实际网络规划分配，不要直接照抄示例值。浮动 IP 需要在单独的配置页面中创建。
在云环境中，允许单播心跳并不等于云网络允许 VIP 漂移；还需按网络条件核对地址绑定、反欺骗和路由。此指南的双机业务验证不能替代特定云环境的网络验证。
第四步：创建浮动 IP（VIP）
入口：【平台系统 → 基础设施 → 流量组管理 → 浮动 IP】→ 新增。
- 选择相同的转发引擎集群。
- 填写业务 VIP 与子网掩码。
- 选择第三步创建的流量组，检查页面列出的两台引擎及其接口。
- 按需开启“是否开启”，保存，并处理页面提示的配置变更。
选择集群和流量组后，再核对实际出现的接口信息；不能仅因输入框保存成功就认为两台引擎已能承载该地址。字段说明见浮动 IP 手册。
第五步：创建虚拟服务（使用流量组）
进入【负载流量管理 → 虚拟服务】，对象类型选择“流量组”，选择第三步的流量组，再选择其业务浮动 IP 和监听端口。配置协议、服务器池、分发规则及必要策略后，保存并执行变更。
若使用指定 SNAT 地址池，应使地址池与虚拟服务引用同一流量组，且两台引擎的后端回程都可用。参见SNAT 与后端回程配置。
从业务客户端访问实际的 VIP、端口和业务路径。HTTPS 应使用对应的域名、SNI 和可信证书验证；ping 只能辅助判断网络可达性，不能代替业务请求。
第六步：运维操作
查看流量组状态
在流量组列表查看当前主引擎，并核对浮动 IP 的启用状态、接口归属和业务访问。配置的引擎顺序表达优先关系，列表中的实际主角色还受引擎健康状态影响。
主动主备切换
在维护窗口内记录当前主引擎、VIP 归属及业务基线，然后使用流量组列表的“主转发引擎切换按钮”。切换后检查：
| 检查层面 | 如何验证 |
|---|---|
| 页面状态 | 当前主引擎是否切换到目标设备；刷新后状态是否稳定 |
| 地址与网络 | VIP 是否由目标引擎承载，客户端邻居项或 ARP 是否更新 |
| 新请求 | 使用同一个 VIP、端口、路径，核对响应、后端节点和错误率 |
| 已有连接 | 单独观察持续连接是否重连、超时或中断 |
| 恢复 | 按计划恢复主角色，再重复上述检查 |
已有回归覆盖了页面切换、VIP/ARP 归属和恢复检查；业务是否无中断仍取决于具体协议、连接及应用状态。会话保持的边界见会话保持指南。
被动切换与恢复
引擎故障、心跳路径异常或受监测的转发服务异常可能触发切换。检测耗时与网络收敛会影响业务恢复时间，不将固定秒数当成承诺。
当前主备配置采用可抢占机制。故障引擎恢复后，应按当时的引擎排序和配置核对最终主角色；主动切换会影响优先关系，不应始终假定最初的 A 会自动变回主引擎。页面没有单独的“不抢占”设置时，不应按其他 VRRP 产品的字段套用。
升级版本时的操作顺序
先确认版本兼容性、升级及回退要求，参见升级指南。
- 确认当前主引擎正常，保留配置备份与业务验证基线。
- 升级备用引擎，等待设备、接口、配置和后端连通恢复。
- 切换到已升级的引擎，验证 VIP、业务请求和已有连接的影响。
- 验证通过后升级另一台；出现异常先按回退方案处理。
- 两台均恢复后，确认版本与最终主备关系符合计划。
双机可降低维护影响，但不能保证所有业务连接在升级过程中保持不中断。
日常巡检要点
| 检查项 | 关注内容 |
|---|---|
| 主备角色 | 页面状态、引擎顺序及实际 VIP 归属是否一致 |
| 业务访问 | 正确域名、协议、VIP、端口和路径是否可用 |
| 网络 | 两端心跳、业务接口、后端路由和回程是否正常 |
| 容量与版本 | 备用引擎能否独立承载业务，版本是否兼容 |
| 切换记录 | 操作时间、角色变化、错误窗口及恢复时间 |
更多字段与操作见流量组手册。