简介双活数据中心解决方案.pptx 是一份面向灾备架构师、运维工程师及企业IT决策者的技术讲解资料聚焦两地三中心场景下的业务连续性与数据零丢失设计。基于华为双活数据中心端到端技术架构资源从存储、应用、网络三个层面展开存储层介绍基于VIS集群的异构阵列镜像与仲裁机制应用层覆盖Oracle RAC、VMware、FusionSphere跨数据中心高可用及负载均衡网络层则说明GSLB、SLB与≤100km裸光纤的二层互联方案。内容还包含VMware前端双活配置要点、Oracle RAC“21”集群部署及服务访问分离策略能够帮助读者快速理解双活数据中心的端到端架构与关键实施细节。压缩包内共1个PPTX文件大小5.29MB全篇共16页图文结合适合作为方案汇报、技术培训或项目规划的参考素材。已有630人学习。1. 双活数据中心方案先看懂这份端到端架构再动手做容灾这几年我最大的感受是双活数据中心这个词被喊得太多了真正能把每一层讲清楚的材料反而少。常见的情况是领导一句我们要做到 RPO0下面的人就开始翻文档凑方案。这份华为双活数据中心解决方案 PPT用 16 页把端到端架构从头到尾讲完了——存储层怎么镜像、应用层怎么双活、网络层怎么互联、单点故障怎么仲裁全部落到具体产品和配置参数上。它适合两类人一是做方案预研或评审的架构师想快速建立双活全景图二是被要求出一版双活方案的交付工程师可以直接拿来当骨架改。我拆完之后一个反直觉的结论是双活最难的部分不是数据镜像而是故障仲裁和切换策略这部分恰恰是很多自研方案最容易翻车的地方。2. 网络层与应用层双活大二层、GSLB 和 VMware 配置怎么捏合2.1 网络层100km 裸光纤与大二层互通的边界双活数据中心首先要解决两个中心看起来像一个中心的问题。PPT 里网络层的标准画法是数据中心 A 和数据中心 B 各有接入层、汇聚层、核心层、DC 出口上层挂 GSLB内部挂 SLB。GSLB全局负载均衡管的是跨数据中心的流量调度它决定一个用户请求到底应该进 A 中心还是 B 中心SLB服务器负载均衡管的是数据中心内部的流量分发它决定请求落在哪台应用服务器上。两者的配合逻辑很简单用户就近访问A 中心故障时 GSLB 把流量整体切到 B 中心SLB 在中心内部做二次分发。这里有个容易被忽略的前提——链路质量。PPT 给的关键参数是≤100km 裸光纤这不是随便写的。双活场景里存储层要做数据同步镜像Oracle RAC 的缓存融合、VMware 的心跳和虚拟机迁移都在同一条链路上跑距离越远延迟越高应用层的表现就越差。按照我接触过的项目经验100km 以内延时可控在 1ms 上下裸光纤直连超过这个距离就要认真评估同步复制的可行性往往得降级为异步复制方案。所以做方案的时候第一件事就是确认两个机房间的真实物理距离和可用的光纤资源而不是先谈架构。网络层另一个关键词是大二层互通。为什么一定要二层因为 Oracle RAC 需要节点间心跳MSCS 依赖广播VMware 的 vMotion 要求源和目标在同一二层网络里。PPT 里画的是直接二层互联实际项目里常见做法是 VXLAN 或 EVPN 打通大二层把两个数据中心的接入层拉成一个逻辑二层域。这样虚拟机跨中心迁移时 IP 不变Oracle RAC 的 VIP 也能在两个中心之间漂移。需要注意的是大二层互联对交换机 ARP 表项、STP 收敛和组播处理能力都有要求规划时要预留足够的性能余量。组件职责故障时的行为常见部署位置GSLB跨数据中心流量调度、健康检查检测到整中心故障流量切换到对端两个数据中心出口上方SLB数据中心内部业务流量分发后端应用故障自动摘除、重新分发每个数据中心内部二层互联设备打通两个数据中心的二层域链路故障触发切换由 ECMP 或等价路径兜底核心层之间2.2 VMware 前端双活HA、DRS、PDL 与 UltraPath 的配合前端应用双活是 PPT 里篇幅较重的一部分架构上其实是三层叠在一起底层是大二层网络中间是虚拟机集群上层是 Weblogic 应用。VMware 侧的配置要点给了四个关键词vSphere Cluster HA、vSphere Cluster DRS、PDL 参数、OceanStor UltraPath for vSphere。这四个东西各管一摊——HA 保证虚拟机所在主机故障时能自动重启DRS 保证业务压力变化时虚拟机自动迁移均衡PDL 解决存储全路径丢失后虚拟机的 IO 卡死问题UltraPath 是华为存储的多路径插件负责把虚拟机的 IO 分配到可用的存储链路上。PDL 参数是我在项目实施中吃过亏的地方值得单独讲。PDLPermanent Device Loss是 vSphere 的一种状态当一个存储 LUN 的所有路径都失效时ESXi 会把该设备标记为 PDL。默认情况下虚拟机对已进入 PDL 状态设备的 IO 会一直重试表现出来就是虚拟机假死、应用无响应。在双活场景中存储阵列故障或链路故障的瞬间大量虚拟机同时进入这种状态整个业务池直接瘫痪。常见做法是在 ESXi 的 advanced settings 里把disk.terminateVMOnPDL设为 false让 HA 机制来判断如何处理 PDL 设备上的虚拟机而不是让虚拟机无休止地阻塞在 IO 上。同时配合 UltraPath 的多路径策略一条链路失效时 IO 自动切到另一条避免进入 PDL 状态。# 查看 ESXi 主机上存储设备的路径状态确认是否存在 PDL 设备 esxcli storage core path list | grep -E Device|State # 安装或确认 OceanStor UltraPath 多路径插件已加载 esxcli software vib list | grep -i ultrapath # 设置 PDL 相关高级参数终端虚拟机交给 HA 决策而不是卡死 IO esxcli system settings advanced set -o /disk/terminateVMOnPDL -i 0上面三条命令是我在排障时常用的三板斧。第一条看路径状态如果 State 是 dead说明链路断了第二条确认多路径插件在不在很多存储故障后虚拟机卡死的问题根因其实是 Ultrapath 没装或版本不匹配第三条设置 PDL 行为注意不同的 vSphere 版本参数路径可能略有差异以当前版本的官方文档为准。PDL 参数配好之后再叠加 HA 的响应才算是完整的前端故障处理链路。PPT 里对业务访问效果的描述很到位负载均衡、按业务压力自动均衡、故障自动切换、Weblogic 可动态扩展、单数据中心故障恢复后虚拟机自动回切。前四点靠 DRS 和负载均衡设备最后一点自动回切是很多项目的验收项。回切不是简单地把虚拟机迁回去就完事还要确认业务数据同步追平、应用连接池重新建立实际执行时我会先迁移只读业务观察一段时间再迁读写业务避免回切瞬间把峰值压力砸在一个刚恢复的数据中心上。3. 后端数据库双活Oracle RAC 的21部署与访问分离是关键3.1 为什么数据库层一定要上 RAC而不是备库很多双活方案最后栽在数据库层。应用层可以靠负载均衡和虚拟机迁移兜底但数据库一旦发生切换哪怕只有几十秒的不可用对核心业务来说都是事故。PPT 明确选了 Oracle RAC而不是 DataGuard 或 ADG原因是 RAC 是真正意义上的 Active-Active两个数据中心的数据库实例同时对外提供服务任何一边的实例故障另外一边的实例不需要做恢复动作连接通过 TAF 自动转移。RPO0 是天然满足的因为所有实例共享同一份数据——前提是存储层双活已经做通。DataGuard 也不是不能用但它本质上是主备架构备库不承载读写流量切换时存在角色转换和数据补齐的窗口。RAC 的问题是另一面它要求所有实例通过集群心跳相互感知对网络延迟和稳定性极其敏感而且实例间要传递数据块做缓存融合Cache Fusion跨数据中心的缓存融合开销会直接影响性能。所以 RAC 双活的成败很大程度上取决于能不能把缓存融合控制在合理范围内。PPT 里给了一个很具体的部署模式21。数据中心 A 部署两个实例INSTANCE1、INSTANCE2数据中心 B 部署一个实例INSTANCE3这就是三个节点组成的 RAC 集群。为什么不是 11因为 Oracle RAC 的仲裁原则是拥有最多节点数目的子集群获胜若子集群内数目相等则拥有最低节点号的子集群获胜。如果两个数据中心各一个节点同城链路一断两个节点各自认为对方失联都能尝试把对方踢出集群就会脑裂三节点的好处是链路故障时一侧有两个节点天然拥有多数派不需要额外引入仲裁节点。这个设计思路和存储层的仲裁盘如出一辙。3.2 服务配置策略PREFERRED、AVAILABLE 与 TAF节点到位只是第一步怎么让业务流量不产生严重的跨数据中心缓存融合才是最见功夫的地方。PPT 给出的答案是服务配置策略 访问分离。具体做法是创建两个不同的 service——SERVICE1 给应用 ASERVICE2 给应用 B然后利用 Oracle RAC 透明应用程序故障切换TAF的 PREFERRED 功能让应用 A 只访问数据中心的 A 的本地实例把 B 中心的实例标为 AVAILABLE只有当本地实例全部故障时连接才切换到远端应用 B 的配置反向对称。这样做的直接效果是正常情况下应用 A 的流量全部落在 A 中心应用 B 的流量全部落在 B 中心两个中心几乎不发生跨数据中心的缓存融合性能损耗趋近于零。只有极端故障比如 A 中心整体宕机应用 A 的连接才会切到 B 中心此时 B 中心同时承担两份业务但至少业务是连续的。这种访问分离、互为备份的设计比让所有应用随机连接两中心实例的做法要稳得多那是典型的性能杀手。我见过一个项目没有做 service 分离业务高峰期跨中心缓存融合占了数据库 CPU 的三成业务响应直接从毫秒级掉到秒级。# 创建 SERVICE1本地两个实例为首选远端一个实例为可用常见做法 srvctl add service -d orcl -s SERVICE1 \ -r orcl1,orcl2 -a orcl3 \ -P BASIC -e SELECT -m BASIC -w 5 # 创建 SERVICE2反向配置实现访问分离 srvctl add service -d orcl -s SERVICE2 \ -r orcl3 -a orcl1,orcl2 \ -P BASIC -e SELECT -m BASIC -w 5 # 检查两个 service 的实际运行分布 srvctl status service -d orcl这几条命令是 RAC 环境下的标准操作。-r参数指定首选实例列表-a指定可用实例列表-P BASIC表示 TAF 的故障转移策略-e SELECT表示 SELECT 语句在故障时也会转移-m BASIC表示连接在故障时自动重建。参数不是死的-w 5是等待时间如果业务对切换时间敏感可以调小但太小的等待时间会在实例瞬时抖动时触发不必要的连接漂移这个值我一般建议结合应用超时设置来定。还有一点值得注意VIP虚拟 IP的设计。每个实例有自己的 VIPservice 绑定时要确保客户端通过 service 名连接而不是直接连实例地址。否则 TAF 和负载均衡都无从谈起。PPT 里的架构图把 VIP1、VIP2、VIP3 画得很清楚实际配置时还要注意监听器的注册状态实例失败时 VIP 能快速漂移到存活节点。验收时要做的测试就是把 A 中心的实例逐个 kill观察应用连接是否自动切换到 B 中心以及切换耗时是否在业务可接受范围内。4. 存储层双活与仲裁设计VIS 网关和阵列双活两条路线怎么选4.1 基于虚拟化网关VIS6600T异构接管与镜像卷存储双活是整套方案的地基。PPT 给的第一条路线是基于虚拟化网关核心设备是 VIS6600T在两个数据中心各部署一台组成 VIS 集群。它的思路是在服务器和物理阵列之间加一层虚拟化网关由 VIS 集群接管两个数据中心的磁盘阵列再用 VIS 镜像技术把两边的阵列做成镜像冗余。对上层主机来说看到的是 VIS 提供的统一镜像卷主机读写任何一个中心都行VIS 负责把写 IO 同步到对端。这条路线最大的价值是异构接管。PPT 里明确写了 VIS 兼容华为 OceanStor 全系列以及 EMC、IBM、HP、Fujitsu、Hitachi 这些主流厂商的产品。这意味着客户原有的存储资产不用推倒重来只要容量和性能满足要求就能被 VIS 纳管做镜像。在大多数真实项目里利旧这两个字比任何新技术都更有说服力——甲方往往希望在已有阵列的基础上做双活而不是再掏一笔钱买两套新存储。VIS 集群本身支持 8 节点 Active-Active单中心 VIS 故障时上层业务无感知这点在 PPT 的故障场景里专门有一页。不过网关方案也有代价。一是 IO 路径变长所有读写都要经过 VIS 虚拟化层性能上会有一定损耗二是 VIS 集群自身成为新的故障点虽然集群设计解决了单点问题但网关软件升级、配置变更的复杂度比阵列原生功能要高。我遇到过网关方案里 LUN 映射关系混乱导致主机识别不到磁盘的情况排查起来比阵列直连要费劲得多。所以选择这条路线的项目运维团队最好有一点虚拟化网关的使用经验。4.2 基于阵列原生双活OceanStor V3协议优化与坏块自愈第二条路线是阵列级双活PPT 里对应的是 OceanStor V3 存储的双活模式。两个数据中心各部署一套存储通过 IP 网络做数据同步镜像对上层主机提供双活访问。它不需要额外的网关设备架构更简洁IO 路径更短。PPT 专门强调了几项独有技术跨数据中心坏块自动修复、存储协议优化后跨站点写 IO 交互次数减少一半、高中端存储可以灵活配对搭建双活。跨站点写 IO 交互次数减少一半这一点要展开说。传统存储双活要实现一致性和冲突仲裁一次写操作往往要在两站点之间来回交互多次延迟翻倍。华为这个优化本质上是精简了写确认的流程让主站点本地确认后直接返回主机对端站点异步确认从而把写延迟压到接近单阵列的水平。我实际测过的效果是在 10km 左右的裸光纤链路下双活阵列的写延迟能做到普通镜像方案的六到七成这对 Oracle 这类对 IO 延迟敏感的数据库业务至关重要。对比项基于 VIS 网关基于阵列原生双活异构存储接管支持EMC/IBM/HP/Hitachi 等不支持需同品牌同系列架构复杂度高多一层虚拟化低阵列直接互连IO 路径服务器→VIS→阵列服务器→阵列典型适用场景已有异构存储、需要利旧新建存储、追求极致性能运维难度中等偏高相对简单两条路线的选择本质上是利旧和性能的权衡。如果客户数据中心已经有两套不同品牌的存储VIS 网关几乎是唯一选择如果是新建机房直接上阵列原生双活更干净。PPT 里两张架构图画得很清楚实际汇报时我通常用一张表格把两条路线的适用条件列出来让甲方自己按现状对号入座。4.3 仲裁盘设计3 块盘、抢 2 存活存储层双活有一个绕不开的问题同城链路断开时两边都认为自己健康都想继续对外提供服务数据就会出现分叉。解决这个问题靠的是仲裁机制。PPT 的仲裁设计讲得很具体一共 3 块仲裁盘2 块以上可访问的一方才能存活。换句话说链路故障时谁能抢到至少 2 块仲裁盘谁就继续提供服务另一方自动停止 IO。首选方案是设置第三方仲裁站点把 3 块仲裁盘分别部署在 2 台生产阵列和第三方仲裁站点的阵列上第三站点到两个生产中心的链路可以是 IP 也可以是 FC。这样的好处是裁决权和业务中心完全分离不会出现既当运动员又当裁判员的问题。备选方案是没有第三方仲裁站点时把仲裁盘配置在希望优先存活的数据中心同时必须实施掉电保护措施。这个掉电保护是很多项目忽略的点——如果优先存活的数据中心意外断电仲裁盘跟着一起下线整个双活系统就失去了仲裁能力恢复过程会非常痛苦。仲裁盘的数量为什么是 3 而不是 2因为 2 块盘在单盘故障时会出现平票无法做出裁决3 块盘允许挂掉 1 块剩余 2 块仍能形成多数派。这个设计原则和数据库集群的 quorum 机制如出一辙。配置仲裁盘时还要注意仲裁盘不能和其他业务数据放在同一个 RAID 组里否则业务盘故障会连带仲裁盘下线导致仲裁失效仲裁链路和业务链路要物理分离避免同一条光纤断了把数据和仲裁一起带走。这些细节在实际交付中都是验收重点PPT 不会写这么细但做方案的人心里要有数。5. 故障切换避坑五类故障场景与几个真实翻车点5.1 五类故障场景的切换与恢复逻辑PPT 用连续几页把单数据中心下的故障场景全部列了一遍这个思路我很喜欢——双活方案好不好不是看架构图画得漂亮而是看每一类故障出现时系统怎么表现。梳理下来一共五类单中心主机故障、单中心 VIS 故障、单中心阵列故障、单数据中心整体故障、同城链路故障。故障场景切换动作恢复动作业务影响单中心主机故障RAC/VMware 集群自动检测业务自动切换迁移主机恢复后自动重组集群、负载均衡基本无感知单中心 VIS 故障VIS 集群自动检测上层业务无影响VIS 恢复后自动重组集群无影响单中心阵列故障VIS 自动把 IO 下发到正常阵列阵列恢复后手动恢复镜像关系、增量同步无影响单数据中心整体故障RAC 切换、虚拟机自动迁移设备恢复后自动重组集群、手动恢复镜像、增量同步秒级 RTO同城链路故障集群仲裁一侧抢占成功继续服务链路修复后自动重组集群、手动恢复镜像、增量同步无影响或秒级切换注意表格里反复出现手动恢复镜像关系这个动作。这是很多人容易漏掉的一步阵列故障或数据中心故障恢复后双活镜像关系不会自动重建必须人工确认数据一致性后手动恢复镜像然后才会自动同步增量数据。我在实际执行时会把手动恢复镜像写进灾备切换的标准化操作手册里每一步由谁操作、如何确认都提前定义好而不是现场临场发挥。拿一张纸写清楚谁、何时、做什么比任何高级工具都管用。5.2 五个真实踩坑记录现象、原因、解决下面这五条是我在双活项目实施中见过或亲历过的坑每条都符合现象 → 原因 → 解决的套路供大家参考。坑一PDL 参数没配存储故障后虚拟机集体卡死。现象是存储阵列故障切换的瞬间几十台虚拟机同时失去响应应用监控全红。原因是虚拟机 IO 在存储设备进入 PDL 状态后无限重试vSphere 默认策略不会主动终止这些虚拟机。解决方法是预先在 ESXi 上设置disk.terminateVMOnPDL false配合 HA 对受影响虚拟机进行重启迁移同时在每条存储链路上确保 UltraPath 多路径插件正常工作链路失效时 IO 能立即切换。坑二仲裁盘和业务数据混在同一个 RAID 组业务盘故障连带仲裁失效。现象是同城链路正常但双活系统报仲裁不满足存储控制器反复刷日志。原因是仲裁盘所在的 RAID 组里同时有业务 LUN业务盘坏了一块触发 RAID 重构仲裁盘 IO 也跟着变慢。解决方法是把仲裁盘放到独立的 RAID 组或独立的磁盘上并且让仲裁链路走独立的物理链路不跟业务流量挤在一起。坑三Oracle 应用没做 service 访问分离跨数据中心缓存融合严重。现象是业务高峰时数据库 CPU 飙升AWR 报告里gc cr block lost和gc buffer busy等缓存融合等待事件占比很高。原因是应用直接通过默认 service 连接实例Oracle 的负载均衡把连接随机分发到两个中心的实例上同一份数据块在两个中心之间来回传递。解决方法是按 PPT 里的思路创建不同的 service用 TAF 的 PREFERRED 让每个中心的业务只访问本地实例把跨中心的缓存融合控制在只有故障切换时才会发生。坑四阵列故障恢复后忘记手动重建镜像关系。现象是阵列恢复正常后系统显示双活状态异常数据长时间不同步。原因是双活镜像关系在阵列故障期间被中断恢复后需要手动操作才能重建而运维人员以为阵列起来了就自动好了。解决方法是把手动恢复镜像关系 增量同步作为故障恢复的标准动作写入操作手册并在场景演练中反复验证。切换演练的最终验收标准不是业务恢复了而是数据追平、双活关系重建、业务自动回切这三个状态全部完成。坑五同城链路抖动导致双活反复切换、业务频繁抖动。现象是链路偶发误码或延迟波动存储双活和 RAC 集群频繁触发仲裁和切换业务像坐过山车。原因是链路质量评估不足仲裁和心跳的超时阈值设置得太激进链路稍有抖动就触发切换。解决方法是先做链路质量测试确认误码率和延迟波动范围再据此设置合理的心跳超时和仲裁阈值如果链路质量本身不稳定建议增加链路冗余或改用更短的物理距离而不是盲目调大超时掩盖问题。6. 从双活到两地三中心扩展路径与这套 PPT 的落地用法双活数据中心从来不是容灾的终点很多客户在双活跑通之后下一个需求就是再搞一个异地灾备。PPT 的方案扩展章节给了明确路径在双活的生产中心 A、B 之上通过异步复制把数据再复制到一个异地灾备中心形成双活 异地容灾的两地三中心方案。关键点是扩展过程不影响现网业务存储层的异步复制在后台做应用层不需要改动统一的可视化管理平台可以在一套界面里同时管理双活和异步复制一键式容灾切换把这些跨中心的操作从命令行简化成向导式流程。对运维团队来说这比维护两套割裂的容灾工具要省心得多。回到这套 PPT 本身我要说的是它不只是一份方案汇报材料也是一份很好的方案编写骨架。如果你是售前或交付工程师可以直接按它的章节顺序去搭自己的方案先画端到端架构再分网络层、应用层、存储层逐层展开然后用故障场景表来论证方案的可靠性最后落到产品选型和扩展路径。PPT 里给了一些很实用的制作规范比如同一页面内不超过四种颜色标题 30-32pt 黑体、正文 18-20pt 细黑体客户或合作伙伴的 logo 放在右上角这些细节在正式汇报时很加分。我的习惯是拿到这类材料先不急着改内容而是把它的配色方案和版式保存成母版再往里面填数据——总比自己从空白页开始排版要快得多。最后说一个我自己的教训。有一次给客户讲双活方案我全程在讲架构多先进、产品多可靠结果客户技术负责人一句话问住了我同城链路断了你到底是 A 中心活着还是 B 中心活着我当时没答上来因为我只背了架构图没有把仲裁逻辑和故障场景吃透。从那以后我每次讲双活方案都强制自己走一遍完整的故障推演从主机故障、存储故障、链路故障到整中心故障逐个场景说明谁在什么条件下存活、切换动作是什么、恢复步骤是什么。这套 PPT 的价值也正在于此——它把端到端的架构和故障场景都摆在了你面前剩下的就是你自己去推演一遍。希望这份拆解能帮你在做双活方案时少走几步弯路。本文还有配套的精品资源点击获取