容灾项目方案设计.doc
《容灾项目方案设计.doc》由会员分享，可在线阅读，更多相关《容灾项目方案设计.doc（38页珍藏版）》请在冰点文库上搜索。
容灾项目方案设计
容灾项目设计方案
目录
第1章 容灾技术规范 4
1.1 容灾的总体规划 4
1.1.1 技术指标RPO、RTO 4
1.1.2 国际标准SHARE 78 5
1.1.2.1 Tier0 6
1.1.2.2 Tier1 7
1.1.2.3 Tier2 7
1.1.2.4 Tier3 8
1.1.2.5 Tier4 8
1.1.2.6 Tier5 8
1.1.2.7 Tier6 9
1.1.3 界定灾备系统的适用范围 9
1.1.4 界定灾备建设的目标 9
1.1.5 界定灾备系统的总体架构 10
第2章 主流容灾技术说明 12
2.1 数据备份 12
2.2 实时数据保护 12
2.2.1 数据镜像（Mirroring） 13
2.2.2 数据复制（Replication） 13
2.2.2.1 软件复制 13
2.2.2.2 硬件复制 15
2.2.2.3 数据库复制 18
2.2.2.4 DatacoreSDS 19
2.3 应用系统恢复 19
2.4 网络系统恢复 19
2.5 容灾切换过程 20
2.6 消防演习 20
第3章 主流容灾技术分析与对比 21
3.1 数据备份 21
3.2 实时数据保护 22
3.2.1 数据镜像（Mirroring） 22
3.2.1.1 硬件镜像 22
3.2.1.2 软件镜像 22
3.2.1.3 软件智能存储镜像 23
3.2.1.4 镜像技术在容灾中的利用 23
3.2.2 数据复制（Replication） 23
3.2.2.1 软件复制（卷复制） 24
3.2.2.2 硬件复制 24
3.2.2.3 基于软件控制器的复制 25
3.2.2.4 数据库复制 25
3.3 应用系统恢复 27
3.4 网络系统恢复 29
第4章 容灾系统设计步骤 29
4.1 第一步，深化数据备份系统 30
4.2 第二步，存储、应用整合 31
4.2.1 存储整合 31
4.2.2 应用整合 31
4.3 第三步，实现远程实时数据卷保护 31
4.4 第四步，建立远程切换消防演习机制 32
4.5 第五步，建立远程切换机制 32
第5章 数据容灾的性能分析 32
5.1 同步数据容灾的性能分析 32
5.1.1 带宽 33
5.1.2 距离 33
5.1.3 中间链路设备和协议转换的时延 34
5.2 异步数据容灾的性能分析 36
容灾技术规范
作为风险防范系统，灾备系统建设本身在总体规划、方案选择和投产实施后的管理运行，以及真正面对灾难时的切换操作等方面也存在着潜在的风险。
计算机信息系统实现数据大集、应用大集中后，系统的运行安全成为风险控制的焦点。
目前，已经有多系统开始或准备进行灾备系统的建设，灾备系统建设的目标是减灾容灾，使计算机信息系统和数据能够最大限度地防范和化解各种意外和灾害所带来的风险。
然而，与大多数工程一样，灾备系统建设本身在总体规划、方案选择和投产实施后的管理运行，以及真正面对灾难时的切换操作等方面也存在着潜在的风险。
可以说，风险防范系统本身也存在风险点，需要小心应对。
灾备系统建设中所涉及的潜在风险大致可分为技术风险、管理风险和投资风险，其中尤以技术选择风险最大，技术方案选择优越，可以规避一定的管理风险和投资风险。
而这三者也存在内在的相互关联，不同灾备级别对应的建设投资规模、所采用的技术以及实施和管理的复杂度也不同，应考虑保护计算机系统的原有投资并提高灾备系统建设投资的利用率。
1.1容灾的总体规划
真正的容灾是数据被不间断的一致性访问！
在灾难备份的世界里，是有等级观念的，级别不同，灾备系统所采用的技术和达到的功能是不同的，在系统建设资金投入方面的差距也很巨大。
所以，对用户来说，明确灾备系统建设的总体规划十分必要。
1.1.1技术指标RPO、RTO
衡量容灾技术的两个技术指标RPO、RTO
RPO（RecoveryPointObjective）:
以数据为出发点，主要指的是业务系统所能容忍的数据丢失量。
及在发生灾难，容灾系统接替原生产系统运行时，容灾系统与原生产中心不一致的数据量。
RPO是反映恢复数据完整性的指标，在同步数据复制方式下，RPO等于数据传输时延的时间；在异步数据复制方式下，RPO基本为异步传输数据排队的时间。
在实际应用中，考虑到数据传输因素，业务数据库与容灾备份数据库的一致性（SCN）是不相同的，RPO表示业务数据与容灾备份数据的SCN的时间差。
发生灾难后，启动容灾系统完成数据恢复，RPO就是新恢复业务系统的数据损失量。
RTO（RecoveryTimeObjective）:
以应用为出发点，即应用的恢复时间目标，主要指的是所能容忍的应用停止服务的最长时间，也就是从灾难发生到业务系统恢复服务功能所需要的最短时间周期。
是反映业务恢复及时性的指标，表示业务从中断到恢复正常所需的时间。
RTO值越小，代表容灾系统的数据恢复能力越强。
各种容灾解决方案的RTO有较大差别，基于光通道技术的同步数据复制，配合异地备用的业务系统和跨业务中心与备份中心的高可用管理，这种容灾解决方案具有最小的RTO。
容灾系统为获得最小的RTO，需要投入大量资金。
不同容灾方案的RTO和RPO是不相同的。
1.1.2国际标准SHARE 78
要建设容灾系统，就必须提出相应的设计指标，以此作为衡量和选择容灾解决方案的参数。
目前，国际上通用的容灾系统的评审标准为SHARE78，主要包括以下内容。
●备份/恢复的范围
●灾难恢复计划的状态
●业务中心与容灾中心之间的距离
●业务中心与容灾中心之间如何连接
●数据是怎样在两个中心之间传送的
●允许有多少数据丢失
●保证更新的数据在容灾中心被更新
●容灾中心可以开始容灾进程的能力
SHARE78是建立容灾系统的一种评审标准。
建立容灾系统的最终目的，是为了在灾难发生后能够以最快速度恢复数据服务，主要体现在RTOObjective）和RPO上。
SHARE 78, M028报告中定义的灾备的七个级别和与其对应的数据丢失量与恢复时间情况详见下表：
灾难备份等级与业务恢复情况对照表
等级
描述
RPO
RTO
企业百分比
0级
无灾备计划
-
-
<0.3%
1级
车辆运送方式
24~48小时
>48小时
<0.1%
2级
车辆运送＋热备份
24~48小时
24小时
90%
3级
电子传送
<24小时
<24小时
6%
4级
活动状态备份中心
秒级
<24小时
<0.5%
5级
两中心、两阶段确认
秒级
<2小时
<0.1%
6级
零数据丢失
零丢失
<2小时
3%
1.1.2.1Tier0
Tier0-无异地数据备份（Nooff-siteData）
Tier0被定义为没有信息存储的需求，没有建立备份硬件平台的需求，也没有发展应急计划的需求，数据仅在本地进行备份恢复，没有数据送往异地。
这种方式是最为低成本的灾难备份解决方案，但事实上这种灾难备份并没有真正灾难备份的能力，因为它的数据并没有被送往远离本地的地方，而数据的恢复也仅是利用本地的记录。
1.1.2.2Tier1
Tier1-PTAM车辆转送方式（PickupTruckAccessMethod）
作为Tier1的灾难备份方案需要设计一个应急方案，能够备份所需要的信息并将它存储在异地，然后根据灾难备份的具体需求，有选择地建立备份平台，但事先并不提供数据处理的硬件平台。
PTAM是一种用于许多中心备份的标准方式，数据在完成写操作之后，将会被送到远离本地的地方，同时具备有数据恢复的程序。
在灾难发生后，一整套系统和应用安装动作需要在一台未启动的计算机上重新完成。
系统和数据将被恢复并重新与网络相连。
这种灾难备份方案相对来说成本较低（仅仅需要传输工具的消耗以及存储设备的消耗）。
但同时有难于管理的问题，即很难知道什么样的数据在什么样的地方。
一旦系统可以工作，标准的做法是首先恢复关键应用，其余的应用根据需要恢复。
这样的情况下，恢复是可能的，但需要一定的时间，同时依赖于什么时候硬件平台能够被提供准备好。
1.1.2.3Tier2
Tier2-PTAM卡车转送方式+热备份中心（PTAM+HotSite）
Tier2相当于是Tier1再加上具有热备份能力中心的灾难备份。
热备份中心拥有足够的硬件和网络设备去支持关键应用的安装需求。
对于十分关键的应用，在灾难发生的同时，必须在异地有正运行着的硬件平台提供支持。
这种灾难备份的方式依赖于用PTAM的方法去将日常数据放在异地存储，当灾难发生的时候，数据再被移动到一个热备份的中心。
虽然移动数据到一个热备份中心增加了成本，但却明显降低了灾难备份的时间。
1.1.2.4Tier3
Tier3-电子传送（ElectronicVaulting）
Tier3是在Tier2的基础上用电子链路取代了车辆进行数据传送的灾难备份。
接收方的硬件平台必须与生产中心物理地相分离，在灾难发生后，存储的数据用于灾难备份。
由于热备份中心要保持持续运行，因此增加了成本。
但确实是消除了运送工具的需要，提高了灾难备份的速度。
1.1.2.5Tier4
Tier4-活动状态的备份中心（ActiveSecondarySite）
Tier4这种灾难备份要求两个中心同时处于活动状态并管理彼此的备份数据，允许备份行动在任何一个方向发生。
接收方硬件平台必须保证与另一方平台物理地相分离，在这种情况下，工作负载可以在两个中心之间被分担，两个中心之间之间彼此备份。
在两个中心之间，彼此的在线关键数据的拷贝不停地相互传送着。
在灾难发生时，需要的关键数据通过网络可迅速恢复，通过网络的切换，关键应用的恢复时间也可降低到了小时级。
1.1.2.6Tier5
Tier5-两中心两阶段确认（Two-SiteTwo-PhaseCommit）
Tier5是在Tier4的基础上在镜像状态上管理着被选择的数据（根据单一commit范围，在本地和远程数据库中同时更新着数据），也就是说，在更新请求被认为是满意之前，Tier5需要生产中心与备份中心的数据都被更新。
我们可以想象这样一种情景，数据在两个中心之间相互映像，由远程two-phasecommit来同步，因为关键应用使用了双重在线存储，所以在灾难发生时，仅仅传送中的数据被丢失，恢复的时间被降低到了小时级。
1.1.2.7Tier6
Tier6-零数据丢失（ZeroDataLoss）
Tier6可以实现零数据丢失率，同时保证数据立即自动地被传输到备份中心。
Tier6被认为是灾难备份的最高的级别，在本地和远程的所有数据被更新的同时，利用了双重在线存储和完全的网络切换能力。
Tier6是灾难备份中最昂贵的方式，也是速度最快的恢复方式，恢复的时间被降低到了分钟级。
对于Tier6的灾难备份解决方案，可以应用两种远程拷贝技术来实现，即PPRC同步远程拷贝和XRC异步远程拷贝。
因此，企业需要根据其计算机处理系统中数据的重要性，以及需要恢复的速度和程度，来进行灾备系统建设的整体考虑和不同灾难对业务冲击的分析，并最终确定灾备系统建设的总体规划。
灾备系统建设的总体规划应包括以下几个方面：
1.1.3界定灾备系统的适用范围
分析不同的应用系统，确定灾备系统是一个覆盖整个计算机系统的工程，根据业务的重要性，对不同的系统采用不同级别的容灾方案，如针对关键的业务应用子系统，实施高级别的容灾工程；对低级别的业务系统，实施低级别的容灾工程。
总之要建立一个综合性的整体灾备建设工程。
1.1.4界定灾备建设的目标
生产系统在单位时间内的数据处理能力或IO流量确定的情况下，RPO实际上成为一个反映灾备恢复过程中的数据丢失量的指标。
而RTO则是指从灾难发生到备份系统可以接管原有生产系统所需要花费的时间，这不仅要考虑数据的恢复时间，还应该考虑恢复后数据的完整性、一致性的修复和确认、备份中心计算机处理系统的启动和备份中心的网络切换等全部时间。
总体规划中应为灾备系统设定明确的RPO和RTO指标。
但是设计容灾系统不能只看RTO和RPO，对于不同的业务系统和用户特殊的要求，其它一些指标有可能成为选择容灾解决方案的主要因素。
例如，某些地区为了防范一些特定自然灾害的风险，要求容灾备份中心与业务中心保持足够的距离，在这种情况下，容灾备份中心与业务中心的距离要求就是容灾系统的重要指标。
通信网络是容灾系统的组成部分，通信线路的质量也是容灾系统的性能指标之一，其中包括网络的数据传输带宽、网络传输通道的冗余和网络服务商的服务水平（网络年中断率）。
如果容灾系统使用的通信网络是确定的，为了比较不同容灾解决方案，可以用单位存储容量的数据库在同一通信网络上的数据完全恢复时间作为一项设计指标。
大部分业务系统都是数据库应用结构，但业务系统容灾并不等于是数据库容灾，还包括访问数据库的应用程序和相关配置信息。
实现数据库容灾是容灾的基础，在保障数据库数据一致的前提下，还要实现应用程序和配置信息的一致性；实现应用系统的高可用性、应用程序在容灾中心与生产中心接管和切回的过程，因此，还要考虑应用的模式是C/S、B/S，两层、三层、多层次的应用结构等等。
1.1.5界定灾备系统的总体架构
根据实际需求、现有技术、所在地域、计划防范的灾难种类和预算投入的资金量等实际情况，确定灾备系统预期达到的级别，并以此来确定灾备系统与生产运行系统在地理位置上的距离（同城还是异地或两者兼备－堡垒节点），备份数据存储所在的介质（磁盘还是磁带或两者兼备），备份数据在生产中心与备份中心传输的方式（这就涉及到了具体的计算机存储与网络技术），以及备份中心计算机系统的处理能力和网络接管所需的具体架构（是否与生产中心采用完全同等数量、容量和性能的计算机、存储设备和网络体系结构）。
第2章主流容灾技术说明
2.1数据备份
数据备份是系统、数据容灾的基础，也是低端容灾的实现，是高端容灾（实时数据保护）的有力保障。
目前备份技术主要有快照备份、离线备份、异地存储备份。
备份系统通过备份策略，对计算机信息系统的操作系统、文件系统、应用程序、数据库系统等数据集，实现某一时间点的完整拷贝，拷贝的数据处在非在线状态，不能被立刻访问，必须通过相应操作,如恢复等方式使用备份数据。
这也解决了高端容灾（实时数据保护）不能解决的问题：
人为误操作、恶意性操作等，这类操作，计算机系统是不能区分的，一旦执行，将造成数据中心、灾备中心同时修改；对于数据库系统，在日志方式下，可以通过回滚方式修改，对于文件系统、操作系统等其他配置信息是不能回滚的，将造成毁灭性的结果。
因此在建设高端容灾系统的前提，一定要做好本地系统的备份，这是容灾技术的起点。
目前成熟的备份软件有SymantecNetBackup、EMCLegato，IBMTSM，HPProtectServer等等。
2.2实时数据保护
实时数据保护，就是在多块磁盘上、多个阵列、多台服务器、多个数据中心实时的保存同一份数据的多份存储，目的是为了避免物理故障，数据不会因为一块磁盘、一个阵列、一台服务器、一个数据中心的故障，而不能访问。
注意，实时数据保护需要以数据备份作为前提，它不能防范人为误操作和恶性操作。
这里我们要强调容灾的目的是让数据在灾难发生时，还能被访问，通过实时数据保护，保证数据的完整性；因此实时数据保护是容灾手段，而不是目的。
目前实时数据保护的技术主要有两种：
数据镜像和数据复制。
2.2.1数据镜像（Mirroring）
数据镜像（Mirroring）是冗余的一种类型，一个磁盘上的数据在另一个磁盘上存在一个完全相同的副本即为镜像。
分软件镜像与硬件镜像，它们的的区别就在于实现镜像所需的CPU周期所处的位置。
最终，都是根据程序的指令，为硬件（磁盘，以及磁盘上存储的数据）制作一个镜像副本。
镜像可以保证两份数据完全一样。
镜像软件有SymantecVolumeManager；各硬件厂商都有基于自己阵列的硬件镜像方式。
2.2.2数据复制（Replication）
数据复制（Replication）是将一个原数据的及其改动，通过后续机制拷贝到另外一处，可以是另一个磁盘、另一个阵列、另一个服务器、另一个数据中心。
由于实现的机制不同，又分为同步复制和异步复制两种方式。
同步复制，能够确保两份数据完全一致，但对系统的影响较大，一般不会采用；异步复制，通过后续机制，确保将本地改动的数据复制的异地，对系统的影响较小，但数据同步有延迟，是目前实现远程数据同步的主要方法。
根据实现机制，数据复制分为软件方式和硬件方式；硬件方式往往又被称为远程镜像。
软件复制有SymantecVolumeReplicator；Datacore等；其中Symantec是基于卷的复制，Datacore是基于block的复制，类似于硬件的复制，纯硬件复制有HDSTrueCopy、EMCSRDF等。
其中软件复制是可以跨硬件平台，可以实现多厂商集成，一般硬件复制则是相同品牌之间的磁盘子系统的操作。
具有一定的限制性。
2.2.2.1软件复制
SymantecVolumeReplicator（简称VVR）负责远程数据复制。
VVR复制基于Volume进行。
复制的数据可以是数据库中的数据（文件方式或裸设备方式），数据库日志，复制的数据也可以是各种文件，如应用和数据库配置文件，应用程序，库文件，等等。
复制的示意图见图四。
VVR与VxVM完全集成在一起。
用VxVM管理界面和命令统一配置管理；由于VVR仅仅将Volume上每次I/O的实际数据实时复制到远程节点，所以在网络线路上传输的数据量很少，对带宽的需求也很小，因此也与应用无关，只要是在定义的复制卷上的任何操作，都会被复制到异地。
Datacore则是基于软件的块设备复制，处于卷的更底层，属于块设备的远程复制，与基于卷的复制不同的是，他具有应用操作系统的独立性，数据的远程复制与操作系统无关，并且不需要远端主机应用系统的运行，支持异步和同步的方式，并且与硬件存储子系统不同的是，Datacore可以实现异构存储子系统的集中管理，打破了单一厂商选择的限制，对于磁盘子系统的选择更加灵活。
其复制示意图如下：
通过整合原有存储子系统以及新购的存储子系统，将数据的改动记录在Datacore的SDS设备当中，采用存储转发的传输机制，利用cache的技术和buffer的技术，记录数据的改变，然后通过传输机制将所有应用的数据传输到对端，该软件支持一对多的远程复制。
类似于硬件复制，但是可以不受品牌限制。
2.2.2.2硬件复制
以EMC的SRDF为例，如下图：
1．系统定期检测磁盘物理数据块的改变状况。
如果发现有数据块改动，将会被系统记录，并一次性将改动过的数据块考到复制缓存，这一动作被称为Switch。
拷贝到缓存中的数据块，在下一个Switch来临之前，被复制到异地相应的阵列缓存中。
在下一个Switch时，本地数据块被复制到本地存中，而异地缓存中上一次被改动过的数据块才被复制到容灾系统中。
根据实应用范围，数据复制分为应用复制、数据库复制、卷复制、控制器复制。
应用复制，是指通过应用系统直接向原生产中心和容灾中心同时发交易，生产中心和容灾中心都处理成功，该笔交易才算成功；只要有一边应用处理失败，该笔交易就算失败。
由于交易的延迟性较大、健壮性较差，应用复制一般不会考虑。
应用
数据库
操作系统
控制器
物理磁盘
数据块
SITEA
应用
数据库
操作系统
控制器
物理磁盘
SITEB
IOLog
SQL/Log
交易
2.2.2.3数据库复制
数据库复制，如Oracle的DataGuard、QuestSharePlex、DSGRealSync等，通过分析数据库RedoLog和ArchiveLog实现日志的复制，将分析结果直接或转化为SQL语句传到容灾中心，在容灾中通过心Aply数据库日志或将日志转化的SQL语句重做，来保证数据库数据的一致性。
数据库复制实际上是应用复制的数据库实现，复制方式通过异步完成。
卷复制如上SymantecVolumeReplicator。
控制器复制，如上EMC的复制过程。
2.2.2.4DatacoreSDS
实际上还有一种新的复制方式，称为基于SAN网络的卷复制，如Datacore的SDS。
它是通过特殊的运行于操作系统上的SDSSAN控制器，实际是将低端的无智能存储变为高端的智能存储，使得他们得以建立基于智能SAN控制器的卷，通过这种与主机应用无关，但与SDS控制器直接相关的卷实现复制。
此种技术较新，目前具有多家厂商均向此方向发展，其中Datacore是较早的研发厂商，当中还有IBM的SVC和HDS的USP系列也是采用此种技术。
2.3应用系统恢复
正如前所述，数据复制是容灾的手段，不是目的，容灾的目的是数据的访问。
因此应用的恢复和以下的网络的恢复也是容灾的关键。
应用系统恢复，这和系统的应用模式直接相关。
需要考虑应用系统的应用架构。
是Client/Server架构，还是Broswer/Server架构；是2层架构、还是3层架构、还是多层架构。
两层架构，表示容灾中心的应用只要启动数据库就可以服务了。
如果是三层架构，就意味着应用系统除数据库以外，还有网络服务程序，如中间件Tuxedo、CICS、WebLogic、WebSphere、9iAS、SAP等等。
在容灾应用切换时，能够手工或自动化的将这些服务一一启动。
2.4网络系统恢复
在灾难发生后，应用切换到灾备中心了，本地的应用前端需要重新访问容灾节点的服务，带来另外一个问题，网络如何切换？
是建立新的网络，还是使用动态路由，还是有其它办法？
实际上最简单的办法，就是通过外部DNS服务器，改变服务器名和IP的映射关系，将原服务器名映射到新的IP地址上，就可以利用容灾网络，实现前端对容灾中心服务器数据的访问。
2.5容灾切换过程
就是在灾难发生后，数据库切换、应用重新启动、网络实现切换等等,容灾中心接管原生产中心的整个过程；同时还包含了在原数据中心修复后，数据库、应用、网络需要重新切会来的整个过程。
这些过程，可以通过手工切换、也可以通过自动化过程完成。
2.6消防演习
大部分的容灾方案，在项目实施后，很难有机会来实现预演，因为对于大部分方案来说，这种预演活动，需要耗费大量的人力财力。
但是消防预演是必不可少的，它是实时测试目前的容灾方
升级会员 