灾备方案

1.数据中心容灾备份解决方案
随着社会的发展和科技的进步，政府日常工作越来越依赖于数据处理来进行，政务系统的连续性依赖于数据中心系统的稳定运行。

然而，灾难就像灰尘一样伏击在运营环境周围，政务系统的数据中心可能正在一个充满风险和威胁的环境下运行。

如果不能对这些风险采取有效治理，一旦数据由于某种原因丢失，就很有可能对政府的日常工作造成严重的影响。

如果核心数据丢失，将会使得某些核心功能陷入瘫痪，造成不可估量的损失。

因此，保证政务的连续性和数据的高可靠性和可用性，已经成为政府部门在数据中心建设中，必须要考虑的问题。

1.1灾备解决方案原则
首先，在制定容灾系统方案的过程中要考虑的就是容灾系统建设对原有业务系统带来的影响。

比如，采用数据复制技术对系统I/O带来的延迟，应用数据同步对日常业务处理系统带来的压力等。

因此，企业要通过周密的测试和分析来规避容灾系统建设时带来的这些风险，以保证业务系统不会因容灾系统的建设而出现在处理性能上下降的问题。

第二，数据状态要保持同步。

为保证在灾难发生时，业务可以成功地切换到备份中心，就必须保证容灾系统数据同步机制的可靠性。

因此，建立可靠的数据同步校验机制是必须的; 同时，还要考虑建立定时的、自动的数据同步核查对比机制，以检验两个中心数据的一致性，这是数据容灾工作中非常重要的一部分。

第三，容灾系统的日常维护工作要尽可能轻，并能承担部分业务处理和测试的工作。

容灾系统的维护和管理是容灾切换成功的重要保证，在系统建设中，就必须要考虑系统的维护管理流程。

生产中心任何业务处理过程的改变都必须完整地复制到备份中心; 所有新业务系统上线时，必须通知备份中心，并在备份中心配置好数据同步机制; 对原程序的改动也必须保证两个中心同时上线。

第四，系统恢复时间要尽可能短。

容灾系统主要是为了实现在主中心系统发生灾难时，可以在规定时间切换到备份中心，保证数据不会丢失，并且继续向用户提供服务。

但往往在灾难发生时，主要技术人员不能及时到达现场，为了顺利实现系统间的切换，应该让系统切换操作尽可能地简单; 并建立固定化的、标准化的切换流程，要求维护人员在切换演习时严格按照流程的指导步骤进行操作。

第五，可实现部分业务子系统的切换和回切。

当人事变动、业务变化、IT设施变化以及其
他可能引起恢复规划文档失效的变化发生时，应及时更新各恢复规划文档，并在必要时启动模拟测试或演习，确保业务连续性系统的工作能力。

第六，技术方案选择要遵循成熟稳定、高可靠性、可扩展性、透明性的原则。

目前，国际上比较成熟的容灾技术包括：SAN/NAS技术、远程镜像技术、虚拟存储、基于IP的SAN互连技术以及快照技术等。

其中基于IP的SAN远程数据容灾备份技术应用比较广泛，其是利用基于IP的SAN的互连协议，将主数据中心SAN中的信息通过现有的TCP/IP网络，远程复制到备份中心的SAN中的。

当备份中心存储的数据量过大时，可利用快照技术将其备份
到磁带库或光盘库。

这种基于IP的SAN远程容灾备份，可以跨越LAN、MAN和WAN，成本低、可扩展性好。

基于IP的互连协议主要包括FCIP、iFCP、InfiniBand、iSCSI等。

第七，构建系统方案可以选择多种技术组合方式。

目前，业内应用较多的容灾方案是基于智能存储系统的远程数据复制技术，它是由智能存储系统自身实现的数据远程复制和同步，即智能存储系统将对该系统中的存储器I/O操作请求复制到远端的存储系统中并执行。

由于在这种方式下，数据复制软件运行在存储系统内，因此较容易实现主中心和容灾备份中心的操作系统、数据库、系统库和目录的实时拷贝及维护能力，且不会影响主中心主机系统的性能。

如果在系统恢复场具备了实时数据，那么就可以做到在灾难发生时，及时开始应用处理过程的恢复。

但这种方案也有开放性差(不同厂家的存储设备系统一般不能配合使用)、对于主、备中心之间的网络条件(稳定性、带宽、链路空间距离)要求较苛刻等缺点。

1.2灾备解决方案设计需要考虑的因素
1.2.1 RTO和RPO
RTO（RecoveryTime Object）：是指灾难发生后，从IT系统宕机导致业务停顿之刻开始，到IT系统恢复至可以支持各部门运作，业务恢复运营之时，此两点之间的时间段成为RTO。

RTO是反映业务恢复及时性的指标，表示业务从中断到回复正常所需要的时间。

RTO值越小，代表容灾系统的数据恢复能力越强。

各种容灾解决方案的RTO有较大差别，基于光通道技术的同步数据复制，配合异地备用的业务系统和跨业务中心与备份中心的高可用管理，这种容灾解决方案具有最小的RTO。

RPO（Recovery Point Objective），是指从系统和应用数据而言，要实现能够恢复至可以支持各部门业务运作，系统及生产数据应恢复到怎样的更新程度。

RPO是反映恢复数据完整性的指标，在同步数据复制方式下，RPO等于数据传输延迟的时间；在异步数据复制下，RPO基本为异步传输数据排队的时间。

在实际应用中，考虑导数据传输的因素，业务数据库与容灾备份数据库的一致性（SCN）是不同的，RPO表示业务数据库与容灾备份数据库SCN的时间差。

发生灾难后，启动容灾系统完成数据恢复，RPO就是新恢复业务系统的数据损失量。

设计容灾系统不能只看RTO和RPO，对于不同的业务系统和用户特殊的要求，其它一些指标有可能成为选择容灾解决方案的主要因素。

例如，某些地区为了防范一些特定自然灾害的风险，要求容灾备份中心与业务中心保持足够的距离，在这种情况下，容灾备份中心与业务中心的距离要求就是容灾系统的重要指标。

1.2.2数据安全
数据的完整性，一致性是保证业务连续的关键。

在本地，数据安全需要使用RAID技术来保证。

在灾备方案的设计中，数据复制方案的设计是整个设计的基础。

目前业界主流的数据复制技术有：基于数据库本身的复制技术，基于操作系统的数据复制，基于虚拟存储的复制技术和基于存储的复制技术。

在方案所用技术的选择时，应当根据客户的预算，现场的条件，
综合来进行考量。

后续在1.6.1数据同步章节，将会有这4类数据复制技术的综合对比，可以作为选择的参考。

1.2.3网络安全
通信网络是容灾系统的组成部分，通信线路的质量也是容灾系统的性能指标之一，其中包括网络的数据传输带宽、网络传输通道的冗余和网络服务商的服务水平（网络年中断率）。

如果容灾系统使用的通信网络是确定的，为了比较不同容灾解决方案，可以用单位存储容量的数据库在同一通信网络上的数据完全恢复时间作为一项设计指标。

1.2.4业务连续性
业务连续性是灾备方案的最终目标，是方案的价值所在。

为了保证业务的连续，首先需要数据的连续，之前我们讨论了数据安全相关的内容。

其次，在数据连续的基础上，出现灾难时，系统需要能够满足（1）网络切换（2）应用切换。

以此，来保证系统能够顺利切换到灾备地，继续安全运营，最大化保证客户利益。

1.3国标系统灾备等级划分及应对措施
国家《信息系统灾难恢复规范》（GB/T 20988-2007）规定了六个级别的容灾，下表分别针对每个级别给出了相应的应对措施。

1.4容灾技术分析
1.4.1备份方式
(1)冷备份
备份系统未安装或未配置成与当前使用的系统相同或相似的运行环境, 应用系统数据没有
及时装入备份系统。

一旦发生灾难，需安装配置所需的运行环境，用数据备份介质（磁带或光盘）恢复应用数据，手工逐笔或自动批量追补孤立数据，将终端用户通过通讯线路切换到备份系统，恢复业务运行。

优点：设备投资较少，节省通信费用，通信环境要求不高。

缺点：恢复时间较长，一般要数天至1周，数据完整性与一致性较差。

(2)温备份
将备份系统已安装配置成与当前使用的系统相同或相似的系统和网络运行环境，安装了应用系统业务定期备份数据。

一旦发生灾难，直接使用定期备份数据，手工逐笔或自动批量追补孤立数据或将终端用户通过通讯线路切换到备份系统，恢复业务运行。

优点：设备投资较少，通信环境要求不高。

缺点：恢复时间长，一般要十几个小时至数天，数据完整性与一致性较差。

(3)热备份
备份处于联机状态，当前应用系统通过高速通信线路将数据实时传送到备份系统，保持备份系统与当前应用系统数据的同步；也可定时在备份系统上恢复应用系统的数据。

一旦发生灾难，不用追补或只需追补很少的孤立数据，备份系统可快速接替生产系统运行，恢复营业。

优点：恢复时间短，一般几十分钟到数小时，数据完整性与一致性最好，数据丢失可能性最小。

缺点：设备投资大，通信费用高，通信环境要求高，平时运行管理较复杂。

在计算机服务器备份和恢复中，冷备份服务器（cold server）是在主服务器丢失的情况下才使用的备份服务器。

冷备份服务器基本上只在软件安装和配置的情况下打开，然后关闭直到需要时再打开。

温备份服务器（warm server）一般都是周期性开机，根据主服务器内容进行更新，然后关机。

经常用温备份服务器来进行复制和镜像操作。

热备份服务器（hot server）时刻处于开机状态，同主机保持同步。

当主机失灵时，可以随时启用热备份服务器来代替。

对于关键的业务，Primeton建议采用同城热备＋异地热备的方式进行部署，对于一般性的业务，建议采用同城热备＋异地温备（应用不启动，数据保持异步复制）的方式进行部署。

1.4.2数据复制技术
目前数据复制技术主要有如下表所列4种，基于红色字体部分的要求，结合客户的需要，Primeton推荐采用基于存储或者基于应用程序的数据复制技术来进行数据同步。

1.4.3重复数据删除技术
重复数据删除技术是指将存储系统中存在的大量内容相同的数据删除，只保留其中一份，从而缩减存储空间的技术。

在云灾备中，该技术既能大幅减少灾备中心存储的数据量，降低灾
备中心的建设和运维成本，又能大幅减少数据备份和恢复过程中用户和灾备提供商间的数据传输量，提高备份和恢复的性能，是一项十分重要的技术。

随着灾备中心的规模不断增大，存储的数据量和访问量不断增加，单一节点上的重复数据删除方法已不能满足性能和容量的需求。

除上述基本重复数据删除技术外，一些优化和改进技术对云灾备是至关重要的，包括高性能、可扩展的、分布式的重复数据删除技术，以及为提高灾备中心数据可靠性的高可靠重复数据删除技术。

1.4.4操作系统虚拟化技术
除了数据级的灾备，还应提供系统级的灾备。

即在将数据复制到云端的同时，也将受保护的应用程序的状态复制到云端，当灾难发生时可以立即切换到云端的应用程序运行，保证业务连续性。

系统级灾备是通过操作系统虚拟化和检查点实现的。

检查点用来捕获进程某一时刻的运行状态，从而实现进程迁移。

进程迁移既可以是用户应用程序进程到云灾备中心的迁移，也可以是云灾备中心内部的虚拟机池间进程迁移，以实现根据前端用户的需求自动地调节灾备服务提供商有限的硬件与软件资源，动态地、弹性的反应前端业务对灾备的需求。

当程序因故障中断，如果不能保留其中间运行状态，恢复后从头运行将会带来极大的消耗。

检查点技术能够解决这个问题。

通过保留各个进程的运行状态，恢复时能够复原到最近一次保留的数据映像。

传统的检查员机制是基于库的检查点机制。

例如以静态库的形式实现，或通过加载动态链接库来追踪程序运行过程中的数据变化。

也有一些检查点机制实现于内核级别甚至硬件级别。

例如通过在文件系统层之上引入一个中间层来实现保留文件系统状态的检查点机制；或者借助Fuse内核模块实现的支持检查点机制的文件系统，通过Fuse侦测、拦截内核级别的文件系统操作并将控制权传递给用户，从而能够在用户空间对文件系统状态进行保留。

随着操作系统虚拟化技术的发展，基于虚拟容器的检查点技术也得到了很好的应用。

虚拟容器是通过系统虚拟化技术构建出来的一个进程运行的较独立的上下文环境。

虚拟容器检查点技术能够有效保护容器内运行的应用程序和服务而不需要对应用进行修改。

1.5总体架构设计
1.5.1Primeton“两地三中心”容灾解决方案架构设计
结合近年国内出现的大范围自然灾害，以同城双中心加异地灾备中心的“两地三中心”的灾备模式也随之出现，这一方案兼具高可用性和灾难备份的能力。

1.5.1.1“两地三中心”本地高可用和容灾保护策略
（1）本地保护策略：
• 本地高可用
• 本地clone
• 持续数据保护
• B2D／BVTL
• 磁带备份
• Archive Log备份
（2）容灾保护策略
• 应用级或者数据级容灾
• 同级容灾、降级容灾
• 同步数据保护／异步数据保护
• 容灾数据复制技术
• 主备中心运营方式／双主中心运营方式／多中心运营方式
• 短、中、远期容灾策略
1.5.1.2“两地三中心”功能定位
同城双中心是指在同城或邻近城市建立两个可独立承担关键系统运行的数据中心，双中心具备基本等同的业务处理能力并通过高速链路实时同步数据，日常情况下可同时分担业务及管理系统的运行，并可切换运行；灾难情况下可在基本不丢失数据的情况下进行灾备应急切换，保持业务连续运行。

与异地灾备模式相比较，同城双中心具有投资成本低、建设速度快、运维管理相对简单、可靠性更高等优点。

异地灾备中心是指在异地的城市建立一个备份的灾备中心，用于双中心的数据备份，当双中心出现自然灾害等原因而发生故障时，异地灾备中心可以用备份数据进行业务的恢复。

1.5.1.3“两地三中心”容灾架构设计
逻辑架构模型设计：
物理架构设计：
方案特点：
• 同城范围有效保证了数据的安全性和业务连续性；
• 异地复制数据根据灾难情形，尽可能降低数据丢失机率；
• 同城双中心为同步复制，数据实时同步，RPO=0；
• 异地无距离限制，保证数据一致性，保证了数据的有效保护；
• 异地容灾带宽要求低，先进的复制机制提高带宽利用率。

对于本地本级备份，应建立在线、近线、离线等多级存储备份系统，充分利用先进的备份手段和备份策略，形成完整的本地备份管理解决方案；备份的数据包括操作系统、数据文件以及应用服务环境等多个方面；日常访问的重要数据采用磁盘或者虚拟带库方式备份，归档数据和非重要数据采用磁带库方式备份；重要数据应至少保证每周做一个全量备份，平时做增量备份。

对于数据级异地灾备中心，选址上，应进行风险分析，避免异地备份中心与主中心同时遭受同类风险；网络备用系统上，必须在核心网络层面实现热备，保证灾备中心区域内通信的可靠性；数据备份系统上，主中心与备份中心的备份链路应有冗余，并确保2小时内将主中心的增量数据复制或备份到灾备中心；数据处理备用系统上，配备灾难恢复所需的全部数据处理设备，并处于就绪状态或运行状态，与主中心共同承担部分核心应用的查询服务功能。

对于同城应用级灾备中心，选址上，主中心与同城灾备中心距离应小于100KM；网络备用系统上，在核心网络层面实现热备，主中心与应用级灾备中心间通过裸光纤互联或VPLS互联，部署TRILL构建大二层网络，满足虚拟化需求；网络负载均衡上，主中心网络与灾备中心网络的负载均衡，提高灾备网络利用率与灾备网络可用性，正常情况下数据流同时使用两个中心的网络，主中心网络出现故障时，则全部数据流向灾备网络；应用集群切换上，关键业务系统集群实现手动切换，主中心与同城灾备中心之间建立高可用性监控技术，实现灾备中心应用服务器集群与主中心生产服务器集群之间的高可用性切换；云计算技术采用上，采用虚拟化技术对同城灾备中心进行规划建设，同时，根据业务关键程度、对性能的要求，系统平台选择不同档次和不同平台的主机资源池、存储资源池。

1.5.2基于不同服务需求选择不同可靠性“两地三中心”架构
1.5.
2.1服务等级划分的可靠性
1.5.
2.2 Primeton通用的基于服务的“两地三中心”架构
1.5.
2.3 Primeton基于不同的服务质量，达到不同级别的整体可靠性（tier）（1）场景1
主环境如图中A所示，包含了数据库，应用，Web三层服务结构，本地高可用环境P作为同城备份站点，复制100%A中的Web服务，100%的A中的应用在线服务，100%的A中的OLTP事务，异地在数据库/应用／Web层均复制75%A中的服务。

那么这套方案整体的可靠性将会达到99.999%。

（2）场景2
主环境如图中A所示，本地高可用环境P复制100%的A中的Web服务，100%的A中的应用在线服务，异地在数据库/应用／Web层均复制75%的A。

那么这套方案整体的可靠性将会达到99.99%。

（3）场景3
主环境如图中A所示，本地高可用环境没有即没有同城备份站点，异地在数据库/应用／Web 层均有一个可以接受的备份（非和A环境100%相同）。

那么这套方案整体的可靠性将会达到99.70%。

（4）场景4
主环境如图中A所示，本地高可用环境没有即没有同城备份站点，异地采用冷备的方式，仅仅在发生灾难的时候采取措施。

那么这套方案整体的可靠性只有99.00%。

1.6数据级容灾设计
数据的复制是应用接管的基础，保障数据复制的完整性和实时有效性才能使得应用的接管有意义。

数据复制主要分为4大类（1.4.2已有说明），综合性价比和客户自身情况，Primeton 推荐可以使用如下两类的数据复制技术：
第一类，是基于磁盘阵列的复制软件实现，比如EMC SDRF、HDS 的TureCopy、IBM的Flash 等；
第二类，是基于服务器或者应用软件（应用层）实现，比如Oracle DataGuard组件、GoldenGate数据库复制软件、DSG的RealSync软件等。

A）磁盘阵列同步有以下主要特点：
• 可以实现对所有数据的灾备，支持所有的数据类型，是最全面的灾备保护方式；
• 基于存储设备进行灾备，可以有效的解决对数据库服务器和各种应用服务器的计算资源的占用问题；
• 部署简单，无需更改原来的文件系统。

维护也更加简单，维护好存储灾备系统就可以。

B）基于服务器或应用软件的灾备，有以下特点：
• 支持异构平台，开放的硬件选择；
• 极短时间切换的热容灾；
• 容灾侧数据库也处于打开状态，可以做主地数据库的负载均衡，提升系统的可用性；• 对网络要求不高，低带宽下能够传输数据；
1.7应用级容灾设计
应用级灾备包括两个方面：数据同步和应用接管。

数据同步是应用接管的前提。

在保证数据同步基础上，要实现应用接管，还要能实现灾难发生时的网络切换和应用切换。

1.7.1网络切换设计
应用级灾备要求提供冗余的网络线路和设备。

正常情况下，客户端通过生产中心的业务网络访问生产中心的应用服务器；在发生灾难时，通过网络切换，客户端能够访问到灾备中心的备用服务器。

目前，网络切换主要有以下三种：
（1）基于IP地址的切换
生产中心和灾备中心主备应用服务器的IP地址空间相同，客户端通过唯一的IP地址访问应用服务器。

在正常情况下，只有生产中心应用服务器的IP地址处于可用状态，灾备中心的备用服务器IP地址处于禁用状态。

一旦发生灾难，管理员手工或通过脚本将灾备中心服务器的IP地址设置为可用，实现网络访问路径切换。

（2）基于DNS服务器的切换
在这种方式下，所有应用需要根据主机名来访问，而不是直接根据主机的IP地址来访问，从而通过域名实现网络切换。

（3）基于负载均衡设备的切换
通过在服务器集群前端部署一台负载均衡设备，根据已配置的均衡策略将用户请求在服务器集群中分发，为用户提供服务，并对服务器可用性进行维护。

负载均衡能够按照一定的策略分发到指定的服务器群中的服务器或指定链路组的某条链路上，调度算法以用户连接为粒度，并且可以采取静态设置或动态调配的方式。

负载均衡设备能够针对各种应用服务状态进行探
测，收集相应信息作为选择服务器或链路的依据，包括ICMP、TCP、HTTP、FTP、DNS等。

通过对应用协议的深度识别，能够对不同业务在主生产中心和灾备中心之间进行切换。

这三种网络切换方式比较如下：
在以上三种网络切换方式中，基于IP地址的切换方式较简单，实现成本低，但是对于拥有较多服务器的灾备中心而言，手工更改大量IP地址和网络配置需要比较长时间，因此这种方式适合于只有少数应用服务器的场合；基于DNS的切换方案，从技术上讲较成熟，应用也较多，而且能够实现网络切换的全自动，但是需要增加两台DNS服务器的投资；而基于负载均衡的切换，需要增加负载均衡板卡，但是切换能够精细到业务和服务内容，因此，在大型数据中心情况下，Primeton建议采用负载均衡的方式进行网络之间的切换。

1.7.2应用切换设计
应用切换是指生产中心由于发生灾难而瘫痪时，可由灾备中心的备用服务器提供业务接管，确保业务运行的高连续性。

实现应用切换的前提条件是：
• 数据已经从生产中心同步到灾备中心；
• 灾备中心配置与生产中心对应的应用软件服务器、数据库服务器和中间件服务器等，且运行正常；
• 灾备中心网络运行正常或能够实现正常切换。

应用切换技术主要有以下几种：
（1）双活数据库技术
部分数据库复制容灾软件，能够实现生产中心和灾备中心数据库双活，即灾备中心的备份数据库也处于Open状态，客户端可对灾备数据库进行只读访问（例如GoldenGate、DSG等数据库复制软件）。

生产中心和灾备中心数据库保持双活，可提高灾备中心的资源利用率，分担生产中心的业务负担，在发生灾难时，自然也可以实现应用和业务的接管。

这种方式的缺点之一是只适合于特定的数据库应用，不适合文件系统等应用，有一定的局限性。

（2）远程集群技术
远程集群是指通过在生产中心和灾备中心的应用服务器上安装远程集群软件(例如Veritas Storage Foundation中的GCO组件)，实现跨广域的多服务器状态的监控，当发生灾难时，实现应用服务器的自动切换。

主要是由厂家提供的一些容灾软件实现自动切换，拉起异地的应用和数据库。

例如，赛门铁克的VCS，IBM的PowerHA等。

（3）手动切换方式
手动切换方式实现较简单，总体成本低，适用范围广，而且较可靠。

采用这种方式时，灾备中心部署与生产中心相对应的应用服务器和数据库服务器，安装相应软件。

在正常情况下，灾备中心服务器可选择不运行或者处于就绪状态但对外不可访问；发生灾难时，可在人为决策后，将灾备中心服务器启动或恢复对外访问，实现业务的快速切换。