一主多辅 XDP 集群配置
场景与工作方式
一主多辅流量组由 **1 台主引擎（Primary）和 1 至 3 台辅助引擎（Secondary）**组成，共 2 至 4 台。客户端访问统一的业务浮动 IP（VIP），主引擎通过 XDP 将流量分配到组内成员处理。主引擎自身也可能处理业务，并非只负责分流；辅助引擎也承载业务，各成员都需要具备可用的后端回程。
| 模式 | 业务入口与成员作用 | 配置重点 |
|---|---|---|
| 主备 | 当前主引擎承载业务，备引擎准备接管 | 两台引擎、VRRP ID 与心跳网络 |
| ECMP 主主 | 上游路由设备将流量分配到多台引擎 | 上游 ECMP 及动态路由配置 |
| 一主多辅 XDP | 主引擎接收入口流量，组内成员共同处理业务 | 同一业务二层网络、XDP 支持及成员顺序 |
主引擎与辅助引擎的角色不等于服务器池中的主、备节点。本章配置的是转发引擎之间的协作；服务器池与分发策略仍按业务需要单独配置。
第一步：准备成员与业务网络
先将全部成员纳入同一个转发引擎集群，确认引擎在线，并准备客户端可访问、各成员互通的业务网络。每台引擎都需要独立的本地业务地址，VIP 必须是该业务网络中未被占用的另一个地址。
下面展示四成员示例。地址、接口名称和引擎名称仅用于说明，应替换为现场规划。
| 角色与截图中的引擎 | 本地业务地址 | 业务逻辑接口 |
|---|---|---|
初始主：engine10.1.9.150 | 10.1.137.150/24 | 137 |
辅助：engine10.1.9.151 | 10.1.137.151/24 | 137 |
辅助：xdp-9160 | 10.1.137.160/24 | 137 |
辅助：xdp-9161 | 10.1.137.161/24 | 137 |
| 客户端 | 10.1.137.8/24 | 接入同一业务网络 |
| 业务 VIP | 10.1.137.250/24 | 稍后关联一主多辅流量组 |
引擎名称中的管理地址用于识别设备，客户端业务访问的是 10.1.137.250。管理节点的 VIP、引擎管理地址、本地业务地址和业务 VIP 要分别规划。
接口与 VLAN 的检查
本例在每台引擎未加入 Bond 的独立物理口上创建 tagged VLAN，实际 VLAN ID 为 137，页面逻辑接口名称也设为 137。在【单台设备 → VLAN 管理】准备 VLAN，再在【本地 IP】配置各自地址；接口列表尚未更新时，先到【网络接口】刷新后再选择。
| 检查项 | 正确配置 |
|---|---|
| 跨节点接口名称 | 所有成员都有同名逻辑业务接口；各台物理口的页面名称、Linux 名称可以不同 |
| VLAN ID | 与交换机端口的 tagged 网络对应；逻辑接口叫 137 本身不能证明实际 VLAN ID 是 137 |
| 通告网桥 | 当前支持单成员网桥；该成员为指定物理口或它的一个 VLAN 子接口 |
| MAC 地址 | 每台机器内部的通告网桥、VLAN 子口与物理父口 MAC 一致；不同机器之间使用各自 MAC |
| Bond | 当前 XDP 路径仅支持 active-backup，并依赖内核与驱动支持；不要直接复用 802.3ad Bond |
| 业务与回程 | 成员之间、客户端到 VIP 所在网络均连通，各成员到后端的回程均可用 |
VLAN 符合以上条件时，页面填写 VLAN 的逻辑接口名称；系统会解析其物理或 Bond 父接口。不要将内部 VLAN 子口的系统名称填入表单。本例使用独立物理口，既有业务的 802.3ad Bond 可以保留在另一条网络上。
本地地址能 ping 通并不代表 XDP 已准备成功。例如，VLAN 网桥使用随机 MAC 而父口使用另一 MAC 时，创建 XDP VIP 会被拒绝。应由网络管理员核对并调整该业务接口配置，再重试；不要通过反复创建 VIP 绕过检查。
第二步：创建一主多辅流量组
入口：【平台系统 → 基础设施 → 流量组管理 → 流量组】→ 新增。
- 填写名称，选择全部成员所在的转发引擎集群。
- 类型选择“一主多辅流量组”。
- “接口名称”填写第一步准备的同名逻辑业务接口，本例为
137。 - 在“已选转发引擎”中放入 2 至 4 台不同引擎，首行设置为初始主引擎，后面的成员作为辅助引擎。
- 检查顺序后保存，按页面提示处理配置变更。
这张图展示流量组表单。它还没有创建业务 VIP，也没有创建虚拟服务。下图是另一个页面，用来关联该组的业务地址。
一主多辅类型不填写普通主备的 VRRP ID。创建后若要改变主引擎，应使用列表的“主转发引擎切换”，不能在“修改”表单中将另一个成员拖到首行。已有 VIP 时也不能直接修改流量组的承载接口，应先安排业务迁移及引用清理。
第三步：创建浮动 IP 并关联流量组
入口：【平台系统 → 基础设施 → 流量组管理 → 浮动 IP】→ 新增。
选择相同集群，填写业务 VIP 和掩码，本例为 10.1.137.250、24；选择第二步创建的一主多辅流量组，开启并保存。
这张图展示浮动 IP 表单。一主多辅模式通过流量组的“接口名称”确定业务接口，表单不会像普通主备模式那样列出逐台接口选择表，这是正常行为。
不要把业务 VIP 作为普通本地地址手工加到每台引擎。VIP 的配置与释放由平台管理；保存失败时先核对提示中的节点、接口、MAC、VLAN 和引擎状态，成功后再进入下一步。
第四步：创建虚拟服务并执行变更
进入【负载流量管理 → 虚拟服务】，对象类型选择“流量组”，选中第二步的组，监听地址选择第三步的 VIP，再填写业务协议、端口、服务器池和必要策略。保存后点击“配置变更”，等待变更执行完成。
关联关系为：本地业务网络 → 一主多辅流量组 → 浮动 IP → 虚拟服务。只创建流量组或 VIP 不会自动生成业务服务。HTTP 发布步骤可参考快速创建 HTTP 虚拟服务。
从客户端访问 VIP 和业务端口。本例可先检查 HTTP 返回码和内容：
curl --connect-timeout 5 http://10.1.137.250:18081/端口与路径必须替换为实际服务配置；连通 VIP 与得到预期业务响应是不同检查。同一个源 IP 的请求可能持续分配给同一成员，不能仅靠一个客户端反复访问来判断全部辅助引擎都已分担流量。
真实后端与源地址转换
首次验证建议选择 HTTP 代理，关联真实服务器池，使用能返回明确内容的后端服务。虚拟服务直接返回固定内容只能检查入口及响应，不能证明服务器池转发与后端回程正常。
在虚拟服务引用的【HTTP 策略】中核对“源地址转换”。本例验证分流时选择“接口IP地址”，后端收到连接的来源地址可用于识别实际处理请求的引擎；不要用客户端看到的 VIP 推断处理节点。
| 配置与检查 | 使用方法 |
|---|---|
| 接口IP地址 | 后端连接使用引擎接口地址；检查每个成员到后端的路由，以及后端到这些地址的回程 |
| 指定地址池或虚拟服务IP地址 | 按现场出口与回程规划选择；多个成员共用来源地址时，不能仅凭后端来源 IP 区分成员 |
| 后端记录 | 用请求标识关联客户端响应与后端访问记录，核对实际来源、响应码和内容 |
“接口IP地址”是本例便于验证的选择，并非所有 XDP 业务都必须使用它。后端连接的 TCP 来源地址与 HTTP 头部中的客户端地址也不同，应分别核对。字段说明见七层策略手册。
如何确认各成员确实承载业务
- 在业务网络上准备多个不同源 IP 的客户端，确认地址未被占用。也可由网络管理员在测试客户端临时配置已规划的地址，验证后恢复。
- 从这些源 IP 向同一个 VIP、端口和路径请求，记录各请求的唯一标识及预期响应。
- 在后端记录中按标识核对实际连接来源，或结合成员侧转发记录，确认每个辅助引擎都实际处理过请求；主引擎处理部分请求属于正常情况。
当前分流与来源 IP 有关，只改变源端口或重复刷新一个客户端，不足以证明所有成员都参与处理。少量请求不保证各成员次数相等；流量组的引擎分流与服务器池的后端负载算法是两个层次，也不要将此结果当作会话保持验证。
第五步：手动切主与确认结果
在维护窗口内，先记录当前主引擎和业务访问结果，并确认目标辅助引擎在线、接口及回程可用。
- 在流量组列表点击“主转发引擎切换”。
- 核对“当前主转发引擎”，在“切换为”中选择目标辅助引擎。
- 点击“确定”，等待当前操作完成，刷新列表核对实际主引擎；处理中不要重复发起切主。
- 保持访问同一个 VIP 和端口，核对响应码、内容和邻居更新；重要业务还需验证已有长连接、TLS 会话和应用登录状态。
本图展示从 xdp-9160 切到 xdp-9161。它属于切主操作页面，与前两张创建表单是不同步骤。切回原主时，同样选择该成员作为目标执行切主。
不能选择当前主引擎再次切主，也不能选择组外成员。若提示“手动切主功能未启用”，应由平台管理员核对部署功能配置；拖动成员顺序不能替代切主操作。短连接访问通过不能替代现场长连接与故障接管验证，自动故障切换需另行确认功能配置并安排验证。
已有连接的验证方法
切主前先建立一条持续收发的连接，在切主过程中保持它打开，记录连接是否重建、失败请求及响应内容。客户端自动重试或重新连接后请求成功，只能说明业务重新可达，不能证明原连接保留。
对于 HTTP 长连接，可连续在同一个 TCP 连接上请求，并核对客户端连接标识与后端记录。本例已验证承载该连接的辅助引擎晋升为主时，原连接仍能持续收发；这不代表整机断电、所有切换方向、TLS 会话、应用登录状态或 AI 流式请求都保证保留。重要业务需使用自己的客户端和协议单独验证。
第六步：自动接管与故障恢复
自动接管和手动切主是两项独立的部署功能。创建一主多辅组不会自动开启故障接管；实施前由平台管理员核对管理节点的 XDP HA 配置，确认自动切换已启用，且健康检测、租约和故障隔离机制可用。不能通过调整成员顺序或开启 VIP 替代自动切换配置。
先完成所有成员的网络、同步与真实业务检查，再在维护窗口验证故障接管。故障注入必须选择可独占的测试节点，确认它不承载其他流量组或直接绑定的虚拟服务，并准备恢复方法；不要在有其他业务的节点上直接停进程或断电。
主节点故障及旧主重新加入
- 记录当前主引擎、各成员状态和业务响应，启动持续请求并记录时间。
- 模拟已规划的主节点故障，等待自动接管；本例通过主节点 Agent 失联验证，不手动点击切主。
- 在故障仍存在时，核对新的实际主引擎，并确认同一 VIP 的业务已恢复。业务恢复与全部节点同步完成是两件事：不可达旧主尚未同步时，接管操作或 VIP 同步诊断仍可能为降级状态。
- 恢复旧主，等待它重新作为辅助引擎加入，并核对所有成员同步及真实业务。
- 确认新主继续担任主引擎。当前自动接管流程不会仅因旧主恢复而主动回切；需要切回时，待恢复和同步完成后按第五步手动操作。
普通 VRRP 主备的抢占行为不能套用到 XDP。接管完成也不等于所有旧连接已恢复，应分别检查新请求、已有连接和应用状态。恢复耗时受故障检测、租约、隔离与网络邻居更新等因素影响，测试验收的时间上限不能作为生产环境恢复时间承诺。
辅助节点 Agent 失联
当主节点保持健康、仅一个辅助节点的 Agent 不可达时，当前流程会记录该成员异常，不应因此切换健康主节点。先检查该成员管理网络和 Agent，恢复后等待重新同步，同时持续验证业务。
Agent 负责节点管理与同步，Agent 失联不等于转发进程已停止。本例辅助节点 Agent 故障期间业务保持可用，但不能据此推断整机断电、业务网口中断或转发引擎停止时也没有请求失败。这些故障应分别验证，不能只看节点在线状态或主引擎名称判断。
维护、删除与常见问题
下线整个流量组前，先迁移该组全部业务并停止访问，再按 删除或解除引用 VS → 执行配置变更 → 删除 VIP → 删除流量组 的顺序处理。仍被 VIP 或 VS 引用的组会拒绝删除。共享成员承载其他组时，删除一组后还要检查其他组的业务继续正常。
同组多个 VIP 的单独下线
例如同一组同时承载业务 A 的 10.1.137.250 和业务 B 的 10.1.137.251，只下线 A 时，不要执行整组删除：
- 按 VS 名称和监听地址确认目标，只删除 A 专用 VS，或从共享 VS 中解除 A 的监听引用；保留 B 的监听和业务配置。
- 执行配置变更，确认 A 已不再被引用，再删除 A 的浮动 IP。
- 保留 B 的 VIP、VS 和共同使用的流量组、服务器池及策略。持续请求 B，核对响应内容、当前主引擎及成员同步状态。
一个 VIP 下线不应触发共享组切主，也不应删除其他 VIP 的配置。只有该组所有业务引用都清理完毕后，才删除流量组；服务器池和策略也应确认没有其他引用后再清理。
如需将原 VIP 改用于普通主备，先完成上述释放，再按双机热备集群配置新建主备流量组、VIP 和 VS，并重新规划 VRRP ID。不能通过编辑直接更改流量组类型。
| 现象 | 优先检查 |
|---|---|
| 找不到逻辑接口或物理口 | 刷新各设备接口，确认同名逻辑接口在所有成员中存在；逐台检查实际父口 |
| 创建 VIP 提示通告接口 MAC 不一致 | 检查报错节点内部网桥、VLAN 子口与父口的 MAC 是否一致 |
| VLAN 能连通但 XDP 准备失败 | 检查单成员拓扑、实际 VLAN ID、Bond 模式及部署的 XDP/内核能力 |
| 创建成功但客户端无法访问 | 是否已有 VS、选对流量组与 VIP、执行配置变更，以及所有成员的回程是否可用 |
| 一个客户端反复访问只命中同一成员 | 改用多个不同源 IP，结合真实后端来源或成员转发记录验证；只改变源端口不足以证明分流 |
| 已切到新主，但仍显示降级或同步异常 | 区分业务恢复与全节点同步；检查仍不可达的成员，恢复后再确认诊断消除 |
| 旧主恢复后没有自动切回 | XDP 自动接管不因旧主恢复主动回切；同步完成后按需手动切主 |
| 辅节点 Agent 异常，主引擎未变化 | 主节点健康时不应仅因辅节点 Agent 失联切主；检查故障节点管理链路与 Agent，并验证实际业务 |
| 修改表单不能更改首行主引擎 | 使用流量组列表的“主转发引擎切换”选择目标辅助引擎 |
| 删除流量组被拒绝 | 先处理引用它的 VS 和 VIP，再删除组 |