智慧电子政务云-容灾建设方案

1、电子政务云整体解决方案 智慧电子政务云容灾建设方案目 录 TOC o 1-3 h z u HYPERLINK l _Toc528863898 第一章电子政务云概述 PAGEREF _Toc528863898 h 1 HYPERLINK l _Toc528863899 1.电子政务云发展背景 PAGEREF _Toc528863899 h 1 HYPERLINK l _Toc528863900 2.业务需求分析 PAGEREF _Toc528863900 h 3 HYPERLINK l _Toc528863901 3.项目建设的必要性 PAGEREF _Toc528863901 h 5 HYPE

2、RLINK l _Toc528863902 第二章电子政务云设计方案 PAGEREF _Toc528863902 h 8 HYPERLINK l _Toc528863903 1.总体设计方案 PAGEREF _Toc528863903 h 8 HYPERLINK l _Toc528863904 1.1电子政务云总体架构 PAGEREF _Toc528863904 h 8 HYPERLINK l _Toc528863905 1.2电子政务云部署架构 PAGEREF _Toc528863905 h 10 HYPERLINK l _Toc528863906 1.3电子政务云技术架构 PAGEREF

3、_Toc528863906 h 13 HYPERLINK l _Toc528863907 1.4电子政务云网络分区 PAGEREF _Toc528863907 h 15 HYPERLINK l _Toc528863908 1.5电子政务云运营架构 PAGEREF _Toc528863908 h 16 HYPERLINK l _Toc528863909 2.容灾中心详细建设内容 PAGEREF _Toc528863909 h 17 HYPERLINK l _Toc528863910 2.1容灾的核心技术及选择 PAGEREF _Toc528863910 h 17 HYPERLINK l _Toc

4、528863911 2.2容灾建设方案 PAGEREF _Toc528863911 h 23 HYPERLINK l _Toc528863912 第三章项目管理和实施 PAGEREF _Toc528863912 h 33 HYPERLINK l _Toc528863913 1.项目管理方案 PAGEREF _Toc528863913 h 33 HYPERLINK l _Toc528863914 1.1项目管理原则 PAGEREF _Toc528863914 h 33 HYPERLINK l _Toc528863915 1.2项目开发工作总结制度 PAGEREF _Toc528863915 h

5、33 HYPERLINK l _Toc528863916 1.3项目进度管理 PAGEREF _Toc528863916 h 34 HYPERLINK l _Toc528863917 1.4项目成本管理 PAGEREF _Toc528863917 h 35 HYPERLINK l _Toc528863918 1.5项目风险管理 PAGEREF _Toc528863918 h 35 HYPERLINK l _Toc528863919 1.6项目的需求变更管理 PAGEREF _Toc528863919 h 36 HYPERLINK l _Toc528863920 1.7项目的交流制度 PAGER

6、EF _Toc528863920 h 38 HYPERLINK l _Toc528863921 1.8项目的奖惩制度 PAGEREF _Toc528863921 h 38 HYPERLINK l _Toc528863922 1.9项目实施的安全管理 PAGEREF _Toc528863922 h 38 HYPERLINK l _Toc528863923 2.项目质量控制方案 PAGEREF _Toc528863923 h 39 HYPERLINK l _Toc528863924 2.1质量控制目标 PAGEREF _Toc528863924 h 39 HYPERLINK l _Toc52886

7、3925 2.2质量控制保证 PAGEREF _Toc528863925 h 39 HYPERLINK l _Toc528863926 2.3质量控制措施 PAGEREF _Toc528863926 h 40 HYPERLINK l _Toc528863927 3.项目运维管理方案 PAGEREF _Toc528863927 h 42 HYPERLINK l _Toc528863928 3.1综合运营平台运维体系 PAGEREF _Toc528863928 h 42 HYPERLINK l _Toc528863929 3.2基础设施管理 PAGEREF _Toc528863929 h 43 H

8、YPERLINK l _Toc528863930 3.3运营项目管理 PAGEREF _Toc528863930 h 45 HYPERLINK l _Toc528863931 3.4测试项目管理 PAGEREF _Toc528863931 h 46 HYPERLINK l _Toc528863932 3.5云服务项目管理 PAGEREF _Toc528863932 h 48 HYPERLINK l _Toc528863933 3.6事件管理 PAGEREF _Toc528863933 h 48电子政务云概述电子政务云发展背景随着近年信息技术持续迅猛发展，公众对政府管理与服务模式变革的期望急剧攀

9、升，各国电子政务建设面临极大挑战。电子政务方面走在前列的国家积极制定和出台新的发展战略和设施计划，如美国“开放政府”行动、“数据中心整合”行动；英国的“智慧政府”战略和ICT战略；澳大利亚的“Government 2.0”战略规划等。其共同特点是体现集约高效、开放共享的发展方向，代表了电子政务发展的最新趋势。我国电子政务建设历史可追溯到20世纪80年代中期，至今经历了3个发展阶段：20世纪80年代的起步阶段、90年代的重点推进阶段和2000年后的加速发展阶段。20世纪80年代以来，我国政府投入了万亿元巨资推进信息化建设，特别是“两网、一站、四库、十二金”等大型项目的建设实施取得了显著成效，在联

10、合国开展的电子政务调查中，我国在世界范围内的排名逐年上升，电子政务发展水平呈现出较好的发展趋势。国家电子政务总体框架（2006）的发布进一步推动了我国电子政务建设的整体发展进程和各部门的电子政务发展。我国主要地区电子政务建设正从覆盖政府业务阶段向与政府业务融合、全面支撑服务型政府建设阶段过渡。从基础电子政务网络而言，中央级传输骨干网开通，国家电子政务外网投入运行，促进了全国范围内横向和纵向电子政务网络的互联互通。从电子政务应用而言，中央政府门户网站和各级政府网站建立并提供对外一站式服务，进一步推进了政务公开和政府与公众的广泛互动。政务信息系统建设覆盖各领域各部门，为政务部门履行“经济调节、市场

11、监管、社会管理、公共服务”等职能提供了重要支撑。电子政务安全体系建设方面，公安部等四部委联合出台信息系统等级保护有关技术标准和规范、国家保密局出台涉密信息系统分级保护的有关技术标准和规范，围绕信息系统建设的信息安全保障工作正在逐步健全和完善。电子政务系统规划与顶层设计是新生事物，在国内没有成熟的案例供借鉴，各地区的发展不平衡，国家电子政务总体存在的共性问题：单项规划好、整体规划差；表面应用好、基础标准差；纵向应用好、横向整合差；独立应用好、一体应用差；国外应用好、国产应用差；非密应用好、涉密应用差。总体上地方电子政务还是传统的离散型、项目建设式的发展方式，需向集约化、效能化的发展方式转变。“十

12、二五”期间，地方电子政务需要围绕政府职能转变、管理创新和经济发展方式转变的要求，全面转变电子政务发展方式。重点由传统的办公自动化系统，转向民生服务、社会管理和决策支持类信息系统，服务方式由面向政府和领导，向部门管理对象、行业以及辖区内公民转变，管理方法从自建自营向统一规划、统筹建设转变，推进方式从基本建设工程项目实施向政府预算基本支出和绩效评价转变。今后电子政务新系统将从无序规划、建设与应用向“统一规划、统筹整合、统一标准、技术复用、互联治理、规范建设、信息共享、自主创新”转变，这将成为我国电子政务发展的新趋势。从技术发展趋势上看，随着智慧城市、智能社区、云计算/存储服务、绿色数据中心、3G通

13、信、微博等新技术与社会经济活动的深度融合，全国各地正在以移动政务、云计算、物联网、绿色数据中心作为电子政务技术创新的主攻方向。业务需求分析电子政务发展急切转型在当前智慧城市建设背景下，对电子政务建设提出了更高的要求，促使电子政务建设朝着集约型、合作化建设方向发展，推动服务型、智慧型政府建设。一是电子政务建设模式转型。当前各级政府的信息化系统建设大多处于粗放式发展阶段，各部门各自为政，各自提出基于部门职能的系统建设要求，分散投资、分散建设，缺乏以区域为单位、着眼全局的统筹规划。由于分散购置、分散管理，设备与投资不能共享，业务系统难以形成规模，整体使用效率很低，资源浪费严重。二是电子政务运维模式转

14、型。目前各部门分散的运维管理导致了较高的人员、技术需求，产生高运维成本，在智慧城市建设背景下，当前项目的运维模式变得不可持续。三是电子政务业务内容转型。电子政务建设将从以部门职能建设向以公共服务为主、寓管理于服务的电子政务转型。以公众为中心的电子政务服务需要更多考虑公众的需求，打破原有基于部门职能分工的组织体系，实现数据、渠道、服务的有效整合，满足公众的个性化、一站式服务需要。基础设施资源亟需扩展在当前大数据时代下，文本、音频、视频等非结构化政务数据规模急剧增长，各单位现有的网络、计算和存储等硬件基础设施已无法满足当前智慧应用的需求，成了制约应用系统运行效率的瓶颈。一方面是存储设备需要扩展。对

15、于某些需要实时存储信息的应用系统，其1年存储量超过200TB。对于综合智慧应用项目建设，预计未来两年存储量达到PB级。当政务数据量接近存储能力极限时，各应用系统会无法充分发挥其设计功效。另一方面是计算资源需要扩展。在存储大量政务数据的同时，各应用系统需要对所存储的政务数据进行处理、分析。数据融合共享迫在眉睫数据是电子政务云计算中心的核心资源，也是未来各大智慧应用发挥功效的驱动力。由于各部门政务系统相互独立，缺乏整体布局，制约我市智慧城市建设。一是需要建立统一的数据架构体系。人口、法人、自然资源和空间地理等基础数据库建设正逐步完善，但各基础数据库仍相互独立，即使在独立的法人及人口基础数据库的内部

16、，来自各部门的数据也未能形成有效的关联关系。除基础数据库之外，还有大量政务数据分散在各职能部门，没有实现集中部署和标准统一，电子政务数据交换逻辑架构体系非常复杂。二是需要促进数据全面深入有效融合。现阶段，全市各部门只利用数据交换平台实现政务数据交换，政务数据分散且独立，数据的准确性和完整性无法保证，没有形成全市电子政务数据深入融合，未能发挥政务数据的功效。只有在数据融合的基础上，才能有效的针对应用主题进行数据挖掘，获取数据背后深层次的信息，为市领导对城市综合重大事项进行决策参考时提供辅助支撑。三是需要制定数据交换共享保障措施。目前,我市电子政务数据交换仅是靠部门需求推动，没有形成固定数据交换共

17、享机制，往往某个部门需要的数据无法获取或获取的数据不准确、不完整，大大影响数据需求部门应用系统建设。二次开发渠道仍需拓展当前许多职能部门提供了基于各自部门职能的应用服务，但是大多数应用是完全封闭的，限制了应用系统的功效。目前需要各应用系统开放部分系统二次开发工具及服务，供其它部门使用，方便其它部门应用系统建设，减少重复投资和浪费。应用系统建设还需丰富当前，随着智慧城市热潮的驱动下，各级省市建设了大量信息化应用系统，也都发挥了相当作用，但现阶段城市发展加快，政府职能转型加速，涌现许多新的政务服务职能，因此衍生出一些新的业务需求，促使各职能部门要新建符合当前职能的信息化工具和应用系统。项目建设的必

18、要性电子政务云是在全国智慧城市建设逐步推进的大环境下，适合各级省市实际情况，运用云计算架构建立的一个具有基础性、公共性的电子政务服务平台。建设电子政务云，对突破电子政务发展体制性障碍、提高政府行政能力、降低行政成本、提高电子政务安全保障能力及推进智慧城市建设等方面都具有十分重要的意义。有利于推动电子政务的统一建设云计算集中建设、统一服务的核心理念，有利于突破部门职能分割造成的条块分割的体制制约，有利于推广统一建设的模式。云计算的建设和服务架构，能将城市所有的业务管理与服务系统纳入一个统一的系统框架，真正实现“一盘棋”效应，改变传统管理体制下各自为政的局面，打破“信息孤岛”，为建立新的开放式、交

19、互式、协同式城市管理与民生服务格局提供信息化技术支持，从而有效提高政府机关的整体工作效能。有利于提升电子政务安全保障能力云计算的技术架构更加健全，它综合运用多种安全手段和容灾备份手段，具有高度容错机制，可以实现严格、有效的控制、配置与管理，使系统的连续性和数据的安全性更有保障。建设统一的政务云计算中心，将在全省范围统一部署数据中心的软硬件和数据资源，并统一部署安全设施，将更有利于集中力量，提高安全部署等级，采取完备的安全策略，配备强大的专业队伍，从而有效提高电子政务的整体信息安全保障能力。有利于降低电子政务的总体成本电子政务分散建设模式存在建设费用大、维护成本高和资源利用率低等问题，而云计算通

20、过资源整合、统一管理和高效的资源流转，可以有效降低电子政务的成本。一是降低投资成本。云计算模式将以往的分散建设变成集中建设，最大限度地实现资源共建共享，相对传统的数据中心，硬件投资至少下降30%以上。同时，通过分时共享或者分区共享可使同样的资源发挥更大的作用，将资源的有效负载提高2倍以上，有效降低设备的投资规模。二是降低日常运营成本。云计算可以实现有效的绿色节能，将空闲的资源关闭或转入节能模式，经过实际验证，这种节能模式可以节约电能70%，同时，电力、制冷、空间和带宽等成本通过资源集中化可以得到大幅度的降低。三是降低管理维护成本。云计算通过资源集中和统一管理，降低了各部门的日常维护工作，大量的

21、工作都转移到后台专业人员完成，从而有效降低了管理维护成本。有利于有效提高电子政务的效能政务云计算中心的核心是在技术层面构建了统一的政府底层信息技术基础结构，基于云计算的服务给电子政务提供了一个崭新的管理模式，可促进现有政府行政管理职能的一体化融合和服务体系的高效整合，提升政府管理服务能力。在政务云计算环境下，政府将通过管理手段的革新，不断调整行政职能、组织结构、决策方式、管理行为、运行模式和工作流程，及时创造、收集、分析、利用、传播和发送信息，切实提高政府管理水平和工作透明度，为政府服务民众、促进经济发展和社会和谐提供重要的技术保障。有利于布局智慧城市建设智慧城市是以多行业、多应用、复杂系统组

22、成的综合体，需要强大的信息处理中心进行各类信息的处理，其中电子政务是这个复杂体系的核心。随着智慧城市的发展，业务应用和数据正从分散部署走向大集中，单纯的交换方式的互联互通已不能满足流程整合后的业务持续发展需求。而政务云计算中心具备传统数据中心、单应用系统无法比拟的优势，在应用方式、信息内容获取和数据开发利用上更具便捷性和智慧性，将加快消除信息“孤岛”及利益、技术“壁垒”，真正实现数据和应用物尽其用、协调发展，有利于布局智慧城市建设电子政务云设计方案总体设计方案电子政务云总体架构电子政务云建设总体架构设计如下图所示：图: 电子政务云建设总体架构设计图基础设施层：提供基础的计算、存储、网络服务；服

23、务于只希望共享计算、存储、网络的项目，这个服务主要针对原有已建成系统的迁移，在这个层次上，除了可享受基础资源的虚拟化服务外，还通过资源的池化，实现资源的动态分配、再分配和回收。基础设施层资源池主要包括计算资源池、存储资源池和网络资源池，为上层软件和数据等资源池提供支撑。信息资源层：利用数据共享交换平台，构建全市统一的数据融合服务枢纽，通过数据的比对、处理、融合和共享，为全市智慧应用、综合管理服务系统、产业经济管理服务系统及各委办局的专业应用提供统一的数据支撑。应用支撑层：主要提供应用开发、测试和运行的平台。通过应用支撑层用户可以进行应用的快速开发、测试和部署运行；依托于云计算基础架构，把基础架

24、构资源变成平台环境提供给用户和应用；为业务信息系统提供软件开发和测试环境，同时可以将各业务信息系统功能纳入一个集中的SOA平台上，有效地复用和编排组织内部的应用服务构件，以便按需组织这些服务构件。应用层：面向各委办局单位提供软件服务，通过迁移或者新建项目部署在电子政务云里面进行托管，各终端客户更多精力对各自业务范围和流程进行梳理，用户通过使用客户端，例如使用浏览器来访问所需软件。在电子政务云建设的过程中，软件即服务层的建设是一个逐步开发完善的过程。电子政务云管理规范体系：电子政务云的良好运营需要管理规范和技术标准体系进行保障。云计算中心的管理规范涉及到对云计算中心基础设施的维护、对数据的管理、

25、对应用系统开发的监管、对运维体系的管理、对应用系统效果的评价等方面；而技术标准体系包括了云计算中心基础设施、数据和应用的标准规范。电子政务云运营运维体系：为保障政务云计算中心的正常运行，提供资源管理、调度管理、监控管理等运维功能，以及业务管理、流程管理、订单管理等运营功能以及相应的组织制度保障措施。门户Portal包括运维管理门户和运营管理门户，是电子政务云对外提供服务的界面。电子政务云部署架构电子政务云部署架构如下图：图：电子政务云整体架构依据电子政务云建设的总体需求，勾画项目的整体部署架构，指导项目整体建设。电子政务云部署架构主要包括几个层面：计算资源池建设、云运营管理区建设、数据库区建设

26、、存储资源池建设、大数据处理区建设、备份区建设等。从整体架构来看：计算资源池可以基于支撑的上层电子政务业务应用的不同特性及对于接入网络安全性的不同需求，计算资源池可以分为：政务应用云资源支撑区：主要通过虚拟化的方式，以虚拟机的形态支撑电子政务应用，如：政务信息管理系统、信息报送系统、政府协同办公平台等电子政务应用系统。在政务应用云资源支撑区里，可以再根据电子政务应用在处理数据类型、业务方式以及对网络需求等方面区分为不同的业务应用资源区，未来随着政务信息化发展，业务系统增加，资源区之间可以实现线性扩展，资源区内部也可以实现线性扩展。大数据应用资源支撑区：主要通过虚拟化的方式，以虚拟机的形态支撑大

27、数据分析处理类前端应用系统，如：公共交通运力分析系统、全市居民健康状况分析系统等。DMZ区：主要通过虚拟化的方式，以虚拟机的形态支撑Web发布类的相关应用系统。计算资源池构建主要采用高端多核心X86服务器作为服务器基础支撑，通过虚拟化技术实现底层物理资源的虚拟化，通过云运营管理中心进行虚拟机的创建、动态分配、迁移及管理，形成统一的计算资源池。云运营管理区基于HA架构建设，通过部署云操作系统，实现底层虚拟化的管理，实现云计算资源的运营以及云计算服务门户建设。数据库区建设主要采用物理机支撑，因为要考虑电子政务云计算的安全性、可靠性及重要性，而且能够保证整个数据库的稳定、高I/O吞吐和访问。数据库区

28、主要通过高端X86高性能服务器通过集群技术进行部署，支撑电子政务外网和内网相关业务数据的存储和管理。存储资源池基于不同的数据类型采用差异化的资源池方式建设，数据类型主要包括结构化数据和非结构化数据。针对结构化的重要业务数据主要通过Oracle/DB2/SQL Server/MySQL等数据库进行数据管理，结构化数据存储利用统一云存储来支撑，在未来需要对存储容量进行扩展时可方便的横向纵向扩展；非结构化数据采用分布式存储系统来支撑，虚拟机的镜像数据也存放在分布式存储系统中，通过多副本机制实现数据的安全可靠，通过高性价比的组成部件实现系统整体TCO的降低，通过线性扩展特性实现随着系统数据节点增加系统

29、性能也随之线性增加，整个系统不存在性能瓶颈。大数据处理区实现海量结构化和非结构化数据的统一分析处理，通过对导入系统中的电子政务相关数据进行挖掘分析处理，提供对上层计算资源池大数据应用支撑区中运行的相关大数据处理业务系统的支撑。备份区通过构建软硬一体化的数据备份系统，通过设置灵活的备份策略对关键数据库系统数据、业务数据等进行备份，可避免数据逻辑错误。电子政务云技术架构图：电子政务云技术架构电子政务云技术架构设计如上图，整个架构从下往上包括云计算基础设施层、云计算平台资源层、云计算业务数据层、云计算管理层和云计算服务层。其中：云计算基础设施层：主要包括云计算中心的物理机房环境。云计算平台资源层：在

30、云计算中心安全的物理环境基础上，采用虚拟化、分布式存储等云计算技术，实现服务器、网络、存储的虚拟化，构建计算资源池、存储资源池和网络资源池，实现基础设施即服务。云计算业务数据层：主要为实现业务数据的安全存储，同时针对云平台的各个虚拟机镜像数据和模板数据进行共享存储，推动虚拟机的动态迁移和数据的迁移；实现部门间数据共享与交换；实现业务应用接入。云计算管理层：在云基础设施的基础上，为了实现动态资源池的构建，通过虚拟化技术对基础设施（网络、服务器和存储设备等）进行资源池化，通过自主可控的云计算操作系统，实现云计算中心的服务管理及业务管理的统一管理，提高运维及运营的效率。云计算服务层：是云计算中心与最

31、终用于交互的接口和平台，通过该平台能够实现云计算中心统一对外提供服务，为客户人员提供整体的云应用和服务。电子政务云通过统一的云计算平台对外提供服务。电子政务云网络分区图：电子政务云网络分区架构电子政务云建设基于以物理分区为基本单元的设计理念，整个云计算中心可分为：核心交换区、管理区、DMZ区、业务应用区以及云存储区。其中：核心交换区：负责网络交换。DMZ区：考虑云计算中心整体安全性，设置专门的DMZ区，承载各业务部门的业务应用系统的WEB发布，同时支撑云计算中心互联网的接入，该区可采用全虚拟机进行支撑。业务应用区包括三部分：数据库逻辑分区、政务应用云资源支撑区和大数据应用资源支撑区。其中：数据

32、库分区主要建设支撑各应用系统的结构化数据数据库，考虑到数据库数据量的庞大和系统对数据的访问I/O吞吐，该区建议采用高端物理机进行支撑；政务应用云资源支撑区和大数据应用资源支撑区采用虚拟化支撑，根据业务部门的不同业务需求决定相应虚拟机的规格。未来，随着电子政务云业务量增加和复杂度增加，可以按照相同的架构进行节点的扩展，达到整个政务云平台的可扩展性和伸缩性。电子政务云运营架构图：电子政务云运营架构整个云计算中心设计采用业务区域的理念。业务区域（即以服务器集群为核心的物理资源区域，不同的业务区域设备配置可以不同）是系统的基本硬件组成单元，整个系统共包括若干个业务区域。系统规模的扩大可以通过增加业务区

33、域方式，使得整个系统具有很好的可扩展性。业务区域的业务网络交换机通过万兆方式上联到核心交换区，通过核心交换区与其他业务区域和域外系统互联。在每个业务区域内，通过云运营管理中心的云计算运营中心节点实现在X86业务节点上部署Hypervisor，并形成一个或多个独立的逻辑资源池，提供给应用使用；通过云计算虚拟化管理中心在逻辑资源池内可实现资源的共享和动态分配。每个业务区域包括：云计算虚拟化管理中心节点、业务节点、业务网络、管理网络、心跳网络、本地镜像存储；业务区域根据各自的业务需要访问FC存储或并行存储等业务数据存储区域。云计算平台配置多台云计算服务门户节点，为最终用户的系统管理员提供自助门户服务

34、。采用以上设计理念，使得整个系统具有超高的可扩展性，可使整个系统扩展到上千台物理服务器规模。容灾中心详细建设内容容灾的核心技术及选择容灾系统是指在相隔较远的异地，建立两套或多套功能相同的IT系统，互相之间可以进行健康状态监视和功能切换，当一处系统因意外(如火灾、地震等)停止工作时，整个应用系统可以切换到另一处，使得该系统功能可以继续正常工作。容灾技术是系统的高可用性技术的一个组成部分，容灾系统更加强调处理外界环境对系统的影响，特别是灾难性事件对整个IT节点的影响，提供节点级别的系统恢复功能。容灾系统衡量指标衡量容灾系统的主要指标有RPO（灾难发生时允许丢失的数据量）、RTO（系统恢复的时间）、

35、容灾半径（生产系统和容灾系统之间的距离）以及ROI(容灾系统的投入产出比)。RPO是指业务系统所允许的灾难过程中的最大数据丢失量（以时间来度量），这是一个灾备系统所选用的数据复制技术有密切关系的指标，用以衡量灾备方案的数据冗余备份能力。RTO是指“将信息系统从灾难造成的故障或瘫痪状态恢复到可正常运行状态，并将其支持的业务功能从灾难造成的不正常状态恢复到可接受状态”所需时间，其中包括备份数据恢复到可用状态所需时间、应用系统切换时间、以及备用网络切换时间等，该指标用以衡量容灾方案的业务恢复能力。容灾半径是指生产中心和灾备中心之间的直线距离，用以衡量容灾方案所能防御的灾难影响范围。容灾方案的ROI（

36、Return of Investment，投入产出比）也是用户需要重点关注的，它用以衡量用户投入到容灾系统的资金与从中所获得的收益的比率。显然，具有零RTO、零RPO和大容灾半径的灾难恢复方案是用户最期望的，但受系统性能要求、适用技术及成本等方面的约束，这种方案实际上是不大可行的。所以，用户在选择容灾方案时应该综合考虑灾难的发生概率、灾难对数据的破坏力、数据所支撑业务的重要性、适用的技术措施及自身所能承受的成本等多种因素，理性地作出选择。容灾级别按照容灾系统对应用系统的保护程度可以分为数据级容灾、应用级容灾和业务级容灾。 数据级容灾仅将生产中心的数据复制到容灾中心，在生产中心出现故障时，仅能实

37、现存储系统的接管或是数据的恢复。容灾中心的数据可以是本地生产数据的完全复制（一般在同城实现），也可以比生产数据略微落后，但必定是可用的（一般在异地实现），而差异的数据通常可以通过一些工具（如操作记录、日志等）可以手工补回。基于数据容灾实现业务恢复的速度较慢，通常情况下RTO超过24小时，但是这种级别的容灾系统运行维护成本较低。应用级容灾是在数据级容灾的基础上，进一步实现应用可用性，确保业务的快速恢复。这就要求容灾系统的应用不能改变原有业务处理逻辑，是对生产中心系统的基本复制。因此，容灾中心需要建立起一套和本地生产相当的备份环境，包括主机、网络、应用、IP等资源均有配套，当生产系统发生灾难时，异

38、地系统可以提供完全可用的生产环境。应用级容灾的RTO通常在12个小时以内，技术复杂度较高，运行维护的成本也比较高。业务级容灾是生产中心与容灾中心对业务请求同时进行处理的容灾方式，能够确保业务持续可用。这种方式业务恢复过程的自动化程度高，RTO可以做到30分钟以内。但是这种容灾级别的项目实施难度大，需要从应用层对系统进行改造，比较适合流程固定的简单业务系统。这种容灾系统的运行维护成本最高。常见容灾建设模式当前，市场上常见的容灾模式可分为同城容灾、异地容灾、双活数据中心、两地三中心几种。同城容灾同城容灾是在同城或相近区域内（200KM）建立两个数据中心:一个为数据中心，负责日常生产运行;另一个为灾

39、难备份中心，负责在灾难发生后的应用系统运行。同城灾难备份的数据中心与灾难备份中心的距离比较近，通信线路质量较好，比较容易实现数据的同步复制，保证高度的数据完整性和数据零丢失。同城灾难备份一般用于防范火灾、建筑物破坏、供电故障、计算机系统及人为破坏引起的灾难。 异地容灾异地容灾主备中心之间的距离较远（200KM)因此一般采用异步镜像，会有少量的数据丢失。异地灾难备份不仅可以防范火灾、建筑物破坏等可能遇到的风险隐患，还能够防范战争、地震、水灾等风险。由于同城灾难备份和异地灾难备份各有所长，为达到最理想的防灾效果，数据中心应考虑采用同城和异地各建立一个灾难备份中心的方式解决。 两地三中心结合近年国内

40、出现的大范围自然灾害，以同城双中心加异地灾备中心的“两地三中心”的灾备模式也随之出现，这一方案兼具高可用性和灾难备份的能力。同城双中心是指在同城或邻近城市建立两个可独立承担关键系统运行的数据中心，双中心具备基本等同的业务处理能力并通过高速链路实时同步数据，日常情况下可同时分担业务及管理系统的运行，并可切换运行；灾难情况下可在基本不丢失数据的情况下进行灾备应急切换，保持业务连续运行。异地灾备中心是指在异地的城市建立一个备份的灾备中心，用于双中心的数据备份，当双中心出现自然灾害等原因而发生故障时，异地灾备中心可以用备份数据进行业务的恢复。双活数据中心所谓“双活”或“多活”数据中心，区别于传统数据中

41、心和灾备中心的模式，前者多个或两个数据中心都处于运行当中，运行相同的应用，具备同样的数据，能够提供跨中心业务负载均衡运行能力，实现持续的应用可用性和灾难备份能力，所以称为“双活”和“多活”；后者是生产数据中心投入运行，灾备数据中心处在不工作状态，只有当灾难发生时，生产数据中心瘫痪，灾备中心才启动。“双活”数据中心最大的特点是：一、充分利用资源，避免了一个数据中心常年处于闲置状态而造成浪费，通过资源整合，“双活”数据中心的服务能力是翻倍的； 二、“双活”数据中心如果断了一个数据中心，其业务可以迅速切换到另外一个正在运行的数据中心，切换过程对用户来说是不可感知的。在 “双活”的模式中，两地数据中心

42、同时接纳交易，技术难度很大，需要更改众多底层程序，因而在现实中，国内还没有真正“双活”数据中心的成功应用案例。容灾建设方案总体方案架构图 同城灾备数据中心架构从容灾层次上来说，本方案包括备份和容灾两个层次。其中备份（主要是数据备份）是指在专用的备份系统中保存多个历史点的生产数据，当生产数据因为人为误操作、病毒感染等原因出现逻辑故障时，可以从备份系统中选择合适历史点的数据进行恢复，备份的数据类型可以是常见的数据库这类结构化数据，也可以是操作系统、虚拟机镜像、文件和应用程序等这类非结构化数据，由于备份窗口的原因，数据备份的频率通常不会很频繁，通常为小时、天甚至是周级别。容灾是为了防止硬件故障、电力

43、中断、地震灾难等物理故障对业务系统所造成的应用中断，其最关键的技术就是数据复制技术。本方案数据复制分为结构化数据的复制和非结构化数据的复制两部分，其中结构化数据复制由支持异构数据库复制的数据库层复制技术实现，虚拟机镜像等非结构化数据的复制由存储层的技术实现。一、基于数据库复制技术的结构化数据容灾系统数据库系统的容灾方案，本方案建议采用支持异构数据库平台的成熟商业版软件实现，这类技术基于复制日志记录，实现各业务系统多个数据库在同城容灾中心的容灾、以及本地两个数据中心之间数据库的互备，保证结构化数据访问的连续性。这类技术实现数据库容灾的技术手段成熟，管理维护相对容易，没有操作系统和数据库版本的限制

44、，具有更好的兼容性。对于TB级数据库，其传输日志的带宽需求在10M以下，网络建设成本比较低。二、基于存储层数据复制技术构建非结构化数据容灾系统对于虚拟机镜像、应用程序等关键非结构化数据的保护建议采用存储层次的容灾方案，该方案建议基于高效的支持异构存储平台的存储层复制技术实现，这类技术基于存储虚拟化技术，利用存储虚拟化网关的数据镜像和数据复制功能，可以实现两中心多套异构磁盘阵列的互备，保证数据访问的连续性。同时，存储虚拟化网关可以整合其他厂商的磁盘阵列，通过这种技术，可以实现异构存储平台之间的数据迁移和数据复制，是构建复杂异构IT系统容灾方案的理想平台。数据库容灾系统设计对于数据库这类核心应用系

45、统，建议构建高级别的容灾方案。综合分析现有业务系统数据库应用情况，本方案建议采用成熟的商业版异构数据库复制软件构建数据库容灾方案。采用这类技术的数据库容灾产品的数据延迟可达亚秒级，处理数据能力高。支持广泛的异构数据库应用环境，源和目标数据库端的操作系统和数据库可以任意组合，支持一对一、一对多、多对一、双向复制等多种灵活拓扑结构，并且有完整的技术支持方案，是建立异构平台或异构数据库的容灾与应急备份方案、双活数据中心的唯一选择。结合容灾性能指标以及预算的情况，本方案建议在同城容灾中心新增1套（1台或多台）Standby数据库服务器，基于异构数据库复制技术实现多个数据库业务系统异构数据库平台到同城容

46、灾中心的集中容灾，同时实现同城灾备中心数据库系统到远程灾备中心和数据库远程容灾。对于各个业务系统的某一个数据库应用来说，当某个生产库出现故障时：如果生产库和容灾库同构，在理想情况下（数据完全同步且可用、容灾链路带宽充足、设备运行良好），可以在分钟级别切换到同城容灾数据库；如果生产库和容灾库异构，那么无法进行数据库切换操作，只能通过方向复制的方法把容灾库的数据恢复到生产库中。Standby数据库服务器的数据和配置可以低于生产数据库服务器，采用降级容灾配置方案，用于节省硬件平台的投资预算；可以先对几个关键业务实现数据库灾备保护，未来实现全业务数据库容灾。为了能够便于维护和管理、最少化投资，各业务系

47、统和同城容灾中心之间采用N+1模式的数据库容灾，同时，为了提升同城容灾中心数据库系统的可靠性和性能，同城容灾中心建议配置2台以上X86架构的高性能多路服务器组成数据库集群系统。各业务系统的多个异构Oracle、SQL Server数据库系统通过异构数据库复制软件实时备份到此数据库集群系统，从而达到了容灾的目的。系统拓扑参考图如下：鉴于建立同城容灾中心的目的是为了应用级别容灾，因此我们在同城容灾中心为各业务系统的多个核心应用建立了不同数据库用户，将各业务系统的各核心应用数据库数据复制到各自用户下的表中，一旦生产中心处于计划停机或非计划停机状态，同城灾备中心将接管生产中心的服务，保障业务的持续进行

48、。为了在集群环境下实现节点间的负载均衡，我们可以将生产中心的多个核心数据库应用划分为N（N=同城容灾中心数据库集群节点数量）个小组，每个小组传送过来的数据由数据库集群中的某个节点承担，从而实现数据库多节点共同工作完成所有业务系统数据的接收。 该方案的应用特点：N+1 灾备模式 各业务系统的多个业务的生产数据库分布在多套异构数据库系统中，使用异构数据库复制技术可以将多个业务的数据库集中备份到一套数据库备份系统，从而实现了 N+1 的备份模式，以较低的成本实现了容灾。N+1 模式区别于其它技术的特点在于其能够实现多个数据库数据向一个数据库的逻辑集中，从而使得同城灾备中心在一个库中对各业务系统相关数

49、据的进行查询和统计，为今后建立大数据平台和开展 BI 等业务创造了条件。 异构平台支持 在本方案中，各业务系统的生产数据库系统是异构的，项目所选技术支持异构数据库系统之间的数据复制。这种跨平台复制的特性降低了容灾中心的硬件投资，减少了后期管理和维护的成本。非结构化数据容灾系统设计对于虚拟机镜像、应用程序以及关键文档这类存储在多台异构磁盘阵列中的关键数据，本方案建议基于虚拟化技术的存储层的数据复制技术构建容灾方案。存储层数据复制技术支持数据镜像和数据复制技术，与上层应用无关，不占用上层应用服务器的资源，是应用最广、最成熟的数据复制技术，同时存储虚拟化技术可以屏蔽底层异构盘阵之间的差异，实现异构盘

50、阵之间的数据复制，便于存储系统的后期扩展，是构建异构平台双活数据中心、两地三中心数据灾备方案的理想选择。本方案建议在主生产中心、同城容灾数据中心新增一套具有存储虚拟化功能的双活存储系统，每个数据中心各放置一半的存储设备，双活存储系统是一种基于同步数据镜像技术的存储高可用技术，上层应用的每一次I/O操作会在两个数据中心之间的存储设备之间同步，任一扩展柜或是控制器出现故障不会影响上层应用的正常访问，可以实现数据近乎不丢失（RPO=0）。同时在远程容灾中心新增一套具有存储虚拟化功能的备份磁盘阵列，通过基于快照技术的数据复制实现同城容灾中心关键非结构化数据到远程数据中心的容灾，由于同城容灾中心和远程容

51、灾中心之间的距离较长，网络延迟较高，建议采用异步数据复制模式。当本地两个数据中心的双活存储系统同时出现故障时，可以从远程容灾中心实现数据的快速恢复（可能会丢失部分数据）。同步数据镜像模式对灾备链路要求较高，建议本地两个数据中心之间租用性能不低于4Gb的裸光纤链路连接，为了提高容灾链路的利用率，建议配置DWDM设备，实现存储层数据复制链路和上层应用数据链路的复用，从而减少容灾链路的投资。异步数据复制模式对数据带宽和延迟要求没那么严格，因此，同城和异地数据中心之间采用IP网络连接即可。为了保证容灾链路的冗余可靠，同城两个数据中心之间以及同城容灾中心和异地容灾中心之间的容灾链路配置2条。为了进一步节

52、省成本，远程容灾磁盘阵列的配置可以适当低于生产磁盘阵列。同城容灾中心和生产中心之间的数据容灾本方案同城容灾中心需要基于存储层的数据复制技术使用应用级容灾，为了实现该灾备目标，本方案建议把同城容灾中心和生产中心需要进行灾备保护的关键非结构化数据如虚拟机镜像、关键文档等集中迁移或存储到新增双活磁盘阵列中，这样可以提升存储系统的性能，减少存储虚拟化网关的数量进而节省投资。 利用存储虚拟化网关的同步数据镜像功能实现关键数据在同城容灾中心和生产数据中心的互备，构建双活存储系统，系统架构图如上所示。本方案在同城容灾中心和生产数据中心各部署1个存储虚拟化网关、1套存储设备、2套24端口FC交换机，两个中心之

53、间的存储虚拟化网关和存储设备通过FC交换机和桥接器组成高可靠的冗余存储网络；两个数据中心存储盘阵里的数据基于镜像技术实现实时数据同步，两个中心之间的任一控制器或是扩展柜出现故障，不影响前端应用的正常运行，任一中心的存储系统全部故障，也可以确保在很短的时间内将存储自动切换到另一中心。同城容灾中心和生产数据中心之间通过DWDM裸光纤实现FC存储和IP数据链路互通，存储虚拟化控制器同时支持FC、iSCSI和NAS存储协议，这样基于存储虚拟化技术实现的双活存储系统本身就具备了统一存储功能，可以为上层各种应用按需提供存储服务。同时，存储虚拟化控制器支持异构存储资源整合，后期用户新购的异构磁盘阵列可以通过

54、这套存储虚拟化控制器进行整合，形成统一存储资源池，便于后期扩展、管理和使用，并有效的提高存储资源率。两个数据中心的存储系统双活架构实现了存储服务与数据的热备（有两份实时同步副本），同时为了预防数据误删除的恢复、查看调用某个阶段的原始数据，以及应对一些灾难情况，本方案同时为存储虚拟化控制器配置快照功能进行数据备份。基于时间点的指针型数据快照技术，结合快照数据恢复软件可以显著节省备份时间和恢复时间，同时节省备份空间。基于快照技术实现的备份数据无需恢复，可直接挂接到主机上进行验证和分析。一体化集中备份系统考虑到人为误操作、病毒感染等操作所带来的数据逻辑错误，建议对各业务系统以及数据中心的关键数据做备

55、份保护，结合以上两种数据容灾方案，形成完善的数据保护体系。备份系统建议选择集备份软件、备份服务器和VTL功能于一体的一体化备份系统，无需考虑软、硬平台的兼容性问题，并且具有更好的性价比和服务。经过调研，在云计算中心建设完成后，大部分现有数据中心的业务系统迁移到云计算中心，这些业务系统的关键数据需要备份。未迁移到云计算中心的各业务系统同样也需要备份，本方案建议在同城容灾中心对这些业务的关键数据做集中数据备份。因此，本方案需配置2套一体化备份系统，其中一套放置在同城容灾中心，一套放置在生产数据中心。同城容灾中心的1套一体化备份设备用于实现对同城容灾中心关键数据的本地集中备份。放置在云计算中心的一体

56、化备份系统实现对迁移到云计算中心的业务的关键数据的本地集中备份。备份服务器上配置相应的数据备份功能模块，利用云计算中心一体化备份设备的数据拷贝功能将本地备份的数据拷贝到同城容灾中心备份服务器所连接的磁盘阵列里。备份网络需要租用运营商带宽或建设专网，并要根据网络状况和拷贝的数据量设置合适的时间点和策略。备份系统功能架构图如下所示。备份的数据可以是数据库、虚拟机镜像，也可以是操作系统和关键文件。支持LAN备份以及Lan-Free备份模式。对于关键数据备份频率可以设置为每周一次全备，每天做一次增量备份或是差异备份，本地局域网的带宽较大，可适当加大备份的频率。如果各业务系统或是本地生产数据出现人为误操

57、作或是不可恢复的硬件故障所导致的数据逻辑错误时，可以利用本地的备份数据进行恢复，取决于需要恢复的数据量以及容灾链路带宽，一般恢复操作需要数小时甚至数天。如果本地的备份数据同样出现逻辑故障，可以利用远程的备份数据进行恢复。项目管理和实施项目管理方案项目的组织和管理是保证一个项目实施成功的重要环节，对于项目更需要采用先进的项目管理手段。我单位在过去承接的大型软件开发项目中积累了丰富的项目管理经验，并不断汲取国内外先进的项目管理方法之优点，形成了特有的项目管理方式，在很多项目实施中得到用户的高度认可。我单位非常愿意在项目建设中充分发挥自身优势，从项目组织、软件开发、实施以及技术服务等各方面入手进行管

58、理，在保证项目质量的前提下，有秩序、按时、顺利的完成项目有关工作，并最终实现系统目标。项目管理原则本着责任明确、奖罚分明的原则，公司建立项目经理负责制，由项目经理作为项目的直接负责人，同时健全相应的审批制度及保密制度，从而构成以项目经理为核心，由QA审查和跟踪、公司总经理监督检查的项目管理体系。即：项目经理负责制的原则；各司其职、逐步评审的原则；责任明确、奖罚分明的原则。 项目开发工作总结制度项目开发组应该要求开发组成员每天对自己所做的工作进行总结、记录。这种记录可以用统一的表格进行填写，这种表格在每天结束工作前用三至五分钟迅速填一下，不需要很详细概要即可。这既可以培养开发组成员的严谨工作作风

59、，又可以使项目主管能够及时了解成员的工作进展，对成员所遇到的困难做出及时的支持和响应, 对整体进度作及时调整。 项目进度管理项目是否能够如期完成，项目的进度控制是一个关键环节。我单位在项目的开发过程中进行总体规划和各阶段详细任务划分；采用辅助工具MS Project制定项目开发计划和实施进度跟踪；形成项目甘特图和关键路径分析；在阶段性规划的阶段里程碑内部建立短期里程碑，短期里程碑的间隔不超过一周，对每个里程碑确定详细的任务，并跟踪该里程碑的实施。公开项目的规划和进度；项目的规划和进度指标列入变动控制。定期在开发组内部和向项目管理小组提供包括项目规划进度、进度跟踪信息、技术工作成果与项目成品在内

60、的项目信息。为保证给客户的承诺能够如期履行，在项目立项阶段，公司每个项目都会委任一个专职QA对项目进度等进行跟踪，所有项目都必须按照公司规范模板中要求的各项内容制定该项目的项目总体计划、质量保证计划、配置管理计划等，并经客户和公司技术管理委员会进行正式评审，评审通过后，各计划纳入基线库进行管理，并严格按照制定的相应计划执行，由该项目的QA进行跟踪控制。跟踪过程通过项目各阶段报告、项目例会、项目协调会等手段，切实了解项目进度，评估项目的进展情况及未按计划完成的原因，制定相应的行动方案，在必要时，由QA以QA报告的形式将有关问题提交公司总经理进行协调管理。具体使用的工具将包括：每周员工周报；每周项