容灾方案应该考虑哪些方面(设计容灾项目时有哪些注意事项需要重视)
大家好，容灾方案应该考虑哪些方面相信很多的网友都不是很明白，包括设计容灾项目时有哪些注意事项需要重视也是一样，不过没有关系，接下来就来为大家分享关于容灾方案应该考虑哪些方面和设计容灾项目时有哪些注意事项需要重视的一些知识点，大家可以关注收藏，免得下次来找不到哦，下面我们开始吧！
容灾是一项为了防范由于自然灾害、社会动乱和认为破坏造成信息系统数据损失、业务暂停的系统工程。影响信息安全的因素是多方面的，因此需要采用不同的技术手段来解决。数据备份，或者说本地容灾在很大程度上已经不能满足企事业单位日益增强的对于数据安全和业务连续性的要求了，异地容灾是信息化发展的必然趋势。
考虑到不同企事业单位对数据安全和业务连续性的要求不尽相同，我们将异地容灾分为两大类：数据级容灾和应用级容灾。
数据级容灾：就是指建立一个异地的数据系统，该系统是本地关键应用数据的一个可用复制。在本地数据及整个应用系统出现灾难时，至少在异地保存有一份可用的关键业务的数据。该数据可以是与本地生产数据的完全实时复制，也可以比本地数据略微落后，但一定是可用的。
应用级容灾：在数据级容灾基础上，在异地建立一套与本地生产系统相当的备份环境，包括主机、网络、应用、IP等资源均有配套，当本地系统发生灾难时，异地系统可以提供完全可用的生产环境。
传统的异地容灾方案大多基于远程复制技术。远程复制是指运用复制技术将数据以同步或者异步的方式存储到异地灾备中心中，其主要实现方式有三种：1.利用主机远程复制软件或硬件。2.利用存储自身的复制软件。3.利用数据库软件产品。远程复制的方式可以实现数据级的容灾,但是一旦发生灾难，无法保证业务的连续性。此外，一旦出现数据库逻辑错误或人为误删除的情况，远程复制不能修复数据错误，也不能找回误删除的数据，更谈不上100%恢复数据并保障数据的可用性了。
老牌容灾备份厂商：和力记易的异地容灾方案以CDP持续数据保护技术为核心，可以构建异地桌面端或服务器端的文件、数据库和应用的全需求平台，能够防范数据丢失、修复数据错误，还能保障业务连续，全方位满足客户不同的数据安全和业务连续性要求。相较于其他异地容灾方案，和力记易的CDP异地容灾方案具有“一低一高一强”的特点
二、什么是容灾如何设计容灾方案
容灾是一项为了防范由于自然灾害、社会动乱和人为破坏造成信息系统数据损失、业务暂停的系统工程。容灾方案的设计要根据实际需求出发，如果单纯是为了防止数据损坏，一般会选择数据级的容灾备份方案，选择相应的数据备份软件或者一体机，例如针对服务器实时备份的备特佳软件，针对虚拟机备份的数易云备系统，还有适合中小企业的备份宝一体机。如果是既要保证数据安全，又要保障业务的连续性，和力记易的备特佳CDP容灾备份软件则是不二之选，对业务连续性要求较高的医疗卫生领域，超过三分之二的客户都选择了备特佳。
三、数据库的容灾方案有哪几种,分别有什么优点和缺点!
简单的说几句吧。其实这个解决方案呢，主要是要先考虑成本问题，其他的，技术问题其实都很容易解决，但是企业应用上，最大的限制就是成本。下面以ORACLE数据库为例，简单说说。希望对你有所帮助。(数据库类型并不重要，解决方案都是大同小异。)
1、基于存储层的容灾复制方案
这种技术的复制机制是通过基于SAN的存储局域网进行复制，复制针对每个IO进行，复制的数据量比较大；系统可以实现数据的同步或异步两种方式的复制。对大数据量的系统来说有很大的优势(每天日志量在60G以上),但是对主机、操作系统、数据库版本等要求一致，且对络环境的要求比较高。
2、基于逻辑卷的容灾复制方案
这种技术的机制是通过基于TCP/IP的网络环境进行复制，由操作系统进程捕捉逻辑卷的变化进行复制。其特点与基于存储设备的复制方案比较类似，也可以选择同步或异步两种方式，对主机的软、硬件环境的一致性要求也比较高，对大数据量的应用比较有优势。其目标系统如果要实现可读，需要创建第三方镜像。个人认为这种技术和上面提到的基于存储的复制技术比较适合于超大数据量的系统，或者是应用系统的容灾复制。
3、基于oracle redo log的逻辑复制方式
使用这种方式的主要有一些第三方的软件，以及oracle自己的DATAGUARD中的logical Standby。目前，国外已经有了很多比较成熟的产品及成功案例，国内也有类似的产品，但在产品的成熟程度和成功案例上跟国外还有一定的差距。
使用oracle以外的独立进程，捕捉redo log file的信息，将其翻译成sql语句，再通过网络传输到目标端数据库，在目标端数据库执行同样的sql。如果其进程赶不上oracle日志切换，也可以捕捉归档日志中的内容。也有的产品在源端以事务为单位，当一个事务完成后，再把它传输到目标端。所有的产品一般都是以表为单位进行复制，同时也支持大部分DDL的复制(主要在oracle9i环境中)。
数据库的吞吐量太大时，其实据会有较大的延迟，当数据库每天的日量达到60G或更大时，这种方案的可行性交差；实施的过程可能会有一些停机时间，来进行数据的同步和配置的激活；复制环境建立起来以后，对数据库结构上的一些修改需要按照规定的操作流程进行，有一定的维护成本。
