关于容灾的那些事儿

​​容灾，运维们都不会陌生的词语。今天，我们来聊一聊关于容灾的那些事儿。

 

关于容灾级别的选择

灾备，是企业中一项重要的技术应用，对于企业数据安全起到了很大的作用。 一般来说，灾备的级别可以分为数据级、应用级和业务级三个级别。

• 数据级灾备：主要关注的就是数据，就是在灾难发生之后，可以确保数据不受到损坏。比如早期的通过备份到磁带转移到异地或者基于网络实现灾备中心与生产中心的异步\同步的数据传输。

• 应用级灾备：建立在数据级灾备的基础上，对应用系统进行复制，也就是在异地灾备中心再构建一套应用支撑系统，可提供应用接管能力。支撑系统包括数据备份系统、备用应用系统、以及备用网络等。

• 业务级灾备：也是最高级别的灾备系统，包括超过IT系统的部分，比如业务用户的办公场所以及业务工作人员备份等。

 

谈到灾备这个话题，很多CIO就会把异地应用级灾备放在首位，还特别强调建设一个数据零丢失、应用自动切换的最高级别的异地灾备系统。（一般业务级灾备需要额外考虑超过IT系统建设的部分，所以从IT的角度来说，业务级灾备不会放在首位来考虑。）

 

灾备的重要性是毋容置疑的，但这并不是说灾备就一定要建应用级，不同的企业应该从实际需求出发，“选择适合自己的”才最重要。

 

灾备建设中，如何选择数据级，还是应用级呢？我们可以从灾备的目标，结合数据和业务分析做一个参考分析。

 

数据分析

对于企业来说，最重要的IT信息资产就是数据。我们从数据用途的角度来分析，可以将需要备份的数据分为系统数据、基础数据、应用数据和临时数据；同时根据数据存储和管理方式又可分为数据库数据、非数据库数据、孤立数据和遗失数据。

• 系统数据：主要是指操作系统、应用系统安装的各类软件包和应用系统执行程序。系统数据在系统安装后基本上不会再变动，只有在操作系统、应用系统版本升级或应用程序调整时才发生变化。

 

• 基础数据：主要是指保证业务系统正常运行所使用的系统目录、用户目录、系统配置文件、网络配置文件、应用配置文件、存取权限控制等。基础数据随业务系统运行环境的变化而变化，一般作为系统档案进行保存。

 

• 应用数据：主要是指业务系统的所有业务数据，对数据的安全性、准确性、完整性要求很高而且变化频繁。

 

• 临时数据：主要是指操作系统、应用系统、数据库产生的系统运行记录、数据库逻辑日志和应用程序在执行过程中产生的各种打印、传输临时文件，随系统运行和业务的发生而变化。临时数据对业务数据的完整性影响不大，增大后需要定期进行清理。

 

业务分析

企业里有不同的业务场景，我们可以根据各种业务系统处理的业务类型、处理方式、实时性要求、以及每天处理的业务量等条件，将业务系统划分为关键业务系统、重要业务系统、一般业务系统等。

• 关键业务系统：业务数据比较集中和核心，所连服务器节点较多，对保证整个企业的正常运转至关重要；一旦业务中断，将会立刻使企业提供的服务及正常业务运作受到相当严重的影响，并直接带来企业经济损失或影响企业信誉，甚至严重情况可能要承担潜在的法律责任。如线上携程、淘宝、京东等。

 

• 重要业务系统：业务中断将对整个企业的正常、有效运转产生较严重的影响。一旦业务发生中断，会使企业部分提供的服务及部分业务受到影响和中断，但无关大局。如：内部企业网站、邮件传输系统、业务运营系统等。

 

• 一般业务系统：业务中断将不会立刻对整个企业的正常运转产生严重影响，一旦中短可以容忍在数天或数周内恢复。比如：人事档案系统、考勤系统、工程预决算系统等。

 

 

关于RTO和RPO

谈完容灾级别的选择，我们来看下容灾的参数指标，有两个关键指标我们必须要了解：RTO和RPO。

RTO和RPO是灾难恢复方面的重要参数指标，可以很好地反映出容灾性能如何。

 

RTO（恢复时长目标）

RTO（RecoveryTimeObjective，恢复时间目标）是可容许服务中断的时间长度。比如说服务发生后半天内便需要恢复，RTO数值就是十二小时。RTO具体时间长短是指从故障发生后，从系统宕机导致应用停顿之刻开始，到系统恢复至可以支持各部门运作之时，此两点之间的时间段。

 

RTO是反映业务恢复的及时性指标，表示业务从中断到恢复正常所需的时间。RTO数值越小，代表容灾系统的数据恢复能力越强。我们可以部署很多容灾系统，来获取最小的RTO，但这意味着投入大量资金。

 

提升RTO的常用技术有：磁带恢复、人工迁移、应用系统远程切换，这几种技术的RTO的表现如下表所示：

 

 

RPO（恢复点目标）

RPO（RecoveryPointObjective，恢复点目标）是指能容忍的最大数据丢失量，是指当业务恢复后，恢复得来的数据所对应时间点。

 

RPO取决于数据恢复到怎样的更新程度，这种更新程度可以是上一周的备份数据，也可以是昨天的数据，这和数据备份的频率有关。为了改进RPO，必然要增加数据备份的频率才行。

 

RPO是反映恢复数据完整性的指标。在同步数据复制方式下，RPO等于数据传输时延的时间，在异步数据复制方式下，RPO基本为异步传输数据排队的时间。提升RPO的常用技术有：磁带备份、定期数据复制、异步数据复制、同步数据复制等，这几种技术的RPO的表现如下表所示：

 

 

RTO和RPO关系

RTO和RPO指标并不是孤立的，而是从不同角度来反映的容灾能力。我们用下面的图说明下RTO和RPO两个指标在故障处理过程中的关系：

 

 

 

几种常见的容灾技术和架构

几种常见灾备技术

软件复制：应用高可用、应用负载均衡、应用配置文件同步、VMware HA

数据库复制：Oracle DG、MySQL 主从、MSSQL 镜像、日志同步；

存储复制：EMC Vplex 、IBM SVC、NetAPP MetroCluster。

 

 

几种常见灾备架构

 

同城双活：互联网用户可同时访问生产和容灾机房入口

 

 

容灾级别：应用级容灾；

容灾技术：CDN、EMC Vplex 存储复制、应用负载均衡、应用配置文件复制；

RTO：可达到秒级恢复；

RPO：根据双活机房的同步复制，可达到数据零丢失；

灾备切换关键：

• 网络层：通过CDN可将用户访问自动切换至容灾机房；

• Web及应用层：容灾机房一直处于运行状态，无需手动切换。但部分应用可能需要调整配置；

• 数据库：通过RAC+基于vplex的存储复制，实现自动切换。

 

异地容灾：某公司内部财务系统异地容灾架构

     

 

容灾级别：应用级容灾；

容灾技术：数据库复制（Oracle Dataguard）、应用配置文件复制；

RTO：可达到分钟级别恢复；

RPO：基本为异步传输数据排队的时间，可达到分钟级别；

灾备切换关键：

• Web及应用层：容灾机房一直处于运行状态，无需手动切换。但部分应用可能需要调整配置；

• 数据库：通过Oracle dataguard实现数据库复制，切换时需要将容灾机房的数据库服务器配置为主节点。

 

 

同城容灾：某公司互联网业务同城容灾架构

 

 

容灾级别：应用级容灾；

容灾技术：存储复制、VMware HA集群【生产ESX主机与容灾ESX主机在同一个HA集群中】；

RTO：可达到分钟级别恢复；

RPO：根据双活机房的同步复制，可达到数据零丢失；

灾备切换关键：

• Web、应用、数据库服务器：在HA集群上迁移虚拟机至容灾ESX主机上，然后启动虚拟机；

• 虚拟机文件、数据库文件均使用存储虚拟化技术实时复制。

 

 

关于应用灾备演练

无论数据级还是应用级，都只是灾备建设的技术手段。灾备建设作为一项系统工程，其复杂程度远远超出了技术的范畴。要想灾备系统在关键时刻能发挥应有的作用，完善的灾备应急预案、定期的灾备演练也非常重要。

 

接下来我们以上述的异地容灾架构案例，结合嘉维蓝鲸应用灾备演练自动化SaaS的功能逐一阐述灾备演练的全过程。

 

基于蓝鲸的应用灾备演练

在上述“异地容灾：某公司内部财务系统异地容灾架构”中，已经告诉了大家灾备切换的关键点有两个：

一个是web应用层，容灾机房一直处于运行状态，但切换应用到灾备机房可能会涉及一些配置参数的调整；

二是在数据库Oracle Dataguard架构中，切换时需要将容灾机房的数据库服务提起为主动节点对外服务。

 

根据关键点，我们梳理一下真实的应用灾备演练的过程如下：

 

 

 

容灾应用管理

应用管理员，登录到SaaS后，首先添加目标灾备应用，包括应用系统基础信息、服务器对象、数据库对象等；

 

灾备预案管理

在灾备预案管理中，添加针对目标应用的灾备切换的预案，定义灾备预案的名称与后台标准运维的流程关联；

 

 

标准运维流程

灾备预案创建完成后，基于最开始调研的容灾切换的流程，进行原子开发，并在标准运维中进行原子流程的编排，操作流程编排完成，与预案管理ID关联；

 

 

容灾切换任务

容灾切换任务，包括切换、恢复的任务，基于目标应用和预案管理，创建切换任务；

 

 

容灾大屏实时展示

管理员基于应用灾备预案及演练计划创建好了灾备切换的计划，在任务执行的时间窗口，可通过菜单中的“大屏”功能，实时展示灾备切换全流程及切换进度。

 

 

嘉维蓝鲸应用灾备演练SaaS如何兼容各种灾备架构

 

SaaS架构设计

 

嘉维蓝鲸应用灾备演练SaaS，基于蓝鲸智云PaaS平台开发，可以兼容各种灾备架构。主要特性如下：

 

预案统一管理

往期传统的容灾预案管理，都是基于现在的文档管理，一般只在一年一次或一年两次的灾备演练结果后，进行文档的维护更新。任意时刻的人员变动或文档的交接，都可能会导致灾备预案的信息不准备，也就意味着下一次的灾备演练又是重新开始。通过在线SaaS的方式，可集中添加多个灾备应用系统，并集中管理好每个核心的灾备预案，并且在每一次的灾备演练完成后，直接可在线更新和完善，同时记录其每次预案的更新信息，从而实现灾备演练目标—持续验证和完善灾备预案 。

 

大屏可视化

在SaaS中，增加了大屏功能的设计，让原本需要通过线下沟通和汇报进度的工作，全部通过可视化的大屏，实时展示所有的切换流程和进度节点，让整个演练过程更为直观高效。

 

适配驱动众多技术对象

嘉维蓝鲸应用灾备演练SaaS，是基于蓝鲸平台上开发的应用运维场景SaaS，可通过蓝鲸管控平台提供的服务能力，如文件分发传输能力、命令实时执行与反馈的能力、大数据采集与传输的能力，来实现针对容灾架构中涉及的众多技术和众多厂商产品的驱动，包括操作系统、数据库、中间件、存储设备以及网络层面。关于蓝鲸管控平台介绍，请参考阅读 《蓝鲸智云的幕后英雄：管控平台》。

​

强大灵活的流程编排

嘉维蓝鲸应用灾备演练SaaS，是基于蓝鲸平台上开发的，借助蓝鲸平台标准运维的核心能力--任务流程编排和自动化调度能力，实现各个驱动对象的作业原子及脚本，跨技术的编排整体的切换流程，包括数据库切换、应用服务测试等。关于蓝鲸标准运维介绍，可参考阅读《看蓝鲸标准运维如何编排一切》。

​

本文主要是从容灾级别选择、容灾系统指标、常见容灾技术及架构、以及应用灾备演练的部分角度，来阐述对企业建设应用容灾系统的观点。当然，对于一整套庞大的灾备体系在实际建设过程中，还有更多的角度分析，如从应对灾难分类进行分级建设，从灾备系统的安全可扩展及易管理需求设计整体架构，从企业流程管理来设计灾备预案，从灾备演练目的选择不同演练方法等等。欢迎联系我们进行探讨。​​​​