两地三中心容灾方案,数据库两地三中心容灾方案

('Xx项目存储方案介绍目录1.现状综述......................................................................................................................................42.总体建设方案..............................................................................................................................42.1.建设原则和策略...............................................................................................................42.1.1.建设原则................................................................................................................42.1.2.建设策略................................................................................................................52.2.建设目标...........................................................................................................................72.2.1.总体目标................................................................................................................72.2.2.分期目标................................................................................................................72.3.建设内容...........................................................................................................................72.4.总体设计方案...................................................................................................................83.容灾的核心技术及选择..............................................................................................................93.1.容灾系统衡量指标...........................................................................................................93.2.容灾级别.........................................................................................................................103.3.常见容灾建设模式.........................................................................................................113.3.1.同城容灾..............................................................................................................113.3.2.异地容灾..............................................................................................................113.3.3.两地三中心..........................................................................................................113.3.4.双活数据中心......................................................................................................113.4.常用的数据复制技术......................................................................................................123.4.1.基于存储层的容灾复制方案...............................................................................133.4.2.基于主机数据复制技术的灾备方案...................................................................193.4.3.基于数据库的数据复制技术构建灾备方案.......................................................203.5.如何选择最优的容灾方案..............................................................................................283.5.1.数据容灾技术选择原理.......................................................................................283.5.2.数据容灾技术选择度量标准...............................................................................293.6.本项目容灾模式及技术的选择......................................................................................293.6.1.容灾模式选择......................................................................................................293.6.2.容灾中心选址......................................................................................................303.6.3.数据复制技术的选择...........................................................................................324.推荐方案概述............................................................................................................................334.1.技术路线选择.................................................................................................................334.2.总体方案架构.................................................................................................................334.3.数据库容灾系统设计......................................................................................................354.3.1.GoldenGate技术原理.........................................................................................364.3.2.各委办局和同城容灾中心之间的数据库复制...................................................374.3.3.同城容灾中心和异地容灾中心之间的数据库复制...........................................404.4.非结构化数据容灾系统设计..........................................................................................404.4.1.同城容灾中心和生产中心之间的数据容灾.......................................................414.4.2.同城容灾中心和远程容灾中心的数据容灾.......................................................434.4.3.应用级容灾几种实现方式...................................................................................444.5.一体化集中备份系统......................................................................................................45I4.6.容灾网络建设方案设计..................................................................................................464.6.1.整体容灾网络架构设计.......................................................................................464.6.2.前端服务网络容灾方案.......................................................................................474.6.3.服务器数据网络容灾方案...................................................................................494.6.4.存储网络容灾方案...............................................................................................504.6.5.本项目建议容灾网络方案...................................................................................515.本项目灾备系统建设的几点建议.............................................................................................525.1.需要按照灾备要求梳理系统..........................................................................................525.2.解决好数据库系统数据复制..........................................................................................525.3.“现实”的切换策略........................................................................................................536.软硬件设计................................................................................................................................546.1.软硬件总体选型原则......................................................................................................546.2.同城容灾中心软硬件设计..............................................................................................556.2.1.一体化备份系统...................................................................................................556.2.2.数据库容灾系统...................................................................................................566.2.3.云计算平台容灾系统...........................................................................................576.2.4.同城数据存储容灾系统.......................................................................................586.2.5.机房改造系统......................................................................................................586.2.6.网络系统..............................................................................................................606.2.7.安全系统..............................................................................................................606.2.8.详细软硬件配置清单...........................................................................................606.3.远程容灾中心软硬件设计..............................................................................................636.3.1.远程数据备份系统...............................................................................................636.3.2.远程数据库容灾系统...........................................................................................646.3.3.远程云计算平台容灾系统...................................................................................656.3.4.远程数据存储容灾系统.......................................................................................666.3.5.网络系统..............................................................................................................666.3.6.安全系统..............................................................................................................666.3.7.详细软硬件配置清单...........................................................................................667.项目组织机构和人员培训.........................................................................................................687.1.领导和管理机构.............................................................................................................687.2.项目实施机构.................................................................................................................707.3.运行维护机构.................................................................................................................707.4.技术力量和人员配置......................................................................................................717.5.人员培训方案.................................................................................................................718.项目实施进度............................................................................................................................728.1.项目建设期.....................................................................................................................728.2.实施进度计划.................................................................................................................728.2.1.同城容灾中心建设计划.......................................................................................728.2.2.异地容灾中心建设计划.......................................................................................739.投资估算....................................................................................................................................759.1.投资估算的说明.............................................................................................................759.2.投资估算.........................................................................................................................759.3.估算编制依据.................................................................................................................76II9.4.资金来源与落实.............................................................................................................769.5.投资估算明细表...............................................................................................................1III1.现状综述XX市政府网站管理中心自成立之日起，就按照集中建设的原则完成了“XX市电子政务外网统一平台示范工程项目”的建设工作，完成了XX市124家党政部门的接入工作，完成了在全市范围内只铺设一套网络基础设施的工作，实现了市及电子政务外网与省、国家政务外网之间的互联互通，目前共有服务器500多台，存储40多套，部署的虚拟服务器300多台。涵盖了XX市各委办局的大部分数据，包括公安局、财政局、民政局、卫生局、发展改革委、外办/侨办等，并为他们提供了各种电子政务应用系统和业务数据，随着业务应用水平的不断提高，各局对网络办公和数据的依赖程度逐年增加，为保障各委办局业务数据的连续安全运行，迫切需要对他们的数据进行备份，但是采用传统的备份方式需要针对每一个应用配置不同的备份方法、策略及容灾设备，将导致投资浪费和管理成本增加，为解决数据备份问题我们计划引人两地三中心云灾备技术。具体分析，XX市电子政务的业务类型众多、业务系统建设和运行的历史比较长，从系统结构和数据结构两方面来说，都是比较复杂的。从系统结构来说，既有单机运行的网站，也有WEB、应用服务、数据库三层架构的大型业务平台。从数据结构来说，既有结构化数据集中存储的资源库平台，所有关键数据统一存储在数据库集群中，也有非结构化数据如文件、图片等应用系统管理维护的资料数据。另外，XX市电子政务各业务系统需要保护的数据类型复杂多样，既有各种数据库如oracle，sqlserver多种版本，mysql等）数据，也有各种应用程序（网站类，OA类，业务系统类等）各种文档（word，execle，txt等）各种非结构化数据（关键视频，档案等），当然也需要对虚拟机镜像提供保护（VMWare和Cloudview等）。以上现状表明很难用一种灾备技术满足上述多种数据类型的容灾需求，结合应用和数据的关键级别、现有业务系统状况分类进行设计，我们计划采用数据备份、存储层数据复制以及数据库层数据复制几种容灾技术构建两地三中心灾备方案。2.总体建设方案2.1.建设原则和策略2.1.1.建设原则4XX市政务信息化容灾备份及安全系统建设是信息中心信息安全保障体系的重要组成部分，信息中心适应信息化发展趋势作出的一项重大战略部署，XX政务容灾系统建设需要遵循以下建设原则：统筹规划原则。容灾备份系统建设，涉及技术面广，复杂程度高，投资巨大，因此我们必须牢固树立“一盘棋”思想，坚持统筹规划，抓紧资源整合，协调各方力量，着眼实际、着眼全局、着眼长远，切实以统筹的理念推进信息化容灾备份系统建设。循序渐进原则。信息化容灾备份系统建设是一项系统工程，实施周期长，要本着循序渐进的原则，分步建设和实施。在建设之前应做好详细的规划设计，并按照规划的内容，分清主次，依次实施。全部建设完成后，还有定期组织演练，确保灾备系统能够正常工作。平战结合原则。灾难备份资源是为小概率事件准备的，平时处于备份、测试或者演练状态，设备闲置，因此我们可以在不影响灾难备份与恢复功能的前提下，本着平战结合的原则，充分利用数据灾备中心的各类资源，开展信息系统培训、开发等业务，真正让数据灾难备份中心的各类资源得到充分的利用和发挥作用。2.1.2.建设策略本项目建设策略上从过去注重单一部门、单一系统容灾问题的解决，向支撑全市电子政务系统安全高效运行的转变；二是在建设方式上，从部门独立建设、自成体系，向跨部门跨区域的协同互动和资源共享转变；三是在系统模式上，从粗放离散的模式，向集约整合的模式转变，确保电子政务项目的可持续发展，符合电子政务项目建设“集约化、专业化、规模化”策略。2.1.2.1.集约化策略在《关于加快推进国家电子政务外网建设工作的通知》(发改高技[2009]988号)文件之前，国家各部委应用系统采取垂直管理，各自独立的方式建设。一套灾备系统牵涉到的有基础设施建设、灾备设备资源以及经验丰富的运维人员，往往需要大量的资金投资。我市信息各委办局都有建设灾备系统需求如果都单独建设，将会是一笔巨大的投资，并且各个委办局都需要培养大量相关的专业运维管理人员。如何更为集约化的建设灾备系统，如何更为简单的管理和维护复杂的灾备系统，是我们必须面对和解决的难题。目前，已有地税局、人社局、国土局、财政局、建委等部门提出了灾备建设需求。5从这些部门的灾备建设方案来看，普遍包括：服务器、存储设备、网络设备、安全设备、链路等内容，平均需要1000万左右的投资才能实现关键业务应用级容灾的目标。此外，异地容灾还需要租用机房、聘用运维人员、支付链路费用等。经初步估算，已经提出或具有潜在容灾备份需求的部门，若单独建设容灾系统，则最少需要9000万建设投资，灾备系统的运维费至少达到每年1800万。本项目建议为各委办局的多个业务系统建立集中数据灾备中心，相比分别为各个业务系统建立独立的容灾系统，既节约IT设备资源，提高容灾资源利用率，又能大大减少后期的管理和运营成本。系统建设充分调研了XX市电子政务信息系统建设情况设计开放性、可扩展性的容灾策略，支持已有投资系统功能性能，有效的保障了系统的可持续发展。2.1.2.2.专业化策略XX市电子政务的业务类型众多、业务系统建设和运行的历史比较长，从系统结构和数据结构两方面来说，都是比较复杂的。从系统结构来说，既有单机运行的网站，也有WEB、应用服务、数据库三层架构的大型业务平台。从数据结构来说，既有结构化数据集中存储的资源库平台，所有关键数据统一存储在数据库集群中，也有非结构化数据如文件、图片等应用系统管理维护的资料数据。全市电子政务各业务系统需要保护的数据类型复杂多样，既有各种数据库如Oracle、SQLServer多种版本、MySQL等）数据，也有各种应用程序（网站类，OA类，业务系统类等）各种文档（Word、Execle、TXT等）各种非结构化数据（关键视频，档案等），当然也需要对虚拟机镜像提供保护（VMWare和Cloudview等）。本项目立足于XX市电子政务系统的容灾备份及安全建设，充分的调研了全市电子政务信息系统的建设和应用情况，从网络接入、系统业务功能及数据量、系统涉密情况、容灾策略需求、性能指标等多方面综合分析。力争满足针对不同的性质的系统提出了数据级、应用级容灾策略，同时分析了不同策略的在线模式与离线模式、远程数据复制、同步与异步容灾、同城与异地等多种容灾方案，专业化的解决未来XX市电子政务信息系统的容灾备份需求。2.1.2.3.规模化策略本项目集约化建设的基础上实现规模化，项目建成之后将承载XX市95%以上电子政务信息系统的容灾工作，解决我市政府各部门内部业务系统、跨区域纵向业务应6用、部门重点应该的容灾备份需求。容灾备份中心依托电子政务外网建设二期工程将完成全市行政区划内共有15个区市县（包括先导区），下辖172个街道（乡、镇）（这里包括个别区市县所管辖的乡镇级别的经济开发区）、1512个社区（村）的全域覆盖。在数据规模方面，容灾备份中心将解决包括国家重点民生工程在内的1000余个业务系统的容灾备份工作。2.2.建设目标2.2.1.总体目标XX市政务信息化容灾备份及安全系统建设计划分成两个阶段，即同城灾备中心建设和异地灾备中心建设，最终建设成为两地三中心模式。其中以新建的XX市云计算中心作为各委办局业务系统的主数据中心，XX市网站管理中心作为同城灾备中心，可以选用城市A或是城市B作为异地灾备中心。云计算中心作为主生产中心，负责日常的各委办局所有业务系统的运行。在灾难发生时，在同城容灾中心恢复各委办局关键业务的应用运行。在城市A异地灾备中心完成各委办局关键数据的保护，在发生地区级（XX）的灾难时，保证各个业务系统的核心数据不丢失。2.2.2.分期目标一期目标：实现xx个委办局关键数据在同城容灾中心的集中备份，以及xx个关键业务在同城容灾中心的应用级容灾。二期目标：实现xx个委办局关键数据在远程容灾中心的集中备份，以及xx个核心业务在同城容灾中心的应用级容灾。2.3.建设内容一期建设内容：\uf0d8完成云计算中心、同城灾备中心、异地灾备中心两地三中心容灾总体设计\uf0d8完成关键技术方案验证、实施方案编制、实施路径设计。\uf0d8完成容灾中心运行管理模式设计。7\uf0d8建设同城应用级容灾中心二期建设内容：\uf0d8优化调整新建云计算中心\uf0d8建设城市A或城市B异地数据级容灾中心2.4.总体设计方案根据各委办局的技术架构现状与策略制定，结合容灾技术的关键技术分析与最佳实践，制定如下总体容灾架构：\uf0d8容灾模式为两地三中心灾备模式\uf0d8容灾级别为数据库系统实现应用级别容灾，其他应用系统基于同城容灾中心实现应用级容灾，关键业务基于远程容灾中心实现应用级容灾\uf0d8结构化数据复制采用支持异构平台的基于数据库层的数据复制技术，虚拟机镜像等这类关键非结构化数据复制采用基于存储层的数据复制技术\uf0d8虚拟机之间的系统切换技术以自动切换方式为主，物理机之间以及物理机和虚拟机之间的系统切换以手工切换方式为主，并配合切换脚本减少系统切换时间\uf0d8容灾网络，建议同城数据中心之间采用大二层的存储网络架构，数据网络和存储网络的物理连接采用DWDM裸光纤高速网络连接，本地和异地数据中心之间采用IP网络连接，网络带宽要保证系统切换的顺畅和数据复制的带宽需求\uf0d8前端（客户端）网络切换技术有手工切换、DNS重定向和负载均衡器的健康路由注入几种，本方案建议根据实际情况选择以上切换技术的一种或几种\uf0d8容灾系统和生产系统之间的配对关系为降级配对，就是容灾中心和生产中心之间的软、硬件配置不遵循1:1比例，容灾中心硬件配置的性能低于生产中心，容灾应用服务器以虚拟机平台为主，从而进一步提升灾备系统的投入产出比建成后的两地三中心结构拓扑图如下：83.容灾的核心技术及选择容灾系统是指在相隔较远的异地，建立两套或多套功能相同的IT系统，互相之间可以进行健康状态监视和功能切换，当一处系统因意外(如火灾、地震等)停止工作时，整个应用系统可以切换到另一处，使得该系统功能可以继续正常工作。容灾技术是系统的高可用性技术的一个组成部分，容灾系统更加强调处理外界环境对系统的影响，特别是灾难性事件对整个IT节点的影响，提供节点级别的系统恢复功能。3.1.容灾系统衡量指标衡量容灾系统的主要指标有RPO（灾难发生时允许丢失的数据量）、RTO（系统恢复的时间）、容灾半径（生产系统和容灾系统之间的距离）以及ROI(容灾系统的投入产出比)。RPO是指业务系统所允许的灾难过程中的最大数据丢失量（以时间来度量），这是一个灾备系统所选用的数据复制技术有密切关系的指标，用以衡量灾备方案的数据冗余备份能力。RTO是指“将信息系统从灾难造成的故障或瘫痪状态恢复到可正常运行状态，并将其支持的业务功能从灾难造成的不正常状态恢复到可接受状态”所需时间，其中包9括备份数据恢复到可用状态所需时间、应用系统切换时间、以及备用网络切换时间等，该指标用以衡量容灾方案的业务恢复能力。容灾半径是指生产中心和灾备中心之间的直线距离，用以衡量容灾方案所能防御的灾难影响范围。容灾方案的ROI（ReturnofInvestment，投入产出比）也是用户需要重点关注的，它用以衡量用户投入到容灾系统的资金与从中所获得的收益的比率。显然，具有零RTO、零RPO和大容灾半径的灾难恢复方案是用户最期望的，但受系统性能要求、适用技术及成本等方面的约束，这种方案实际上是不大可行的。所以，用户在选择容灾方案时应该综合考虑灾难的发生概率、灾难对数据的破坏力、数据所支撑业务的重要性、适用的技术措施及自身所能承受的成本等多种因素，理性地作出选择。3.2.容灾级别按照容灾系统对应用系统的保护程度可以分为数据级容灾、应用级容灾和业务级容灾。数据级容灾仅将生产中心的数据复制到容灾中心，在生产中心出现故障时，仅能实现存储系统的接管或是数据的恢复。容灾中心的数据可以是本地生产数据的完全复制（一般在同城实现），也可以比生产数据略微落后，但必定是可用的（一般在异地实现），而差异的数据通常可以通过一些工具（如操作记录、日志等）可以手工补回。基于数据容灾实现业务恢复的速度较慢，通常情况下RTO超过24小时，但是这种级别的容灾系统运行维护成本较低。应用级容灾是在数据级容灾的基础上，进一步实现应用可用性，确保业务的快速恢复。这就要求容灾系统的应用不能改变原有业务处理逻辑，是对生产中心系统的基本复制。因此，容灾中心需要建立起一套和本地生产相当的备份环境，包括主机、网络、应用、IP等资源均有配套，当生产系统发生灾难时，异地系统可以提供完全可用的生产环境。应用级容灾的RTO通常在12个小时以内，技术复杂度较高，运行维护的成本也比较高。业务级容灾是生产中心与容灾中心对业务请求同时进行处理的容灾方式，能够确保业务持续可用。这种方式业务恢复过程的自动化程度高，RTO可以做到30分钟以内。但是这种容灾级别的项目实施难度大，需要从应用层对系统进行改造，比较适合流程10固定的简单业务系统。这种容灾系统的运行维护成本最高。3.3.常见容灾建设模式当前，市场上常见的容灾模式可分为同城容灾、异地容灾、双活数据中心、两地三中心几种。3.3.1.同城容灾同城容灾是在同城或相近区域内（≤200KM）建立两个数据中心:一个为数据中心，负责日常生产运行;另一个为灾难备份中心，负责在灾难发生后的应用系统运行。同城灾难备份的数据中心与灾难备份中心的距离比较近，通信线路质量较好，比较容易实现数据的同步复制，保证高度的数据完整性和数据零丢失。同城灾难备份一般用于防范火灾、建筑物破坏、供电故障、计算机系统及人为破坏引起的灾难。3.3.2.异地容灾异地容灾主备中心之间的距离较远（＞200KM)因此一般采用异步镜像，会有少量的数据丢失。异地灾难备份不仅可以防范火灾、建筑物破坏等可能遇到的风险隐患，还能够防范战争、地震、水灾等风险。由于同城灾难备份和异地灾难备份各有所长，为达到最理想的防灾效果，数据中心应考虑采用同城和异地各建立一个灾难备份中心的方式解决。3.3.3.两地三中心结合近年国内出现的大范围自然灾害，以同城双中心加异地灾备中心的“两地三中心”的灾备模式也随之出现，这一方案兼具高可用性和灾难备份的能力。同城双中心是指在同城或邻近城市建立两个可独立承担关键系统运行的数据中心，双中心具备基本等同的业务处理能力并通过高速链路实时同步数据，日常情况下可同时分担业务及管理系统的运行，并可切换运行；灾难情况下可在基本不丢失数据的情况下进行灾备应急切换，保持业务连续运行。异地灾备中心是指在异地的城市建立一个备份的灾备中心，用于双中心的数据备份，当双中心出现自然灾害等原因而发生故障时，异地灾备中心可以用备份数据进行业务的恢复。3.3.4.双活数据中心所谓“双活”或“多活”数据中心，区别于传统数据中心和灾备中心的模式，前11者多个或两个数据中心都处于运行当中，运行相同的应用，具备同样的数据，能够提供跨中心业务负载均衡运行能力，实现持续的应用可用性和灾难备份能力，所以称为“双活”和“多活”；后者是生产数据中心投入运行，灾备数据中心处在不工作状态，只有当灾难发生时，生产数据中心瘫痪，灾备中心才启动。“双活”数据中心最大的特点是：一、充分利用资源，避免了一个数据中心常年处于闲置状态而造成浪费，通过资源整合，“双活”数据中心的服务能力是翻倍的；二、“双活”数据中心如果断了一个数据中心，其业务可以迅速切换到另外一个正在运行的数据中心，切换过程对用户来说是不可感知的。在“双活”的模式中，两地数据中心同时接纳交易，技术难度很大，需要更改众多底层程序，因而在现实中，国内还没有真正“双活”数据中心的成功应用案例。3.4.常用的数据复制技术在构建容灾系统所涉及的诸多要素中，数据复制技术是基础，只有保证了数据的安全可用，应用或是业务的恢复才有可能。正常情况下系统的各种应用在数据中心运行，数据存放在数据中心和灾难备份中心两地保存。当灾难发生时，使用备份数据对工作系统进行恢复或将应用切换到备份中心。数据复制技术的选择决定灾备系统的RPO指标，灾难备份系统中数据备份技术的选择应符合数据恢复时间或系统切换时间满足业务连续性的要求。数据复制（Replication）是指利用复制软件把数据从一个磁盘复制到另一个磁盘，生成一个数据副本。这个数据副本是数据处理系统直接可以访问的，不需要进行任何的数据恢复操作，这一点是复制与D2D备份的最大区别。根据不同容灾方案所采用数据复制技术位于企业IT架构不同层面，数据复制可分为基于存储层的复制、基于主机层复制和基于应用的复制。具体到一个I/O从磁盘到应用的流程上，可能经由磁盘阵列、存储网络、卷管理软件、文件系统、数据库系统和应用系统全部流程或是其中的几个流程，那么数据复制就可以在这些流程的任一层次上实现，如下图所示：12基于存储层的复制可以是由存储设备的控制器执行，也可以是由网络层的虚拟化存储管理平台来执行，基于存储层的复制基于主机和应用的无关性，兼容性要求最低，实施难度最小，但是由于是卷级别的数据拷贝，对网络带宽要求最高；基于主机的复制可以由安装在主机上的卷管理软件或是文件系统来实现，在实际的应用场景中，以基于卷管理软件的数据复制技术居多，这种方式通常要求主机平台相关，实施难度升高，但是带宽要求降低；基于数据层的复制通过数据库的容灾功能模块来实现，对网络带宽要求最低，但是只能实现数据库数据的容灾；基于应用层的数据复制需要对应用程序进行定制开发，现实场景中很难见到。下面就重点介绍一下几种常见的数据复制技术。3.4.1.基于存储层的容灾复制方案3.4.1.1.基于存储设备的数据复制基于存储设备的数据复制技术的核心是利用存储阵列自身的盘阵对盘阵的数据块复制技术实现对生产数据的远程拷贝，从而实现生产数据的灾难保护。在主数据中心发生灾难时，可以直接利用灾备中心的数据建立运营支撑环境，为业务继续运营提供IT支持。同时，也可以利用灾备中心的数据恢复主数据中心的业务系统，从而能够让企业的业务运营快速回复到灾难发生前的正常运营状态。基于存储设备的数据复制技术示意图如下：13基于存储设备的复制可以是如上示意图的“一对一”复制方式，也可以是“一对多或多对一”的复制方式，即一个存储的数据复制到多个远程存储或多个存储的数据复制到同一远程存储；而且复制可以是双向的。基于存储的数据复制技术有两种方式：同步方式和异步方式。同步方式：可以做到主/备数据中心磁盘阵列同步地进行数据更新，应用系统的I/O写入主磁盘阵列后(写入Cache中)，主磁盘阵列将利用自身的机制同时将写I/O写入后备磁盘阵列，后备磁盘阵列确认后，主中心磁盘阵列才返回应用的写操作完成信息。异步方式：是在应用系统的I/O写入主磁盘阵列后(写入Cache中)，主磁盘阵列立即返回给主机应用系统“写完成”信息，主机应用可以继续进行写I/O操作。同时，主中心磁盘阵列将利用自身的机制将写I/O写入后备磁盘阵列，实现数据保护。采用同步方式，使得后备磁盘阵列中的数据总是与生产系统数据同步，因此当生产数据中心发生灾难事件时，不会造成数据丢失，可以实现RPO为零。为避免对生产系统性能的影响，同步方式通常在近距离范围内（FC连接通常是200KM范围内，实际用户部署多在35KM之内）。而采用异步方式应用程序不必等待远程更新的完成，因此远程备份存储设备的性能的影响通常较小，并且生产中心的距离和灾备中心的距离理论上没有限制（通常基于IP连接来实现数据的异步复制）。采用基于存储设备数据复制技术构建容灾方案的必要前提是：14\uf0d8通常必须采用同一厂家统一系列的且同时具有数据复制技术的高端存储平台，给用户的存储平台选择带来一定的限制。\uf0d8采用同步方式可能对生产系统性能产生影响，而且对通信链路要求较高，有距离限制，通常在近距离范围内实现（同城容灾或园区容灾方案）\uf0d8采用异步方式与其他种类的异步容灾方案一样，存在数据丢失的风险,通常在远距离通信链路带宽有限的情况下实施。尽管有以上限制，基于存储设备的数据复制技术仍然是当前选择较多的容灾技术平台，这主要是由于基于存储的复制技术方案有如下优点：\uf0d8采用基于存储的数据复制独立于主机平台和应用，对各种应用都适用，而且完全不消耗主机的处理资源；\uf0d8基于存储得数据复制技术，由于在最底层，实施起来受应用、主机环境等相关技术的影响最小，非常适合于主机和业务系统很多、很复杂的环境，采用此种方式可以有效降低实施和管理难度；\uf0d8采用同步方式可以完全不丢失数据，在同城容灾或园区内容灾方案中，只要通信链路带宽许可，完全可以采用同步方案，而不会对主数据中心的生产系统性能产生显著影响；\uf0d8采用异步方式虽然存在一定的数据丢失的风险，但没有距离限制，可以实现远距离保护；\uf0d8灾备中心的数据可以得到一定程度上的有效利用（用作测试或报表等）。构建成本：存储层容灾产品报价，都是采用磁盘阵列的高级功能许可授权方式进行报价。并按照磁盘阵列的具体数量进行报价。越是高端盘阵，高级功能模块授权价格成阶梯式增长。除了这些高级功能授权的许可外，其还有MA（维护）费用以及实施费用，MA费用整体磁盘阵列报价（含高级功能模块）的25%左右。实施费用一般按人天费用方式进行计算，总体成本很高。另外，其对带宽要求很高，容灾网络建设费用更高。适用场景：存储设备复制技术利用磁盘阵列自身卷复制功能实现，首先要求必须是同构高端存储系统，其次对带宽要求较高，实现的是底层数据块级别的复制，属于数据层容灾15范畴。这类容灾产品由于其自身的功能特性，作为高端盘阵衍生出来的附加高级功能来实现容灾，其投资巨大，从盘阵本身到链路的要求都极高，需要专门的链路确保数据的一致性。当灾难发生时，需要通过人工调整的方式，将镜像卷提供给远端生产业务系统，实现业务系统的容灾，RTO在数小时以上。经过以上分析可以看出，基于存储层的灾备方案对存储平台要求非常严格，适合用于为底层存储平台单一、服务器平台构成复杂、上层应用繁多的IT系统构建数据级的容灾方案，不适合于复杂、异构存储平台的容灾场景需求。3.4.1.2.基于虚拟化存储技术的数据复制存储虚拟化的技术方法，是将系统中各种异构的存储设备映射为一个单一的存储资源，对用户完全透明，达到屏蔽存储设备异构的目的。通过虚拟化技术，用户可以利用已有的硬件资源，把SAN内部的各种异构的存储资源统一成对用户来说是单一视图的存储资源（StoragePool），而且采用Striping、LUNMasking、Zoning等技术，用户可以根据自己的需求对这个大的存储池进行方便的分割、分配，保护了用户的已有投资，减少了总体拥有成本（TCO）。另外也可以根据业务的需要，实现存储池对服务器的动态而透明的增长与缩减。通过存储虚拟化技术可以实现数据的远程复制，这种数据复制技术原理和基于存储设备的原理基本一样，唯一的区别就是前者由存储虚拟化控制器实现，或者由磁盘阵列控制器实现，所以这种技术不要求底层磁盘阵列同构。存储虚拟化技术通常在存储网络层面实现，其数据复制同样也可以有同步复制方案和异步复制方案，需要根据具体的需求选择合适的技术。16基于存储虚拟化控制器的两地三中心容灾方案架构采用虚拟存储化技术建设容灾方案有以下优点：\uf0d8主生产中心和容灾中心的存储阵列可以是不同厂家的产品，存储平台选择不受现有存储平台厂商的限制；\uf0d8对不同厂家的存储阵列提供统一的管理界面。在虚拟存储环境下，无论后端物理存储是什么设备，服务器及其应用系统看到的都是其熟悉的存储设备的逻辑镜像。即便物理存储发生变化，这种逻辑镜像也永远不变，系统管理员不必再关心后端存储，只需专注于管理存储空间，所有的存储管理操作，如系统升级、建立和分配虚拟磁盘、改变RAID级别、扩充存储空间等比从前的任何产品都容易，存储管理变得轻松简单。采用虚拟存储化技术建设容灾方案需要考虑以下问题：\uf0d8需要验证选择的产品和技术的成熟性以及和现有设备、未来设备的兼容性能力；\uf0d8存储虚拟化控制器作为一种带内接管方式，存储系统的性能直接和存储虚拟化控制器相关，在高I/O负载应用场景下，需要考虑存储虚拟化控制器的性能瓶颈问题。虚拟化技术即继承了基于存储设备实现数据复制方案的优点，同时又能兼容异构存储系统，并且切换过程比较简单，甚至可以实现自动切换，成为越来越多容灾用户17的选择。构建成本：存储网络层产品报价，一般采用虚拟化网关的数量和容量结合起来的报价方式，存储网关数量的多少和虚拟化存储容量的多少都直接影响整个报价。除此之外还有MA费用和实施费用，MA费用整体价格的25%左右。实施费用一般按人天费用方式进行计算，总体成本较高。另外，其对带宽要求比较高，容灾网络建设费用比较高。适用场景：存储网络层容灾产品，利用了存储虚拟化技术，将后台存储进行统一池化的方式进行管理。利用其镜像和复制技术，实现池化后数据块的镜像和复制，保证数据的一致性。从实现方式上面来讲，属于数据层容灾范畴。其有两种实现方式：一种是镜像的方式，通过镜像技术实现数据块的完全同步，这种采用的是同步方式，对带宽要求极高。另外一种复制的方式，采用虚拟化网关机头之间的数据复制实现，它可以采用同步方式也可以采用异步的方式，往往受限于带宽的限制，这种复制方式往往采用异步的方式进行复制。不管采用哪种方式进行数据的一致性保证，数据卷都存在主备关系，远端数据卷不能被前端业务系统进行访问，当灾难发生时，通过自动切换人工调整的方式，将远端卷提供给远端业务系统，实现业务系统的容灾。这类产品采用的都是带内虚拟化方式，很好的解决了异构存储容灾问题，但是其数据流都要经过虚拟化网关，前端业务系统性能会有所下降，其吞吐能力受到限制。综合这类产品的特性，其适合用于为拥有较多型号的异构磁盘阵列并承担多个应用的现有IT系统构建容灾平台方案。3.4.2.基于主机数据复制技术的灾备方案采用基于主机复制技术的容灾方案的示意图如下：18图3-1.基于主机的容灾方案示意图采用基于主机系统的数据复制技术的核心是利用主、备中心主机系统通过IP网络建立数据传输通道，通过主机数据管理软件实现数据的远程复制，当主数据中心的数据遭到破坏时，可以随时从备份中心恢复应用或从备份中心恢复数据，从而给企业提供了应用系统容灾的能力。实现主机层数据复制的数据管理软件有很多产品，如Symantec公司的VeritasVolumeReplicator(VVR)以及RoseHA公司的RoseReplicator等，这些方案可实现基于主机的远程数据复制，从而构建基于主机的容灾系统。采用基于主机的数据复制技术建设容灾方案有以下优点：\uf0d8基于主机的方案最主要的优点是只和服务器平台和主机数据管理软件相关,完全不依赖于底层存储平台，生产中心和灾备中心可以采用不同的存储平台；\uf0d8可同时对数据库和文件系统提供容灾保护；\uf0d8有很多不同的基于主机的方案，可以满足用户的不同数据保护要求，提供多种不同数据保护模式；\uf0d8基于IP网络,没有距离限制；同时，采用主机的数据复制技术建设容灾方案有以下局限：\uf0d8基于主机的方案需要主机平台同构；\uf0d8基于主机的数据复制方案由于生产主机既要处理生产请求，又要处理远程数据19复制，必须消耗生产主机的计算资源，对于主机的内存、CPU进行升级是非常昂贵的，因而对生产主机性能产生较大的影响，甚至是产生严重影响；\uf0d8灾备中心的数据一般不可用，如果用户需要在远程数据中心使用生产数据进行开发测试、DW/BI应用使用将非常困难；\uf0d8利用主机数据复制软件的方案比较复杂，尤其是和数据库应用结合的时候需要很复杂的机制或多种软件的结合，从而对生产系统的稳定性、可靠性、性能带来较大影响；\uf0d8如果有多个系统、多种应用需要灾难保护，采用基于主机的方案将无法用统一的技术方案来实现。\uf0d8管理复杂，需要大量的人工干预过程，容易发生错误。主流产品列表：厂家名称产品型号容灾功能赛门铁克StorageFoundation镜像/复制构建成本：主机层卷复制容灾产品，通常的报价方式是按照主机的CPU数据进行报价，主机数量越多，CPU数量越多价格也越高，同样也存在MA费用和实施费用。此类容灾产品，相应的容灾网络建设成本相对较低。适用场景：目前，企业采用基于主机的数据复制技术建设容灾方案的案例相对比较少，通常适合单一应用或系统在I/O规模不大的情况下局部使用。在应用I/O负载比较大，需要灾难保护的应用及应用类型比较多、主机环境复杂的时候，基于主机系统的方案并不适用。3.4.3.基于数据库的数据复制技术构建灾备方案基于数据库的数据复制技术大体上可分为两类：数据库自己提供的数据容灾模块和第三方厂商提供的数据库复制技术。以最常见的Oracle数据库为例，Oracle自己的数据复制技术有DataGuard，Streams，AdvancedReplication和GoldenGate数据复制软件。第三方厂商的数据复制技术有Quest公司的SharePlex和DSG的RealSync等。3.4.3.1.几种常见数据库复制技术DataGuard数据复制技术20DataGuard是Oracle数据库自带的数据同步功能，基本原理是将日志文件从原数据库传输到目标数据库，然后在目标数据库上应用（Apply）这些日志文件，从而使目标数据库与源数据库保持同步。DataGuard提供了三种日志传输（RedoTransport）方式，分别是ARCH传输、LGWR同步传输和LGWR异步传输。在上述三种日志传输方式的基础上，提供了三种数据保护模式，即最大性能（MaximumPerformanceMode）、最大保护（MaximumProtectionMode）和最大可用（MaximumAvailabilityMode），其中最大保护模式和最大可用模式要求日志传输必须用LGWR同步传输方式，最大性能模式下可用任何一种日志传输方式。最大性能模式：这种模式是默认的数据保护模式，在不影响源数据库性能的条件下提供尽可能高的数据保护等级。在该种模式下，一旦日志数据写到源数据库的联机日志文件，事务即可提交，不必等待日志写到目标数据库，如果网络带宽充足，该种模式可提供类似于最大可用模式的数据保护等级。最大保护模式：在这种模式下，日志数据必须同时写到源数据库的联机日志文件和至少一个目标库的备用日志文件（standbyredolog），事务才能提交。这种模式可确保数据零丢失，但代价是源数据库的可用性，一旦日志数据不能写到至少一个目标库的备用日志文件（standbyredolog），源数据库将会被关闭。这也是目前市场上唯一的一种可确保数据零丢失的数据库同步解决方案。最大可用模式：这种模式在不牺牲源数据库可用性的条件下提供了尽可能高的数据保护等级。与最大保护模式一样，日志数据需同时写到源数据库的联机日志文件和至少一个目标库的备用日志文件（standbyredolog），事务才能提交，与最大保护模式不同的是，如果日志数据不能写到至少一个目标库的备用日志文件（standbyredolog），源数据库不会被关闭，而是运行在最大性能模式下，待故障解决并将延迟的日志成功应用在目标库上以后，源数据库将会自动回到最大可用模式下。根据在目标库上日志应用（LogApply）方式的不同，DataGuard可分为PhysicalStandby（RedoApply）和LogicalStandby（SQLApply）两种。PhysicalStandby数据库，在这种方式下，目标库通过介质恢复的方式保持与源数据库同步，这种方式支持任何类型的数据对象和数据类型，一些对数据库物理结构的操作如数据文件的添加，删除等也可支持。如果需要，PhysicalStandby数据库可以只读方式打开，用于报表查询、数据校验等操作，待这些操作完成后再将数据库置于日21志应用模式下。LogicalStandby数据库，在这种方式下，目标库处于打开状态，通过LogMiner挖掘从源数据库传输过来的日志，构造成SQL语句，然后在目标库上执行这些SQL，使之与源数据库保持同步。由于数据库处于打开状态，因此可以在SQLApply更新数据库的同时将原来在源数据库上执行的一些查询、报表等操作放到目标库上来执行，以减轻源数据库的压力，提高其性能。DataGuard数据同步技术有以下优势：1）Oracle数据库自身内置的功能，与每个Oracle新版本的新特性（如ASM）都完全兼容，且不需要另外付费；2）配置管理较简单，不需要熟悉其他第三方的软件产品；3）PhysicalStandby数据库支持任何类型的数据对象和数据类型；4）LogicalStandby数据库处于打开状态，可以在保持数据同步的同时执行查询等操作；5）在最大保护模式下，可确保数据的零丢失；DataGuard数据同步技术的劣势体现在以下几个方面：1）由于传输整个日志文件，因此需要较高的网络传输带宽；2）PhysicalStandby数据库虽然可以只读方式打开，然后做些查询、报表等操作，但需要停止应用日志，这将使目标库与源数据不能保持同步，如果在此期间源数据库发生故障，将延长切换的时间；3）LogicalStandby数据库不能支持某些特定的数据对象和数据类型；4）不支持一对多复制，不支持双向复制，因此无法应用于信息集成的场合；5）只能复制整个数据库，不能选择某个schema或表空间进行单独复制；6）不支持异构的系统环境，需要相同的操作系统版本和数据库版本；DataGuard技术是Oracle推荐的用于高可用灾难恢复环境的数据同步技术。Streams数据复制技术Streams是从版本Oracle9i才开始具有的数据同步功能，是为提高数据库的高可用性和数据的分发和共享功能而设计的，Streams利用高级队列技术，通过用LogMiner挖掘日志文件生成变更的逻辑记录，然后将这些变更应用到目标数据库上，从而实现数据库之间或一个数据库内部的数据同步。Streams数据同步大致分如下几个步骤：221）Capture进程分析日志，生成逻辑记录LCR，将其放入一个队列中；2）Propagation进程将LCR发送到另一个数据库中，通常是目标数据库；3）在目标数据库中，Apply进程将LCR应用到目标库，实现数据的同步；在简单的Streams配置中，Capture进程一般位于源数据库，因此叫做LocalCaptureProcess，Capture进程在分析日志后将生成的LCR放入队列中，由Propagation进程将LCR发送到目标库中。这样做的好处是不用在网络上传送整个的日志文件，因此可提高网络传输的效率，但这一般会给源数据库带来较大的压力，影响其性能。另一种配置是Capture进程位于Downstream数据库中，源数据库只负责将日志文件传送（日志传输方式可为ARCH传输、LGWR同步传输和LGWR异步传输中的任何一种）到Downstream数据库中，所有的Capture操作都在Downstream数据库上完成。这种配置的好处是可以大大降低源数据库的压力，缺点是需要传输整个日志文件，对网络带宽要求较高。Streams数据同步技术有以下优势：1）可支持一对多、多对一和双向复制，可用于数据分发和共享，这是DataGuard所不具备的；2）可灵活配置复制数据库中的一部分对象，如可按Table复制、Schema复制、表空间复制等，并可在复制过程中对数据进行过滤和转换，使之满足不同的需要；3）同DataGuard一样，是Oracle内置功能，与每个Oracle新版本的新特性（如ASM）都完全兼容，且不需要额外付费；4）可用于异构的操作系统和数据库版本，但有一些限制；5）可支持非Oracle数据库和Oracle数据库之间的数据同步；6）目标数据库处于打开状态，可以在保持数据同步的同时执行查询等操作，分担源数据库的压力；Streams数据同步技术有以下缺点：1）配置维护较复杂，需要较高的技术水平；2）在非Downstream复制中，对源数据库压力较大；如果使用Downstream复制则增加了配置的复杂性且需要通过网络传输整个日志文件，对网络带宽要求较高；3）不能支持某些特定的数据对象和数据类型；4）不能保证数据的零丢失；Oracle公司将Streams技术定位于数据的分发和共享，虽然也可用于高可用的灾难23恢复场合，但Oracle推荐使用的灾难恢复技术是DataGuard。AdvancedReplication数据复制技术AdvancedReplication配置管理较复杂，且对源数据库性能影响较大，在以后的Oracle版本中将可能逐步被Streams技术所取代。GoldenGate数据复制技术GoldenGate原来是一家独立的软件厂商的产品，现该产品已被Oracle公司收购，Oracle将GoldenGate软件集成到到其“融合（Fusion）”中间件中，预计以后该产品将与Oracle数据库更紧密地集成。GoldenGate可以用于多种不同的操作系统平台（Unix、Linux、Windows）和多种不同数据库系统（如DB2、Oracle、Infomix、MySQL、Sybase等）之间的数据同步，是一款优秀的数据同步及数据分发产品。GoldenGate是一种基于软件的数据复制方式，它从数据库的日志中解析数据的变化（数据量只有日志的四分之一左右），并将数据转化为自己的格式，直接通过TCP/IP网络传输，无需依赖于数据库自身的传递方式如OracleNet，而且可以通过高达9:1的压缩比率对数据进行压缩，大大降低带宽需求。在目标端，GoldenGate可以通过交易重组、分批加载等技术大大加快数据投递的速度和效率，降低目标系统的资源占用，可以在秒一级实现大量数据的复制。作为一种软件方案，GoldenGate可以采用非常灵活的方式加以配置，包括单向复制、双向复制和多层次的数据复制。特别是其在双向数据复制领域的先进技术，可以满足用户在本地或广域网络环境中的各种复杂需求。GoldenGate数据库复制技术具有如下特性∶本机数据改变捕捉–作为一个基于日志的同步解决方案，将对源系统和网络的影响减少到最低。灵活性–源和目的系统不需要有一样的操作系统、数据库及模板(例如∶表，索引，等)。GoldenGate能在同一个系统的多个数据库实例之间实现数据复制，或把数据复制到局域网内的其它数据库实例，或把数据复制到广域网上的远端数据库实例。无需宕机时间的移植–GoldenGate能在不同版本的数据库和操作系统之间同步数据。数据库，操作系统或应用系统的更新可以在辅助系统里进行。一旦更新后的辅助系统通过了完整的测试，所有的处理工作就可以切换到辅助系统，然后更新主系统。24一旦主系统的更新完成了，主与辅助系统之间能够再一次同步而无宕机时间。不依赖于硬件和数据库–GoldenGate不依赖于操作系统，数据库和硬件。数据可以在不同的环境之间移动，因而消除了客户对任何拓扑结构的依赖性。RPO与RTO的目标–GoldenGate提供了立即恢复备份的装备。这是因为源和备份系统可以配置或构架设计为双向”端到端”的功能。双向复制–GoldenGate提供了两个或两个以上生产系统之间的数据复制功能。这些系统无须具有一样的属性或相同的操作系统，数据库或数据库版本。数据一致性–备份数据库支持读一致性的查询活动(交易的一致性在任何时候都受到保护)。灵活的拓扑结构–在数据库和表一级实现了多种相关数据的分部方式。例如∶支持一对多，多对一，多对多以及分层的配置。映射与转换功能–列转换能够适应特别的备份需要，包括查看和执行存储过程。数据选择–选择性的复制数据而不是全部，例如表，行和列。GoldenGate是一种基于数据库日志的数据复制产品，可以利用极少的系统开支，实时复制数据库，改善数据可用性。GoldenGate可以在数据移植、在线维护等场合应用，以减少或消除数据库的停机时间。同时，它还可用于数据容灾、负载均衡、数据集中、数据分布等应用中。GoldenGate可确保在这些工作进行时，源系统的正常事务处理得以继续进行，功能上不受影响。SharePlex数据复制技术SharePlex是Quest公司开发的用于专门用于Oracle数据库的数据同步软件，可以运行在异构的操作系统平台上和Oracle数据库的不同版本之间。SharePlex的数据复制原理与GoldenGate类似，需要分别在源数据库服务器和目标数据库服务器上安装SharePlex软件。具体处理过程是：Capture进程分析源数据库的日志文件，抓取所需的数据变更操作，将其存储在SharePlex自己专有的queue文件中，放入到CaptureQueue，然后由Read进程对queue文件进行封装处理，将其放入到ExportQueue中，由Export进程将queue文件通过网络发送到目标服务器上，目标服务器上的Import进程接收这些queue文件，将其放入到PostQueue中，最后由Post进程将这些queue文件中的变更应用到目标数据库中，其处理流程如下图：25SharePlex数据同步技术的优势有：\uf0d8支持异构的操作系统平台，便于数据库管理系统的版本升级及操作系统平台切换；\uf0d8跟DataGuard传输整个日志文件相比，SharePlex传输的数据量大大降低，这点跟GoldenGate差不多；\uf0d8目标数据库处于打开状态，且支持一对多、多对一、双向复制等配置，也可以选择部分对象进行复制，可满足数据分发和数据集成的需要，减轻源数据库压力，这方面也类似于GoldenGate；\uf0d8所占系统资源较少，通常在10%以下。SharePlex数据同步技术的劣势体现在以下几个方面：\uf0d8需要支付额外的Liscense费用，通常是一笔不小的支出；\uf0d8需要在数据库软件外安装一套专门数据同步软件，增加了管理维护的复杂程度；\uf0d8由于数据复制操作独立于数据库管理系统，因此不能确保数据零丢失；\uf0d8由于是第三方的软件产品，在对某些特定的数据对象、数据类型和Oracle某些新特性如ASM的支持方面不如数据库厂商自己的解决方案；另外，还有一种可能就是如果Oracle对自己的日志格式做些改变或加密，SharePlex将无能为力。从上述分析可知，SharePlex虽然专用于Oracle数据库同步，但同GoldenGate相比并无明显优势，GoldenGate对异构数据库的支持更是SharePlex所不能比。DSGRealSync数据复制技术除了上述数据同步技术外，在国内市场上用于Oracle数据同步的产品还有DSG公26司的RealSync软件，RealSync的实现原理及功能与SharePlex基本类似，也是只支持Oracle数据库，也可以跨越不同的操作系统平台。值得一提的是RealSync在目标数据库的数据装载方面，不是通过主键或唯一键来实现数据记录的定位，而是自己维护一个源数据库和目标数据库的数据记录的rowidmapping表，通过rowid来实现记录的定为，因此在数据装载效率方面有不小的提高。3.4.3.2.主流产品列表对比项DataGuardStreamAdvencedReplicationGoldenGate原理基于日志挖掘，通过传播线程将归档日志由源数据库传到目的数据库基于日志挖掘基于触发器（trigger）所有复制对象结构（DDL）的改变，都必须通过oracle提供的复制包来实施基于日志挖掘主要用途灾备恢复、高可用性数据共享数据同步高可用与容灾、实时数据集成实现简易程度实现过程和管理简单实现过程复杂，对DBA的要求非常高配置和管理复杂配置较简单安全性与稳定性较稳定、可靠稳定、可靠稳定、一般稳定、可靠对源数据库的性能影响一般一般基于触发器原理，对主库影响比较大，生产系统一般不适用亚秒级复制，对源数据库影响非常小（独立的软件，并且只是针对redo日志的扫描）拓扑结构支持一对多模式，standby数据库最多为9个支持一对一、一对多、多对一、双向复制等多种拓扑结构支持一对多模式或者包含多个MasterSite支持一对一、一对多、多对一、双向复制等多种拓扑结构是否支持操作系统异构不支持支持，但是有限制支持收费情况免费免费免费收费3.4.3.3.构建成本Oracle数据库类应用容灾产品，目前分为两种类型：27Oracle企业版自身提供的DataGuard功能模块，其模块是免费的。商业版的如GoldenGate，SharePlex等软件，按照CPU的数量进行收费，主机的CPU数量越多，价格也越高，同样也具有MA费用和实施费用。下表为Goldengate的list价格：Oracle产品组件描述licenseList价格OracleGoldenGate包括GoldenGateCapture,DeliverandActiveDataGuardOnoracleDB$17500/CPUOracleGoldenGateVeridataAdd-oncapabilitytovalidatedateinreplicatedsystems$30000/CPUManagementPackforGoldenGateAdd-onmanagementpack$3500/CPU这类容灾产品，如果采用商业版本，软件费用和实施服务费用也比较高。3.4.3.4.适用场景数据库类应用容灾产品，采用安装在主机端的应用软件实现容灾，其最大的优势是可为数据库数据提供应用级别的保护，对网络带宽要求较低，容灾网络基于IP网络构建，成本较低；其劣势是仅能对数据库数据提供保护，并且对源数据库都有或多或少的性能影响。经过对以上几种数据库复制技术的分析，DataGuard、Stream、AdvencedReplication是专为Oracle数据库开发的灾备模块，适合于同构平台的Oracle数据库容灾；Shareplex适合于异构平台的Oracle数据库容灾；GoldenGate适合于异构平台和异构数据库的容灾与应急备份，消除计划内停机、双业务中心、数据仓库实时供给、实时报表等应用场景需求。3.5.如何选择最优的容灾方案3.5.1.数据容灾技术选择原理28图：沙漏模型3.5.2.数据容灾技术选择度量标准在构建容灾系统时，首先考虑的是结合实际情况选择合理的数据复制技术。在选择合理的数据复制技术时主要考虑以下因素：\uf0d8灾难承受程度：明确计算机系统需要承受的灾难类型，系统故障、通信故障、长时间断电、火灾及地震等各种意外情况所采取的备份、保护方案不尽相同。\uf0d8业务影响程度：必须明确当计算机系统发生意外无法工作时，导致业务停顿所造成的损失程度，也就是定义用户对于计算机系统发生故障的最大容忍时间。这是设计备份方案的重要技术指标。\uf0d8数据保护程度：是否要求数据库恢复所有提交的交易，并且要求实时同步，保证数据的连续性和一致性，这是备份方案复杂程度的重要依据。3.6.本项目容灾模式及技术的选择3.6.1.容灾模式选择在灾备模式选择上，目前，XX市各委办局信息中心信息系统直接面向群众提供服29务，业务的连续性以及数据安全的保障是在选择容灾模式时首要考虑的两个方面。既要在生产中心发生灾难时，保证关键业务不中断，又要保证在同城发生灾难时，各委办局所有关键数据保存一份相对完整的备份。新建的XX市云计算中心作为未来的主生产中心，未来各委办局的业务系统会逐步迁移到该中心运行，承载当前XX市电子政务信息系统的主要业务，提供对内对外服务；同城容灾中心做为生产中心的容灾备份，在生产环境发生灾难不能运作的时候，将接管生产，暂时作为主数据中心运行，恢复各委办局关键业务的应用运行。同城容灾中心作为生产中心的区域内备份，不能防御区域性灾害。异地容灾中心用于防范区域性灾难，从《中国地理杂志》发布的《中国地震带分布》图上可以看出，XX位于中国第4大断裂带“郯庐断裂带”的边沿上，有发生区域性灾难的可能性。当发生区域性灾难时，生产中心和同城容灾中心都不可用，异地容灾中心可以保证关键数据还有一份拷贝，并且核心应用可以选择在异地容灾中心重新启动。因此，从整个容灾体系来看，省厅容灾模式应选择“两地三中心”的方式。3.6.2.容灾中心选址3.6.2.1.同城灾备中心地址选择根据XX市电子政务实际情况和拟建设的云计算中心进度情况，本项目拟将XX市政府网站管理中心现有机房做为同城灾备中心，充分利用现有的服务器、存储、网络等资源，降低建设成本和运维成本。XX市政府网站管理中心现有机房位于XX市xxxxxxxxxx，同时也是XX市政府网站管理中心的办公地点。选择该地点作为同城灾备中心具有以下优势：\uf0d8具备完善的物业服务、市电供电、消防设施等，各种配套设施比较齐全。\uf0d8该机房建设时已经充分考虑了承重、抗震、防雷、防水等内容，选择该处可以大大降低建设成本和建设周期。\uf0d8该机房内的设备可以作为灾备设备使用，无需搬迁，降低搬迁费用和搬迁风险。\uf0d8XX市电子政务外网的光纤专线全部汇聚到该机房，在云计算中心建成后可以利用这些光纤专线作为XX市电子政务外网的备份线路。3.6.2.2.异地灾备地址选择按照国家有关要求，电子政务灾备中心须依托电子政务网络进行建设，达到共享30灾备基础设施、降低昂贵的线路租赁费用等目的。XX市政府网站管理中心先期对国内知名的云计算中心进行考察并同国内部分城市的电子政务管理部门进行了沟通和交流，已经有广州、成都、无锡等城市表达了愿意同XX市等价交换机房、网络、安全、运维人员等方面资源的意愿，形成互惠机制，最大限度的发挥双方的优势。广州、成都、无锡等城市均已经建成了云计算中心，南京的云计算中心也是高标准云计算中心。这些中心均具有良好的机房环境、网络设施和较强的运维能力，完全具备灾备中心必须具备的硬件条件和技术服务能力。灾备中心除了需要考虑机房、网络和运维能力等因素以外，还需考虑距离、地震带、地质结构、电网、江河流域、建筑环境等各种因素。目前，XX市政府网站管理中心正在积极同其他城市联系，拟在初步设计阶段同其他城市达成正式的合作协议，明确机房交换、网络设施使用、运维人员互用等事宜。考虑到CNGI的建设情况，本项目拟在项目建议书阶段选择城市A或是城市B作为异地灾备城市，理由如下：\uf0d8城市A和城市B是距离XX市较近的且不在地震带上的CNGI主节点城市，总带宽为2.5GB。\uf0d8中国移动辽宁分公司已在城市A建设了高标准机房，完全能够满足异地容灾对机房环境的要求。\uf0d8城市B市已经建设了高标准云计算中心，完全能够满足异地容灾对机房环境的要求。CNGI主干网拓扑图如下：313.6.3.数据复制技术的选择在数据复制技术的选择上，通过比较存储层、主机层以及数据库层的数据复制技术的优缺点后，以及结合用户的业务系统现状，我们认为，本项目采用支持异构平台的基于数据库层和存储层的数据复制技术。经过调研发现，各委办局的关键数据多为结构化的数据库数据，存储在Oracle、SQLServer等异构数据库平台上，采用支持异构平台的数据库层数据复制技术，可以实现异构数据库平台的统一容灾，具有良好的扩展性和开放性，同时具有较高级别的RTO和RPO，并且支持两地三中心的架构。用户另一类关键数据是大量的虚拟机镜像、文档等非结构化数据，这些数据也是分散存储在多套异构磁盘阵列上。因此本方案采用基于存储虚拟化功能的异构平台存储层数据复制技术，该技术对底层磁盘阵列没有严格的限制，可以在同构盘阵和异构盘阵之间实现数据复制，具有同步、异步多种工作模式，满足不同级别RPO、RTO用户的要求。同时，存储虚拟化技术支持存储设备进行横向和纵向的扩展，满足未来各委办局数据增长的需要，具有良好的扩展性。数据复制技术是用来解决设备down机、机房断电、自然灾害等物理故障的技术，为了解决人为误删除、病毒感染等逻辑故障对生产系统的业务连续性影响，本方案又32引进数据备份这项技术。4.推荐方案概述4.1.技术路线选择经过上述现状的综合分析，我们计划基于两地三中心灾备模式构建XX电子政务灾备方案，其中以新建的XX市云计算中心作为各委办局业务系统的主数据中心，XX市网站管理中心作为同城灾备中心，可以选用成都云计算中心作为异地灾备中心。云计算中心作为主生产中心，负责日常的各委办局所有业务系统的运行。在灾难发生时，在同城容灾中心恢复各委办局关键业务的应用运行。在成都异地灾备中心完成各委办局关键数据的保护，在发生地区级（XX）的灾难时，保证各个业务系统的核心数据不丢失。根据各委办局的技术架构现状与策略制定，结合容灾技术的关键技术分析与最佳实践，制定如下容灾架构：\uf0d8容灾模式为两地三中心灾备模式\uf0d8容灾级别为数据库系统实现应用级别容灾，其他应用系统基于同城容灾中心实现应用级容灾，基于远程容灾中心实现数据级容灾\uf0d8结构化数据复制采用支持异构平台的基于数据库层的GoldenGate数据复制技术，虚拟机镜像等这类关键非结构化数据复制采用基于存储层的数据复制技术\uf0d8虚拟机之间的系统切换技术以自动切换方式为主，物理机之间以及物理机和虚拟机之间的系统切换以手工切换方式为主，并配合切换脚本减少系统切换时间\uf0d8容灾网络，建议同城数据中心之间采用大二层的存储网络架构，数据网络和存储网络的物理连接采用DWDM裸光纤高速网络连接，本地和异地数据中心之间采用IP网络连接，网络带宽要保证系统切换的顺畅和数据复制的带宽需求\uf0d8前端（客户端）网络切换技术有手工切换、DNS重定向和负载均衡器的健康路由注入几种，本方案建议根据实际情况选择以上切换技术的一种或几种\uf0d8容灾系统和生产系统之间的配对关系为降级配对，就是容灾中心和生产中心之间的软、硬件配置不遵循1:1比例，容灾中心硬件配置的性能低于生产中心，容灾应用服务器以虚拟机平台为主，从而进一步提升灾备系统的投入产出比4.2.总体方案架构33本项目两地三中心灾备项目的整体架构图如上所示。从容灾层次上来说，本方案包括备份和容灾两个层次。其中备份（主要是数据备份）是指在专用的备份系统中保存多个历史点的生产数据，当生产数据因为人为误操作、病毒感染等原因出现逻辑故障时，可以从备份系统中选择合适历史点的数据进行恢复，备份的数据类型可以是常见的数据库这类结构化数据，也可以是操作系统、虚拟机镜像、文件和应用程序等这类非结构化数据，由于备份窗口的原因，数据备份的频率通常不会很频繁，通常为小时、天甚至是周级别。容灾是为了防止硬件故障、电力中断、地震灾难等物理故障对业务系统所造成的应用中断，其最关键的技术就是数据复制技术。本方案数据复制分为结构化数据的复制和非结构化数据的复制两部分，其中结构化数据复制由支持异构数据库复制的GoldenGate实现，虚拟机镜像等非结构化数据的复制由存储层的技术实现。一、基于数据库复制技术的结构化数据容灾系统数据库系统的容灾方案，本方案建议基于成熟的商业版软件GoldenGate实现，采用GoldenGate复制日志记录，实现各委办局多个数据库在同城容灾中心和异地容灾中心的容灾、以及本地两个数据中心之间数据库的互备，保证结构化数据访问的连续性。GoldenGate实现数据库容灾的技术手段成熟，管理维护相对容易，没有操作系统34和数据库版本的限制（不过GoldenGate对Oracle9i及以下版本的支持有些限制，对10g及以上版本支持的更好），具有更好的兼容性。对于TB级数据库，其传输日志的带宽需求在10M一下，网络建设成本比较低。二、基于存储层数据复制技术构建非结构化数据容灾系统对于虚拟机镜像、应用程序等关键非结构化数据的保护建议采用存储层次的容灾方案，该方案建议基于高效的存储层复制技术实现，利用某公司高端磁盘阵列的MetroCluster和SnapMirror数据镜像和数据复制功能，可以实现两地三中心多套磁盘阵列的互备，保证数据访问的连续性。同时，可以整合其他厂商的磁盘阵列，通过这种技术，可以实现异构存储平台之间的数据迁移和数据复制，是构建复杂异构IT系统容灾方案的理想平台。4.3.数据库容灾系统设计对于数据库这类核心应用系统，建议构建高级别的容灾方案。综合分析现有业务系统数据库应用情况，本方案建议采用成熟的商业版软件GoldenGate构建数据库容灾方案。GoldenGate的数据延迟为亚秒级，处理数据能力高。支持广泛的异构数据库应用环境，源和目标数据库端的操作系统和数据库可以任意组合，支持一对一、一对多、多对一、双向复制等多种灵活拓扑结构，并且有完整的技术支持方案，是建立异构平台或异构数据库的容灾与应急备份方案、双活数据中心的唯一选择。结合容灾性能指标以及预算的情况，本方案建议在同城容灾中心和远程容灾中心各新增1套（1台或多台）Standby数据库服务器，基于GoldenGate灾备技术实现多个委办局异构数据库平台到同城容灾中心的集中容灾，同时实现同城灾备中心数据库系统到远程灾备中心和数据库远程容灾。对于各委办局的某一个数据库应用来说，当某个生产库出现故障时：如果生产库和容灾库同构，在理想情况下（数据完全同步且可用、容灾链路带宽充足、设备运行良好），可以在分钟级别切换到同城容灾数据库；如果生产库和容灾库异构，那么无法进行数据库切换操作，只能通过方向复制的方法把容灾库的数据恢复到生产库中。如果同城数据中心的数据库系统同时出现故障，可以利用远程容灾库进行生产库数据的恢复，由于异地容灾数据库与生产库的数据有一定的延迟，有可能会丢失部分数据。Standby数据库服务器的数据和配置可以低于生产数据库服务器，采用降级容灾配35置方案，用于节省硬件平台的投资预算；可以先对几个关键业务实现数据库灾备保护，未来实现全业务数据库容灾。4.3.1.GoldenGate技术原理GoldenGate软件需要安装在源数据库服务器和目标数据库服务器上，所需的操作系统资源在10%以下。GoldenGate数据同步的基本原理是由Extract进程读取源数据库的事物日志（Oracle中是redolog），将其中的变更操作（insert、update、delete等）按事务执行的顺序组合在一起，直接将其发送到目标服务器上，或者存放到Trails文件中，然后由DataPump进程将Trails文件传输到目标服务器上，在目标服务器上Collector进程接收从源服务器传送过来的Trails文件，最后由Replicat进程将Trails文件中的数据装载到目标数据库中，其处理过程如下图：由于GoldenGate将数据存储到自己的统一格式的Trail文件中，因此可以将Trail文件传送到不同的操作系统，应用在不同的数据库系统上，大大增强其灵活性。另外，由于GoldenGate只收集必要的数据到Trail文件中，且Trail文件可以压缩，因此大大减少通过网络传输的数据量，压缩后传输的数据量通常是日志量的1/4或更少。GoldenGate还可以分流查询，如下图所示：36GoldenGate有以下优点：\uf0d8支持异构的操作系统和数据库管理系统，便于客户在不同数据库管理系统和操作系统平台之间的数据同步，这是其核心优势所在；\uf0d8跟DataGuard传输整个日志文件相比，GoldenGate传输的数据量大大降低，在没有LOB等数据对象的情况下，通常是整个日志文件1/4或更少；\uf0d8目标数据库处于打开状态，且支持一对多、多对一，双向复制等，也可以选择部分对象进行复制，可满足数据分发和数据集成的需要，减轻源数据库压力；\uf0d8所占系统资源较少，通常在10%以下；\uf0d8GoldenGate被Oracle公司收购后，对Oracle数据库的支持方面做的更好。4.3.2.各委办局和同城容灾中心之间的数据库复制为了能够便于维护和管理、最少化投资，个委办局和同城容灾中心之间采用N+1模式的数据库容灾，同时，为了提升同城容灾中心数据库系统的可靠性和性能，同城37容灾中心建议配置2台以上X86架构的高性能多路服务器组成OracleRAC集群系统。各委办局的多个异构Oracle、SQLServer数据库系统通过GoldenGate数据复制软件实时备份到此OracleRAC集群系统，从而达到了容灾的目的。系统拓扑参考图如下：鉴于建立同城容灾中心的的目的是为了应用级别容灾，因此我们在同城容灾中心为各委办局的多个核心应用建立了不同数据库用户，将各委办局的各核心应用数据库数据复制到各自用户下的表中，一旦生产中心处于计划停机或非计划停机状态，同城灾备中心将接管生产中心的服务，保障业务的持续进行。为了在集群环境下实现节点间的负载均衡，我们可以将生产中心的多个核心数据库应用划分为N（N=同城容灾中心OracleRAC集群节点数量）个小组，每个小组传送过来的数据由RAC集群中的某个节点承担，从而实现RAC多节点共同工作完成所有委办局数据的接收。该方案的应用特点：N+1灾备模式各委办局的多个业务的生产数据库分布在多套异构数据库系统中，使用GoldenGate数据复制技术可以将多个业务的数据库集中备份到一套数据库备份系统，38从而实现了N+1的备份模式，以较低的成本实现了容灾。GoldenGateN+1模式区别于其它技术的特点在于其能够实现多个数据库数据向一个数据库的逻辑集中，从而使得同城灾备中心在一个库中对各委办局相关数据的进行查询和统计，为今后建立数据仓库和开展BI等业务创造了条件。异构平台支持在本方案中，各委办局的生产数据库系统是异构的，GoldenGate支持异构数据库系统之间的数据复制。GoldenGate这种跨平台复制的特性降低了容灾中心的硬件投资，减少了后期管理和维护的成本。支持双向复制GoldeGate支持双向数据复制模式，通过该模式，可以将各委办局的某些数据库负载均衡到同城容灾中心，从而提高同城容灾中心的设备利用率，降低生产中心的负载。双向数据复制是基于单向数据复制原理之上，两端互为源/目的数据复制对象，两端生产系统同时保持Active状态。在这种配置模式下，GoldenGate采用必要的冲突处理机制来解决可能发生的冲突。为了避免出现刚被复制进对端目的数据库数据马上又被捕捉进程复制回源端，陷入死循环的状态。GoldenGate采用了相应的判别机制来保证对捕捉数据的识别，当应用程序和GoldenGate复制进程同时更新同一个表时,捕捉进程使用了一个跟踪表机制。在配置双向数据复制时,需要通过命令行向两边的数据库中加入跟踪表。当捕捉进程读到一个交易中有针对跟踪表的更新,捕捉进程就知道这个交易是由复制进程产生的并且39把这笔交易忽略掉.如果没有针对跟踪表的更新,捕捉进程就知道这个交易是由应用程序产生的并且把这笔交易读取出来.通过以上处理机制后，就可以很好的解决双向数据复制中所担心的重复捕捉变化数据的操作出现。4.3.3.同城容灾中心和异地容灾中心之间的数据库复制同城容灾中心和异地灾备中心之间采用1+1模式的数据库容灾，本方案建议在远程容灾中心配置1台X86架构的高性能多路服务器组成Oracle异地容灾数据库系统。同城容灾中心的OracleRAC集群中的数据通过GoldenGate数据复制软件备份到远程容灾中心Oracle数据库系统，从而达到了远程容灾的目的。系统拓扑参考图如下：为了进一步节省投资，同城容灾机房和异地容灾机房之间的同构Oracle数据库复制可以采用免费开源的DataGuard数据库复制技术实现。4.4.非结构化数据容灾系统设计对于虚拟机镜像、应用程序以及关键文档这类存储在多台异构磁盘阵列中的关键数据，本方案建议基于存储层的数据复制技术构建容灾方案。存储层数据复制技术支持数据镜像和数据复制技术，与上层应用无关，不占用上层应用服务器的资源，是应用最广、最成熟的数据复制技术，是构建异构平台双活数据中心、两地三中心数据灾备方案的理想选择。本方案建议在主生产中心、同城容灾数据中心新增一套双活存储系统，每个数据40中心各放置一半的存储设备，MetroCluster是一种基于同步数据镜像技术的存储高可用技术，上层应用的每一次I/O操作会在两个数据中心之间的存储设备之间同步，任一扩展柜或是控制器出现故障不会影响上层应用的正常访问，可以实现数据近乎不丢失（RPO=0）。同时在远程容灾中心新增一套磁盘阵列，通过盘阵的SnapMirror数据复制技术实现同城容灾中心关键非结构化数据到远程数据中心的容灾，由于同城容灾中心和远程容灾中心之间的距离较长，网络延迟较高，建议采用异步数据复制模式。当本地两个数据中心的存储系统同时出现故障时，可以从远程容灾中心实现数据的快速恢复（可能会丢失部分数据）。同步数据镜像模式对灾备链路要求较高，建议本地两个数据中心之间租用性能不低于4Gb的裸光纤链路连接，为了提高容灾链路的利用率，建议配置DWDM设备，实现存储层数据复制链路和上层应用数据链路的复用，从而减少容灾链路的投资。异步数据复制模式对数据带宽和延迟要求没那么严格，因此，同城和异地数据中心之间采用IP网络连接即可。为了进一步节省成本，远程容灾磁盘阵列的配置可以适当低于生产磁盘阵列。4.4.1.同城容灾中心和生产中心之间的数据容灾本方案同城容灾中心需要基于存储层的数据复制技术使用应用级容灾，为了实现该灾备目标，本方案建议对同城容灾中心和各委办局生产中心做适当的改造：一、把同城容灾中心和生产中心需要进行灾备保护的关键非结构化数据如虚拟机镜像、关键文档等集中迁移或存储到新增磁盘阵列中；二、首先对各委办局需要实现应用级容灾的物理应用服务器进行适当的改造，把应用服务器需要修改的数据集中存储在数据库或是盘阵中，不需要修改的数据可以存储在本地硬盘中，然后利用VWware的P2V工具为这些物理应用服务器做虚拟机镜像，并把镜像数据存储在新增盘阵中。41改造完成后，利用DS900的MetroCluster功能实现关键数据在同城容灾中心和生产数据中心的互备，构建双活存储系统，系统架构图如上所示。本方案在同城容灾中心和生产数据中心各部署1个DS900控制器、2个DS900扩展柜、2套24端口FC交换机（若现、新大楼之间的距离少于500米，可以不用交换机）、2套DS900FC-SAS桥接器，两个中心之间的DS900主机头和扩展柜通过FC交换机和桥接器组成高可靠的冗余存储网络；两个数据中心DS900盘阵里的数据基于MetroCluster技术实现实时数据同步，两个中心之间的任一主机头或是扩展柜出现故障，不影响前端应用的正常运行，任一中心的DS900设备全部故障，也可以确保在很短的时间内将存储自动切换到另一中心。同城容灾中心和生产数据中心之间通过DWDM裸光纤实现FC存储和IP数据链路互通，DS900同时支持FC、iSCSI和NAS存储协议，这样基于MetroCluster技术实现的双活存储系统本身就具备了统一存储功能，可以为上层各种应用按需提供存储服务。同时，DS900支持异构存储资源整合，后期用户新购的异构磁盘阵列可以通过这套DS900主机头进行整合，形成统一存储资源池，便于后期扩展、管理和使用，并有效的提高存储资源率。两个数据中心的DS900MetroCluster双活架构实现了存储服务与数据的热备（有两份实时同步副本），同时为了预防数据误删除的恢复、查看调用某个阶段的原始数据，以及应对一些灾难情况，本方案同时为DS900配置SnapShot功能进行数据备份。42SnapShot基于时间点的指针型数据快照技术，结合SnapRestore快照数据恢复软件可以显著节省备份时间和恢复时间，同时节省备份空间。基于快照技术实现的备份数据无需恢复，可直接挂接到主机上进行验证和分析。考虑到实际情况，这套DS900MetroCluster双活存储系统初期全部放置在同城容灾中心，等生产数据中心完成建设后，再把一半的存储系统迁移到生产数据中心。MetroCluster工作原理MetroCluster技术是结合了的数据镜像功能、数据快照功能、阵列双控制器双活和故障切换保护功能，并在这些功能远距离实现（最远160公里）的基础上所实现的一项提供存储系统高可靠性保证和数据访问双活架构的存储功能。MetroCluster技术把一套DS900标准的双控制器配置的存储系统分为两部分，每部分包括各自的控制器和磁盘柜，然后把两部分分开部署，最长距离可以达到160公里。如果两部分之间的距离不超过5米，则可以直接使用普通的FC和SAS连接线相互连接，如果两部分之间的距离超过5米，则需要配置4套专用的SAN交换机和4套FC-SAS桥接器实现两部分的互连。这样一套MetroCluster存储系统的两部分可以部署在同一个机房中，也可以分开部署在用户的两个机房，而在逻辑上，这分开部署的两部分组成的存储系统仍旧是一套存储系统，两个控制器之间的负载均衡和故障切换功能和标准的本地双控制器的存储系统完全一致，一个部分的控制器失效，另外一个部分的控制器会自动接管其工作，且对前端应用系统透明。MetroCluster技术增强了DS900的SyncMirror数据镜像功能从而实现数据的远距离镜像，即数据在一套MetroCluster存储系统分开部署的两部分之间实现镜像，只要镜像的这两份拷贝有一个有效，就可以保证数据的正常访问。结合上述两点，MetroCluster为用户提供了一种比传统的硬件冗余保护架构更高级别的可靠性保证，就算组成MetroCluster存储系统的两部分中的某部分存储部件完全失效，另外一部分的控制器可以利用镜像过来的数据接管故障部件所承担的工作，以保证用户应用系统的持续性，且这个接管动作由存储系统自动进行，对前端应用透明。如果MetroCluster存储系统的两部分分开部署在两个机房，则利用两个机房互连的SANFC网络和NASIP网络，前端应用主机可以在任何一个机房访问同一份数据，因此实现了数据访问的双活架构。用户可以根据自己的实际情况把应用系统部署在任意一个机房甚至同时部署在两个机房。43在MetroCluster存储系统的任何一部分中所进行的数据快照，都会被自动的镜像到另外一部分中进行保存，因此实现了数据快照的镜像保护，提升了数据快照对逻辑性错误和硬件错误的双重抵御能力。4.4.2.同城容灾中心和远程容灾中心的数据容灾为了进一步提高数据保护的级别，可以在另外一个城市建立远程容灾中心。在远程容灾中心新增一套磁盘阵列，基于SnapMirror技术，实现同城容灾中心关键非结构化数据到远程容灾中心的复制，当本地MetroCluster双活存储系统都出现故障后，可以利用远程盘阵里的数据实现数据恢复。基于以上措施构成的完全数据保护方案架构图如下所示：SnapMirror技术原理SnapMirror技术将数据镜像到一个或多个网络Filer上。SnapMirror不断地更新镜像数据，以确保数据是最新的，并且能够用于进行灾难恢复、减少磁带备份、发布只读数据、在非生产性Filer上进行测试、执行联机数据迁移等等。SnapMirror可以将同一数据发布到所有地点。通过自动更新这些数据，并支持对镜像数据的本地访问方式，SnapMirror可以大大提高员工的工作效率，提高数据保护级别。SnapMirror技术优势\uf0d8SnapMirror支持多种复制方式，用于适应不同的容灾环境，包括：同步，准同步，异步。异步方式的复制对于距离没有限制。\uf0d8SnapMirror支持多种网络环境，用于适应不同的容灾环境，包括：IP接口和FC接口。\uf0d8SnapMirror支持多种拓扑方式的复制，包括：1对多；多对1；级联复制等。\uf0d8SnapMirror支持对多种数据的复制，包括：基于卷的复制，基于qtree的复制44支持对NAS/SAN/iSCSI中的数据复制。\uf0d8SnapMirror只传输变化的数据块，可以大大节省网络带宽和减轻Filer的负载。\uf0d8通过使用SnapManager，与SQL、Oracle、Exchange、SharePoint、Virt等实现了集成，从而简化故障转移和灾难恢复。由于同城容灾中心和远程容灾中心之间的距离相距较远，为了减少容灾链路带宽投入，本方案建议采用SanpMirror异步数据复制技术，容灾链路采用IP网络构建即可。4.4.3.应用级容灾几种实现方式基于存储复制技术实现应用级容灾，可有如下几种方式：\uf0d8受保护和容灾的应用服务器同为虚拟机，那么基于DS900MetroCluster双活存储系统，利用虚拟机的HA技术即可实现虚拟机应用级别容灾；\uf0d8如果受保护的应用服务器为物理机，容灾的应用服务器为虚拟机，那么利用VMWare的P2V技术先对物理机做一个虚拟机镜像，并把该虚拟机镜像存储在DS900双活存储系统中，物理应用服务器出现故障时，可以人为启动该虚拟机镜像，实现应用级切换；\uf0d8如果受保护和容灾的应用服务器都需要是物理机，那么可以利用成熟的双机技术或是物理备机技术实现应用级容灾，所谓物理备机就是在同城容灾中心配置一套相同架构的物理服务器，并配置成和应用服务器相同的软件环境，当生产应用服务器出现故障时，管理员手动把这台备机启动，也可实现应用级容灾。4.5.一体化集中备份系统考虑到人为误操作、病毒感染等操作所带来的数据逻辑错误，建议对各委办局以及本地两个数据中心的关键数据做备份保护，结合以上两种数据容灾方案，形成完善的数据保护体系。本方案需配置3套一体化备份系统，其中两套放置在同城容灾中心，一套放置在生产数据中心。同城容灾中心的其中1套用于各委办局关键数据在同城容灾中心的集中备份，另外一套实现对同城容灾中心关键数据的本地集中备份。放置在生产数据中心的备份系统实现对生产系统关键数据的本地集中备份。如果需要把关键数据在远程也集中备份一份，那么需要在远程的容灾中心配置一台容灾服务器和一个磁盘阵列，容灾服务器上配置备份系统的一个Lan-Free智能客户端模块，利用备份系统的Datacopy功能将本地备份的数据拷贝到远程智能客户端所连45接的磁盘阵列里。备份网络需要租用运营商带宽或建设专网，并要根据网络状况和拷贝的数据量设置合适的时间点和策略。备份功能架构图如下所示。备份的数据可以是数据库、虚拟机镜像，也可以是操作系统和关键文件。支持LAN备份以及Lan-Free备份模式。对于关键数据备份频率可以设置为每周一次全备，每天做一次增量备份或是差异备份，本地局域网的带宽较大，可适当加大备份的频率。如果各委办局或是本地生产数据出现人为误操作或是不可恢复的硬件故障所导致的数据逻辑错误时，可以利用本地的备份数据进行恢复，取决于需要恢复的数据量以及容灾链路带宽，一般恢复操作需要数小时甚至数天。如果本地的备份数据同样出现逻辑故障，可以利用远程的备份数据进行恢复。4.6.容灾网络建设方案设计容灾通信链路设计是容灾系统建设非常重要的部分，也是容灾方案设计的难点、要点之一，本章节对这一部分内容进行详细描述。不同的通信链路有不同的要求，如距离限制、带宽能力等；而不同的容灾技术、不同的容灾应用对通信链路的要求不同；采用同步方式或采用异步方式进行数据复制对通信链路的要求也大不相同。根据用户的不同要求进行科学的通信链路设计是保障用户在合理的通信成本下成功实现容灾系统建设的重要步骤之一。464.6.1.整体容灾网络架构设计根据其作用不同，网络系统分为计算网络、存储网络和对外服务网络。其中计算网络用来实现服务器设备之间的通信，根据对带宽、延迟的不同要求，可以基于千兆、万兆以太网或是Infiniband、Myrinet等高性能网络构建；存储网络用来实现服务器和存储设备或是存储设备之间的数据通信，通常基于FC、千兆和万兆IP网络（iSCSI、NFS、CIFS等）或是Infiniband网络构建；服务网络用来为互联网或是局域网用户提供服务，对网络带宽要求不高，通常采用百兆或是千兆以太网络即可。在设计网络系统的时候，计算、存储和对外服务网络可以共用一套物理网络，但是为了提高系统可靠性，减少不同类型通信之间的性能影响，建议这三套网络要实现物理隔离，各自构建自己的网络链路。另外，为了进一步提高IT系统可靠性和性能，计算网络和存储网络一般采用双网架构，双网以主、备或是负载均衡模式工作。经过以上分析，若要实现应用级的容灾，那么生产中心和容灾中心之间通常需部署三种互联链路，每种互联链路所承载的数据不同，实现的功能不同，并且这三种链路在逻辑上相互隔离。网络三层互联。也称为数据中心前端服务网络互联，所谓“前端服务网络”是指数据中心面向广域网的出口。不同数据中心（主中心、灾备中心）的前端网络通过IP技术实现互联，客户端通过前端网络访问各数据中心。当主数据中心发生灾难时，前端网络将实现快速收敛，客户端通过访问灾备中心以保障业务连续性；网络二层互联。也称为数据中心服务器数据网络互联。在不同的数据中心服务器网络接入层，构建一个跨数据中心的大二层网络（VLAN），以满足服务器集群或虚拟机动态迁移等场景对二层网络接入的需求；SAN互联。也称为后端存储网络互联。借助传输技术（裸光纤、DWDM、FCIP等）实现主中心和灾备中心间磁盘阵列的数据复制。4.6.2.前端服务网络容灾方案正常情况下，用户、分支机构等都是连接到主数据中心，当主数据中心发生故障之后，用户、分支机构等都应该能切换为与备份数据中心相连接，实现这种前端网络47（客户端）切换的技术主要有以下几种：手工切换、DNS和HTTP重定向以及健康路由导入等。手工切换手工切换的技术通常应用于异地灾备中心或是同城容灾中心。例如：生产中心的IP子网为A.B.0.0，正常情况下，用户和分支机构都会通过这个网段来连接到生产中心，容灾中心的子网也是设置为A.B.0.0，但正常情况下容灾中心的网段是关闭着的，当生产中心发生灾难时，此时手动操作打开容灾中心的网段，用户和分支机构不做任何修改便可以连接到容灾中心。这种方式操作最简单，也不需要额外的设备和技术支持，但是需要人工干预。DNS重定向DNS重定向是同城容灾中心和双活数据中心常使用的一种网络切换技术。要实现DNS切换方式，在主数据中心和容灾中心的部署中必须要有一个智能的DNS设备作为站点的域名解析服务器，当用户需要访问某一个应用服务器时，系统首先会将请求发送到数据中心的DNS服务器进行处理，DNS设备常具有应用感知功能，它可以监控数据中心WEB服务器、应用服务器等的状态。当主数据中心正常时，DNS会将主数据中心服务器的IP地址回给用户，这时用户就连接到主数据中心了。当主数据中心发生灾难时，主数据中心的DNS设备检测不到它的服务器状态，此时灾备中心的DNS设备便将备份数据中心服务器的IP地址回给用户，用户连接到灾备中心。健康路由注入健康路由导入也是同城容灾中心和双活数据中心常使用的另一种网络切换技术。要采用这种技术，生产中心和灾备中心均需配置一套负载均衡设备，数据中心的负载均衡设备能探测数据中心后台服务器的健康状况，如果探测到的服务器状况良好，负载均衡设备便向网络中发送一条与负载均衡设备对应的数据中心服务器的主机路由。对于生产中心和灾备中心来说，它们发出的主机路由值不同，生产中心发送低Cost值路由，灾备中心发送高Cost值路由。两个数据中心都正常工作时，用户发送连接请求后会收到两条Cost值不同的主机路由，通常情况下会选择Cost值低的路由连接到生产中心。当生产中心发生灾难时，请求连接的用户只能收到一条来自灾备中心的高Cost值路由，用户通过该路由连接到灾备中心。48总结以上几种前端网络容灾技术综合比较如下：对比项手工切换DNS方式健康路由导入切换速度分钟1分钟秒客户端软件配置不需要修改不需要修改不需要修改增加设备不需要增加DNS服务器增加负载均衡器可扩展性多中心，多服务器较低高高分配方式静态连接，用户交易随机发送可根据数据中心负载、用户距离分配只能在数据中心间平均分配4.6.3.服务器数据网络容灾方案在传统的数据中心服务器区网络设计中，通常将二层网络的范围限制在网络汇聚层以下，通过配置跨汇聚交换机的VLAN，可以将二层网络扩展到多台接入交换机，这种方案为服务器网络接入层提供了灵活扩展能力。近年来，服务器高可用集群技术和虚拟服务器动态迁移技术（如VMotion）在数据中心容灾及计算资源调配方面得以广泛应用，这两种技术不仅要求在数据中心内实现大二层网络接入，而且要求在数据中心间也实现大范围二层网络扩展(DCI:DataCenterInterconnection)。EVI（EthernetVirtualInterconnection，以太网虚拟化互联）是一种实现异构网络二层互联的技术。EVI采用先进的"MACinIP"技术，用于实现基于IP核心网络的L2VPN。通过EVI技术在站点的边缘设备上维护路由和转发信息，而无需改变站点内部和核心网络。在EVI的组网方案中，不需要考虑数据中心之间的网络类型，只需要保证EVI边缘设备（EdgeDevice）之间IP可达就可以实现数据中心之间的二层互通。在EVI边缘设备之间建立EVI隧道，以太报文就可以通过该隧道到达另一个数据中心的二层域内，实现二层互联互通。49EVI技术可以结合IRF技术使用，从而保证边缘设备的HA性能和双归属设计。另外，如果数据中心汇聚交换机也支持IRF，就可以有效提高边缘设备与数据中心汇聚交换机之间的链路带宽利用率和HA性能。EVI组网方案的优点非常明显：支持Overlay网络，可以跨裸光纤、MPLS或是IP网络实现二层互联；EVI配置简单，只需要6条命令即可以启动；EVI支持IRF，可以有效提高系统的HA性能。4.6.4.存储网络容灾方案当前业界存储网络容灾方案的通讯链路有“裸光纤直连交换机方式、通过DWDM设备连接裸光纤方式、IP网络方式”等几种，每种方式各有利弊，以下对不同通信链路方式进行比较。裸光纤直连采用FC协议的通信链路只适用于基于存储复制或虚拟存储复制的容灾方案。在这类方案中，生产中心与备份中心的光纤交换机通过裸光纤直连，如下图所示：两个中心存储系统的容灾端口通过光纤交换机和裸光纤进行连接，可以保证同步或异步数据复制的性能。为保证高可用，通常采用冗余连接链路设计。容灾链路裸光纤可以和生产主机共享SAN交换机，也可以独立SAN交换机（也需要冗余）。通常为避免容灾链路通信和主机访问存储的相互干扰，采用独立的SAN来连接容灾通信链路的方式采用较多。不同容灾方案需要的通信链路数量是不同的，具体需要链路的条数（即带宽要求）需要具体分析、计算获得。CWDM/DWDM直连裸光纤采用密集波分复用技术，可以加载多协议，例如FC协议、IP协议，如下图所示：50如上图所示,通过CWDM/DWDM技术，主数据中心和容灾数据中心的IP网络连接、FC连接都可以复用到共享裸光纤，比较好的解决了裸光纤的利用率和多协议复用的问题。为避免单点故障，同样可以采用冗余连接、没有单点故障的解决方案。同时，采用CWDM/DWDM方式有更多的拓扑方案，需要在具体设计时进行分析后确定。IP网络连接远程容灾中心存储网络通常基于IP网络构建。采用“基于存储或基于虚拟存储”的容灾技术将需要进行FC协议到IP协议的转换，从而将FC加载在IP网络中传输。此方案采用国际流行的IP网络协议和链路，通过FC/IP转换设备，将FC通道协议打包在IP数据包内，通过IP链路传输，理论上没有距离的限制，适用于远程异步数据复制，是性价比很好的选择。连接示意图如下：4.6.5.本项目建议容灾网络方案结合本项目的容灾目标，本方案建议容灾网络建设方案如下：同城容灾中心需要实现应用级别的容灾，并且数据复制采用同步数据复制技术，对网络带宽要求较高，因此，生产中心和同城容灾中心分别采用DNS重定向、EVI、DWDM技术构建前端服务网络、服务器数据网络和存储网络；51异地容灾中心和同城容灾中心之间实现数据级容灾即可，采用IP网络构建容灾链路。5.本项目灾备系统建设的几点建议容灾系统的建设，必须立足于XX市各委办局现有业务系统运行的现状，对各委办局的业务系统进行持续和彻底的调研分析，将业务系统的架构进行详细分类，对关键数据的类型和存储架构进行整理，按照业务系统对容灾的需求急迫程度排序，优先选择一批业务系统作为容灾方案设计的试点，侧重于业务系统切换、结构化数据复制和非结构化数据复制以及数据集中备份四个方面的技术论证，并根据容灾规划的经验，对其他需要容灾设计的业务系统提出这四个方面的优化建议。5.1.需要按照灾备要求梳理系统容灾系统规划的首要工作是对各委办局现有业务系统的全面梳理，需要各委办局业务科室、软件开发厂商、运维管理人员、容灾方案设计人员共同参与，形成详细的调研报告。梳理系统需要切实做好以下工作：明确业务系统的责任单位、承建单位以及服务器数量、配置。调研业务系统的架构，按照单机应用、应用服务器+数据库服务器、WEB+应用服务器+数据库、WEB+应用服务器等分类，便于设计容灾切换的各个环节。业务系统各部分所用服务器是虚拟机还是物理机、虚拟机和物理机数量，业务系统的IP资源、操作系统、中间件类型、负载均衡使用Websphere等软件方式还是F5、Radware等硬件方式。业务系统是否按照WEB层负载均衡、应用服务器集群、数据库集群设计，便于实现高级别容灾。业务系统的数据是否集中存放，非结构化数据是放在应用服务器本地硬盘，还是放在磁盘阵列上，数据库数据是放在本地硬盘，还是集中放在磁盘阵列，为实现容灾，可否改进数据存储策略。5.2.解决好数据库系统数据复制各委办局的业务系统普遍使用Oracle两种数据库，数据库的数据包括数据文件和日志文件，从原理上来说，数据库复制包括数据文件和日志文件的传输。Oracle数据库复制，通常是在两地部署数据库系统，将主站点的数据库全备份在52备份站点恢复，此后即时传输变化的日志文件即可。对两地容灾的场景，日志传输采用异步的方式，不会影响主站点数据库性能。目前容灾系统上常用的DataGuard、GoldenGate、SharePlex等都是这种实现机制。5.3.“现实”的切换策略容灾规划中关于切换策略的制定，必须基于委办局各业务系统的特点，预先制定并定期演练，以便确保容灾系统有效运行。切换方式分为两种，即手工方式和自动方式．手工方式手工方式是对于复杂的应用系统进行容灾切换的主要方式，手工方式需在备份中心按照对故障的判断，启动预先编写的业务系统切换脚本完成应用系统的切换过程．手工方式容灾切换过程需要人为介入，因此，容灾备份系统安全性以确保人员的安全以及对系统的访问能力为基础。自动方式自动方式可以实现应用系统的自动切换功能；保证当突发性灾难发生时，即使在无人值守的情况下，也能够实现系统的正常切换，确保业务系统能够实现全天候的正常运行。但是由于应用系统的复杂性，自动方式要求能够对用户选择的某类或某些业务种类的数据平台、业务平台和接入平台按照正确的关系完整切换。更重要的是，自动方式需要对复杂的系统环境中的各种故障作出正确分析判断，以根据事先定义的策略，触发相应切换流程。这样需要高度客户化、智能化的自动容灾切换系统，目前没有产品化技术可供选择。切换当主生产中心发生的故障或灾难影响到业务系统的正常运行时，应首先对业务系统的受影响程度进行检查，尽可能快速定位业务系统的故障部位。分别对机房受损程度、机房电源、计算机网络、系统硬件、操作系统、数据库、应用系统等进行检查，评估恢复时间，然后由相应人员决策是否进行系统切换，应考虑以下因素和原则：一、故障影响程度可以分为两大类：\uf0d8业务停顿，但故障范围明确，并且可在可忍受的时间内修复，不需要异地切换。例如：电源发生故障、软硬件故障、消防系统和空调系统等机房环境告警、人为因素误操作的情况，应用系统应建立相应的本地高可用性系统、备份策略，53管理流程，采用专业服务支持、基础设施的防护等措施，来预防和避免故障对业务系统连续性运行的影响。\uf0d8数据中心系统在可以忍受的时间内无法恢复或彻底破坏，必须进行容灾切换二、优先选择本地恢复原则当无法判定主中心的业务系统修复所需时间时，应在继续恢复主中心的系统的同时，在备份中心开始进行切换的准备工作。只要主中心的业务系统在可容忍时间内有恢复的可能，就应优先选择本地恢复。三、优先恢复关键性业务原则对于应用系统的各个子系统，根据停机时间所造成的影响和损失的大小的不同，优先恢复关键性核心业务。当备份中心的主机、网络等资源不足时，优先提供给关键性核心业务使用。回切当主生产中心的系统恢复以后，就应将业务系统由容灾中心回切到主生产中心。回切过程中要保证两中心的数据的一致性。一、业务影响最小原则系统回切不同于系统切换，由于灾难发生的随机性和不确定性，系统切换都是在被动的情况下发生的，有可能造成业务数据的丢失和切换时间较长，对业务的正常进行会造成严重影响。而系统的回切是可以按照事先的计划来实现的，因此在系统回切计划中，应选择业务量较小的时候，采用最简化的步骤回切；二、及时性原则业务系统由主数据中心切换到容灾中心后，核心数据不再有容灾保护，因此应尽快恢复主数据中心，并将业务系统回切到主中心，使核心数据重新得到容灾保护；三、数据一致性原则系统回切前需将数据由容灾中心复制到主中心，并保持严格的一致性。6.软硬件设计6.1.软硬件总体选型原则本项目基于同城容灾中心和远程容灾中心实现应用级别的容灾，为了尽可能节省投资，本方案建议对容灾系统采用降级容灾的模式构建。因此在同城和远程容灾中心，需要从服务器系统、网络系统、存储系统、应用软54件等整个IT平台建立起和生产系统的配对关系，容灾中心这些系统配置的数量可以少于生产中心、性能可以低于生产中心，为了降低同城容灾中心的构建成本，同时增强系统的开放性和扩展性，同城容灾中心和异地容灾中心的服务器平台采用X86架构服务器构建，同时建议采用虚拟化技术，用以提高设备的利用率，进一步节省投资。软硬件的总体设计原则如下：数据复制方面，数据复制技术的选择必须结合用户现有业务系统的现状，允许数据库平台、存储平台、操作系统的异构，同时需要满足不同RPO、RTO级别的需要，同时该技术要具有良好的开放性，满足未来扩展的需要。硬件设备方面，主要考虑存储、主机设备及核心交换机。硬件平台的选择要兼顾性价比、开放性的原则，同时要符合未来主流技术的发展趋势。存储设备需要按照容灾规划新采购，同城容灾中心需要配置一部分存储空间用于保留数据快照，因此同城中心容量和生产数据容量配置比例为1.2:1。异地中心存储容量略大于生产数据容量。借助于虚拟化技术，容灾中心主机设备配置的数量和性能均可低于生产系统。软件方面，对于同城和异地应用级容灾中心，需要新增数据库软件和应用软件主要用于应用容灾所需，和生产系统系统无需1：1考虑，仅需新增到应用容灾的最小配置即可，减少投资。其它。运维监控所需软硬件、安全所需软硬件将根据相应需求增加。6.2.同城容灾中心软硬件设计6.2.1.一体化备份系统同城灾备中心需要配置3台一体化备份系统（其中一台在云计算中心建设完成后迁移过去），分别用于计划迁移到云计算中心的各委办局业务系统的关键数据的备份、剩余业务系统的关键数据的备份以及XX市电子政务外网业务系统关键数据的备份。经统计，43个单位的794个应用软件和294个网站共有数据容量共记813.8TB。其中数据库这类结构化数据约为75TB，其中80%是关键数据需要备份，这类数据的年增长率约为10%，考虑到未来3年的备份需求，这部分数据备份空间配置不少于80TB。文档、图片、音视频这类非关键数据中的10%为关键数据，需要备份，这类数据的年增长率约为20%，考虑到未来3年的备份需求，这部分数据备份空间配置需不少于127TB。因此，3套一体化备份系统总的备份存储空间配置不少于210TB。从备份功能上分析，备份系统需同时支持主流数据库、文件、主流操作系统、主55流虚拟机镜像等常见数据的备份，备份策略支持全备、增量和差异备份，支持LAN以及LAN-Free备份。6.2.2.数据库容灾系统数据库容灾系统包括数据库服务器、数据库存储、存储交换机以及数据库复制软件。数据库服务器从《电子政务外网运行应用主要情况表》里可以看到，43个单位共有79个数据库，其中28个Oracle数据库、9个DB2数据库、20个SQLServer数据库里面的数据需要容灾备份（其中Oracle、SQLServer数据库要实现应用级别容灾，DB2数据库只需要实现数据级容灾即可），为了降低构建成本，生产数据库和容灾数据库按照10：1的数量进行配置，因此，同城容灾中心共需要配置不少于6台容灾数据库服务器。由于生产库和同城容灾库的配比比例较高，因此，要求单台容灾数据库服务器的性能较高，配置应不少于8颗物理CPU，内存配置不少于512GB，同时配置不少于2块8GbFCHBA卡用于和盘阵连接。为了保证数据库系统的开放性和兼容性，本方案建议选用X86架构的数据库服务器平台。数据库存储经统计，需要容灾的57个生产数据库约有52TB的数据，这类数据的年增长率约为10%，考虑到未来三年数据增长的需要，这部分数据存储空间配置需不少于70TB，同时需要约20%的快照存储空间，用于数据库数据验证。因此，同城容灾中心需配置一套数据库存储，存储空间配置不少于90TB，该存储系统具有较好的性能和扩展性，要求配置主机接口不少于16个8GbFC以及48GBCache，存储容量最大可扩展至PB级别。同时该盘阵需支持快照和卷拷贝等高级数据保护功能。存储交换机本系统还需要配置2套FCSAN交换机，用于构建连接数据库服务器和数据库存储盘阵的高可靠冗余数据网络，每套交换机至少配置不少于24个8GbFC接口。数据库容灾软件本系统还需要配置一套数据库容灾软件，该软件支持异构数据库系统之间的数据复制，支持Qracle、DB2、SQLServer等常见的数据库，支持常见的UNIX、Linux和Windows操作系统，配置不少于10颗CPU授权许可，满足容灾需求。56数据库软件需要购置部分Oracle数据库软件，配置不少于6颗CPU授权许可，以满足同城灾备中心数据库灾备需要。6.2.3.云计算平台容灾系统为了降低容灾系统的构建成本，同时保证容灾系统具有良好的扩展性和开放性，本方案采用云计算平台用于生产应用服务器的容灾。同城云计算平台容灾系统包括虚拟化服务器、存储设备（兼做非结构化数据容灾存储）、存储交换机、虚拟化软件等，另外，有些委办局要求容灾应用服务器必须使用物理机，本系统还需配置一些容灾服务器。虚拟化服务器经调研，43个部门中约有80个核心应用需要在同城容灾中心实现应用级别的容灾，每个应用需要大约2台2路服务器，需要配置不少于160个虚拟机。一台高性能4路服务器大约可以虚拟出20个2路虚拟机，本项目需要配置不少于8台虚拟化服务器，每台服务器配置不少于40个CPU核，配置不少于256GBCache以及4个千兆网卡。并要配置2个8GbFC板卡用于和存储设备相连。虚拟化软件为了实现服务器虚拟化功能，本系统需要配置一套企业版服务器虚拟化软件，配置不少于32颗CPU许可，同时需要配置容灾套件。虚拟化存储（兼做非结构化数据容灾存储）本系统需要为每个虚拟机分配不少于50GB的操作系统镜像存储空间，以及20GB的数据存储空间用于存储应用程序的数据，虚拟机的数量以每年20%的速度增长，考虑到未来3年用户业务扩展的需要，这部分存储空间配置需不少于20TB，这部分存储空间对IOPS性能要求较高，建议存储介质采用高性能SAS硬盘。上述80个业务共生成约40TB的非结构化数据，要实现应用级容灾，这类数据也需要复制到同城容灾中心，并且这类数据以每年20%的速率增长，考虑到未来3年的需要，这部分存储空间配置需不少于70TB，这部分存储空间对连续读写性能要求较高，存储介质可采用高性价比SATA硬盘构建。这两部分存储空间可由一套磁盘阵列提供，为了实现应用级别的容灾，这部分数据需要在云计算中心和同城容灾中心都存储一份，因此，本系统需要配置2套磁盘阵57列，每套配置不少于20TB的高性能SAS存储空间，以及70TB的高性价比SATA存储空间，为了保证存储系统的IOPS性能和带宽性能，每套存储系统配置不少于4个8GbFC以及2个10Gb主机接口，以及20GBCache，并需支持二级Cache加速技术。存储交换机本系统还需要配置2套FCSAN交换机，用于构建连接虚拟化服务器和虚拟化存储盘阵的高可靠冗余数据网络，每套交换机至少配置不少于24个8GbFC接口。容灾服务器有些委办局的业务要求容灾应用服务器也必须采用物理机搭建，本系统为这类需求用户配置4台容灾服务器，每台服务器配置不少于2颗CPU以及32GB内存。应用软件基于同构环境设计思路，同城容灾应用的版本、配置、运行环境等信息要保持和生产中心一致。需确保应用相关的授权、外设齐备并可用。基于同构环境设计思路，同城灾备的应用平台设计和生产中心保持一致，在版本、配置信息等要和生产中心保持同步。为了尽可能节省投资，这种许可按照最低配比关系配置即可。6.2.4.同城数据存储容灾系统本系统配置的两套虚拟化磁盘阵列需要通过存储虚拟化网关实现数据的实时同步，组成双活存储系统，因此，本系统需要配置一套（2个节点）存储虚拟化网关。当前有些高端盘阵的控制器同时可以兼做存储虚拟化数据复制网关，不需要配置额外的硬件设备，但是需要开通以下功能：存储虚拟化功能，实现异构存储资源整合，借助于此功能，可以实现异构存储设备之间的数据复制；数据复制功能，支持同步、半同步、异步数据同步模式；数据快照和卷拷贝功能，利用这些功能，实现数据的验证。还有一些厂商采用专用的硬件设备构建存储虚拟化网关，这类产品除要求具有上述软件功能上，对于硬件配置要求每个节点配置不少于4个8GbFC和2个10Gb接口，20GBCache，这类产品通常按照管理存储容量许可进行收费，本系统要求每个节点配置不少于90TB的存储容量管理许可。同时，为了存储系统的开放性和扩展性，要求该网关最好同时可以提供SAN和NAS协议，兼容市场主流磁盘阵列、主流数据库和虚拟化应用。586.2.5.机房改造系统机房基础设施设备包括制冷设备、配电设备、综合布线、机房监控系统、机房机柜系统、指挥大厅、机房装修系统等。空调室内机机房制冷设备采用机柜行间制冷空调，行间空调穿插在机柜间安装，单台空调制冷量≥25KW；行间空调风机需采用EC风机，可根据负载情况自动调节风机转速；行间空调自带温度、烟感、漏水、湿度传感器，并且能够上传到第三方监控平台，无偿提供协议，支持远程监控；行间空调与服务器机柜机柜尺寸、外观统一，可进行并柜安装；行间空调采用模块化设计，可在任意标准19英寸机柜内安装；行间空调采用前出风后回风的方式，空调冷媒为氟利昂；单台行间空调分为上下两个单元，可分别调节制冷量，满足机柜不同高度制冷需求；空调室内机自带LED显示屏，可显示空调送风温度及风机转速；机房整体散热采用热池形式，热池自带封闭门及封闭顶板，封闭门及封闭顶板带自控功能，当热池内温度过高或者有火警信号时，封闭门及封闭顶板自动打开；空调室外机空调室外机采用风冷设计，单台室内机制冷量为200kW；空调室外机采用模块化设计，任意模块损坏不会对其他模块产生影响，机组能够继续运行，可在线进行维修、更换部件；空调室外机采用多联机模式设计，可实现一拖多，空调室外机冷媒为氟利昂；空调室外机带自然冷却功能，在室外温度低于18℃时，可充分利用室外自然冷源进行制冷，关闭部分或者全部关闭压缩机进行制冷；空调室外机能够实现远距离输送制冷剂，为空调室内机提供冷媒；机柜配电机柜配电采用列头配电柜的形式，列头配电柜与服务器机柜机柜尺寸、外观统一；机柜PDU与列头柜采用工业连接器进行连接，列头配电柜能够监控每一路PDU的用电量及电流、电压，具有标准S485接口，无常提供通讯协议；列头配电柜及PDU要求为服务器同一品牌；59UPS及蓄电池UPS选择模块化UPS，功率因数要高于0.94；蓄电池建议采用进口品牌或者合资品牌，待机时间为1个小时；综合布线机房弱电建议采用上走线，并且建议采用机柜一体化线槽，美观大方；建房强电建议采用下走线，避免与弱电产生干扰；机房监控系统机房监控系统要求能够监测到电力、温度、湿度、烟感、漏水、消防、视频；监控系统能够监控到每个热池的温度、湿度、烟感、漏水、开门系统；监控系统包含PUE检测系统，能够实时监测机房PUE值，包括日、周、年级平均PUE值，具有相应计算软件，支持客户自行计算；机房机柜系统机柜建议采用600mm宽标准19英寸机柜，支持42U内部扩展空间；行间空调柜、列头配电柜、服务器机柜机柜尺寸、外观统一；机柜框架建议采用铝镁型材机柜，黑色，表面采用静电粉末喷涂处理，角规厚度2.0mm，坚固可靠，承重≥1200kg；热池通道封闭部件需采用钣金件结构，顶板采用防火玻璃，透光率要好；指挥大厅指挥大厅内监控大屏采用LED无缝拼接大屏，自带相应应用软件及监控主机；指挥大厅内监控大屏能够连接机房监控系统，实时显示机房内各种设备运行状况及显示机房整体PUE值；指挥大厅前部工位采用弧形设计，工位上放有台式电脑，能够连接监控大屏后台系统；机房装修机房地面、墙体、屋顶需刷防尘漆、做保温，保证机房绝热性能良好；机房防静电活动地板要求架高500mm，材质要求为钢化地板；机房门窗要求密封性好，减少漏热、漏湿；机房防雷接地系统要满足国家相应标准；机房内隔断需采用防火钢化玻璃；606.2.6.网络系统6.2.7.安全系统6.2.8.详细软硬件配置清单同城灾备中心设备明细表序号项目配置要求单位数量一、同城数据集中备份系统1备份存储系统软硬一体化备份存储系统；支持在线备份、增量备份和差异备份；支持LAN、LAN-Free备份功能；支持文件、各种数据库和操作系统的备份功能，配置≥70TB备份存储空间，可按需扩展；支持Windows、Linux、AIX、HP-Unix、Vmawre等各种异构客户端备份，配置≥30个异构客户端备份许可，≥10个数据库备份许可，≥3个虚拟机备份许可，可按需增加套3二、同城数据库容灾系统1数据库服务器8CPU，512GB内存；2块300GB10K2.5寸SAS硬盘；配置1块6Gb512MSASRAID；配置2块单口8GbPCI-E光纤HBA卡；配置≥4个千兆以太网口；配置冗余电源套62数据库存储双控制器；缓存≥48GB；16个8GBFC接口；1TB二级高速Cache，扩展能力：要求存储容量能够达PB级别。初始容量90TB配置自动精简配置、快照、卷拷贝等功能支持Cache加速、远程数据复制等功能套13数据库存储交换机FC端口数：实配≥24个8Gbps，支持级联。套24数据库容灾系统软件异构数据库复制软件，配置≥10颗CPU许可，兼容主流Oracle、DB2、SQLServer数据库平台以及主流UNIX、Linux和Windows操作系统平台。套15数据库软件数据库软件，配置不少于6颗CPU授权许可套16安装实施数据库容灾软件的首次安装与调试服务套1三、同城云计算平台容灾系统1虚拟化服务器4CPU，CPU核心数≥10；配置≥256GB内套861存；4个千兆以太网口配置冗余电源2虚拟化存储（兼做数据容灾存储）≥8个8GBFC接口；缓存≥20GB；支持PCI-ESSD和SSD硬盘二级高速Cache，扩展能力：要求存储容量能够达4PB。初始容量≥86TB，其中≥20TB高性能SAS(≥10KRPMSAS)和≥70TB高性价比SATA存储空间；配置自动精简配置、数据压缩以及集群容错等功能。套23虚拟化存储交换机FC端口数：实配≥24个8Gbps，支持级联。套24容灾服务器（2路）2颗CPU，CPU核心数≥8；配置≥32GB内存；2个千兆以太网口；配置冗余电源套45虚拟化软件服务器虚拟化软件，企业版，配置不少于32颗CPU许可，配置容灾套件套16操作系统软件操作系统（虚拟化平台需要）套1四、同城数据存储容灾系统1存储虚拟化网关（用于数据复制）每台设备配置不少于20GBCache，8个8GbFC和2个1Gb主机接口；配置不少于90TB存储容量管理许可；可自动实现I/O级复制,支持并配置同步、半同步、异步数据复制功能；配置存储虚拟化功能，支持IBM、EMC、HDS等主流厂商的异构盘阵整合；支持主流数据库、操作系统、虚拟机；可对外同时提供SAN和NAS存储访问协议。台2五、同城容灾备份中心机房改造1机房装修320平米机房区域改造装修、照明，含容灾备份主计算设备区、网络区、配电室、UPS室、发电机室等项12配电系统改造110KW动力市电供配电系统改造，至猎头柜双路供电项13UPS供电系统160KVA主机2台，并机，供电时间≥0.5小时套14空调系统制冷量120KW（室外机45KW2台、室内机30KW1台）1套，制冷量120kW（室内机15KW8台）。套15机柜系统44个机柜，分布在两个机房，封闭成4组冷池（机房一有三个冷池、机房二有一个冷池），每组机柜冷池系统由双排机柜封闭组成。项16新风系统/排风量3850立方米/小时套162风系统7机房环境监控系统机房环境监控告警、机柜监控、PUE监测套18消防系统机房各区域消防监控、联动控制、探测、报警、灭火装置及管线套19柴油发电系统200KW柴油发电机组套110视频监控系统18点高清数字监控枪机，32路高清网络硬盘录像机，最长保存3个月套111门禁系统4套四门门禁控制、4个指纹读感器套112综合布线系统机房内强、弱电桥架，布线施工套1六、网络系统七、安全系统6.3.远程容灾中心软硬件设计6.3.1.远程数据备份系统为了保证关键数据的可靠性，本项目需要把关键数据传送到远程容灾中心再备份一份，因此，本系统需要在远程容灾中心新增一台备份服务器和一套备份存储设备。备份服务器备份服务器对处理性能要求不高，采用普通X86架构2路服务器即可，内存配置63不少于16GB，同时需配置一块8GbFCHBA卡，用于与备份存储设备相连。备份存储设备备份存储设备用来为备份服务器提供备份存储空间，由于同城容灾中心的3套一体化备份系统的总数据量为210TB，这就要求本套存储设备提供不少于210TB存储空间，备份系统对存储性能要求不高，存储设备配置不少于4个8GbFC主机接口以及8GbCache即可。功能软件除了上述硬件，要实现关键数据的远程集中备份，还需要备份软件功能的支持，这就要求备份服务器需要配置介质管理功能，用于把存储设备虚拟成备份存储空间，同时同城容灾中心的3个一体化备份设备还需要开通远程数据拷贝功能。6.3.2.远程数据库容灾系统远程数据库容灾系统包括数据库服务器、数据库存储、存储交换机以及数据库复制软件。数据库服务器经过调研发现，在需要同城容灾的28个Oracle数据库、9个DB2数据库、20个SQLServer数据库里面，又有6个Oracle数据库、4个DB2数据库以及2个SQLServer数据库需要远程容灾备份（Oracle、SQLServer数据库要实现应用级别容灾，DB2数据库只需要实现数据级容灾即可），为了节省投资，生产数据库和容灾数据库按照6：1的数量进行配置，因此，远程容灾中心共需要配置不少于2台容灾数据库服务器。由于源库和远程容灾库的配比比例较高，因此，要求单台容灾数据库服务器的性能较高，配置应不少于8颗物理CPU，内存配置不少于512GB，同时配置不少于2块8GbFCHBA卡用于和盘阵连接。为了保证数据库系统的开放性和兼容性，本方案建议选用X86架构的数据库服务器平台。数据库存储经统计，需要容灾的12个生产数据库约有25TB的数据，这类数据的年增长率约为10%，考虑到未来三年数据增长的需要，这部分数据存储空间配置需不少于33TB，同时需要约20%的快照存储空间，用于数据库数据验证。因此，远程容灾中心需配置一套数据库存储，存储空间配置不少于40TB，该存储系统具有较好的性能和扩展性，要求配置主机接口不少于8个8GbFC以及8GBCache，存储容量最大可扩展至PB级64别。同时该盘阵需支持快照和卷拷贝等高级数据保护功能。存储交换机本系统还需要配置2套FCSAN交换机，用于构建连接数据库服务器和数据库存储盘阵的高可靠冗余数据网络，每套交换机至少配置不少于24个8GbFC接口。数据库容灾软件本系统还需要配置一套数据库容灾软件，该软件支持异构数据库系统之间的数据复制，支持Qracle、DB2、SQLServer等常见的数据库，支持常见的UNIX、Linux和Windows操作系统，配置不少于2颗CPU授权许可，满足容灾需求。数据库软件需要购置部分Oracle数据库软件，配置不少于2颗CPU授权许可，以满足异地灾备中心数据库灾备需要。6.3.3.远程云计算平台容灾系统为了降低容灾系统的构建成本，同时保证容灾系统具有良好的扩展性和开放性，本方案采用云计算平台用于生产应用服务器的容灾。远程云计算平台容灾系统包括虚拟化服务器、存储（兼做非结构化数据容灾存储）、存储交换机、虚拟化软件等。虚拟化服务器经调研，同城容灾中心的80个核心应用中的20个应用有远程应用级容灾需求，需要配置不少于40个虚拟机。一台高性能4路服务器可以虚拟出20个虚拟机，本项目需要配置不少于2台虚拟化服务器，每台服务器配置不少于40个CPU核，配置不少于256GBCache以及4个千兆网卡。并要配置2个8GbFC板卡用于和存储设备相连。虚拟化软件为了实现服务器虚拟化功能，本系统需要配置一套企业版服务器虚拟化软件，配置不少于8颗CPU许可，同时需要配置容灾套件。虚拟化存储（兼做非结构化数据容灾存储）本系统需要为每个虚拟机分配不少于50GB的操作系统镜像存储空间，以及20GB的数据存储空间用于存储应用程序的数据，虚拟机的数量以每年20%的速度增长，考虑到未来3年用户业务扩展的需要，这部分存储空间配置需不少于5TB。上述20个业务共生成约20TB的非结构化数据，要实现应用级容灾，这类数据也需要复制到同城容灾中心，并且这类数据以每年20%的速率增长，考虑到未来3年的65需要，这部分存储空间配置需不少于35TB。这两部分存储空间可由一套磁盘阵列提供，该存储配置不少于40TB的高性价比SATA存储空间，为了保证存储系统的IOPS性能和带宽性能，每套存储系统配置不少于4个8GbFC和4个1Gb主机接口，以及24GBCache。存储交换机本系统还需要配置2套FCSAN交换机，用于构建连接虚拟化服务器和虚拟化存储盘阵的高可靠冗余数据网络，为了节省投资，这两套交换机可以复用数据库容灾系统的存储交换机。应用软件基于同构环境设计思路，远程容灾应用的版本、配置、运行环境等信息要保持和同城容灾中心一致。需确保应用相关的授权、外设齐备并可用。基于同构环境设计思路，远程灾备的应用平台设计和生产中心保持一致，在版本、配置信息等要和同城容灾中心保持同步。为了尽可能节省投资，这种许可按照最低配比关系配置即可。6.3.4.远程数据存储容灾系统本系统配置的虚拟化磁盘阵列需要通过存储虚拟化网关实现与同城容灾中心虚拟化盘阵之间的数据同步，组成异地容灾存储系统，因此，本系统需要配置1个存储虚拟化网关。当前有些高端盘阵的控制器同时可以兼做存储虚拟化数据复制网关，不需要配置额外的硬件设备，但是需要开通以下功能：存储虚拟化功能，实现异构存储资源整合，借助于此功能，可以实现异构存储设备之间的数据复制；数据复制功能，支持同步、半同步、异步数据同步模式；数据快照和卷拷贝功能，利用这些功能，实现数据的验证。还有一些厂商采用专用的硬件设备构建存储虚拟化网关，这类产品除要求具有上述软件功能上，对于硬件配置要求每个节点配置不少于4个8GbFC接口，24GBCache，这类产品通常按照管理存储容量许可进行收费，本系统要求每个节点配置不少于40TB的存储容量管理许可。同时，为了存储系统的开放性和扩展性，要求该网关最好同时可以提供SAN和NAS协议，兼容市场主流磁盘阵列、主流数据库和虚拟化应用。666.3.5.网络系统6.3.6.安全系统6.3.7.详细软硬件配置清单异地容灾中心投资估算明细表序号项目配置要求单位数量（一）远程数据备份系统（二）远程数据库容灾系统（三）远程云计算平台容灾系统67（四）远程数据存储容灾系统（五）网络系统（六）安全系统（七）场地线路租用费687.项目组织机构和人员培训7.1.领导和管理机构为了更好地协调组织好项目建设，项目建设由甲方及承建公司共同成立一个项目建设领导小组（以下简称领导小组）来协调双方的工作和步调。领导小组项目专家组质量保证组总体组软件文档与测试组数据组项目开发组...总体设计系统集成开发小组[1]规范标准...开发小组[2]...测试小组[1]测试小组[2]...数据小组[1]数据小组[2]...文档小组[1]系统建设组织机构建议示意图项目领导小组：建议由甲方领导亲自挂帅，同时包含承建公司的领导，该小组主要处理一切与项目有关的重要决策和事务，主要包含下面的任务：（1）批准项目的总体方案和实施计划；（2）定期召开相关各方会议，并根据系统实施的实际情况做出双方一致同意的重要决策。项目专家组：负责系统在技术和业务上的咨询、探讨和评审，同时对项目进行“事前监管”，确保项目的顺利实施，即由专家小组对项目开发和实施过程中可能出现的种种问题进行充分的分析和论证，不仅直接确定解决方案，同时对可能出现的风险因素和实现难度组织有效可控的对应预案。所以，该“事前监管”能够在最大限度上规避各种问题及各种风险，对项目的顺利实施是十分关键的。项目协调组：负责与甲方项目领导组联系，保障项目实施。质量保证组：是公司的组织机构，负责项目开发过程的质量控制，对该项目的每一个阶段进行评审验收。项目总体组：代表公司对项目全面负责；负责与甲方项目领导组联系；负责项目计划实施，并对各组职能进行安排、监督，保证项目圆满完成。项目开发组：负责项目系统开发、调试，根据用户对功能的微调进行系统软件的修改完善及文档建立，并负责白箱测试。69项目文档与测试组：负责项目集成阶段性和最终的黑箱测试，配合用户进行的验收测试人员从开发组和测试组中抽调，编写文档。项目数据组：负责项目相关的数据制作。7.2.项目实施机构7.3.运行维护机构灾备中心的运行维护工作非常复杂，为了灾备中心日常管理工作和灾难恢复工作有效开展，并完成对灾备中心的日常管理、演习、测试、培训等工作，在灾备中心需要设立相应的运维管理组织机构。XX市政务网站管理中心需要配备专职的灾备中心维护和管理人员，确保灾备中心系统的可用性并能按照灾难恢复要求的时间完成系统切换。在项目实施过程中，需要根据灾备系统的功能和建设的模型，全面衡量灾备中心的工作量，确定灾备中心的人员编制。参照国家标准《信息系统灾难恢复规范》中关于灾难恢复组织机构建立的相关原则，建议成立包括：XX市电子政务信息中心最高管理层、业务部门负责人、信息中心负责人及其他相关部门负责人在内的灾难恢复管理委员会，指导和协调灾难恢复管理工作。建议由最高决策层成员担任灾难恢复管理委员会的负责人，进行灾难恢复的最终策略，审核批准灾难恢复工作所需的资源和经费，保证灾难恢复策略与经营目标的一致性；并对两地三中心日常灾难恢复准备工作和实际灾难恢复工作中的关键问题进行最终决策。建立常设的灾难恢复组织机构，在灾难恢复管理委员会的指导下，统一负责两地三中心的灾难恢复建设和灾难备份中心的运行维护工作；统一负责XX市电子政务信息系统的应急响应和灾难恢复工作。灾难恢复组织机构应包含灾难恢复规划建设、灾备中心运行维护、紧急事件应急响应、灾难恢复等工作所需的相关人员。灾难恢复组织机构在灾难恢复规划建设和运维阶段的主要职责包括：组织进行灾难恢复需求分析和策略制订；组织进行灾难恢复资源的准备工作；组织进行灾难备份系统的建设工作；组织进行灾难备份系统的日常运行和维护；70组织进行灾难恢复预案的开发、维护和演练；组织开展人员的教育和培训工作。灾难恢复组织机构在紧急事件应急响应和灾难恢复阶段的主要职责包括：应急响应和预警报告；事件通报和沟通；损害评估和抢修拯救；信息系统恢复、重建和回退；灾难恢复资源保障和供应；媒体公关和信息通报；恢复成效评估和总结。7.4.技术力量和人员配置7.5.人员培训方案培训目的通过灾备培训，可确保：相关人员明确自身职责、掌握相关灾备知识，提高各组织人员的工作技能和灾难应对能力。培训对象培训对象为XX市政务网站管理中心所有与灾备项目相关的人员，包括管理中心领导组成员、执行组成员，系统组成员，业务组成员，行政管理组成员等。培训内容培训内容包括灾备基础培训、灾备流程培训、灾备技术培训、灾备管理培训等课程。培训方式培训方式采用集中培训、现场培训、发放宣传材料等相结合的方式，针对不同层次的人员，开设不同的培训课程和确定培训方式。（1）集中培训方式：分别针对系统管理员、系统维护人员和系统操作人员，开设集中培训课程。重点是系统维护人员和系统操作人员，采用集中授课的方式进行培训。（2）现场培训方式：重点针对系统管理员，通过在现场的施工和培训，深层次的掌握系统各设备的使71用、维护、故障检修和各种日常操作等。8.项目实施进度8.1.项目建设期根据XX市电子政务建设实际情况和拟建设的云计算中心方案，项目建设期为xx年，分期建设目标为：第一期主要完成同城数据备份和同城容灾备份，建设周期为xx年x月至xx年x月；第二期完成异地容灾和远程异地数据备份，建设周期为xx年x月至xx年x月。8.2.实施进度计划8.2.1.同城容灾中心建设计划同城应用级容灾灾备建设步骤，分为如下5个阶段，请参考下图。针对每一个阶段，我们从实施内容、周期、建设重点与风险几个方面进行了描述。阶段A为准备阶段。因应用容灾需要比数据容灾更多的主机设备、相关软硬件等，本阶段将根据预先做好的规划设计，在同城容灾中心建设完成后在容灾中心安装、部署这些设备，为后续实施做好准备。同时本阶段应完成所需的应用软件平台改造工作。72在整个阶段，所有操作均为对现有设备的改造过程，需要对现有环境操作，风险相对较高，实施周期较长。阶段B为实施阶段的第一步。本阶段主要进行应用容灾业务接入网络的建设，及应用软件安装配置。业务网指的是各业务使用部门、最终用户连接到容灾中心的访问链路，在生产中心发生灾难时将通过此链路访问容灾中心的备用系统。此阶段由于不对现有系统做任何操作，风险极低，实施周期比较短。阶段C为实施阶段的应用同步步骤。本阶段的工作为建立起生产中心与容灾中心之间的应用同步。具体分为初始同步，和持续数据同步。应用的同步，是自动同步，即应用程序和代码和数据一起同步；生产中心和同城容灾中心的应用同步实施完成，标志着应用容灾实现运行。在容灾端，应用平台能够顺利运行并对各委办局提供服务。阶段D为运维阶段。到本阶段前，应用和数据的同步已经建立，应用容灾的目标已经实现。运维阶段主要任务是做好日常监控和管理，保障数据容灾系统的正常运行。应用容灾阶段运维工作还需要进行容灾演练。阶段E为灾难切换阶段。本阶段的工作不属于日常范畴，仅在发生灾难后，容灾中心发挥作用，将发生灾难的生产系统切换到容灾中心运行。工作步骤分为接管、运行、反向复制、系统恢复等几步。8.2.2.异地容灾中心建设计划在完成同城应用级容灾后，可进一步进行异地应用容灾建设，分为5个阶段，请参考下图。针对每一个阶段，我们从实施内容、周期、建设重点与风险几个方面进行了描述。73阶段A为异地容灾中心环境建设阶段。本阶段包含机房改造完毕与机器进场调试；阶段B为实施阶段的同城容灾中心的系统调整步骤。系统调整的主要目的是下一步数据向异地同步的实施做好准备。阶段C为实施阶段的数据同步步骤。本阶段的工作为建立起同城容灾中心与异地容灾中心之间的数据同步。具体分为初始数据同步，异地容灾中心数据从无到有的过程；持续数据同步，数据在同城容灾中心与异地容灾中心保持持续的同步。应用的同步，是自动同步，即应用程序和代码和数据一起同步；同城容灾中心和远程容灾中心的应用同步实施完成，标志着应用容灾实现运行。在容灾端，应用平台能够顺利运行并对委办局核心业务提供服务。阶段D为运维阶段。到本阶段前，数据及应用同步已经建立，异地数据容灾的目标已经实现。运维阶段主要任务是做好日常监控和管理，保障容灾系统的正常运行。阶段E为灾难切换阶段。本阶段的工作不属于日常范畴，仅在发生地域级灾难后，异地数据容灾中心发挥作用，为发生灾难的地域提供复制的数据，协助省厅恢复数据，或是实现核心业务的接管。749.投资估算9.1.投资估算的说明项目投资包括如下部分：\uf0d8容灾网络链路租赁费用；\uf0d8容灾平台硬件设备建设费用；\uf0d8容灾平台软件授权费用；\uf0d8对原有生产业务的改造费用；\uf0d8容灾平台建设系统安装实施费用。9.2.投资估算经初步估算，本项目总投资xx万元，其中，建筑工程费xx万元，软硬件设备购置费xx万元，工程建设其他费xx万元，预备费xx万元。项目资金拟全部申请xx市财政投资解决。投资估算汇总表序号建设内容费用估算备注（万元）一期建设内容--同城灾备中心建设一工程建设费1.1同城灾备中心数据集中备份系统1.2同城灾备中心数据库容灾系统1.3同城灾备中心云计算平台容灾系统751.4同城数据存储容灾系统1.5同城容灾备份中心机房改造1.6同城灾备中心网络系统1.7同城灾备中心安全系统二项目建设其他费用2.1前期咨询费计价格[1999]1283号,含项目建议书、可研2.2招标计价格[2002]1980号2.3初步设计计价格[2002]10号2.4环评费计价格[2002]125号2.5监理费发改价格[2007]670号2.6前期评估费计价格[1999]1283号,含项目建议书、可研三项目预备费项目建设工程费用5％二期建设内容四工程建设费4.1异地容灾中心--应用级容灾4.2异地容灾中心--数据备份系统五项目建设其他费用765.1前期咨询费5.2招标5.3初步设计5.4环评费5.5监理费5.6前期评估费六项目预备费项目建设工程费用5％总投资9.3.估算编制依据前期研究及可行性报告编制费根据国家计委《建设项目前期工作咨询收费暂行规定》(计价格[1999]1283号)的有关规定计算；招标代理费根据《招标代理费用收费管理暂行办法》（计价格【2002】1980号）进行计算；初步设计费根据《工程勘察设计收费管理规定》(计价格[2002]10号)进行计算；节能评估费根据国家计委《建设项目前期工作咨询收费暂行规定》(计价格[1999]1283号)的有关规定计算。9.4.资金来源与落实全部建设资金申请XX市政府投资解决。779.5.投资估算明细表序号项目配置要求单位数量1',)