数据中心容灾与双活
把容灾从纸面指标变成「真能切、切得快、切得回」的能力。本技能给出从 RTO/RPO 定义、两地三中心架构选型、数据复制方式、脑裂防范、切换机制到演练验证的完整可执行链路。
一、核心原理
容灾的本质是用空间换时间：在两个或多个物理隔离的机房之间做数据与算力的冗余，使单个站点故障时业务能在可接受的时间内（RTO）以可接受的数据损失（RPO）恢复。
- RTO（Recovery Time Objective）：从故障发生到业务恢复可用的目标时长。决定切换机制与自动化程度。
- RPO（Recovery Point Objective）：可容忍的最大数据丢失窗口（时间长度）。决定数据复制方式。
- 两地三中心：同城（≤100km）双中心 + 异地（≥300km）一个灾备中心。同城双中心承担双活/主备，异地中心兜底「城市级」灾难。
flowchart LR
U[用户流量] --> GSLB[GSLB 全局负载均衡]
GSLB -->|健康检查| A[同城中心A<br/>生产/主]
GSLB -->|健康检查| B[同城中心B<br/>生产/备 或 双活]
A <-->|同步复制 RPO≈0| B
A -->|异步复制 分钟级| C[异地灾备中心C<br/>兜底城市级灾难]
B -->|异步复制| C
Q[第三方仲裁点] --- A
Q --- B
- 同步复制：写请求在两地都落盘才返回，RPO=0，但受限于同城光纤往返时延（<2ms），超过则写性能显著下降。
- 异步复制：主站落盘即返回，后台复制到备站，RPO=复制周期+链路时延，可跨任意距离。
- 脑裂（Split-Brain）：双活两中心之间心跳/链路中断后，两中心都自认为主，同时写导致数据冲突。必须靠第三方仲裁（仲裁点/仲裁盘/云仲裁）解决。
二、参考架构（两地三中心）
flowchart TB
subgraph 同城双中心
direction LR
A[中心A<br/>生产<br/>DC-A] ---|裸纤/DWDM<br/>≤100km, RTT<2ms| B[中心B<br/>生产/容灾<br/>DC-B]
end
subgraph 异地灾备
C[中心C<br/>灾备<br/>≥300km]
end
A ---|异步复制| C
B ---|异步复制| C
GSLB[GSLB/GTM] --> A
GSLB --> B
配套 ASCII 逻辑图（用于方案文档/PPT）：
┌──────────────────────────────────────┐
│ GSLB / GTM（智能 DNS） │
│ health check + 就近/主备调度 │
└───────────────┬──────────────────────┘
│
┌────────────────────────┼────────────────────────┐
│ 同城（<100km，RTT < 2ms） │
┌────▼─────┐ 同步复制 RPO=0 ┌────▼─────┐
│ 中心A │◄──────────────────────────────►│ 中心B │
│ 生产(主) │ 心跳 + 仲裁 │ 生产(备) │
└────┬─────┘ └────┬─────┘
│ 异步复制（分钟级） 异步复制 │
┌────▼───────────────────────────────────────────▼─────┐
│ 中心C（异地灾备，≥300km） │
│ 兜底城市级灾难，冷备/温备，RPO=分钟~小时级 │
└───────────────────────────────────────────────────────┘
三、关键参数决策表
3.1 业务分级与 RTO/RPO 达标线（真实量级）
| 业务等级 | RTO 达标线 | RPO 达标线 | 复制方式 | 参考架构 | 依据/典型场景 |
|---|---|---|---|---|---|
| L1 核心交易 | ≤15 min | ≈0（同步） | 同步复制 | 同城双活 | 银行核心、支付、交易撮合 |
| L2 重要业务 | ≤2 h | ≤15 min | 准同步/半同步 | 同城主备 | 订单、ERP、核心数据库 |
| L3 一般业务 | ≤8 h | ≤4 h | 异步复制 | 异地灾备 | 报表、BI、OA |
| L4 非关键 | ≤72 h | ≤24 h | 备份恢复 | 异地冷备 | 归档、开发测试 |
3.2 复制方式对比（真实数值）
| 复制方式 | RPO | 跨距限制 | 写时延代价 | 常见实现 | 常见错误 |
|---|---|---|---|---|---|
| 同步复制 | 0 | 同城 ≤100km（RTT<2ms） | 每次写 +1×RTT | 存储阵列同步 / DB 同步提交 | 跨城硬上同步导致写性能崩塌 |
| 半同步 | ≈0~5 s | 同城 | +0.5×RTT | MySQL 半同步、阵列级 | 退化为异步时未告警 |
| 异步复制 | 复制周期+时延 | 任意 | 近 0 | 阵列异步、日志复制、对象复制 | 复制周期设太大导致 RPO 失控 |
| 备份恢复 | 备份周期 | 任意 | 0 | 快照+异地备份 | 把「有备份」当成「有容灾」 |
3.3 机房距离与同步复制可行性
| 同城距离 | 光纤往返时延（估算） | 同步复制 | 说明 |
|---|---|---|---|
| ≤20 km | ≤0.2 ms | 推荐 | 写时延几乎无感 |
| 20~50 km | 0.2~0.5 ms | 可用 | 需评估写放大 |
| 50~100 km | 0.5~1.0 ms | 临界 | 仅低写放大业务 |
| >100 km | >1.0 ms | 不推荐 | 改为异步/准同步 |
> 光纤单向时延约 5μs/km，往返约 10μs/km。务必用 scripts/rto_rpo_calculator.py 按实际距离与复制方式测算 RPO 与达标情况。
四、分步 SOP
- 业务盘点与分级：列出全部业务，按「停机/丢数据损失」划分 L1~L4，明确每级的 RTO/RPO 目标。
- 架构选型：核心业务走同城双活（同步 RPO=0），一般业务走异地异步灾备，形成两地三中心。
- 数据复制落地：按分级选择同步/异步复制，实测复制延迟与复制积压，确认 RPO 达标。
- 网络冗余：机房间链路物理路径分离（不同运营商/管道），同城双中心间做双路由。
- 脑裂防范：部署第三方仲裁点（独立机房仲裁节点或云仲裁），双中心心跳双路。
- 切换机制：确定 VIP/网关漂移（BGP anycast / keepalived / SLB）与 DNS/GSLB 调度策略，明确自动/手动切换边界。
- 演练验证：完成端到端切换演练，实测 RTO，记录回切步骤，输出演练报告。
五、真实配置示例
5.1 GSLB 智能 DNS（F5 BIG-IP GTM 风格 / 通用概念）
# GTM 逻辑：对业务域名做双中心健康调度
# pool 定义两个数据中心 VIP
gtm pool /Common/dr_pool {
members add {
/Common/vs_dc_a:80 { }
/Common/vs_dc_b:80 { }
}
# 依赖健康检查，故障自动摘除
}
# 基于可用性 + 就近性调度
gtm wideip /Common/app.example.com {
pools add { /Common/dr_pool }
pool-lb-mode topolo
}
5.2 VIP 漂移（BGP anycast，双中心同网段）
! 思科 IOS-XE / 华为 VRP 思路：两中心向骨干通告同一业务网段
! 中心A（主）正常通告，中心B（备）故障时接管
router bgp 65001
network 10.10.0.0 mask 255.255.0.0
neighbor 172.16.1.1 remote-as 65000
! 备中心用 AS-PATH prepend 压低优先级，主故障后自动切换
neighbor 172.16.1.1 route-map DR-OUT out
!
route-map DR-OUT permit 10
set as-path prepend 65001 65001 65001
5.3 存储同步复制（华为 OceanStor 风格，概念级）
# 创建远程复制一致性组，同步模式（RPO=0）
create remote_replication_consistency_group name=dr_cg_01 \
remote_device_id=DC_B_Storage \
replicate_mode=synchronous \
recovery_policy=automatic
# 将 LUN 加入一致性组
add remote_replication_consistency_group name=dr_cg_01 lun=1,2,3
> 完整可填空切换模板见 assets/dr-switchover-template.txt，逐行解释与更多厂商见 references/dr-replication-configs.md。
六、验证方法与达标阈值
切换演练是容灾可信的唯一证明，未演练的容灾视为「未验证」。演练必须实测以下指标：
# 复制延迟检查（存储/DBA 侧）
# 示例：MySQL 半同步状态
mysql -e "SHOW STATUS LIKE 'Rpl_semi_sync_master_no_tx';"
# GSLB 健康检查（模拟中心A故障）
dig app.example.com +short # 观察解析是否切到中心B
| 验证指标 | 达标线（参考） | 采集方式 |
|---|---|---|
| 切换完成时间（RTO） | ≤ 该业务等级 RTO 达标线 | 演练秒表实测 |
| 数据丢失窗口（RPO） | ≤ 该业务等级 RPO 达标线 | 复制积压/位点对比 |
| 复制延迟 | 同步<2ms，异步<复制周期 | 存储/DB 复制状态 |
| 脑裂风险 | 仲裁可达，心跳双路正常 | 仲裁心跳测试 |
| 回切 | 能回切且无数据冲突 | 回切演练 |
七、常见故障排查表
| 现象 | 根因方向 | 首要动作 |
|---|---|---|
| 双中心同时写、数据冲突（脑裂） | 心跳/仲裁链路同时中断 | 检查仲裁点可达性，立即隔离一端写 |
| 切换后数据不一致 | 复制积压未清零就切 | 检查复制位点/积压，补齐后再切 |
| RPO 持续超标 | 复制链路带宽不足/周期过长 | 核对复制带宽与周期，升级链路 |
| 同步复制写性能暴跌 | 机房间距过大 RTT 超 2ms | 改半同步/异步，或拉近机房 |
| GSLB 未自动切换 | 健康检查配置错误/TTL 过长 | 核对健康检查与 DNS TTL（建议≤60s） |
| 切换后回不来 | 回切流程缺失/数据反向复制未就绪 | 提前演练回切，建立反向复制 |
> 更多案例见 references/dr-troubleshooting.md。
八、输出规范
交付时应产出：业务分级与 RTO/RPO 指标表、两地三中心架构图、数据复制方案（含实测延迟）、脑裂防范与仲裁方案、切换与回切流程、演练报告（含实测 RTO/RPO）、资源就绪核对表。
九、边界与风险
- 演练是唯一可信证明，未演练的方案视为未验证，不承诺「开箱即切」。
- 双活必须配脑裂防范，否则风险大于收益；同步复制受物理距离硬约束。
- 应用侧需同步改造（无状态化、会话保持、数据库分库分表），仅靠网络/存储复制无法保证业务可切。
- RTO/RPO 数值为分级量级参考，最终以业务实测与厂商实现为准。
配套资源
- 参数手册：
references/rto-rpo-parameters.md - 厂商配置对照：
references/dr-replication-configs.md - 故障案例库：
references/dr-troubleshooting.md - 数据基线：
assets/rto-rpo-baseline.csv - 切换模板：
assets/dr-switchover-template.txt - 脚本：
scripts/rto_rpo_calculator.py（RTO/RPO 达标计算器） - 配套检查清单：《数据中心容灾与双活清单》
