容灾系统建设方案

******x应用容灾。

系统建议方案。

目录。1. 用户需求及针对本需求的容灾系统设计综述 3

1.1 应用数据安全级别的分级考虑 3

1.2用户需求分析： 4

1.3 本项目中需要注意的几个要点 6

2.数据容灾系统的详细设计 8

2.1 系统设计原则 8

2.2 系统的产品选择 9

3.3 灾备中心的组建 11

2.4 数据容灾系统的基本结构 12

2.5 数据的远程复制流程 14

2.6 数据的远程恢复流程 15

2.7 本容灾系统的结构特点 18

2.8 数据容灾系统扩展 19

2.9系统投资保障 19

3.数据容灾系统与其他方案的简要比较 19

4.数据容灾系统的实施计划 21

4.1 系统实施需求规划 21

4.2 相关性要求/实施步骤 22

4.3 系统配置清单 24

5.数据容灾系统的测试/验收计划 24

5.1 基本测试及对oracle和其他类型数据的测试 25

5.2 切换及回切的测试 26

5.3故障测试 27

6.数据容灾系统的日常管理/演练计划 27

7.应用级容灾的规划 28

8.后续其他节点的扩展规划 28

10. emc recoverpoint的维护 28

附件一：美国emc公司简要介绍 29

******x应用容灾系统建议方案。

******x当前的应用系统类别较多，包括了办公及业务等多个方面。在平台上包括windows及当前主流的多种unix,在存储体系上也具有多种型号的存储产品。因此，整个系统的复杂程度较大。

同时，由于应用系统一经处于比较完善的程度，因此，任何的调整都将带来很大的影响。

为此，为了确保数据的安全性，在早期用户实施了数据的磁带备份，但对于关键数据来说，这种磁带备份还不能够完全满足系统抵御各种灾难的能力。为此，用户考虑对数据实施灾备计划。

数据的容灾保护提供最基本的容灾底线保证，确保在任何预计之外的灾难发生后，业务系统都可以在允许损失极少量数据（或无损失）的情况下，在一定的时间内恢复，数据容灾同时也是应用逻辑错误和数据库软件bug的容灾应对出发点；可以通过一定的方式来恢复到这种故障之前的可用的状态。

鉴于当前存在的大量数据，在安全性的要求上建议分出不同的优先级别，建立不同安全级别的保护措施。这样不仅在成本上会带来优势，同时也可以确保最关键数据的不丢失。

这种分级保护一般根据可以承受的数据丢失量（如半小时，或一天）来考虑。我们不妨把不允许有任何数据丢失的应用定义为安全级别最高，要求进行实时的同步的数据远程传输，对于相对来讲数据安全级别稍低者可以把数据传输的优先级别作相对较低的配置，从而确保在同一时间优先发送最为关键的应用数据。

而对于数据安全要求一般的数据来说，建议采用本地的磁带备份即可，而不必纳入到灾备的体系中来。

这样不仅可以合理使用资金，同时也可以确保关键数据的最高级别保护。

用户资料采集：

******x当前san环境（图）

用户需求分析：

1）数据的实时远程复制。

针对关键业务系统数据实现数据的实时的远程复制，从而保障数据在本地发生各种故障之后首先可以保障数据的完整性，并可以通过一定的途径快速得以恢复，或者根据情况在远程直接启动应用。

2）灾备数据的可处理性，包括对数据的读写操作。

所谓的读操作，是指灾备数据可以为其它的某些临时的应用提供便利，支持对这些数据的读操作。从而可以方便地验证灾备体系的工作是否正常，或者在必要的时候利用这些数据进行诸如员工培训、软件调试、相关系统的引用等多种处理。

所谓的数据读写操作，是考虑利用灾备数据提供诸如员工培训、系统应用测试、后续软件调试或其他临时应用的可能。这样，可以为上述应用带来最大的便利性。但是，为了保持和原始数据的一致性，系统应该支持上述写入操作的reset(重置)操作，使得在上述任务结束后，可以方便地把数据恢复到没有进行写入操作之前的状态，维持灾备数据和源数据的严格一致。

另外一个方面，数据的读写支持，也可以很方便地验证灾备体系的工作是否正常。

当然，这种读写操作必须要对数据的远程复制和本地的应用不产生任何影响。

2）（远期）应用的可切换支持。

灾备中心不应该作为纯粹的备用系统，在提供诸如数据查询等应用的同时，还要提供自动的应用切换等支持，一旦在生产中心发生故障后，灾备中心的关键系统可以自动接管生产系统，提供持续的应用保障。

这种规划建议作为远期的目标之一，当前建议只以数据的远程复制为主，但当前的方案必须要考虑到本要素。

通过在对用户的具体环境和需求作了细致的分析之后，我们认为用户对该数据容灾系统给以了充分的重视，所提出的观点和要求是十分详细和具体的，在此，从我们方案提供商的角度，对此作如下的概括，便于整体方案的分析。

方案的通用性。

这种通用性体现在两个方面：一是异构平台、存储设备的支持性，二是对不同应用类型数据的适用性，只有这样的方案才可以较好地保障用户当前投资，达到与应用类型无关、与平台无关以及与磁盘阵列等存储设备无关的适用性最广的解决方案。在当前，数据主要以oracle、db2、sql2000类型为主，但是随着应用类型的增加，产生不同类型数据的可能性还是很有可能的。

如果现在选用了仅仅支持如oracle数据的解决方案，那末临时性的其他数据将无法得到及时的复制，或者今后的应用扩展将受到很大的制约。

实时的数据复制解决方案。

我们认为最终用户已经对不同应用数据的安全性要求做出了很好的分析和划分，其中关键数据要求不丢失，或尽量少地丢失。因此，我们认为必须要采用真正的实时的数据复制解决方案才可以满足这种要求。在条件具备的情况下，应该做到无延迟数据复制。

而建议采用非实时或准实时复制方案。

灾备数据的可用性。

分为两个方面，一是数据的实时复制的可靠性，要求复制数据要和源数据保持严格一致，严格按照源数据的写入顺序进行复制，使得灾备数据具有可用性。二是在需要的时候可以很便利地对灾备数据进行读写操作，但是，这种读写操作不应该对数据的实时复制产生影响。还有，在对灾备数据进行修改（如进行员工培训、软件测试等操作时对数据的采集或调整测试）后可以恢复到原有状况，从而确保数据的一致性和安全性。

扩展的便利性。

包括对当前和今后其他应用类型数据的实时复制的扩展，复制距离的扩展以及复制节点数量的扩展等多个方面，在当前选择方案的时候面对未来的需求进行全面考虑。

数据的丢失量。

对于关键应用要求数据不丢失，因此，不建议采用诸如当前在主机上开辟一定的缓存（buffer）空间，用来存放待复制的数据，利用异步的方式发送到远程。这样的产品无疑会因为各种原因导致数据的丢失率较大，如当主机资源意外掉电或宕机时，上述buffer（缓存）中的数据必然会被丢失。我们推荐在主机产生写入操作的同时数据被发送出去，这样，数据始终保持和本地的写入同步，这样的方案才可以真正做到数据的无丢失。

数据的可回滚性（最新数据不可用情况下的数据恢复支持）

不可避免地会在某些情况下，最新复制的数据不可用的情况下，尤其对于oracle数据库，很可能在管理员发现故障时，其内部已经在几分钟之前就已经出现了问题，那末，被复制过去的数据肯定也是不能够被使用的。此时，我们必须要具有数据的回滚性支持，比如可以往前回滚30秒、1分钟或2分钟，并利用这些数据获得可用数据同时数据的丢失量最小化。

灾备自身系统实施及恢复的便利(简易)性。

灾备系统的实施不应该对现有的应用系统作任何调整，尤其是对当前运行较稳定的系统。当然，即使需要一定的调整。那末。

这种调整夜必须是系统管理员可以理解并接受的。同样，对于灾备系统自身而言，发生问题后的解决或全面的恢复也要简易化，要支持如web管理，图形化管理，而不应该需要较复杂的配置。否则，今后如果需要作系统调整，那末，系统管理员将无法面对这种配置和管理，甚至导致日常的维护也不敢动手的现状。

对系统的影响最小化。

由于当前应用系统的完善性和稳定性，不建议为了本灾备系统而对当前的应用系统做任何方面的调整。主机资源不能够因为灾备系统的实施而显得紧张，包括内存、cpu等资源的占用应力求最小化。当然这种影响我们认为同样包括实施时候对系统、对数据库、对应用的调整合对存储空间的调整等多个方面。

灾备方案要支持策略化配置。

便于不同的应用数据具有不同的复制优先级别，以确保关键数据不丢失。

灾备系统的管理简易性。

容灾系统建设方案

系统建设方案

绩效评价系统建设方案

健康档案管理系统建设方案

其他用户还读了