3. 多活网络架构设计原则
在 EVPN 多活网络工程中，架构设计的第一步不是选协议，而是先回答四个问题：业务需要多高的可用性、故障时允许多大范围的流量中断、冗余资源如何摆放、以及用什么指标验收。多活与主备的选择、流量模型的推演、故障域的划分、冗余设计原则和 SLA 目标定义，共同决定了后续 VTEP、ES、DF 等具体机制的落地方式。本节围绕这五个设计维度展开，并给出可直接用于方案评审的判断依据。
一、多活与主备模式的本质差异
主备模式（Active-Standby）下，同一业务网段在同一时刻只有一台设备（或一条路径）承载转发，备用设备处于待命状态，依赖 VRRP、BFD 或路由收敛完成切换。多活模式（Active-Active）下，两台或多台设备同时参与转发，通过 EVPN 的 ES（Ethernet Segment）与 DF（Designated Forwarder）选举机制协调 BUM 流量，单播流量则由所有成员共同分担。
两者的关键差异不在“是否冗余”，而在“冗余资源是否参与转发”。主备的备用资源平时闲置，切换时存在收敛窗口，典型中断在秒级；多活资源平时即分担流量，单点故障时剩余成员立即接管，中断可压缩到毫秒级，但代价是控制面复杂度上升、DF 选举与别名（Aliasing）机制必须正确配置，否则会出现 BUM 重复或黑洞。
二、流量模型分析
设计前必须量化三类流量：南北向（数据中心到外部）、东西向（服务器之间）、以及 BUM 流量。以典型双活数据中心为例，假设每台 Leaf 下挂 20 台服务器，每台服务器平均产生 2Gbps 东西向流量、0.5Gbps 南北向流量，则单 Leaf 东西向负载约 40Gbps、南北向约 10Gbps。若采用 2 台 Leaf 组成多活 ES，每台需具备至少 50Gbps 有效转发能力，并预留 30% 突发余量，即上行链路建议按 2×40Gbps 或 4×25Gbps 设计。
BUM 流量需要单独估算。VXLAN 环境下，ARP 广播、ND 组播和未知单播会被复制到同一 BD 内所有 VTEP。若一个 BD 内有 50 台 VTEP，单次 ARP 请求的复制份数即为 50。多活场景下，DF 选举确保只有 DF 转发 BUM，非 DF 丢弃，从而避免重复。因此流量模型必须包含“BD 内 VTEP 数量 × BUM 速率”这一项，否则容易低估核心层压力。
三、故障域划分
故障域划分的目标是：任一单点故障不得导致业务整体不可用。常见划分层级如下：
- 链路级：单条物理链路或单成员链路故障，由 LACP 或 ECMP 自动收敛，影响范围限于该链路承载的流量。
- 设备级：单台 Leaf 或 Spine 故障，多活 ES 中剩余成员接管，需验证 DF 重新选举时间。
- 机架级：整机架断电或上联中断，要求服务器双归到不同机架的 Leaf，且两个 Leaf 属于同一 ES。
- 机房级：单数据中心整体故障，依赖 DCI 与远端 VTEP 的冗余路径，需确认远端 BD 与 RT 导入策略一致。
划分完成后，应逐一列出“故障对象—影响业务—预期恢复时间—验证方式”，形成故障域清单。例如：Leaf-01 故障，影响其下挂 20 台服务器的本地接入，预期 200ms 内由 Leaf-02 接管，验证方式为持续 ping 加 BFD 会话状态检查。
四、冗余设计原则
冗余设计遵循四条原则：第一，路径冗余，任意两台设备之间至少存在两条物理分离路径，且不共享同一光缆或同一电源；第二，设备冗余，关键角色（Spine、Border、DF）至少 N+1，多活 ES 成员建议 2 台起步、不超过 4 台以避免 DF 选举震荡；第三，协议冗余，控制面使用 BGP EVPN 多路径，数据面使用 ESI 多活，避免单协议失效导致整体不可用；第四，配置冗余，ES 配置、RT、RD 在成员间保持一致，建议通过自动化模板下发，减少人工差异。
五、SLA 与可用性目标定义
SLA 必须可量化、可验证。常用指标包括：可用性百分比、RTO（恢复时间目标）、RPO（恢复点目标，主要针对有状态业务）、以及丢包率与抖动上限。可用性与年中断时间的换算关系为：99.9% 对应年中断约 8.76 小时，99.99% 对应约 52.6 分钟，99.999% 对应约 5.26 分钟。
以某金融类业务为例，定义 SLA 如下：可用性 99.99%，RTO ≤ 500ms，RPO = 0（无状态转发），单次故障丢包 ≤ 3 个报文。对应的设计约束为：多活 ES + BFD 检测间隔 50ms×3 次、DF 选举收敛 ≤ 200ms、上行 ECMP 成员 ≥ 2。验收时通过持续打流工具记录切换期间的丢包数与中断时长，若实测 RTO 超过 500ms，则需回查 BFD 参数或 DF 选举配置。
六、设计落地检查表
将上述原则转化为可执行的检查项，便于方案评审时逐条确认：
| 检查项 | 判断依据 | 示例值 |
|---|---|---|
| 模式选择 | RTO 与链路利用率是否满足业务 | 多活，RTO ≤ 500ms |
| 流量容量 | 东西向 + 南北向 + BUM 是否留有余量 | 单 Leaf ≥ 50Gbps，余量 30% |
| 故障域覆盖 | 链路/设备/机架/机房四级是否均有冗余 | 服务器双归不同机架 Leaf |
| ES 成员数 | 是否在 2～4 台合理区间 | 2 台 Leaf 组成 ES |
| BFD 参数 | 检测间隔 × 次数是否匹配 RTO | 50ms × 3 = 150ms |
| SLA 验收 | 是否有可复现的测试方法与记录 | 持续打流，记录丢包与中断时长 |
需要强调的是，多活架构的收益并非自动获得。若 DF 选举配置错误、ES 成员间 RT 不一致、或 BFD 参数与 RTO 不匹配，多活反而可能引入 BUM 重复、流量黑洞或切换抖动。因此，设计阶段必须把“模式—流量—故障域—冗余—SLA”作为一个整体闭环来推演，并在实施后用真实打流数据回验每一项指标，而不是仅凭配置下发成功就判定架构可用。