可编辑双活数据中心原理图:架构解析与改图避坑指南
简介双活数据中心是高可用架构中的经典方案这份PPT以原理图形式完整呈现双活数据中心的核心组件与拓扑关系涵盖架构设计、网络架构、存储架构、服务器架构、数据库架构、应用架构及HA架构等模块适合数据中心运维工程师、架构师及正在备考高级网络或云计算认证的读者快速理解双活容灾的关键设计。图片为可修改原图便于按需调整配色、标注或二次绘制。资源为单个PPT文件大小3.77MB核心是一张层次清晰的双活数据中心全景原理图同时附带主故障域、备故障域、仲裁节点、机房间链路等关键要素的图例说明。目前已有205人学习下载。读者可借助该图梳理主备故障域间的仲裁机制、Oracle RAC架构下的数据库高可用部署、存储网络规划以及多应用APP1-APP4的HA容灾路径节省自行绘图和整理架构的时间适合作为方案汇报、课程讲解或文档配图的直接材料。1. 双活数据中心原理图一份能改的架构图不是一张只能看的截图做运维和架构的人应该都有过这种经历网上找了一圈双活数据中心的方案图下载下来全是整张的图片想改个机房名、换个IP都得重新画。这份PPT原理图的价值就在于“原图可修改”——图里每一个框、每一条连线、每一处文字都是矢量对象双击就能编辑适合售前画方案、运维做汇报、架构师评审架构时直接拿来改。双活数据中心本身也不是什么新概念两个机房同时对外提供服务任何一个机房整体故障业务都不中断关键在于数据怎么同步、流量怎么切换、脑裂怎么防。这篇笔记就按“原理图怎么读 → 双活机制怎么落地 → 原图怎么改 → 哪些细节容易画错 → 怎么验证图合格”一路讲下来照着做你也能把这张图改成自己方案里能用的那张。2. 把原理图读透双活架构的组件、连线与两个核心机制2.1 先看框架双活架构里那几层和它们之间的连线关系拿到这张PPT第一件事不是改而是读懂图里的分层逻辑。常见的双活数据中心原理图会画成上下三层的结构最上面是接入层中间是应用层最下面是数据层。两个数据中心左右并列中间用几条线连起来旁边通常还挂一个仲裁站点。图里每个框都不是随便画的接入层的负载均衡设备负责把用户流量分到两个机房应用层的应用集群在两个机房都活着数据层的存储或数据库负责保证两边数据一致。图里最值得注意的不是那些实心的业务流量线而是虚线和标注。业务流量线一般是粗实线表示用户请求从外部进来、经过负载均衡到应用、再到底层数据心跳线是细虚线表示两个机房之间互相探活的通道。原理图的核心就是把这两类线分清楚——实线是数据面虚线是控制面很多人在图上把这两种线混着画方案评审时一眼就被问住了。连线之外还要看标注。一份合格的双活原理图至少会在链路上标注RPO和RTO的承诺值会在仲裁站点旁边标注仲裁规则会在两个数据中心之间标注链路的距离或时延。拿到原图后先花五分钟把这些标注扫一遍基本就摸清了这张图对应的方案设计思路。如果图里只有框和线、没有任何标注那它只是一张拓扑草图还不是一份能拿去汇报的原理图。2.2 应用双活与数据双活图里两条关键链路双活数据中心要真正成立必须同时解决两个问题应用层双活和数据层双活。两张图里最容易忽略的是数据层因为应用层双活相对好做——两个机房各部署一套应用集群前面用负载均衡把流量按比例分发任何一个机房挂了负载均衡把流量全切到另一边就行。数据层双活才是双活的灵魂也是最难画清楚的部分。常见做法是在两个机房的存储之间建立同步复制关系两边各有一份完整数据任何一笔写操作必须同时落到两个机房才算成功。这张原理图里数据层通常会用一对存储阵列加一条粗实线表示同步复制链路线上标注带宽和时延要求。另一种常见的数据双活形态是数据库层直接双活不依赖存储复制。比如基于数据库集群方案让同一个数据库集群的节点分别部署在两个机房两边同时提供读写。这时候原理图的数据层就不再画“存储复制线”而是画一个跨两个机房的数据库集群节点之间的通信线单独标注。这两种形态在PPT里看起来差别不大实际方案设计差很多改图之前要先确认原图画的是哪一种。判断方法很简单看数据层是画了两套存储加一条复制链路还是画了一个跨机房的数据库集群。前者走的是存储复制路线后者走的是数据库原生双活路线。2.3 心跳线、仲裁站点和脑裂防护图上最容易画错的部分双活数据中心有一个所有人都会问的问题两个机房之间的网络断了怎么办这就是脑裂场景——两个机房都认为对方挂了都抢着接管业务数据就会两边写、产生分叉。防脑裂的机制就是仲裁原理图里一定要把仲裁画出来。最常见的仲裁设计是引入第三个站点作为仲裁者这个站点可以是一个轻量机房也可以只是一台部署在第三方机房的仲裁虚拟机。两个数据中心之间通过心跳线互相探测同时都跟仲裁站点保持连接。当心跳线中断时仲裁站点根据两边的心跳状态决定谁是活着的那个让另一方降级为只读或直接停止服务。原理图上画这部分时容易犯两个错误。一个是不画仲裁图上只有两个机房间的心跳线评审时被问“网络断了怎么办”就答不上来另一个是把仲裁画在其中一个数据中心内部这样仲裁本身就跟被仲裁方成了同生共死的关系起不到第三方判定作用。正确画法是仲裁独立于两个数据中心之外用虚线分别连到两边线上标注“仲裁心跳”。另外我把之前做方案时踩过的坑也列出来了都在后面避坑章节里改图时对照着检查一遍比返工强。3. 数据中心双活的数据同步复制模式、参数与链路风险3.1 同步复制与异步复制用在哪条链路上双活的“活”字建立在两份数据一致的基础上所以数据同步方式值得单独讲清楚。存储层的复制模式分同步和异步两种原理图上的标注不同方案的RPO承诺就完全不同。同步复制的逻辑是应用发出一次写请求存储先把数据写到本端同时通过复制链路发给对端两端都落盘成功后才向应用返回“写入成功”。这个模式下任何时间点两个机房的数据都是一致的机房故障时RPO等于零一份数据都不丢。代价是每一次写操作的延迟都包含链路的往返时间跨机房的物理距离越远延迟越高应用性能受影响越大。异步复制则相反本端写入成功就直接返回数据在后台异步地往对端传。性能好、对链路不敏感但灾难发生时对端可能缺了最近一小段时间的数据RPO不再是零。双活数据中心为了追求“两边都能随时接管”主链路一般都用同步复制异步复制只会用在跨城灾备这种对RPO要求不那么苛刻的场景。原理图里如果两个机房之间只画了一条复制线务必确认线上标注的是同步还是异步。我拿到原图后的第一个动作就是看这条线。3.2 同步复制的参数与链路质量要求同步复制链路不是随便拉一条专线就能用的。距离和时延是硬指标距离越远光线传播耗时越长时延越大每一次写操作的额外开销越大。实测经验里同城双活的两个机房距离控制在20公里以内比较稳妥两端的网络往返时延RTT要稳定在5毫秒以内。超出这个范围应用写性能的劣化会变得非常明显有些在线交易类的业务甚至会出现超时。带宽方面同步复制对带宽的要求取决于业务写入量。如果峰值写入流量是每秒200MB那复制链路至少要预留400MB以上的带宽——因为同步复制虽然有压缩和重删机制但你不能把压缩率当成保证值来规划。更稳妥的做法是在复制链路上跑专门的性能测试工具连续压测几个小时观察延迟的抖动情况。延迟的平均值低不算好关键是峰值延迟不能高因为高延迟会直接拖慢应用写入。原理图改到这里时我一般会在复制链路上补一行小字标注“建议距离≤20kmRTT≤5ms带宽≥2×峰值写流量”。这行字是方案图的加分项评审时一看就知道画图的人真做过落地而不是只画了个拓扑。顺带一个经验链路的稳定性比带宽大小更重要。带宽不够最多是慢一点链路抖动造成的同步中断却可能触发复制会话重置严重时两边数据产生不一致需要重新做同步那才是真正的灾难现场。3.3 数据库层的双活选型从存储复制到数据库原生方案数据双活不只有存储同步复制一条路数据库层还有原生双活方案。图2.2里提过这类方案的本质是把同一个数据库集群的节点打散到两个机房两个机房都跑着同一个集群的节点任何一边的节点都能接受读写数据一致性由数据库集群内部机制保证不需要在存储层做复制。这种方案的好处是RPO为零而且不存在存储复制切换的中间态应用感知不到任何切换动作代价是数据库版本和架构受限不是所有数据库都支持这种跨机房集群部署网络抖动对集群的影响也比较敏感。原理图上这两种方案长得很像但组件画法明显不同。存储复制方案的图里一定有两套存储阵列阵列之间画一条带标注的复制线数据库层画的是独立的双机集群或单机。数据库原生双活方案的图上存储层往往只画一层共享存储或各画各的本地盘重点是数据库层画一个大集群集群节点跨两个机房分布节点之间的连线要标注集群内部通信。改图时先问自己一句这张原图的数据层走的是哪条技术路线不是的话把图里数据层的框和线全部换掉不要试图通过改文字把存储复制方案说成数据库原生方案评审专家一眼就能拆穿。选型建议上如果业务对一致性要求极高、应用本身不太依赖数据库扩展能力走存储复制路线更通用如果应用已经跑在支持跨机房集群的数据库上数据库原生方案更干净。4. 动笔改这张PPT解组、改线、加标注的完整做法4.1 先检查这份原图是矢量还是位图拿到文件后别急着改第一步先确认图里的元素是不是矢量对象。判断方法在PowerPoint里点击图中的一个方框看选中后外围有没有出现可拖动的白色圆形控制点。有说明是形状对象可以编辑没有或者一选就是整张图被框住那很可能是位图需要先找原始绘图文件。这份标题里写明了“原图可修改”正常情况里面全是矢量形状和文本框。但下载过太多所谓“可编辑PPT”后我养成了一个习惯先整体选中看是否全部是形状和文本框再看有没有嵌入的图片对象。我遇到过不止一次某个PPT里标题和说明文字是可编辑的文本框中间架构图却是嵌进去的一张整图这种只能算半可编辑。真遇到这种情况唯一靠谱的做法是按原图的拓扑结构重新画一遍别想在位图上修补。确认矢量后先点选图里任意一个元素右键查看是否有“组合”菜单。绝大多数PPT架构图会把所有形状编成一个总组合。如果是组合先复制一份原始页面再操作避免改了以后想回退却找不到原版。用两侧的CtrlShiftG连续解组直到每一个方框单独可选中为止。解开组合后的常见现象是文字错位、甚至出现乱码或者排版错乱。因为当初做图的人可能用的是某一个字体字体缺失时PowerPoint会自动用其他字体替换并改变文字宽度所有文本框都变了形。解决方法是全选文字统一重设字体和字号。做这一步的VBA代码如下它会把当前选中页面里的所有文本框字体统一成“微软雅黑”遇到字体缺失时直接在本机补齐。Sub FixFonts() Dim sld As Slide Dim shp As Shape For Each sld In ActivePresentation.Slides For Each shp In sld.Shapes If shp.HasTextFrame Then shp.TextFrame.TextRange.Font.Name 微软雅黑 shp.TextFrame.TextRange.Font.Size 14 End If Next shp Next sld End Sub在这段代码里外层循环遍历所有幻灯片内层循环遍历每张页面的所有形状逐个判断是否带文本框。统一字体和字号的意义在于字体缺失是解组后最影响观感的问题手动一个个改又容易漏跑一遍脚本至少保证全图字体一致。字号统一为14磅只是保守默认值实际使用时可以先注释掉字号那一行只统一字体避免改动后文字溢出原来的框。4.2 改文字和IP最常用的三个操作解组完成后实际改图最频繁的操作是改机房名、改IP地址、改应用名。三个操作都不难难的是改完之后不能破坏原有布局。下面三个习惯我每次都会用至今没翻过车。改IP时用等宽字体。IP地址的数字对齐在等宽字体下是严格逐字符对齐的比如“192.168.1.10”和“192.168.11.2”用等宽字体显示时冒号和数字的宽度完全一致修改后不容易让人看出差异。宋体和微软雅黑在“1”和“11”这类字符上宽度不同改完以后整个框的布局会轻微跳动。实际操作中我会把图里所有IP文本框字体统一换成“Consolas”并保持字号不变。改应用名时先调整文本框宽度再居中。直接把新名字敲进去经常会发现文字溢出框外原因不是字号不对而是新的名字比原来的长文本框默认不会自动调整大小。选中文本框后先把框拉宽设置文本垂直居中再修改名字最后按Ctrl方向键微调位置。改完顺手检查框内文字有没有被截断或换行有时候一个词被折到第二行整行对齐就乱了。批量替换文字用VBA比手动高效得多。下图里这段宏会把所有形状中出现的旧机房名替换成新名字同时保持格式不变。这是个通用脚本把Replace参数换成你实际要替换的内容即可。Sub BatchReplace() Dim sld As Slide Dim shp As Shape Dim oldText As String Dim newText As String oldText 机房A newText 中心一 For Each sld In ActivePresentation.Slides For Each shp In sld.Shapes If shp.HasTextFrame Then If InStr(shp.TextFrame.TextRange.Text, oldText) 0 Then shp.TextFrame.TextRange.Text Replace(shp.TextFrame.TextRange.Text, oldText, newText) End If End If Next shp Next sld End Sub这段脚本的原理是逐页逐形状检查文本框内容包含旧文字就整体替换。有个坑要注意它只能改Shape类型的文本框如果原图里的文字在表格或组合内部需要先解组或先用表格逐一改。另一个更隐蔽的问题是文字可能被拆成了多个文本框比如一个矩形里既有标题又有内容这时要分别处理不能指望一次替换全改完。4.3 加新组件时怎么保持连线整洁原图再完整落到具体方案时总要加东西。最常见的是加新应用节点、加新存储设备、在链路上加标注。大部分人在这一步开始翻车因为新增的框和连线跟原有的风格不一致一眼就看出来是后加的。加框之前先选中一个已有的同类框复制一份再改文字这是保证风格一致最好的方法。直接新建形状虽然快但边框粗细、颜色、阴影、圆角半径这几个属性很难手动调到和原有元素一致。在已有框的基础上改文字新框跟原图就是同一套视觉语言。如果新增的是一个列表里没有的组件类型比如原来只有“应用服务器”现在要加“消息队列”那就选一个最接近的框类型复制然后改文字不要从空白插入。加连线时优先使用“连接符”而不是普通直线。PowerPoint里插入菜单下的“直线”跟“肘形连接符”有本质区别前者只是画了一条线移动任何一个框时线不会自动跟随后者是真正的连接线两端粘在形状上移动框时线自动伸缩。架构图改动最频繁的操作就是微调位置如果所有连线都是普通直线每动一个框都要手动修线费时还容易留下不齐的线头。按键方式插入→形状→线条→肘形连接符然后把两端分别拖到两个框的锚点上看到锚点变红就是吸附成功。连线相撞也是加组件后常见的问题。新增的框如果放在原有的连线路径上线会从框上面或下面穿过图面变得很乱。解决办法有两种一是加框之前先观察周边哪些区域有线经过避开这些位置二是利用“置于底层”或“置于顶层”调整层次让线从框后面走过去不遮挡文字。线多的地方能绕开就绕开绕不开就跟用户解释千万不要让两条线形成一个假的交叉点——评审时有人会以为那是网络汇聚点。5. 双活原理图避坑指南五个让方案图翻车的细节按“现象→原因→解决”的格式收录五条真实踩坑记录每一条都在实际评审或汇报中造成过问题。改完图之后对着这五条过一遍能省掉很多解释工作。5.1 网络分区后仲裁在哪图上没画清楚等于方案没想清楚现象原理图里两个数据中心有业务链路有复制链路也有心跳线但找不到仲裁组件。被问到“两个机房之间网络断了怎么处理”回答不上来方案直接被打回。原因画图时只参考了双活架构的功能性组件忽略了脑裂防护这个最关键的可靠性设计。没画仲裁在评审方看来就是没有考虑脑裂风险。解决补画仲裁站点放在两个数据中心之外的第三方位置用虚线分别连到两个机房。虚线上标注“仲裁心跳独立链路”。如果真实方案里确实没有独立仲裁而是利用其中一侧兼做仲裁那至少要在图上用文字明确标注仲裁角色并说明这种设计的局限性。5.2 只画存储复制不画数据库冲突同步复制解决不了逻辑冲突现象双活的数据链路图上只有存储同步复制一条线但应用层的数据库画成了两个机房各自独立的双机集群。评审问“两边数据库同时接受写入主键冲不冲突”现场才发现方案里根本没讨论。原因存储同步复制解决的是数据块层面的物理一致解决不了应用层面两个机房同时写同一行数据的逻辑冲突。两块存储上的数据永远一致但两个数据库实例同时对同一条记录写入时后写的一方会覆盖先写的一方业务逻辑错乱。解决方案设计阶段就要确认数据库层采用哪种双活模式。如果是存储复制路线数据库层往往需要配合主备切换机制同一时间只有一边能写如果是数据库原生双活路线图要改成跨机房的统一集群。画图时把数据库层的角色标注清楚注明“主写中心”还是“双写中心”别让评审替你去猜。5.3 心跳线画成业务链路图上分不清控制面和数据面现象原理图里两个机房之间只画了一条粗实线上面既跑业务流量又是心跳链路。汇报时说“这条线同时承担两种角色”评审现场就追问心跳断了和业务中断如何区分会不会心跳跟业务互相影响。原因画图时嫌线多影响美观把心跳复用在业务链路上。实际上控制面和数据面的可靠性要求完全不同业务链路断了可以做应用切换心跳出问题则会触发脑裂判定性质完全不一样。解决尽管理论上心跳可以和业务共用传输通道原理图上一定要分成两条线。业务流量用粗实线心跳用虚线或单独的细线标注“业务流量”和“心跳链路”两个名字。如果方案里确实复用了物理链路图上拆成两条虚拟通道并注明“共享物理链路”也远好过画成一条线含糊带过。5.4 忘了标注RPO和RTO架构图画得再完整承诺值缺失等于白画现象图里所有组件、链路、仲裁齐全但没有任何地方写RPO和RTO。汇报时被问“你们承诺数据丢多少、恢复多久”回答“大概不丢、大概几分钟”评审当场失去信心。原因画图的人聚焦在拓扑结构上认为指标是文字方案的事跟图无关。实际评审时评审专家看图会默认图上展示的所有信息是方案核心缺少的指标就意味着方案没做过推演。解决在数据复制链路上标注RPO0同步复制或RPO≤某值异步复制在切换流程示意图或关键组件旁标注RTO目标值。数值不需要写得太绝对但要让评审看到你做过定量承诺。一个常见做法是在图右下角加一个表格列出RPO、RTO、链路带宽、最大距离四个参数一图胜千言。5.5 改动后出现叠字、乱线、对不齐原图可修改的前提是改完还能看现象把原图改完一轮后局部文字叠在一起部分连线走位混乱两个原本对齐的框高度不一致。打印或投屏展示时整个图像一张拼贴画与原模板品质差距很大。原因改动过程中只关注了内容正确性忽略了布局维护。PowerPoint在叠加了“改文字高度变化”“移动框时连接符自动伸长”“批量替换后文本长度不一致”这三个因素之后布局迟早会乱。解决每改完一类内容立即执行一次对齐操作。选中逻辑上应该在同一水平线上的多个框使用“格式→对齐→顶端对齐”或“横向分布”几秒钟就能拉齐。调整完文字大小后快速扫描一遍所有框看有没有文字溢出的按4.2里的方法调整框宽。最后再用“视图→显示比例→适应窗口”整体看一眼缩略效果往往能发现局部的乱线。6. 用这张原图讲清一次真实切换验证原理图是否合格的检验法原理图画得再漂亮讲不清切换流程就是一张废图。我判断一张双活原理图合不合格只看一件事拿一个故障场景能不能照着图把流程讲完。推荐的做法是做完图后用“中心机房整体故障”这个最极端的场景来验证。沿着图的流向往下一个节点走用户流量被负载均衡切到另一侧应用继续服务数据库写入路径切换复制链路自动隔离仲裁判定原中心脱离集群。流程中每一步都要能在图上找到对应的元素——有箭头指引、有链路标注、有组件承接。找不到的那一步就是图需要补的地方。我一般在讲完主流程后会加一页“切换时序图”用箭头从上到下串起时间轴标注每步切换的触发条件和预计耗时RTO的承诺值靠这一页来支撑。最后一页常放一段我自己的教训有一次评审前改了机房名全局替换跑完没检查文字是否溢出投屏时一个核心组件的名字折成了两行当场非常尴尬。从此凡是动过文字的图发出去之前必按5.5的做法整体过一遍。这张原理图的最大价值也正在于此——它是一份能反复修改的基础设施而不是一次性的汇报材料读透、改好、讲得清你手里的图就是方案最好的说明书。希望帮到你。本文还有配套的精品资源点击获取