凌云时刻 · 技术

导读：为什么要做容灾？什么是容灾系统？容灾和备份的区别是什么？

作者 | 云享

来源 | 凌云时刻（微信号：linuxpk）

开场白

Hi，从你点开这篇文章起，已经在和我一起开启容灾探索之旅。从本篇文章开始，我和我的小伙伴们会陆续推出系列文章，从不同视角、不同维度来介绍容灾系统架构设计及容灾交付中的那些事儿。

也许你对容灾体系不够了解、对业务如何实现容灾没有思路、不了解容灾演练如何规划......

No Problem！我们团队的应用容灾服务包已经上架，可以为你排忧解难！我们有成熟的容灾调研评估方法论、有丰富的应用容灾架构和部署规划经验、有大量成功的容灾演练项目实战经验。作为一个容灾交付人，有义务也有必要利用我们的技术积累和项目沉淀，和兄弟团队一起，为我们客户的容灾体系建设添砖加瓦，让客户用好云的同时，安全用云！

本篇，先给大家介绍下容灾系统建设的前世今生，了解下容灾系统建设的背景及意义。然后，逐步推出“靠谱”的云厂商应该具备什么样的容灾能力、主流容灾架构形态、企业应用架构容灾实战、金融业容灾最佳实践等系列主题或文章，由浅入深，理论结合实战，把容灾交付这件事讲清楚。

为了方便大家更加直观的了解系列文章全貌，上张图，看看系列文章会具体说点啥。感兴趣的同学也可以提出自己想了解的容灾话题，大家一起来探讨容灾的业态、典型架构、关键技术、交付落地。

本文接下来的章节，我们先一起来探讨下容灾系统建设的背景及意义，为后续文章抛个砖！

容灾，why？

为什么要做容灾，可以说是一个老生常谈的话题。在切入正题之前，我们先聊一下学术上的灾难事件是如何定义的，容灾维度上的灾难事件又是怎么一回事。然后，再来看下什么是容灾系统，容灾和备份的区别又是什么。我们一步步抽丝剥茧。

 灾难事件的定义

我们常常把灾难事件定义为一个突发的、非计划的、能够导致重大伤害或损失的严重的不幸事件。而灾难事件随时都可能发生。看一看近 20 年来发生的一些重大灾难事件，恍如隔日，是很多人记忆深处的痛！

 容灾维度的灾难事件

从容灾维度上讲，又是如何来定义灾难事件的？我认为可以从以下三个方面重点考虑：

一、突发事件造成企业关键业务功能或流程的中断时间超过企业能够容忍的最大限度

二、通常由恢复时间目标值（RTO 值）作为判定是否是灾难的依据

三、通过评估，当预计关键业务功能的中断时间将超过预定的 RTO 值，则视为灾难发生，应该启动相应的预案及计划

我们再来看一组数据，2000 年之前的 20 年时间里，因为电力中断、暴风雨/雪以及洪水等自然灾害造成的灾难事件，稳居前列。据国际权威机构 Swiss Re 的统计数据，在世界范围内，从 20 世纪 60 年代，到 20 世纪 90 年代，世界上可统计的自然灾害发生率增长了 3 倍，经济损失增长了 9 倍！进入 21 世纪，这个数字在还在快速增加！

容灾建设的重要性不言而喻！

那容灾与备份到低如何定义的呢，他们是一回事吗？和我一起继续往下看......

 容灾与备份

容灾系统的目的在于保证系统数据和服务的“在线性”，即当系统发生故障时，仍然能够正常的提供数据和服务，以使系统不至于停顿。通俗点讲，就是为了防止天灾人祸、不可抗力，在两地或多地建立相同的 IT 系统，彼此有同步，随时能切换。

而备份的目的与此不同，备份是“将在线数据转移成离线数据的过程”，其目的在于应对系统数据中的逻辑错误和历史数据保存。备份是基石，是数据高可用的最后一道防线，其目的是为了系统数据崩溃时能够恢复数据。

那建设了备份系统，是否就不需要容灾系统了？答案肯定是否定的，有一个前提，就是要看业务部门对 RTO/RPO 指标的期望值。备份只能满足数据丢失、数据破坏时的数据恢复目的，而不能提供实时的业务接管功能。因此，容灾系统对于某些关键业务而言是必不可少的。

 容灾系统建设刻不容缓

我认为，数据是企业的核心，业务是企业的灵魂。据 IDC 数据统计，2000 年以前的10年间，由于受灾导致的数据丢失，55% 企业倒闭，29% 在 2 年内倒闭，仅 16% 得以生存。另据权威机构 Swiss Re 的统计数据，2017 年全球灾难造成损失超 3000 亿美刀，较 2016 年激增 63%。

天灾人祸难以避免，“黑天鹅”事件也会导致巨大的经济损失。

从 2003 年开始，国家陆续出台了信息安全保障工作意见、灾难恢复规范、网络安全法等等。目的显而易见，就是为了保护企业的核心数据及业务生命线。容灾系统建设刻不容缓！

容灾系统建设的价值几何？

不论是基于规避天灾人祸造成的业务影响考虑还是监管要求，我们都不难发现容灾系统建设的必要性，以及给企业带来的潜在的巨大价值。

容灾系统建设既可以有效的增强企业应对灾难的能力又可以完善企业的日常经营管理，从下图的展示中大家可以一窥究竟：

再上一张对比图，和我一起直观感受下灾难发生时有无容灾体系对企业生产能力造成的巨大影响差异。

容灾系统建设都需要考虑啥？

既然容灾系统建设价值连城，那么我们该如何去评价容灾系统建设的指标呢？可以从以下几个因素来考虑：

从这些因素中，我们不难发现，衡量容灾系统建设有两个核心指标：RTO（Recovery Time Objective）和 RPO（Recovery Point Objective）。

 RTO？

就是业务挂了，多久能恢复。不中断最好，RTO=0

 RPO？

就是系统挂了，数据能丢多少。不丢最好，RPO=0

两者的值要充分考虑到数据的重要程度和业务中断时间的允许范围！

没有最好，只有更合适！

在谈论容灾系统是好是坏之前，我们从对系统的保护程度这个维度来看看容灾系统的两个层次：

 数据容灾

其实就是数据远程的备份。灾难发生时，只保证数据尽量不丢失，但是业务会中断，慢慢恢复、重建，可以脑补下这个画面。

 应用容灾

在数据备份或同步的基础上，还要建立一套相同的应用系统，除了涉及数据，还要涉及到主机、网络、存储、OS、软件等等。很复杂，但是这种付出是有回报的。灾难发生时，业务能快速恢复甚至不中断。

这两个层次，建设成本不同，恢复能力自然也不同。

那对应的容灾系统建设的等级是什么样的呢？根据国标《信息系统灾难恢复规范》定义来看，容灾系统建设一共有 1～6 个等级。等级越高，RPO/RTO 值越小。

每个等级对应的 RPO、RTO 指标如下表所示：

了解完容灾系统建设等级，我们继续探讨什么是好的容灾系统这个话题。

有人会问，是否可以从容灾系统的两个核心评价指标，RPO 和 RTO 来判定？RPO 和 RTO 值越小，那不就是最好的容灾系统吗？从目标来看，千真万确！但是容灾建设，是一个庞大的体系化的工程问题。技术能力、建设成本、客户现状、甚至生态能力等都需要去考量。

所以，我认为，没有最好的容灾系统，满足客户容灾建设等级需求的容灾系统就是好的容灾系统，就是最适合的容灾系统。

技术问题，Not only！

顺着上一节话题我们继续聊。当下，影响国计民生的行业，比如银行、电力、电信，都会追求业务不中断、数据零丢失，他们会按照最高容灾级别建设。然而，容灾级别越高，建设成本也越高，不是人人都建得起“两地三中心”，除了技术能力，人力、物力、财力缺一不可！

也许，土豪们会说：我玩得起“两地三中心”；但更多的普通人会说：那俺该咋整，有没有更“合理”的方案呢？

放在以前，“高级别”容灾可能只是“土豪”的专利。但到了云时代，这一切已经在悄然改变。云计算，正在让容灾变得更便宜、更简单......

容灾的前世今生

 容灾的起源与发展

据我了解，容灾起源于上世纪 70 年代，虽然当时使用的大多数是用于批处理的大机，但是数据中心管理者意识到他们的业务越来越依赖于 IT 系统。基于 IT 灾难可能对业务造成的影响，一些灾难恢复公司提供备用的数据中心，第一个商用的热备站点是由后来的 SunGard 在 1978 年建立的，难能可贵的是，这个 SunGard 现在还活的好好的。

在 80～90 年代，受益于开放平台和实时处理系统的快速发展，企业更加依赖于IT系统。同时监管要求不同行业的企业制定业务连续和灾难恢复计划，催生了商业容灾服务的需求，比如基于卡车的移动数据中心。

90 年代到千禧年，是 IT 膨胀的时期，IT 连续性稳定运行对企业来说变的至关重要。各种各样的容灾技术和产品蓬勃发展，从温备站点到热备站点，从数据级容灾到应用级、业务级容灾，从备份到两地三中心容灾，容灾方案及业务连续性日趋完善。

从 2010 年开始互联网时代对业务连续性的要求更高，IT 进入了云时代。IT 的使用者不再关心应用由哪些物理设备提供，更多是提供 IaaS 服务、PaaS 服务，甚至是 SaaS 服务，容灾也朝着容灾即服务的形态迈进。

从容灾技术上看，也由注重复制技术（存储复制、FS 复制、数据库复制）发展到需要整体方案（主机、存储、网络等）。云上的容灾，从部署形态上看也呈现多样化，公共云、专有云、混合云等等。

公有云，本身，就具备基础容灾能力。大型云服务商，在数据中心基础设施、网络线路以及上层支持平台、运营体系都是具有相当的容灾保障的。阿里云、腾讯云、AWS、Google......

混合云，本身，我认为就是一种异地容灾的雏形。很多企业，IT 系统已经采用混合云架构。混合云，其实就是一种“异地”的模式，具备容灾的潜力。最近一些车企客户的 case，他们的容灾架构就是这种混合云模式。

云计算按需服务模式，也让低成本容灾成为可能。企业建设云上异地容灾，不必灾考虑基础设施的建设成本，根据自己的业务增长和容灾级别，按需使用，成本低廉，更少投入就能拥有”土豪“一样的容灾能力。我大胆的预测下，混合云容灾未来一定拥有非常广阔的市场......

 从 1.0 到 3.0

从容灾系统的职能上看，也悄然的从容灾 1.0 发展到了容灾 3.0 时代！

容灾 1.0 时代：主要是 2000 年以前，IT 主要作为业务支撑系统，是一个十足的高成本部门。容灾以数据为中心，主要是将生产数据通过存储复制等技术在容灾中心保存，恢复以人工为主，容灾系统作为备用系统，使用率非常低。可以称为容灾的 1.0 时代。

容灾 2.0 时代：当前，IT 系统越来越重要，IT 系统作为业务的使能，业务连续对 IT 系统提出更高的要求。容灾系统的建设以能恢复业务为目标，容灾系统最好能承担部分业务，双活、AQ 模式使得容灾系统得以支撑部分业务。可以称之为容灾的 2.0 时代。

容灾 3.0 时代：容灾系统与生产系统的界限越来越模糊，进入容灾即业务时代。容灾以客户为中心，通过智能流量切换，多中心部署，多生产系统共同支撑业务，互为灾备，容灾系统即业务系统。可以称之为容灾的 3.0 时代。我们，已经在路上......

不同阶段容灾系统的架构对比情况概括如下：

未来已来

是的，未来的容灾系统不再仅仅是容灾系统，是一个容灾即业务（DRaaS）的时代。

跨地域分布式数据库实现数据多活、读写分离、存储双活、海量/对象存储跨 AZ 多活、多活业务网关、多活网络网关、智能流量切换、混合云灾备等等。是一个不需要纠结能不能切，敢不敢切的时代，不需要纠结是人工决策还是自动切换的时代。

“喂，你醒醒，快准备好xxx容灾演练实施手册，准备好脚本，马上要进行容灾演练了......"

原来是场梦。

梦虽梦，但异常真实！

三言两语话 ending

拖着像是被灌了铅一样的眼皮，但是想到即将到来的容灾建设 3.0+，甚至 4.0 时代，内心的憧憬和喜悦还是溢于言表。虽然距离 Dream 还有差距，但是像阿里云一样的云厂商、容灾系统的建设者、相关从业者已经 Ready，信心满满！

xxx银行同城 2 机房/3 机房容灾，xxx中心异地容灾，xxx两地三中心、阿里金融云四地九中心、xxx电子税务局异地多活等，“靠谱”的云厂商释放的容灾技术红利，已经在一步步的为客户的容灾体系建设保驾护航，在进一步赢得客户的心。

作为一个交付人，需要时刻保持创新思维，站在客户的角度并引导客户更合理的去容灾！

广而告之，“靠谱“的云厂商应该具备什么样的容灾能力呢？他们的容灾架构是如何设计的，处于什么样的容灾水平？我们下回聊～

END

往期精彩文章回顾

NFS Write IO 不对齐深度分析

通过 IDEA 黑掉你

Sentinel 实战应用中的小技巧

基于 Multiple Teacher Single Student 框架的多领域对话模型

【精彩回顾】企业IT治理样板间直播

洛神云网络 SLB 负载均衡新姿势

业务中台实践助力企业数字化转型

中保车服灾备云，为保险公司“上保险”

阿里云重磅发布应用负载均衡ALB，加速企业应用交付

“电”亮数字生活，阿里云助力南方电网智能调度

阿里云为自动驾驶量身打造一体化解决方案，助力行业突破技术瓶颈

长按扫描二维码关注凌云时刻

每日收获前沿技术与科技洞见