简介面向数据中心架构师、运维工程师及容灾方案规划人员这份PPT以可修改原图形式完整呈现双活数据中心的核心原理与拓扑设计帮助读者快速理解两地三中心、主备故障域、仲裁节点等关键概念。资源为单个PPT文件约3.77MB适合方案汇报、技术培训或二次编辑底稿。目前已有203人学习下载。内容覆盖网络、存储、服务器、数据库、应用及HA架构包括业务网络、VXLAN与存储网络隔离双交换机堆叠和裸光纤互联存储管理网络vlan10/11/12Oracle RAC主备节点与共享盘副本机制以及APP1APP4在主备机房的分布和全局负载。整张原理图直观呈现主机房、备机房与第三机房仲裁节点的链路关系并标注推荐万兆、延时≤1ms等关键参数。下载后可基于原图自由修改文字、连线与图标快速生成符合自身业务场景的双活数据中心架构图用于方案设计、投标材料或内部评审。 前阵子公司要做灾备体系升级评审售前丢过来一份PPT文件名写着《双活数据中心原理图原图可修改.ppt》。打开一看页面很漂亮交互图、渐变线条、立体机柜一个不少但仔细往下追的时候发现问题了图里画了双数据中心画了两条业务链路也画了存储复制可是最关键的仲裁链路没画存储双写的方向也是简化的单向箭头。这种图拿去给领导汇报问题不大但真要照着它做方案评审会被运维和DBA当场问住。这份PPT的标题之所以强调原图可修改说明它不是一张静态的效果图而是一张需要被反复打磨、对齐、演化成落地方案的底稿。本文就用这份PPT的视角把双活数据中心原理图从看得懂到画得好再到经得起追问拆开讲一遍。适合售前、运维工程师、灾备负责人以及任何需要给双活项目画图或读图的人参考。1. 为什么需要双活原理图背后的业务逻辑1.1 从备份-恢复到双活的演进先明确一个概念双活数据中心的核心不是两个数据中心都有电、都有设备而是两个中心同时处于运行状态并且都能对外提供服务。这和传统的主备模式有本质区别。主备模式大家很熟悉生产中心承担全部业务灾备中心同步数据但处于待命状态。平时备中心不干活只有生产中心故障时才切换过去。这个模式的痛点在于——备机常年闲置硬件投资回报率低切换过程依赖脚本、依赖人RTO恢复时间目标动辄小时级而且备份说到底是为了恢复恢复本身又是一个高风险操作。双活的思路是把两个中心都变成生产中心业务流量按策略分发到两边任何一个中心挂了另一个中心直接接管全部流量用户几乎无感知。这里顺便说一句很多人把两地三中心和双活混在一起其实两地三中心是容灾架构的一种布局而双活是可用性的一种运行模式一张原理图里到底想表达哪种画图之前先要想清楚。1.2 双活解决的三个核心指标画原理图之前先搞清楚图要支撑哪几个目标RPO0两个中心的数据实时一致任何一端发生故障数据零丢失。这是双活最核心的卖点。RTO趋向于0故障时另一端直接接管不需要拉起应用和数据因此恢复时间被压缩到分钟级甚至秒级。资源利用率50%两个中心同时扛业务流量避免一台跑死、一台睡着的浪费。图上如果连RPO、RTO这些指标都不标注那这张图就停留在概念示意图阶段。一份能用于落地的双活原理图应该把这三个指标对应的组件和链路都画出来别人一看就知道这个双活是怎么实现零丢失的。2. 一张双活原理图必须画出的核心组件与链路2.1 两个站点之间那条贯穿全图的大动脉任何双活原理图第一眼看到的一定是中间那条粗线代表两个数据中心之间的互联链路。这条线不是普通的网线它承担的是存储双写和仲裁通信要求很高。链路类型最常见的是DWDM波分设备承载的裸光纤或者运营商的MSTP专线两个中心通过SAN交换机或IP网络对接。链路参数图上的标注不能只写专线要把带宽、时延、距离写出来。双活数据中心距离一般控制在100公里以内环路时延RTT最好在5毫秒以内超过这个值存储双写的性能会很难看。链路冗余两个中心之间至少要有两条不同物理路由的链路一条断了另一条顶上。图上要画成双线并注明主备路由或负载分担。这中间最容易画错的地方是只画了一条业务通信链路没有画存储复制链路。其实存储双活的数据流量比普通业务流量大得多这条通路如果不画清楚图就不完整。2.2 存储层双活的核心凭证存储双活是双活数据中心和普通负载均衡集群的最大区别。服务器层面的双活很多公司都能做但要做到存储层面的双活需要专门的存储网关或者存储原生双活能力。在原理图上存储层通常画成两组存储阵列中间有两条逻辑链路一条是数据复制链路另一条是缓存同步/锁管理链路。具体实现方案有两类存储网关方案在两个存储阵列前面各加一台存储虚拟化网关常见的有IBM SVC、HDS VSP G系列等网关之间同步数据后端存储不感知双活。图上要在存储上面多画一层网关层。存储原生双活方案存储阵列本身支持双活比如华为HyperMetro、戴尔EMC的VPLEX、Pure的ActiveCluster两个阵列直接对拷不依赖额外网关。图上直接画两个阵列之间的双写链路即可。2.3 应用与接入层流量怎么活起来存储只是数据底座应用层必须能够在两个中心同时提供对外服务这就依赖两样东西数据中心内部的负载均衡和跨数据中心的全局负载均衡。原理图的画法一般是用户流量先经过最上层的全局负载均衡GSLB或DNS智能解析按策略分到两个中心每个中心内部又有本地负载均衡SLB把流量分到后面的应用服务器集群应用服务器下面挂数据库数据库再往下是存储。这里建议画图时把逻辑链路和物理链路分开物理链路用实线逻辑调度关系用虚线。比如GSLB到两个中心SLB之间的调度关系物理上其实走的是公网或专线但逻辑上是调度一跳用虚线表达更清楚。2.4 仲裁节点防止大脑分裂双活架构最怕的故障是脑裂——两个中心之间的链路断了但两边都还活着各自认为对方已死同时抢占资源这时候数据就乱了。解决脑裂必须靠仲裁机制。原理图上要把仲裁节点放在显眼位置可以画成独立于两个中心的第三个站点也可以画成双中心互为仲裁还有的是利用存储阵列自带的仲裁盘机制。无论哪种必须画出来并标注仲裁策略。没有仲裁节点的双活图等于没有刹车系统的跑车——好看但不敢开。3. 双活那张图里最容易被画错的三个技术点3.1 双写链路的方向双向而非单向我见过不少原理图存储复制链路画的是一个箭头从A指向B这暴露了画图人对双活的理解还停留在同步复制阶段。双活的双写是双向的任何一端写入数据另一端都要同步。图上应该画成双向箭头或者用两条方向相反的箭头并且标注双写同步。双写这件事还牵扯到一致性组的概念一个应用关联的多个LUN必须作为一个整体同步不能出现这个LUN同步成功了另一个失败。图上如果要细致可以把一致性组用虚线框圈起来标注。当然这是细化层面的事原理图阶段点到为止即可。3.2 仲裁链路不能顺便和业务共用一条线很多图把仲裁链路画成从数据中心A拉一条线到数据中心B没有标注优先级、没有画成独立链路。实际上仲裁帧虽然数据量极小但对链路质量很敏感最好用独立的物理通道或者至少是独立的逻辑通道。在原理图上我建议把仲裁链路用醒目的颜色比如橙色单独画出来和业务链路、存储复制链路区分开并且标注专用链路低时延或独立于业务链路。这样评审的时候运维一眼就能确认仲裁通信不会因为业务拥塞而超时。3.3 时延标注决定方案可用的那根红线双活不是想多远就多远。存储双写的IO时延取决于两个存储之间链路的往返时间。以典型的数据库应用为例单次写操作如果网络开销超过1-2毫秒整个数据库的提交耗时就会肉眼可见地恶化。所以图上在A和B之间那条链路上务必标注RTT≤X ms。建议标注实测值或设计值比如5ms让看的人通过这个数字判断方案是否可行。顺带补一个知识点双活距离限制和光速有关。光在光纤中的传播速度大约是每毫秒100公里考虑光纤的折射率实际约200公里/毫秒往返所以100公里级的双活光本身往返传输就需要约1-2毫秒再叠加设备处理时延现实的稳定方案一般控制在50-100公里。这些不是图上必须写的细节但它解释了为什么要强调时延标注。4. 修改这份PPT的实操方法分层、配色与信息降噪标题说了原图可修改那这份PPT大概率会被不同角色的人反复打开。如果原图把所有信息堆在一张幻灯片上我建议动手之前先做三件事能让图的可用性上一个台阶。4.1 拆图总览图加分层图比一张全图更专业原理图PPT常见问题是一页放不下硬把所有元素压缩到一张结果文字看不清、链路交叉混乱、改一处要拖动二十个形状。我的习惯是拆成三种图总览逻辑图画两个数据中心、三条核心链路业务链路、存储复制链路、仲裁链路一句话讲清楚双活大格局存储数据平面图专门画存储双活、一致性组、快照/备份的关系网络与接入图专门画GSLB、SLB、防火墙、交换机等网络接入链路。三张图放到三页PPT里既保留了整体感又方便评审时单页深入追问。标题已经说明原图可修改那就大胆调整结构。4.2 利用PPT图层组管理可编辑性一份能长期使用的原理图PPT不是画得漂亮而是改起来方便。把站点边框设备图标线路连接标注文字分别放进不同的组合Group这样挪动站点框时线不会断成一堆所有设备图标统一用图标库或形状绘制不要一个截图一个形状混着来配色保持克制建议站点背景用2种颜色区分A/B中心链路类型用3种固定颜色比如蓝色业务链路红色存储复制链路橙色仲裁链路逻辑关系统一用虚线。加一个图例评审时不用反复解释。4.3 每条线都要能说清楚是什么、为什么修改原理图时我给自己的硬性要求是图上每一条线被问到时都能回答三个问题——这条线承载什么协议是多大的带宽如果断了会怎样存储复制链路标注协议FC或IP、带宽、同步模式同步/异步、时延要求业务链路标注应用协议、流量方向、冗余方式负载分担或主备仲裁链路标注仲裁机制如第三方仲裁站点、优先站点策略、链路独立性。这样改完图就不再是给人看的示意图而是一张能直接支撑方案评审和故障演练的工程图。我曾经把一份只有框和线的概念图改成带标注的版本后集成商对我们的需求理解明显少了很多来回确认。5. 看图辨架构拿到一份双活原理图时我通常会追问的三个问题最后聊一个附加技能当你作为评审角色拿到别人画的双活原理图时怎么快速判断这套架构有没有价值。不要只看图美不美按下面三个问题往下问一般问完就能把图纸背后的真实水平摸个七七八八。5.1 双活到什么程度RPO/RTO到底是多少如果图上只有双活两个字却找不到RPO/RTO的说明那基本可以断定这是概念汇报图。真正落地的双活方案一定写清楚预期指标RPO是否为0RTO是分钟级还是小时级。更细一点还可以追问故障范围——是数据中心整体故障还是某台存储故障、某个网络分区故障不同故障场景下指标可能不同。5.2 故障切换是自动还是手动仲裁策略是什么这个问题能测试架构的成熟度。有的双活其实只是存储层双活应用层切换要靠人工改DNS、改负载均衡这在图上看不出来必须问。另外要问仲裁机制存储仲裁放在哪如果仲裁站点也挂了还有没有兜底策略能答上来的人说明真的做过双活答不上来的说明还在概念阶段。5.3 数据库层和中间件成对了吗是双活还是主备这是最容易混淆的地方。很多双活项目做到了存储双活、网络双活但数据库层是主备模式同一时刻只有一个库接受写入另一侧只读或者完全待机。这不叫全链路双活准确说叫存储层双活应用层双活数据库主备。如果图里把数据库标成了两个节点都活但没有画数据库级的同步方案如RAC、AlwaysOn、OGG等就要追问清楚。数据库双活比存储双活复杂得多涉及分布式事务、冲突处理、全局一致性视图不是一张图能含糊带过的。5.4 别把接入层双活当成数据中心双活最后提醒一个常见的PPT陷阱有的架构图只是把两个数据中心各画了一排Web服务器前面加了一个全局负载均衡就标注双活。这本质上是接入层双活后端数据库和存储仍是单点。图看着没问题但业务连续性保障能力非常有限。看到这种图建议直接把问题抛出来Web节点可以双活那数据库主库压在一台机器上这台挂了怎么办问完这张图的价值就显现了。我个人的经验是一份可修改的双活原理图真正的价值不在于它的美术效果而在于它能否被不同角色的人反复推演。存储双活、仲裁链路、全局调度这三条线画清楚了图就成功了大半。如果看到哪张图三个核心链路缺了一条别急着改样式先补架构再谈美化。本文还有配套的精品资源点击获取