服务器托管要不要做同城双机房?灾备规划五步定

不是所有业务都需要双机房。停机以分钟计就有明显损失的核心系统值得做,内部和归档类系统用单机房加异地备份通常就够。

要点速览

• 是否做双机房,看停机容忍时间和数据丢失容忍度
• 核心系统考虑双活或温备,内部和归档用单机房加备份
• 两处机房要供电、路由独立,时延满足同步方式
• 切换要明确触发条件、决策人和回切方案,并定期演练
• 成本按机柜、带宽、授权、人力、演练逐项叠加估算

先说结论:托管业务不一定都要做同城双机房。判断主要看两件事。一是业务停一段时间会损失多少,也就是停机容忍时间(常说的 RTO)。二是出问题时能接受丢掉多久的数据,也就是数据丢失容忍度(常说的 RPO)。对外交易、核心生产、对客户承诺连续服务的系统,停机以分钟计就会造成明显损失,值得做双机房。内部办公、报表、测试开发、归档类系统,用单机房托管,再加上可靠的定期备份和存放在另一处的副本,通常就够了。双机房也不是“有或没有”的开关,而是从冷备、温备到双活的一段梯度。它应当按业务分级逐个确定,不宜整体一刀切。

先分清:什么业务值得做双机房

很多企业讨论灾备时,一上来就问“双活要多少钱”。更该先问的是:哪些系统真的停不起。可以用下面的粗分做个起点:

• 值得认真考虑双机房的:在线交易与支付、对外服务的核心接口、生产调度系统,以及合同里对客户约定了服务时长的系统。这类业务一旦停机,会直接对应收入损失或违约风险。
• 温备或冷备就够的:内部业务系统、CRM、OA、内部知识与文档系统。停几个小时会影响效率,但可以靠手工流程临时顶上。
• 单机房加备份即可的:测试与开发环境、日志归档、历史报表、离线分析。这些系统更需要的是“数据别丢”,而不是“服务别停”。

要注意,备份和灾备不是一回事。备份解决的是数据能不能找回来,灾备解决的是业务能不能在另一处跑起来。很多企业有备份,却没有可用的恢复环境,真出事时才发现找回数据要花一两天,业务早已等不起。

一、梳理业务分级:用两把尺子量清楚

分级不能只由 IT 部门闭门完成,应当拉上业务负责人一起定。建议按以下顺序推进:

1. 列清单:把托管在机房里的系统逐个列出,包括容易被忽略的公共依赖,比如数据库、身份认证、域名解析、消息队列、文件存储。核心系统能不能恢复,往往卡在这些依赖上。
2. 问两个数:每个系统都要问业务方两件事:停多久开始造成实质损失,能接受丢多长时间的数据。答案不必精确,但要落成文字,双方都认可。
3. 分三档:按答案把系统归为核心、重要、一般三档,每档对应一种灾备形态。档位之间如果有依赖关系,被依赖系统的档位不能低于依赖它的系统。
4. 定期复核:业务会变化,去年的内部工具今年可能已经对外开放。分级表建议每年至少复核一次,遇到重大业务调整时同步更新。

二、选择形态:冷备、温备、双活各要付出什么

冷备

备用端只保存数据副本和必要的配置。设备平时不常开,或者干脆没有对应设备,出事时再启动或采购上架。这种形态成本低、复杂度低,代价是恢复时间长,通常以小时甚至天计,适合一般档系统。

温备

备用端有一套规模较小、处于运行状态的环境,数据按一定频率同步过去。出事时把业务切到备端,再视情况扩容。它的成本和复杂度适中,是多数企业核心以下系统的现实选择,也是第一次做双机房时比较稳妥的起点。

双活

两处机房同时对外提供服务,数据实时或准实时同步,一处故障时流量转到另一处。双活恢复快,但对应用架构、数据库一致性、网络时延和运维能力的要求都明显更高,改造工作量也不小。买了两套设备并不等于双活,应用本身要支持多点写入,或者有清晰的主从切换逻辑才行。

实际规划中,常见做法是混合使用:核心交易系统做双活或高配温备,内部系统做温备,归档与测试做冷备。这样既控制了投入,也把钱花在停不起的地方。

三、核对两处机房:距离、专线与时延

两处机房的选址受一对相反的约束。离得太近,两地可能共用同一片供电区域、同一条运营商路由,或者同时受到同一场极端天气影响,灾备就形同虚设。离得太远,网络时延上升,数据同步跟不上,双活和高频同步就难以实现。同城不同区是两者之间的折中,能兼顾独立性和同步时延。它覆盖不了城市级的大范围事件,针对这类风险,可以在异地另外保留一份离线或低频副本作补充。

具体核对时,建议向机房逐项确认:

• 两处机房的市电接入是否来自不同来源,各自的供电与制冷冗余如何配置;
• 运营商线路是否走不同的物理路由,有没有多家运营商接入;
• 两地之间能否提供专线,专线带宽能否覆盖日常同步量,以及峰值时期的追赶量;
• 两地之间的实测时延与抖动,是否满足所选同步方式的要求。

带宽的计算方法和签约前该问的问题,可以参考服务器托管带宽怎么选一文。机房停机的常见原因与防范思路,在托管数据中心为什么会停机里有展开,规划双机房前值得过一遍。它能帮你分清哪些风险靠单机房冗余就能缓解,哪些必须靠第二处机房。

四、写清切换与演练:谁来触发、多久恢复、多久练一次

双机房建好之后,真正决定效果的是切换流程。不少项目设备齐全,故障当下却因为“谁来决定切”耽误了时间。建议提前写清以下几项:

• 触发条件:什么情况下启动切换。例如主端核心服务不可用超过约定时长,或者机房方发出明确的故障通告。
• 决策人与备份决策人:谁有权下令切换,联系不上时由谁接替,避免层层请示。
• 操作手册:把域名解析、IP 切换、数据库主从调整、应用启动的顺序,逐步写成可以照着执行的步骤。
• 回切方案:主端恢复后,数据如何同步回来、何时切回。这一步常被忽略,却很容易出现数据冲突。

演练频率可以分层安排。单个组件的恢复测试频率高一些,整体切换演练选在业务低峰期定期进行。每次演练都记录实际恢复时间和数据差异,与分级时定下的目标对照。如果长期达不到目标,要么调整形态,要么调整预期,不要让文档里的数字一直停在纸面上。

五、算清账:双机房不是简单乘以二

双机房的成本由几部分叠加而成,建议逐项估算:

1. 机柜与电力:备端设备规模可以小于主端,但要预留扩容空间,功率要按切换后的满载情况评估。
2. 带宽与专线:两地都要准备对外带宽,两地之间的专线是额外的持续支出。
3. 设备与软件授权:服务器、存储、网络设备,以及数据库、虚拟化、同步工具的授权。有些授权按节点计费,双端会翻倍。
4. 运维人力:两处巡检、两处变更、配置一致性维护都会增加工作量,需要有人专门负责,防止两端配置出现偏差。
5. 演练与改造:应用为支持切换所做的改造,以及每次演练投入的人力和窗口期。

把这笔账和分级表里的停机损失放在一起比,就能看出哪些系统值得上双活,哪些做温备就划算。账算不平的系统,退一档并不丢人。

同城两处机房的一个参考:前海云与田心

以润迅为例,润迅在深圳自建并运营两处数据中心。前海云位于深圳宝安,面积近 1 万平方米,拥有 1400+ 机柜,按 T3+ 标准建设。田心位于深圳罗湖,拥有 400+ 机柜。两处同在深圳、分属不同城区,可以作为同城两处机房布局的一种参考思路。比如把主生产环境放在一处,把温备或备份环境放在另一处。

需要说明的是,两处之间具体的互联方式、可用的网络方案与带宽规格,以及具体业务能达到的可用性,都要结合业务情况评估,以业务咨询的结论为准,这里不给统一说法或数值。同城布局也不能替代异地副本,城市级风险仍建议另作安排。两处机房的设施情况可以在润迅数据中心页面查看。

双机房规划自查清单

1. 所有托管系统已列清,包括数据库、认证、域名解析等公共依赖。
2. 每个系统的停机容忍时间和数据丢失容忍度,已与业务方书面确认。
3. 系统已分档,被依赖系统的档位不低于依赖它的系统。
4. 每一档对应的灾备形态(冷备、温备、双活)已确定,并写明理由。
5. 已确认两处机房的供电来源、运营商路由相互独立。
6. 两地专线带宽、实测时延与抖动满足所选同步方式。
7. 城市级风险有异地副本兜底。
8. 切换触发条件、决策人、备份决策人已写入文档。
9. 切换与回切操作手册可以直接照着执行。
10. 演练计划、频率、记录模板已建立,演练结果定期与目标对照。
11. 机柜、带宽、授权、人力、演练成本已逐项估算,并与停机损失做过对比。

行动建议

如果你正在考虑做双机房,可以按这样的节奏推进。第一步,花一两周把分级表做出来,这一步不需要任何采购。第二步,挑一两个核心系统从温备开始试,跑通切换和演练,再决定是否扩大范围或升级为双活。第三步,选第二处机房时,带着上面的清单逐项去问。如果涉及把部分业务迁到新机房,可以参考服务器搬迁机房要核对什么里的迁移前、割接中、上线后清单。如果需要结合前海云与田心评估具体方案,可以拨打润迅业务热线 400-854-5566 沟通。

→ 联系润迅,聊聊你的场景,获取适合的方案