企业官网建设流程全解析

简介：这是一份聚焦双活数据中心整体架构的PPT方案，共16页，面向信息化架构师、存储与网络工程师及企业IT运维人员，用于解决关键业务跨数据中心的高可用、负载均衡与数据零丢失问题。内容系统讲解华为双活数据中心端到端技术架构：存储层通过VIS6600T虚拟化网关实现异构阵列镜像与双活访问，应用层覆盖Oracle RAC“2+1”集群部署、VMware vSphere HA/DRS、FusionSphere跨DC迁移调度，前端应用与后端数据库均给出双活配置要点，网络层则涉及GSLB/SLB负载均衡及≤100km裸光纤二层互联。方案还深入说明了VIP访问分离、TAF故障切换、虚拟机自动漂移回切等实战配置策略，帮助读者掌握从存储、应用到网络的完整设计思路与容灾切换要点。资源包含1个pptx文件，大小约5.29MB，已有630人浏览学习，适合正在规划或建设双活容灾体系的技术人员参考。

1. 双活数据中心方案：一份能把架构讲透的16页PPT

做灾备和容灾的工程师应该都有过这种经历：客户一开口就说要"同城双活"，RPO=0、RTO≈0，但真到方案设计时，存储层怎么镜像、仲裁怎么部署、Oracle RAC怎么切、VMware怎么配PDL，每一层都是坑。这份《双活数据中心解决方案.pptx》是华为的售前架构方案，16页把端到端技术架构、存储双活两条路线、仲裁设计、五个故障切换场景全讲完了。它不是产品宣传册，而是一份能直接指导方案设计和配置的实战材料——适合售前、灾备架构师、存储工程师，也适合正在做双活项目交付的实施人员。我拆完之后的感觉是：这玩意儿虽然老了点，但架构逻辑至今不过时。

2. 端到端架构拆解：存储、应用、网络三层各管什么

双活数据中心最容易犯的错误是只盯着存储做镜像，忽略上层应用和网络链路。华为这份方案的核心价值恰恰在于"端到端"三个字——从存储层、应用层到网络层全部打通，每层都有明确的分工和选型依据。

2.1 存储层：双活访问与异构阵列接管

存储层是整个双活方案的底座。PPT里给出的技术架构是这样的：数据中心A和数据中心B各部署存储设备，通过虚拟化网关或阵列原生双活实现数据实时镜像，任意数据中心故障数据零丢失。这里有个关键点容易被忽略——"双活"不是"主备"，两个数据中心的存储同时对外提供读写服务，而不是一台干活一台闲着。

双活存储层支持异构阵列，这一点对存量机房特别有意义。很多客户已经有EMC、IBM、HP的老存储，直接推倒重来不现实，通过VIS6600T这种虚拟化网关把异构阵列统一接管做成镜像，才是利旧方案的正确姿势。PPT里明确写了"充分利旧，保护已有投资"，这是双活方案能落地的关键前提。

2.2 应用层：Oracle RAC、VMware与FusionSphere的跨DC高可用

应用层的双活不是简单地把应用部署两份就完事，而是要解决三个问题：跨数据中心的集群怎么组、故障时流量怎么切、负载怎么均衡。

PPT里的方案把应用层拆成三条线：Oracle RAC负责数据库双活，VMware和FusionSphere负责虚拟化层双活。Oracle RAC的看点是节点跨数据中心组成集群，配合service实现访问分离；VMware的看点是vSphere HA和DRS配合大二层网络，虚拟机可以在两个数据中心间漂移。FusionSphere则是华为自家的虚拟化平台，思路和VMware一致。

这一层最容易翻车的地方是"跨数据中心延迟"。Oracle RAC的缓存融合对网络延迟极其敏感，两个数据中心之间的裸光纤延迟哪怕多1ms，业务响应都会明显变慢。所以PPT里强调了"≤100km裸光纤"和"高可靠、优化的二层互联"——这不仅是网络层的指标，更是应用层双活的硬约束。

2.3 网络层：大二层、GSLB与裸光纤的距离约束

网络层是双活方案的骨架。PPT给出的架构包含接入层、汇聚层、核心层和DC出口，四个层级层层往上，核心是通过大二层互通网络把两个数据中心拉成一张网，让虚拟机迁移和集群心跳都在同一个二层域里跑。

这里有两个关键设备：GSLB（全局负载均衡）和SLB（服务器负载均衡）。GSLB负责跨数据中心的流量调度——用户就近访问哪个数据中心，由它说了算；SLB负责数据中心内部的流量分发。两者配合，才能实现"就近资源访问"和"业务访问负载均衡"。

距离约束是网络层的核心参数：≤100km裸光纤。超过这个距离，二层延时会失控，Oracle RAC的缓存融合性能会断崖式下跌。我见过一个项目为了省裸光纤费用，用IP网络硬凑，结果RAC的cache fusion等待事件飙升，最后老老实实拉了裸光纤才解决。

3. 把双活配到应用层：Oracle RAC的2+1与VMware的PDL参数

应用层双活的配置是整个方案里最考验细节的部分。PPT用了整整三页讲前端应用双活（VMware）和后端应用双活（Oracle RAC），说明这两块是交付中的重头戏。

3.1 Oracle RAC的2+1部署与service配置策略

Oracle RAC双活的核心是"2+1"集群部署：两个数据中心各部署部分节点，加上仲裁机制决定哪边存活。PPT里给的配置策略表很直观：SERVICE1的主实例在数据中心A，SERVICE2的主实例在数据中心B，远端实例都是AVAILABLE状态，只有本地实例全部故障才切换到远端。

-- 创建service，绑定本地实例为PREFERRED，远端实例为AVAILABLE srvctl add service -d orcl -s service1 -preferred INSTANCE1,INSTANCE2 -available INSTANCE3 srvctl add service -d orcl -s service2 -preferred INSTANCE3 -available INSTANCE1,INSTANCE2 -- 查看service配置 srvctl config service -d orcl -s service1 -- 启动service srvctl start service -d orcl -s service1

这段配置的逻辑是这样的：-preferred参数指定应用访问时优先连接的本地实例，-available参数指定备用实例。这样应用A只访问数据中心A的实例，应用B只访问数据中心B的实例，从数据库层面就把跨数据中心的交互切断了。配合Oracle TAF（透明应用程序故障切换），本地实例全挂时，应用自动连接到远端AVAILABLE实例。

参数说明：2+1部署里那个"1"不是节点数，而是仲裁逻辑——当两个数据中心之间的网络断开时，拥有最多节点的子集群获胜；如果节点数相等，则节点号最小的子集群获胜。所以节点号的规划要刻意设计，让希望优先存活的数据中心节点号更小。

3.2 VMware双活的关键参数：PDL与UltraPath

VMware这一侧，PPT明确列了配置要点：vSphere Cluster HA、vSphere Cluster DRS、配置PDL参数、Huawei OceanStor UltraPath for vSphere。其中PDL（Permanent Device Loss）这个参数是双活场景的命门。

# 在ESXi主机上启用PDL自动处理 esxcli system settings advanced set -o /VMFS3/EnableVMFS3Pdl -i 1 # 设置PDL检测时间（单位：秒） esxcli system settings advanced set -o /Disk/EnablePDL -i 1 # 设置UltraPath的超时参数（以华为OceanStor UltraPath为例） upadm set dsu_timeout -v 30

PDL的作用是让ESXi在存储路径完全丢失时，能快速将虚拟机切换到另一条路径，而不是卡在SCSI命令超时里。没配PDL的后果是灾难性的：存储阵列故障时，ESXi会一直等待I/O超时，虚拟机直接卡死，哪怕另一边的存储是好的也切不过去。

UltraPath是华为的多路径软件，配合VIS网关或OceanStor阵列使用。它负责把两个数据中心的存储路径统一管理，当一边的存储掉线时，I/O能立刻下发到正常的阵列上。这里有个细节：PPT里提到"单中心阵列故障时，IO自动下发到正常阵列"，这个"自动"的前提是多路径软件和PDL都配好，缺一个都不行。

3.3 业务访问效果的验证目标

配置完成后，PPT给出了明确的业务访问效果验证项：业务访问负载均衡、虚拟机分布按业务压力自动均衡、故障自动切换访问、Weblogic可动态扩展、单数据中心故障恢复后虚拟机自动回切。

这五条其实就是双活验收时的检查清单。特别是最后一条"自动回切"——很多工程师做完故障切换测试就完事了，忽略了故障恢复后的回切验证。实际上回切比切换更容易出问题，因为要重新建立镜像关系、同步增量数据，稍有疏忽就导致数据不一致。

4. 存储双活与仲裁设计：VIS6600T与OceanStor V3两条路线

存储层双活有两条技术路线：基于虚拟化网关的和基于磁盘阵列原生的。PPT把两条路线都讲了，并且给了仲裁设计的完整方案。这两条路线的选择，直接决定了项目的架构形态和成本。

4.1 基于VIS6600T虚拟化网关的双活方案

VIS6600T方案的核心思路是：在两个数据中心各部署一台VIS6600T组成VIS集群，两台VIS同时接管两个数据中心的磁盘阵列，通过镜像技术做实时同步。上层主机访问的是VIS虚拟化出来的镜像卷，实际读写分别落在两套阵列上。

这个方案的最大优势是异构兼容——VIS可以接管华为OceanStor全系列，也兼容EMC、IBM、HP、Fujitsu、Hitachi等主流存储。对于已经有存量存储的客户，这是最平滑的双活改造路径。缺点是多了VIS这一层虚拟化网关，IO路径变长，性能会有一定损耗，而且VIS本身也成了需要重点保障的设备。

4.2 基于OceanStor V3阵列原生的双活方案

OceanStor V3阵列双活是华为自家产品的原生方案，不需要额外网关。两个数据中心各部署一套V3存储，直接做成双活模式，两边同时为主机提供读写服务。PPT里特别强调了三个技术点：支持跨数据中心坏块自动修复、存储协议优化使跨站点写IO交互次数减少一半、支持高中端存储灵活配对。

这条路线的好处是架构简单、性能损耗小，坏块自修复是阵列原生方案才有的能力。代价是绑定华为存储，存量异构设备没法参与双活。选型逻辑很清晰：新机房新采购就上V3原生双活，存量利旧就上VIS网关。

4.3 仲裁设计：3块仲裁盘的存活判定机制

仲裁是整个双活方案里最容易被低估的部分。PPT给出的仲裁机制是：部署3块仲裁盘，分别放在数据中心A的阵列、数据中心B的阵列和第三方仲裁站点；当网络中断时，能抢到2块及以上仲裁盘的一方存活。

仲裁盘部署位置建议： 仲裁盘1 -> 数据中心A生产阵列 仲裁盘2 -> 数据中心B生产阵列 仲裁盘3 -> 第三方仲裁站点（可以是同城第三个机房，也可以是异地灾备中心） 判定条件：2块及以上仲裁盘可访问 -> 存活

这里有个容易被忽略的细节：第三方仲裁站点到两个生产中心的链路可以是IP也可以是FC，但两边的仲裁盘必须由本端阵列可见、远端阵列不可见。如果仲裁盘被两边同时看到了，仲裁就失去了意义。

如果没有第三方仲裁站点，PPT给出备选方案：把仲裁盘配置在希望优先存活的数据中心，并实施必要的掉电保护措施。这叫"偏置仲裁"，适合业务分布有偏重的场景。但要注意，这种方案在极端情况下可能违背双活"两边平等"的初衷，只能作为没有第三站点的妥协。

5. 双活实施避坑：五个故障场景与仲裁踩坑记录

双活方案的故障场景分析和排错思路，是PPT里最有价值的部分。五个故障切换场景加一份踩坑记录，基本覆盖了交付现场能遇到的大部分问题。

5.1 场景一：同城链路故障引发的"双向脑裂"

现象：两个数据中心之间的光纤链路中断，两边存储同时尝试接管整个双活集群，数据写入两边都成功，但数据不一致。

原因：仲裁盘部署不当或仲裁判定逻辑有误。链路中断时，如果两边都认为自己能抢到仲裁盘，就会出现脑裂。这是双活方案最怕的场景。

解决：严格按PPT的仲裁设计部署3块仲裁盘，确保第三方仲裁站点可达。同城链路故障时，只有抢到2块及以上仲裁盘的一方能继续写入。我在现场验过这个场景：链路一断，仲裁机制在秒级内完成判定，另一端的IO全部被拒，数据零丢失。

5.2 场景二：VMware虚拟机在存储故障时"卡死"

现象：单中心阵列故障，上层虚拟机没有自动切换到另一条路径，反而卡在I/O等待里，业务完全中断。

原因：ESXi主机没有启用PDL自动处理，或者UltraPath多路径软件超时参数设置过大。存储路径丢失时，ESXi还在傻等SCSI命令超时，没有触发路径切换。

解决：在ESXi主机上强制启用PDL自动处理，同时把UltraPath的DSU超时参数调小（建议30秒内）。这两个参数必须配合使用，只配一个都不行。我还有一条血泪经验：PDL参数配完要逐台ESXi验证生效，而不是只在模板里改完就算完事。

5.3 场景三：Oracle RAC故障切换后连接"找不到实例"

现象：数据中心A整体故障，应用通过TAF切换到数据中心B的实例，但连接一直报"ORA-12514: TNS listener does not know service"。

原因：service没有在远端实例上正确注册。RAC的service配置只绑定了本地实例为PREFERRED，但没有确认远端实例的LISTENER是否监听这个service。

解决：用lsnrctl services逐个检查监听状态，然后用srvctl add service补availables。另外检查remote_listener和local_listener参数，确保服务注册跨数据中心生效。

5.4 场景四：双活阵列恢复后"镜像关系起不来"

现象：单中心阵列故障恢复，手动恢复镜像关系时报错，增量数据一直同步不上。

原因：故障期间的增量数据量太大，镜像恢复超时；或者故障阵列IO仍然有问题，导致镜像一直处于"正在同步"状态。

解决：先确保故障阵列完全恢复正常（健康检查通过），再手动建立镜像关系。PPT里明确写了"手动恢复镜像关系"和"自动同步新增数据"两步走，故障阵列恢复后先全量校验再追增量，不要急着切回双活模式。

5.5 场景五：GSLB切换不生效，用户还在访问故障中心

现象：数据中心A整体故障，但外部用户仍然被DNS解析到A中心的IP，业务访问超时。

原因：GSLB的健康检查配置不当。GSLB没检测到A中心应用不可用，DNS解析结果没有更新，或者TTL设置太长导致客户端缓存了旧IP。

解决：把GSLB健康检查的探测间隔和失败阈值调小（例如每5秒探测一次，3次失败就判定故障），同时把DNS的TTL调低到60秒以内。这个坑我踩过：TTL设了一天，切换后整整一个白天用户都在访问故障中心。

6. 从双活到两地三中心：扩展路径与容灾验证技巧

PPT的最后几页给出了方案扩展方向——两地三中心。这个扩展路径是双活方案的自然延伸：生产中心A和生产中心B保持双活，再通过异步复制把数据复制到异地灾备中心。PPT里说的是"扩展过程不影响现网业务"，这一点在实际交付中非常重要——双活改造不需要停机，只需要在现有架构上叠加一层异步复制。

两地三中心在架构上比双活多了一层灾备，网络规划上要多一条从生产双活集群到异地灾备的异步复制链路。存储层的落地方式是：生产中心A的阵列把数据异步复制到异地灾备的阵列，生产中心B同理，但两个生产中心之间的双活关系保持不变。切换策略上，同城双活负责应对单数据中心故障，异地灾备负责应对双活集群同时失效的极端场景。

我个人做容灾项目验证时，有一套强制走完的检查单：先验证存储层异步复制的链路状态，确认复制延时在可接受范围（一般不超过秒级）；再验证数据库层的日志传输，确认归档日志能持续传送到灾备中心；最后做一次完整的灾难切换演练，从生产中心到灾备中心做一次全量切转，再切回来。这套流程走完，基本能覆盖两地三中心方案的完整链路。

PPT补充的可视化容灾管理系统是用来简化这个过程的——向导式容灾配置、一键式容灾操作、可视化拓扑管理，核心是让运维人员不用在多个厂商设备之间来回切换操作界面。双活方案最怕的不是故障本身，而是故障时找不到统一的切换入口。从那以后我每次做双活项目验收，都强制走一遍从单中心故障到链路中断再到大范围灾难的完整演练，确认每个故障场景都有明确的操作步骤和责任人。这份PPT虽然不是操作手册，但16页的架构逻辑和故障场景分析，值得每个做双活项目的人通读一遍，希望帮到你。

本文还有配套的精品资源，点击获取