灾备理论-可靠的异地灾备

2022-01-01 04:50:14

1. 技术背景

1.1. 灾备评价指标

业界普遍数据丢失量和系统恢复时间作为标准，对某个容灾系统进行评价，公认的评价标准是RPO和RTO。
　　RPO（RecoveryPointObjective）：恢复点目标，以时间为单位，即在灾难发生时，系统和数据必须恢复到的时间点要求。RPO标志系统能够容忍的最大数据丢失量，系统容忍丢失的数据量越小，RPO的值越小。
　　RTO(RecoveryTimeObjective)：恢复时间目标，以时间为单位，即在灾难发生后，信息系统或业务功能从停止到必须恢复的时间要求。RTO标志系统能够容忍的服务停止的最长时间。系统服务的紧迫性要求越高，RTO的值越小。
　　RPO针对的是数据丢失，RTO针对的是服务丢失，两者没有必然的联系，并且两者的确必须在进行风险分析和业务影响分析之后根据业务的需求来确定。

1.2. 灾难恢复能力等级

要建设容灾系统，就必须提出相应的设计指标，以此作为衡量和选择容灾解决方案的参数。目前，国际上通用的容灾系统的评审标准为SHARE 78，主要包括以下内容。
　　●备份/恢复的范围
　　●灾难恢复计划的状态
　　●业务中心与容灾中心之间的距离
　　●业务中心与容灾中心之间如何连接
　　●数据是怎样在两个中心之间传送的
　　●允许有多少数据丢失
　　●保证更新的数据在容灾中心被更新
　　●容灾中心可以开始容灾进程的能力
　　SHARE 78是建立容灾系统的一种评审标准。建立容灾系统的最终目的，是为了在灾难发生后能够以最快速度恢复数据服务，主要体现在RTO和RPO上。在SHARE 78的基础上，国家质量监督检验检疫总局和国家标准化管理委员会联合制定规范了适合我国国情的RTO/RPO与灾难恢复能力等级的关系。

RTO/RPO与灾难恢复能力等级的关系表：

等级	RPO	RTO	备注
1级	2天以上	1天至7天	<0.1%
2级	24小时以上	1天至7天	90%
3级	12小时以上	数小时至1天	6%
4级	数小时至2天	数小时至1天	<0.5%
5级	数分钟至2天	0至30分钟	<0.1%
6级	数分钟	0	3%

1.3. 容灾的分类

由于容灾包含的内容比较广泛，对容灾的分类也可以从多个方面进行。总的来讲，可以从容灾的范围和容灾的内容来区分。

从容灾的范围讲，容灾可以分成本地容灾，近距离（同城）容灾和远距离（异地）容灾。这三种容灾能容的灾难是不相同的，采用的容灾技术也是不同的。

从容灾的层次讲，容灾又可以分成数据容灾和应用容灾，数据容灾是应用容灾的基础，没有数据的一致性，就没有应用的连续性，应用容灾也是无法保证的。数据容灾是指建立一个备用的数据系统，该备用系统对生产系统的关键数据进行备份。

应用容灾则是在数据容灾之上，建立一套与生产系统相当的备份应用系统。在灾难发生后，将应用迅速切换到备用系统，备份系统承担生产系统的业务运行。

1.4. 主流数据容灾技术

1.4.1. 数据备份

数据备份是系统、数据容灾的基础，也是低端容灾的实现，是高端容灾（实时数据保护）的有力保障。目前备份技术主要有快照备份、离线备份、异地存储备份。备份系统通过备份策略，对计算机信息系统的操作系统、文件系统、应用程序、数据库系统等数据集，实现某一时间点的完整拷贝，拷贝的数据处在非在线状态，不能被立刻访问，必须通过相应操作，如恢复等方式使用备份数据。这也解决了高端容灾（实时数据保护）不能解决的问题：人为误操作、恶意性操作等，这类操作，计算机系统是不能区分的，一旦执行，将造成数据中心、灾备中心同时修改；对于数据库系统，在日志方式下，可以通过回滚方式修改，对于文件系统、操作系统等其他配置信息是不能回滚的，将造成毁灭性的结果。因此在建设高端容灾系统的前提，一定要做好本地系统的备份，这是容灾技术的起点。

目前成熟的备份软件有Symantec NetBackup、EMC Legato，IBM TSM，HP Protect Server等等。

1.4.2. 实时数据保护

实时数据保护，就是在多块磁盘上、多个阵列、多台服务器、多个数据中心实时的保存同一份数据的多份存储，目的是为了避免物理故障，数据不会因为一块磁盘、一个阵列、一台服务器、一个数据中心的故障，而不能访问。

实时数据保护需要以数据备份作为前提，它不能防范人为误操作和恶性操作。这里我们要强调容灾的目的是让数据在灾难发生时，还能被访问，通过实时数据保护，保证数据的完整性；因此实时数据保护是容灾手段，而不是目的。目前实时数据保护的技术主要有两种：数据镜像和数据复制。

1.4.2.1. 数据镜像（Mirroring）

数据镜像（Mirroring）是冗余的一种类型，一个磁盘上的数据在另一个磁盘上存在一个完全相同的副本即为镜像。数据镜像分为软件镜像与硬件镜像，镜像软件有Symantec Volume Manager；各硬件厂商都有基于自己阵列的硬件镜像方式。

在通过SAN的支持，DWDM的拓展，光纤网络可以扩展到100公里或更远，镜像可以在较远的两个数据中心的磁盘上建立。但由于镜像系统是以同步方式实现的，受到距离、光纤协议、和相关协议转换的影响，同步方式会影响本地服务器的性能，所以，一般建议在<20公里的同城容灾中使用，在远程容灾中可作为一种加强方案与远程容灾方案整合。

基于SAN的镜像支持所有的类型数据同步，包括文件数据、数据库数据、裸设备、应用配置文件、应用程序、库函数等，因而支持各类应用系统容灾，包括数据库、中间件、客户自己开发的应用，适用于2层架构、3层或多层应用架构。

1.4.2.2. 数据复制（Replication）

数据复制（Replication）是将一个原数据的及其改动，通过后续机制拷贝到另外一处，可以是另一个磁盘、另一个阵列、另一个服务器、另一个数据中心。由于实现的机制不同，又分为同步复制和异步复制两种方式。同步复制，能够确保两份数据完全一致，但对系统的影响较大，一般不会采用；异步复制，通过后续机制，确保将本地改动的数据复制的异地，对系统的影响较小，但数据同步有延迟，是目前实现远程数据同步的主要方法。

根据实现机制，数据复制分为软件方式和硬件方式；硬件方式往往又被称为远程镜像。此外还有数据库复制和基于SAN的卷复制。

软件复制有Symantec Volume Replicator(简称VVR)、Datacore 等，软件复制可以跨硬件平台，可以实现多厂商集成，其中VVR是基于卷的复制，复制的数据可以是数据库中的数据（文件方式或裸设备方式），数据库日志，复制的数据也可以是各种文件，如应用和数据库配置文件，应用程序，库文件，等等。Datacore是基于block的复制，类似于硬件的复制，处于卷的更底层，与基于卷的复制不同的是，他具有应用操作系统的独立性，数据的远程复制与操作系统无关，并且不需要远端主机应用系统的运行，支持异步和同步的方式，并且与硬件存储子系统不同的是，Datacore可以实现异构存储子系统的集中管理，打破了单一厂商选择的限制，对于磁盘子系统的选择更加灵活。

硬件复制一般是相同品牌之间的磁盘子系统的操作。具有一定的限制性，纯硬件复制有HDS TrueCopy、EMC SRDF等。硬件复制通过基于硬件的远程磁盘镜像实现，其实现要求严格。只能基于同一厂商、同样容量大小的两个阵列来实现。受光纤线路影响、复制数据量大，在使用间歇性复制时，数据延迟大，磁盘容量要求4倍于源数据，并且在极端情况下，不能保证数据一致性。厂商一般建议使用间歇性复制。远程磁盘镜像（复制），在容灾实现中，支持所有的类型数据同步，包括文件数据、数据库数据、裸设备、应用配置文件、应用程序、库函数等，支持各类应用系统容灾，包括数据库、中间件、客户自己开发的应用，适用于2层架构、3层或多层应用架构。

数据库复制，Oracle Data Guard、Oracle GoldenGate、Quest SharePlex、DSG RealSync等，通过分析数据库Redo Log和Archive Log 实现日志的复制，将分析结果直接或转化为SQL语句传到容灾中心，在容灾中通过心Apply数据库日志或将日志转化的SQL语句重做，来保证容灾中心数据与生产中心数据一致。但数据库复制也存在如下限制：一是数据库复制，是专门针对相应数据库的，只能实现单一的数据库复制。如果有ORACLE、SQLSERVER等多种数据库，就必须采用相互各不相同的数据库复制技术，管理和维护工作非常复杂；二是数据库复制技术不是一个完整的容灾解决方案，只能有限的复制数据库数据，不能复制其他的应用程序，配置文件，就是Oracle自己的tnsnames.ora, listner.ora，initSID.ora, *.ctl也不能复制，一旦这些文件改动过，将需要管员人为操作或者需要其他软件的管理，保证容灾中心与生产中心同步应用、程序、配置文件同步。

基于SAN网络的卷复制是一种新的复制方式，如Datacore的SDS。它是通过特殊的运行于操作系统上的SDS SAN控制器，实际是将低端的无智能存储变为高端的智能存储，使得他们得以建立基于智能SAN 控制器的卷，通过这种与主机应用无关，但与SDS控制器直接相关的卷实现复制。此种技术较新，目前具有多家厂商均向此方向发展，其中Datacore是较早的研发厂商，当中还有IBM的SVC和HDS的USP系列以及飞康CDP也是采用此种技术。

1.5. 应用和网络容灾

数据复制是容灾的手段，不是目的，容灾的目的是数据的访问，因此应用的恢复和网络的恢复也是容灾的关键。

应用系统恢复，这和系统的应用模式直接相关。需要考虑应用系统的应用架构。是Client/Server架构，还是Broswer/Server架构；是2层架构、还是3层架构、还是多层架构。两层架构，表示容灾中心的应用只要启动数据库就可以服务了。如果是三层架构，就意味着应用系统除数据库以外，还有网络服务程序，如中间件WebLogic。在容灾应用切换时，能够手工或自动化的将这些服务一一启动。

在灾难发生后，应用切换到灾备中心了，本地的应用前端需要重新访问容灾节点的服务，带来另外一个问题，网络如何切换。实际上最简单的办法，就是通过外部DNS服务器，

在灾难发生后，本地应用访问路径如何由指向原生产中心改为指向容灾中心。在灾难修复后，又需要指向原生产中心。最简单得方法就是更改外部DNS服务器得IP映射关系。在灾难发生前，IP映射为生产中心服务器；在灾难发生后，IP由映射为容灾中心得服务器；在灾难修复后，IP又映射为生产中心得服务器。

当然，在一些中间件软件中，支持多服务器、多IP的配置，那也是可以考虑的。

1.6. 容灾切换

就是在灾难发生后，数据库切换、应用重新启动、网络实现切换等等，容灾中心接管原生产中心的整个过程；同时还包含了在原数据中心修复后，数据库、应用、网络需要重新切回来的整个过程。这些过程，可以通过手工切换、也可以通过自动化过程完成。

1.7. 容灾演练

大部分的容灾方案，在项目实施后，很难有机会来实现预演，因为对于大部分方案来说，这种预演活动，需要耗费大量的人力财力。

但是这种预演是必不可少的，它是实时测试目前的容灾方案的漏洞，保证容灾方案在灾难发生时，能够真正生效。

2. 灾备系统建设

2.1. 灾备系统选型要素

容灾技术的选择，是一个以业务容灾需求为核心，多种因素综合权衡的过程。容灾技术选择所需考虑的因素
一、业务分析结果
　　容灾系统建设应根据业务分析结果选择合适的容灾技术并确定具体的实现策略，以满足业务恢复时相应的RTO、RPO指标。
二、业务关联程度
　　在进行容灾技术选择时，需要考虑到核心业务系统各种业务之间的关联关系。业务关联紧密，数据的藕合程度高，可能会造成所有关联的业务都要采用同一种容灾技术，业务关联松散，数据的藕合程度低，可能会针对不同的业务要求进行区分，分别采用不同的容灾技术。
三、系统现状
　　核心业务系统容灾技术必须充分考虑与现有系统的配合。现有核心业务系统的应用分布、应用的实现方式、硬件设备平台的种类、存储数据量的大小、IO吞吐量的大小等，都会对容灾技术的选择产生影响。
四、技术成熟度
　　容灾系统必须采用成熟可靠的技术，保证系统特续，稳定的运行。该技术应具有类似于电信业务运营支撑系统容灾建设的成功案例，不能由于技术手段的不成熟或不稳定而增加核心业务系统新的风险。
五、容灾系统环境
　　核心业务系统容灾技术必须考虑生产中心与容灾中心之间的距离，网络环境等因素，不同的技术对距离，网络带宽的要求会有所不同。
六、管理维护难度
　　不同的容灾技术对管理维护的要求各不相同，在同等条件下，应采用易于管理和维护的容灾技术。
七、成本分析
　　不同的容灾技术对软硬件投资，实施维护成本的要求各不相同，在同等条件下，应采用总体成本最小的容灾技术。