级电子政务云计算中心-建设服务方案

1、省级电子政务云计算中心建设服务方案 目 录 TOC o 1-3 h z u HYPERLINK l _Toc524552045 第1章 建设目标、范围、任务 建设目标、范围、任务建设目标以国务院办公厅关于促进电子政务协调发展的指导意见为指导，统筹推进省电子政务基础设施提升、电子政务业务系统协同发展、信息资源共享共用和数据开放利用；按照湘府阅201553号文件要求，以资源整合、集约建设、稳步推进为原则，建成安全可靠、统一高效、国内领先的云计算平台并开展示范应用，为全省各级部门提供弹性的云计算和云存储能力、政务外网承载服务与应用能力，基本满足省直部门“十三五”期间非涉密业务的统一网络、计算资源、存

2、储资源、数据库服务、备份服务、安全服务等需求，提升政府效能，促进政府管理创新，达到简政、兴业、惠民的目标。建设范围省级电子政务外网主要满足各级政府部门社会管理、公共服务等方 面的需求，为各省直部门的非涉密电子政务业务提供承载服务。本次建设省级电子政务外网统一云平台，总体框架为“1+2+N”， 即“1网、2中心、N多应用云”，省本级政务大数据中心，初步形成“8+3+5”的基本框架。具体业务目标主要包括： “一个网络”优化升级电子政务外网平台，满足省直部门间以及省 到市、市到县网络传输和承载的需求； “两个中心”建设云计算中心、大数据中心，满足省直部门十三五期间非涉密业务需求，为政府领导提供科学、

3、合理的决策支持。 “N 朵应用云”建设基于云平台的 N 个全省性应用系统，包括政务 服务、政务管理、政务行业、政务决策和政务办公等领域。 “8大基础数据库、主题数据库”完成人口、法人、宏观、地理空间、政务服务信息、工商企业、信用信息、电子证照等8大基础数据库、主题数据库的建设、迁移、备份共享； “3大平台”完成大数据智能分析平台、数据交换和共享平台、数据开放平台3大平台； “5大示范工程”完成全省旅游大数据分析、12345服务平台、区域经济脸谱大数据分析、省互联网产业发展状况分析、省政府网站群智能监测分析5大示范工程；建设建设统一的安全体系；建设统一运维管理机制；设计迁移策略，完成部分系统的迁

4、移；明确云平台建设、管理、运营模式，节约投资，提升服务质量。建设任务充分考虑省级电子政务外网统一云平台计算、存储资源需求的阶段性和应用系统建设的复杂性，为了保证投资的有效使用，采用分期建设的原则。（一）第一期2016年1完成省电子政务外网的升级改造；2建设40%的计算、存储资源；3启动大数据中心建设；4启动N朵云建设。（二）第二期2017年1建设60%的计算、存储资源；2完成灾备中心建设；3完成大数据中心建设；4完成N朵应用云的部分建设。（三）第三期2018年-2020年1全面完成N应用朵云建设。其中，本期云平台基础设施部分的建设任务具体包括以下：完成省电子政务外网升级改造（含安全平台）；建设

5、主数据中心、同城双活数据中心40%的计算、存储资源，数据交换和共享平台；建设政府协同办公平台、政务安全邮箱；提供省政府门户网站群五年的运维服务；提供统一的运维管理服务（五年），确保本期建设的政务外网、安全体系、云计算中心安全稳定运行。省级云计算中心方案整体架构 （图示：数据中心架构设计）湖南政务云数据中心采用标准化、开放和高扩展的云计算架构，支撑省政府各部门的政务外网、互联网等多种不同业务服务。（1）网络资源设计：网络采用扁平化二层架构，分为核心层和接入层，提高性能，减少时延；网络大二层部署，保证虚拟机在资源池内部的热迁移能力；核心交换机旁挂负载均衡器，提供负载均衡增值服务；防火墙支持虚拟防火

6、墙能力，实现业务系统之间的安全隔离。外网服务区与互联网服务区之间网络通过部署数据交换平台实现不同业务域之间的安全隔离。（2）计算资源设计：采用标准化的X86物理服务器，构建计算资源池。采用OpenStack开放架构，支持Xen、KVM等主流虚拟化平台。X86服务器根据业务系统对资源的不同需求，配置不同的产品型号及物理配置，划分高性能计算区、通用性能计算区，分别作为虚拟化资源和物理机资源。（3）存储资源设计：多样化存储部署，满足不同业务系统的需求，降低存储的投资成本。对于数据库、VM文件系统采用FC SAN进行承载；对于非结构化数据、虚拟化镜像等数据存储，建议采用分布式文件系统存储承载，保障存储

7、性能和扩容能力。（4）业务云化设计：根据各政府部门业务对云资源的不同需求，以及业务云化的难度，分批逐步的将现网业务系统迁移至云服务商政务云，实现更多政务业务的云化。（5）云管理平台设计： 构建统一云管理平台，通过对政务云基础资源的抽象和资源池化，提供自助式的IaaS、PaaS、SaaS服务。政府客户可通过云管理平台统一门户自助申请云服务，并进行灵活的管理。同时，云管理平台也负责对政务云所有基础资源进行统一的运维管理。数据库平台方案数据库平台整体架构数据库平台设计如下：数据库计算资源池分为可横向扩展的物理群集和虚拟化群集，以满足不同性能的数据库要求；其中物理群集主要部署Oracle RAC、DB

8、2等高性能数据库，兼容其它数据库类型和版本（包括Oracle、DB2、SQL Server、Mysql以及国产达梦、金仓、Golden DB等），满足高性能的数据库服务要求；虚拟化群集通过虚拟化技术主要部署SQL Server、Mysql等数据库，主要满足性能要求不高，但灵活性比较高的数据库服务器要求；在底层存储数据同步提供跨主数据中心和同城双活数据中心的共享卷的基础上，各数据库跨数据中心站点建立群集，包括Oracle RAC,SQL Server alwayson群集等，实现数据库服务的同城双活或故障切换；通过波分设备建立独立的10Gb高性能通道，作为跨站点集群的心跳专用网络；关键业务数据库

9、群集Oracle RAC和SQL Server AlwaysOn，采用2+1部署，即主数据中心部署2个节点，同城双活数据中心部署1个节点。满足设备故障时的优先本地切换，以及减少跨站点的数据同步数据量；Oracle和SQL Server AlwaysOn等部署模式，支持同城双活中心节点作为只读节点，满足查询业务的处理要求，实现读写分离。数据库分类设计目前主流的数据库Oracle、DB2、SQL Server和 MySQL。特性OracleSQLserverMySQLDB2费用收费收费免费收费运行环境、开放性能在所有主流平台上运行（包括 Windows）。采用完全开放策略。只能在Windows上运

10、行，没有丝毫的开放性。能在所有主流平台上运行（包括 Windows）能在所有主流平台上运行（包括windows）。可伸缩性、并行性高可用性和高伸缩性。并行实施和共存模型并不成熟，伸缩性有限。较强的伸缩性，高并行性。具有很好的并行性安全性获得最高认证级别的ISO标准认证。没有获得任何安全证书。没有获得任何安全证书。获得最高认证级别的ISO标准认证。 性能性能最高。多用户时性能不佳。支持多用户操作，性能较高。性能较高适用于数据仓库和在线事物处理。适用场景多用户，数据量大的系统。少量用户。中小型网站。最适于海量数据的数据仓库从产品的兼容性、性能、安全性以及使用的广发程度来比较，Oracle、DB2等

11、是兼容性最好，性能最高，使用最广泛地数据库产品。因此建议高性能应用建议主要采用Oracle、DB2等数据库，并主要通过物理群集的部署模式承载。其它的性能要求不高的应用建议主要采用SQL Server、Mysql等数据库承载，采用虚拟化群集部署。数据库云部署方案本次数据库设计的目的主要是对各个省直部门提供高性能、高可靠性的数据库服务。根据当前实际情况，数据库池（或者数据库平台），需要能够支持当前主流的数据库（包括Oracle、DB2、SQLServer、Mysql以及国产达梦、金仓、GoldenDB等）以及其各种版本。支持在服务器池中透明部署数据库，从而提供对硬件故障或计划内停机的容错能力。由于

12、各用户所需的数据库量级或者功能、性能差别较大，故本数据库平台需要支持多种构建的方式，一是使用可横向扩展的物理机集群，以满足部分高性能应用对数据库的需求，二是通过虚拟化的方式进行数据库的搭建，以满足性能要求不高，但灵活度要求极高的数据库需求。数据库设计采用基于标准的x86的软、硬件架构，将多个数据库计算节点和存储节点高速的互联起来，在逻辑上形成一个集中式的、可扩展的数据库系统，并能够实现系统性能随节点的增加而呈线性上升。数据库平台需要具有绝对的可靠性，所有数据都实现100%冗余，确保数据安全；同时，如果云数据库中的某个或者某几个计算节点出现问题，可在3秒的时间内实现应用透明切换；某个或者某几个存

13、储节点失效，可以在线实现数据自动重新分布与重新冗余。支持数据备份和数据迁移，系统支持实时备份和定时备份，备份时能够将分布式数据库的存储数据、相关元数据以及其他分布式数据库运行必要数据备份到指定文件系统上。数据库恢复时，需要支持将数据恢复到备份时刻、指定时刻，数据恢复时需要能够保证数据一致性。所有数据库备份策略都要支持通过界面的形式进行制定。支持读写分离，提升读写效率主库和备库之间以同步方式来实现主库备库之间数据一致，当主库发生故障后，数据库前置中间件层自动路由到备库中；前置中间件层通过语法解析，可以自动识别业务提交的语句，是DML还是DQL语句。对于DML统一修改提交到主库，DQL查询负载均衡

14、到从库，提升系统资源利用率和查询效率；统根据负载情况及操作类型，尽可能的把写操作发送到主库、读操作负载均衡到从库，提高从库的利用率。数据库通过高速互联的专用网络组建，需要能够确保数据库的性能随节点的增加得以线性提升，在进行扩容的过程中，不影响现有的业务。数据库需要支持SQL92标准，包括DQL（数据查询语言）、DML（数据操纵语言）、DDL（数据定义语言）、DCL(数据控制语言）、TCL(事务控制语言)、常用函数、程序控制等。支持多租户。同时为多个业务提供数据存储服务，具备基本的多租户管理机制，保证多个业务间数据隔离、访问隔离、用户信息隔离。在这个新的架构中，单个多租户容器数据库可以托管多个“

15、可插拔”数据库。对于应用程序而言，每个整合或“插入”到多租户容器中的数据库感觉就和现有数据库一样。对可插拔数据库的访问与对现有数据库的访问一样，并且管理员可以控制所有整合数据库使用可用资源的优先级。数据中心的所有数据库，无论是生产、测试还是开发数据库，都将需要进行修补和升级。将多个可插拔数据库整合到一个多租户容器中，可以大大减少所需的修补和升级活动的数量。只需要在容器级应用补丁和升级，不需要对每个可插拔数据库应用补丁和升级。还可以灵活地创建新的修补和/或升级的容器数据库，可以有选择地将数据库从旧的容器数据库中拔出，然后插入新升级的容器数据库中。数据库管理员可以轻松复制生产数据库并将它们插入开发

16、和测试容器，如果底层文件系统支持写时复制（如 ZFS 文件、ASM 集群文件系统），那么可插拔数据库的克隆几乎可以实时进行。每个整合（即插入）到多租户容器中的数据库，不仅管理该特定数据库的元数据和数据，还保留了以前独立数据库的所有安全访问权限。虽然从独立数据库迁移到可插拔数据库后，应用程序用户继承了自己的访问权限，但是这些权限将不能用于访问容器中的其他可插拔数据库。本次设计的数据库平台，能满足根据实时负载与用户自己定义的阈值，进行弹性变化，根据需要增加或者减少节点。当某一用户的数据库负载较高时，通过自己定义的流程及软件开关，增加一个或者若干个实例；当其负载降低时，又能根据实际情况，减少若干个实

17、例。完善的分布式事务机制。不同于单机数据库的事务方案可以由数据库本身来保证，对于分布式数据库集群需要引入额外的机制来保证分布式事务的协调机制，保证各种场景下的数据一致性；要能够彻底解决分布式数据库可能引起的数据脏读问题；支持集群单节点故障时,系统自动重新路由数据及调整数据复制拓扑、备机接管、损坏节点自动退出服务。分布式事务相比较非分布式事务需要占用更多的资源，平台需要提供灵活的分布式事务控制机制，应用可以根据实际情况控制事务控制粒度，需要支持在系统级、会话级、事务级三个维度上进行事务控制。事务控制需要分读级别控制、写级别控制。在源系统和目标系统间移动事务时，保持事务提交边界和原子性、一致性、隔

18、离、持久性 (ACID) 等属性。确保主数据库、备份系统和报表数据库间的数据一致性和引用完整性。针对不同的数据库版本，本次数据库平台做不同的规划。根据需求调研了解到通常Oracle数据库作为主要的生产数据库，承载负荷较高的数据库服务，而其他的种类数据库，如Mysql、SQLServer等，承载负荷较低。本次规划中，数据库使用物理机集群的方式构建，通过动态调整资源以匹配压力，增加可靠性，同时降低管理难度。根据对现有数据库的调研，得出各个品牌数据库的数量和占比情况如下表。表6-2 现状表数据库品牌数量支持的操作系统授权方式授权数量DB21WindowsCPU数4DB21LinuxCPU数4SQL

19、Server10Windows用户数558SQL Server2WindowsCPU数19My SQL1WindowsMy SQL1LinuxORACLE7LinuxCPU数48ORACLE5Linux用户数136ORACLE3WindowsCPU数11ORACLE5Windows用户数57达梦1Linux金仓1表6-2 各品数库数和比情表品牌数量占比DB225%SQLSrver1232%MySQL25%ORACLE2053%达梦13%金仓13%总计38数据库集群，需要支持MPP架构，支持根据业务或者性能线性增加计算和存储节点。集群不应该存在单节点的故障瓶颈和性能瓶颈。设置独立的数据库运维管理

20、系统，该系统具备以下功能：1）查看各个网元的性能统计信息、链路状态信息、运行状态信息等；2)查看故障告警信息，比如节点宕机、服务异常、超时、断链等；3）查看分布式SQL操作的一些统计信息，如SQL语句的分布式执行计划。实现数据库集群与大数据系统的互联互通。提供云数据库服务，用户能够自助申请所需要数据库，数据库类型至少包括Oracle、MySQL、SQLServer，审批通过后数据库自动化部署，多套数据库可部署在同一台物理服务器上且能够保证数据库CPU、内存、网络IO、磁盘IO独享。多租户设计多租户架构数据库多租户是一个数据库中的单一实例服务多个用户的架构。每个用户称之为一个租户。租户们是逻辑隔

21、离，物理集成的。在一个典型的多租户数据库中，原本不 共享也看不到彼此数据的租户，在运行统一系统，使用统一硬件和存储系统时，就可以分享同一数据库。在云计算中，一个数据库服务（DaaS）提供者可以运行 一个实例并提供给对多个用户的访问。Oracle 多租户是 Oracle Database 12c 企业版的一个新选件， 它通过简化整合、供应以及升级等过程来帮助客户降低 IT 成本。Oracle 12c的多租户功能是一个高密度的Oracle数据库整合平台，它把一个单一的多租户容器数据库（CDB）当做很多的可插拔数据库（PDBs）使用。操作 系统会将一个物理CDB视为数据库，而用户或租户则会将一个虚拟

22、PDB视为数据库。一个容器数据库提供了将许多可插拔数据库作为一个数据库加以管理的能 力。在对独立数据库保持安全，隔离和资源控制的情况下可插拔数据库共享实例显示了容器数据库的SGA内存和后台进程：多租户架构（multitenant architecture）使得Oracle数据库可以作为一个包含0个、1个或者多个用户创建的可插拔式数据库（PDB）的多租户容器数据库（CDB）。PDB是一个模式、模式对象和非模式对象的便携式集合，以一个非CDB形式展现给Oracle Net客户端。Oracle Database 12c之前的数据库都是非CDB。容器（container）可以是一个PDB或者root容

23、器（也称为root）。Root容器是一个模式、模式对象和非模式对象的集合，所有的PDB都属于root。每个CDB都包含以下容器：一个root。Root包含Oracle提供了元数据和公用用户，例如Oracle提供的PL/SQL包的源代码。公用用户是每个容器中都可以使用的数据库用户。Root容器的名称为CDB$ROOT。一个种子PDB。种子PDB是系统提供的一个模板，可以用于CDB创建新的PDB。种子PDB的名称为PDB$SEED。用户不能添加或者修改PDB$SEED中的对象。零个或者多个用户创建的PDB。PDB由用户创建，包含支持特定特性的数据和代码。一个PDB可以支持一个特点应用，例如人力资源

24、或者销售。创建CDB时不会创建PDB，可以基于业务需求添加PDB。 下图显示了一个拥有4个容器的CDB：root，种子PDB以及2个PDB。每个PDB拥有自己专有的应用，并且由它自己的PDB管理员进行管理。一个公用用户在CDB中使用单个身份认证。在下例中，公用用户SYS可以管理root和每个PDB。在物理层，该CDB拥有一个数据库实例和数据库文件，与非CDB一样。数据库整合使用多租户技术后，可以将省级直属单位及下属单位的数据库迁移到省电子政务外网统一云平台。整合完成后，各单位的数据库都作为一个租户都托管到数据库平台。可靠性设计数据库层可靠性通过集群技术实现，在业界主要分为两种方式：A/S（Ac

25、tive-Standby）集群与A/A（Active-Active）集群。Active-Standby集群节点之间为主备部署，备节点只在主节点故障后进行故障切换。常见的主备集群系统如：IBM PowerHA、HP ServiceGuard、Microsoft WSFC、Veritas Cluster Server等。在主节点故障后，集群备节点将自动重新启动应用系统，无需管理员干预，即所谓的“故障切换(Failover)”。管理员需要提前在所有集群主备节点上部署集群软件，由集群软件控制文件系统的挂载，应用系统服务的启动，以及公网IP地址的配置。主备集群架构如下图所示：Active-Active集

26、群的多个集群节点可以同时运行同一项服务，可同时对外提供业务访问。采用Active-Active集群，不仅可以和主备应用集群一样提升应用系统的可靠性，更可以做到故障的无缝切换，而且可以提升应用系统整体性能。当前最典型、应用最广泛的Active-Active集群，是Oracle RAC(Real Application Cluster)集群系统。Oracle RAC集群是一种数据库集群，实现了多节点对数据库访问的动态负载分担。Active-Active集群架构如下图所示：Oracle数据库群集设计Oracle RAC简介Oracle Real Application Clusters (RAC)是

27、Oracle公司设计的一套Active-Active群集解决方案，能实现跨站点Oracle数据库服务的双活。它允许依托一组共享的数据文件（也称为数据库）在集群中的不同服务器上运行多个数据库实例。该数据库跨越多个硬件系统，但是在应用程序看来，它是一个统一的数据库。这样就能够利用商用硬件降低总拥有成本并为支持各种应用程序负载提供一个可伸缩的计算环境。Oracle RAC 是 Oracle 首要的共享磁盘数据库集群技术。Oracle RAC 体系Oracle RAC数据库要求首先在系统上安装Oracle Clusterware，然后再安装支持OracleRAC的数据库主目录。Oracle Clust

28、erware (OCW)是Oracle Grid Infrastructure(GI)产品套件的一个不可或缺的组成部分，该产品套件还包括自动存储管理(ASM)和Oracle云文件系统(CloudFS)。包含Oracle ASM/CloudFS和Oracle Clusterware的Oracle Grid Infrastructure以及包含Oracle Real Application Clusters(RAC)选件的Oracle数据库共同构成了Oracle RAC体系。Oracle ClusterwareOracle Clusterware是一种将服务器场转换为集群的技术。集群是一组独立但相

29、互连接的服务器，它们能够像一个系统似的协同工作。Oracle Clusterware是该系统中支持协同工作的智能所在。Oracle Clusterware作为运行Oracle Real Application Clusters(RAC)所需的底层集群软件，随Oracle Database 10g第1版而引入。作为OracleRAC体系的一部分，Oracle Clusterware还用于Oracle ASM集群版，并且紧密集成到Oracle RAC体系中。Oracle Clusterware作为一个全面的免费集群解决方案，也可在Oracle RAC以外的环境中使用。在这些环境中，通常使用Orac

30、le Clusterware来自动执行各种应用程序的资源布置、调整和管理。在两种环境中，Oracle Clusterware都负责维护节点的成员关系并确保其相互隔离。根据集群部署和管理需求，可通过以下三种方式之一来安装Oracle Clusterware 12c：1)标准集群（典型的Oracle RAC集群，其配置与Oracle Clusterware 12c之前的版本类似）；2)Oracle Flex Cluster （Oracle Clusterware 12c提供的一种新型集群拓扑，将传统的、紧密耦合的以及新型松散耦合的服务器组合到一个集群中）；3)应用程序集群（为非数据库应用程序定制的

31、一种优化部署）。Oracle 自动存储管理 (ASM)OracleRAC采用共享磁盘架构，因此卷管理和用于存储数据库数据的文件系统必须支持集群识别。Oracle自动存储管理(ASM)是为Oracle数据库推荐的（集群）卷管理器。OracleASM管理所有数据：Oracle数据库文件、OracleClusterware文件和非结构化数据，如二进制文件、外部文件和文本文件（通过OracleCloudFS进行管理）。凭借其较低的成本、便捷的管理以及较高的性能特性，OracleASM成为管理Oracle数据库存储的理想存储技术。为实现性能和高可用性目标，Oracle ASM遵循“全面条块化和镜像”原则

32、。通过智能化的镜像功能，管理员可以定义双向或三向镜像以保护重要数据。当读操作识别出磁盘上损坏的块时，Oracle ASM自动将有效的块从镜像副本重新定位到磁盘的未损坏部分。Oracle 云文件系统 (CloudFS)Oracle云文件系统简化并自动化存储管理功能，提高存储利用率、正常运行时间和敏捷性，从而可为所有通用文件和数据库文件提供可预测的性能和可用性。CloudFS包含集群卷管理器和集群文件系统：OracleASM动态卷管理器(ADVM)是针对OracleACFS和第三方文件系统的通用集群卷管理器。OracleASM集群文件系统(ACFS)是一个通用的与POSIX和Windows兼容的集

33、群文件系统，其中包含高级数据服务，如快照、复制、加密和安全性等。可靠性Oracle数据库以其可靠性而著称，OracleRAC消除了数据库服务器单点故障问题，从而使可靠性更上一层楼。如果一个实例发生故障，集群中的其余实例仍将保持正常运行状态。Oracle Clusterware监视所有Oracle进程，并能立即重启任何发生故障的组件。错误检测OracleClusterware自动监视OracleRAC数据库和其他Oracle进程（OracleASM、实例、监听器等），并快速诊断环境中的问题。它还经常能在用户察觉到故障之前自动完成故障恢复。恢复能力Oracle数据库包含的许多特性有助于数据库轻松地

34、从各类故障中恢复。如果Oracle RAC数据库中的一个实例出现故障，集群中的另外一个实例将察觉到这一故障，随后自动进行故障恢复。利用快速应用程序通知(FAN)、快速连接故障切换(FCF)，尤其是利用Oracle RAC 12c应用程序连续性特性，可轻松地掩藏任何组件故障，使用户无法察觉。连续运行可在计划和意外中断期间提供连续的服务。如果一个服务器（或实例）出现故障，数据库将保持运行，应用程序仍能继续访问数据，从而让业务关键型负载得以完成运行，而且多数情况下服务交付无延迟。大多数数据库维护操作无需停机即可完成，而且对用户透明。很多维护任务都可以滚动方式执行，因此可最大限度地减少应用程序停机，或

35、消除停机。全对等分布式架构针对云平台整体要求，数据库平台应采用全对等分布式架构，即在整个数据库集群中，不存在其故障可能影响整个集群安全的部分，如集中式的元数据管理部分。数据库中平台中的任何节点，无论是数据库节点还是存储节点，任意一个或有限个出现故障，都不会对整个数据库服务产生影响，即某个或者某些节点故障时，数据库集群仍能够对外提供服务。数据库平台需要实现多维度资源隔离，即：1）物理资源隔离各功能节点内部资源隔离，如多个数据库节点间资源隔离，每个数据库节点的正常操作或者异常状态，都不会影响到同一集群内的其他数据库节点。各功能节点间资源隔离，数据库节点与存储节点间资源隔离，即一个或者数个数据库节点

36、的正常操作或者异常状态，都不会影响到存储节点的服务状态；一个或者数个存储节点的正常操作或者异常状态，也不会影响到数据库节点的服务状态。2）逻辑资源隔离用户间资源隔离不同用户使用的数据库逻辑资源（如数据库实例），相互隔离，某个用户的操作，不会影响其他用户的正常使用。逻辑资源组隔离即实例或者实例组隔离，不同的实例与实例组在资源使用上相互隔离，某个或者某些实例进行创建、删除、启动、停止等操作或者出现异常、故障，都不会影响其他实例或者实例组使用的资源。数据库平台需要具备虚拟化平台的部分特性，根据用户的实际需要，数据库可以建立在物理服务器（集群）或者虚拟机服务器上，创建在虚拟服务器上的数据库资源，应具备

37、虚拟化平台要求的可靠性。Oracle RAC部署架构Oracle RAC以共享存储为基础，通过共享的存储资源，实现各节点对数据文件、重做日志文件、控制文件和参数文件的并行访问，且在单个节点出现故障时，业务能自动切换到正常节点，从而保证数据库系统正常可用。存储双活技术提供共享卷，将跨数据中心的存储以共享方式提供给上层应用访问，满足Oracle RAC的共享存储需求，实现跨数据中心的Oracle Extended RAC集群构建。Oracle Extended RAC集群配合Oracle监听器技术，可实现客户端在数据中心间业务双活访问和负载均衡；配合Oracle透明应用程序故障转移（TAF）技术，

38、当服务器或单数据中心故障时，使客户端能够在新的连接中继续工作，防止业务中断。Oracle RAC节点部署建议：在出现中间网络心跳链路故障时，Oracle RAC会采用如下的原则进行仲裁：拥有最多节点数目的子集群（Sub-cluster with largest number of Nodes）获胜。若子集群内数目相等则拥有最低节点号的子集群(Sub-cluster with lowest node number)获胜。Oracle RAC建议采用“2+1”的部署方式，数据中心A部署2台服务器，数据中心B部署1台服务器。保证在出现心跳链路故障时数据中心A的实例优先存活。若节点数一致，则建议部署时

39、将节点号小的服务器部署在数据中心A。Oracle Extended Distance Cluster节点部署方式如下图所示：Oracle RAC服务部署建议：为了避免跨数据中心进行数据的交互，建议在Oracle RAC层创建不同的service，实现业务分离。通过Oracle RAC透明应用程序故障切换（TAF）的PREFERRED功能设置应用只访问本地实例；同时设置远端数据中心的实例为AVAILABLE，只有本地实例都故障才切换到远端实例。服务设置方式如下表所示：服务配置策略服务名INSTANCE1INSTANCE2INSTANCE3SERVICE1PREFERREDPREFERREDAVA

40、ILABLESERVICE2AVAILABLEAVAILABLEPREFERRED其他建议：要实现Oracle数据库的跨数据中心的集群部署，需采用支持Oracle Extended Distance Cluster的Oracle版本。建议使用Oracle 10g发行版2 或更高版本。Oracle部署通常有三种存储管理方式：文件系统，裸盘和ASM，推荐使用ASM。对于Oracle Extended Distance Cluster配置，建议对 Oracle Clusterware和Oracle 数据库二进制文件和主目录进行本地存储，以减少站点间流量。DB2数据库群集设计DB2群集方案采用IBM

41、PowerHA/XD（IBM PowerHA/Extended Distance）集群实现DB2数据库的跨数据中心双活部署。PowerHA/XD（Extended Distance）是PowerHA for AIX的一个可选特性。支持将应用切换到远程站点的备份资源。PowerHA的目标是消除SPOF（Single Point Of Failure），当两个服务器中的一个发生故障时，让另一个服务器接管。 PowerHA集群技术通过提供冗余实现故障转移保护，同时通过并发/并行访问支持水平扩展。典型的PowerHA双机系统结构如下图所示：PowerHA为主备集群模式，在一个时刻只有一个节点可对外提供

42、服务，从方案的成本与可靠性角度出发，建议部署两节点的PowerHA集群。SQL Server数据库群集设计SQL Server alwayson群集简介在Windows MSCS故障转移群集的基础上部署AlwaysOn高可用组，用户可以在群集节点上安装SQL Server单机实例，也可以安装SQL Server群集实例，AlwaysOn仅要求所有SQL Server实例都运行在同一个MSCS中，但SQL Server实例本身是不需要群集模式的，这与SQL Server2008 群集的实例完全不同。在此推荐使用单机模式的SQL Server，好处是：可用性副本是个单机实例，那么数据库副本就存放在

43、该运行该实例节点的本地磁盘上；如果可用性副本是个群集实例，那么数据库副本就存放在共享磁盘上。可用性组从Windows群集角度来看，就是一个群集资源，其中的所有数据库作为一个整体在节点间进行故障转移，当然这不包括系统数据库，系统数据库是不能加入高可用性组中的。因为需要借助Windos群集实现监控和转移，所以AlwaysOn会受到一些限制：一个可用性组中的所有可用性副本必须运行在单一的Windows群集上，跨不同Windows群集的SQL Server实例不能配置成一个AlwaysOn可用性组。一个可用性组的所有可用性副本必须运行在Windows群集的不同节点上。运行在同一个节点上的两个不同实例不

44、能用作同一个可用性组的副本。如果某个可用性副本实例是一个SQL群集实例，那同一个SQL群集的其他非活跃节点上安装的任何其他SQL实例都不能作为它的辅助副本。一个数据库只能属于一个可用性组。 AlwaysOn最多可以支持五个副本，但只有一个可用性副本上运行的数据库是处于可读写状态。这个可读写的数据库被称为主数据库（PrimaryDatabase），同时这个可用性副本被称为主副本（primaryreplica）。其余的副本都被称为辅助副本（secondaryreplica），辅助副本上的数据库可能是不可访问的，或者是只能接受只读操作（取决于可用性组的配置），这些数据库被称为辅助数据库。一但发生故障

45、转移，任何一个辅助副本都可以成为新的主副本实例。主副本会不断地将主数据库上的数据变化发送到辅助副本，来实现副本间的数据库同步。下图就显示了一个可用性组中各副本之间的关系。侦听器AlwaysOn创建后，客户端就需要进行连接，为了让应用程序能够透明地连接到主副本而不受故障故障转移的影响，我们需要创建一个侦听器，侦听器就是 一个虚拟的网络名称，可以通过这个虚拟网络名称访问可用性组，而不用关心连接的是哪一个节点，它会自动将请求转发到主节点，当主节点发生故障后，辅助节点 会变为主节点，侦听器也会自动去侦听主节点。一个侦听器包括虚拟IP地址、虚拟网络名称、端口号三个元素，一旦创建成功，虚拟网络名称会注册到

46、DNS中，同时为可用性组资源添加IP地址资源和网络名 称资源。用户就可以使用此名称来连接到可用性组中。与故障转移群集不同，除了使用虚拟网络名称之外，主副本的真实实例名还可以被用来连接。SQL Server2012早期版本的SQL Server只有在实例启动的时候地会尝试绑定IP和端口，但是SQL Server2012却允许在副本实例处于运行状况的时候随时绑定新的IP地址、网络名称和端口号。因此可以为随时为为可用性组添加侦听器，而且这个操作 会立即生效。当添加了侦听器之后，在SQL Server的错误日志中可以看到类似：在虚拟网络名称上停止和启动侦听器的消息。要注意的是，SQLBrowser服务

47、是不支持Listener的。这是因为应用程序在使用Listener的虚拟网络名连接SQLServer时，是 以一个默认实例的形式进行访问的（只有主机名，没有实例名），因此客户端根本就不会去尝试使用SQLBrowser服务。各副本间的数据同步AlwaysOn必须要维护各副本间的数据一致性，当主副本上的数据发生变化，会同步到辅助副本上。这里AlwaysOn通过三个步骤来完成：步骤1：主副本记录发生变化的数据；步骤2：将记录传输到各个辅助副本；步骤3:把数据变化操作在辅助副本上执行一遍。具体实现如下：在主副本和辅助副本上，SQL Server都会启动相应的线程来完成相应的任务。对于一般的SQL Se

48、rver服务器，即没有配置高可用性，会运行Log Writer的线程，当发生数据修改事务时，此线程负责将本次操对应的日志信息记录到日志缓冲区中，然后再写入到物理日志文件。但如果配置了 AlwaysOny主副本的数据库，SQL Server会为它建立一个叫Log Scanner的线程，不间断的工作，负责将日志从日志缓冲区或日志文件里读出，打包成日志块，发送到辅助副本。因此可以保证发生的数据变化，不断送给各 辅助副本。辅助副本上存在固化和重做两个线程完成数据更新操作，固化线程会将主副本Log Scanner所发过来的日志块写入辅助副本磁盘上的日志文件里，因此称为固化，然后重做线程负责从磁盘上读取日

49、志块，将日志记录对应的操作重演一遍，此 时主副本和辅助副本上的数据就一致了。重做线程每隔固定的时间点，会跟主副本通信，告知自己的工作进度。主副本由此知道两边数据的差距。Log Scanner负责传送日志块，不需要等待Log Writer完成日志固化；辅助副本完成日志固化以后就会发送消息到主副本，告知数据传输完成，而不需要等待重做完成，这样各自独立的设计，是尽可能减少 AlwaysOn所带来的操作对数据库性能的影响。SQL Server alwayson部署架构中国电信建议省电子政务外网统一云平台中，对于关键性业务的SQL Server群集，采用2+1的部署架构。即在主数据中心部署2个节点，同城

50、双活数据中心部署1个节点。其中主数据中心2个节点作为本地Active-Standby群集，同城双活数据中心节点作为容灾切换节点，数据在本地2个节点实现同步写入，同时异步同步到容灾节点。如下图所示：当本地主副本出现故障时，SQLServer群集本地节点接管数据库服务。如果主数据中心站点故障，则数据库服务切换到同城双活中心运行。其它数据库群集设计华为存储双活方案采用共享卷技术，将跨数据中心的存储以共享方式提供给上层使用。其它的数据库系统可基于此建立跨数据中心的HA系统，建立Active-Standby的群集，或通过将不同数据库实例同时运行在两个站点，建立Active-Active群集，从而实现跨数

51、据中心的故障切换，或基于人工规划的负载均衡，达到极少（几分钟级别）的业务恢复。可扩展性设计中国电信建议省电子政务外网统一云平台中高性能应用都采用物理主机承载的Oracle RAC群集承载；其它性能要求不高，但灵活度要求比较高的数据库需求通过服务器虚拟化群集承载。因此，数据库平台的可扩展性从两个方面进行设计。Oracle RAC群集扩展Oracle RAC 支持在集群服务器池上透明地部署Oracle 数据库。这使客户能够轻松地将单台服务器中的孤立Oracle 数据库重新部署到数据库服务器集群上，从而充分利用集群数据库服务器提供的组合内存容量和处理能力。Oracle RAC 让客户能够十分灵活地伸

52、缩其数据库负载。客户可以用商用组件来构建服务器池和存储池，从而降低IT 成本，而日后需要时则可以通过在集群中添加更多服务器来轻松实施横向扩展。此外，Oracle RAC 可以在硬件更新过程中，将现有服务器替换为更强大的服务器，从而轻松、持续地实施纵向扩展。虚拟化群集扩展本项目中中国电信建议采用的华为FusionCompute具有业界最大容量，单个逻辑计算集群可以支持128个物理主机，最大可支持3200个物理主机。可随时通过添加计算节点而扩展虚拟化群集。通过扩展虚拟化群集，并结合数据库集群技术，可实现性能要求不高的数据库服务的横向扩展。读写分离设计各种数据库都有自己的读写分离机制和方案，具体如下

53、。Oracle 读写分离Active Data Guard 使备用数据库保持为与生产数据库在事务上一致的副本。这些备用数据库可能位于距生产数据中心数千英里的远程灾难恢复站点，或者可能位于同一城市、同一校园乃至同一建筑物内。Oracle Active Data Guard 包括一个生产数据库，也称为主数据库，以及一个或多个备用数据库，这些备用数据库是与主数据库在事务上一致的副本。Active Data Guard 利用重做数据保持这种事务一致性。当主数据库中发生事务时，则生成重做数据并将其写入本地重做日志文件中。通过 Active Data Guard，还将重做数据传输到备用站点上，并应用到备用

54、数据库中，从而使备用数据库与主数据库保持同步。Active Data Guard 允许管理员选择将重做数据同步还是异步地发送到备用站点上。 备用数据库的底层技术是 Active Data Guard 重做应用（物理备用数据库）和 Data Guard SQL 应用（逻辑备用数据库）。物理备用数据库在磁盘上拥有和主数据库逐块相同的数据库结构，并且使用 Oracle 介质恢复进行更新。逻辑备用数据库是一个独立数据库，它与主数据库包含相同的数据。它使用 SQL 语句进行更新，其相对优势是能够并行用于恢复以及诸如报表、查询等其他任务。备用数据库表使用从主数据库接收到的重做数据进行更新，并且可用于诸如备

55、份操作、报表、合计和查询等其他任务，从而减少执行这些任务所必需的主数据库工作负载，节省宝贵的 CPU 和 I/O 周期。使用逻辑备用数据库，用户可以在模式中不从主数据库进行更新的表上执行数据处理操作。逻辑备用数据库可以在从主数据库中对表进行更新时保持打开，并可同时对表进行只读访问。最后，可以在维护的表上创建额外索引和物化视图，以获得更好的查询性能和适应特定的业务要求。达到数据库读写分离的目标。SQL Server的读写分离部署的SQL Server AlwaysOn群集支持活动辅助副本。 活动辅助功能包括读写分离的的支持，包括：对辅助副本执行备份操作辅助副本支持对完整数据库、文件或文件组执行日

56、志备份和仅复制备份。 您可以配置可用性组，以便为备份指定一个首选位置。 理解 SQL Server 不强制使用首选备份位置十分重要，因为它对即席备份没有影响。 对此首选备份位置的解释取决于您为给定可用性组中的每个数据库撰写作业脚本的逻辑（如果有）。 对于单独的可用性副本，您可以指定对此副本（相对于同一可用性组中其他副本）执行备份的优先级。对辅助副本执行只读访问可以对任何可用性副本进行配置，以便允许在其履行辅助角色时对其本地数据库进行只读访问，尽管不会完全支持某些操作。 此外，如果您想要禁止在主副本上产生只读工作负荷，则可以将副本配置为在以主角色运行时仅允许读写访问。如果某一可用性组当前拥有一个

57、可用性组侦听器以及一个或多个可读辅助副本，则 SQL Server 可以将读意向连接请求路由到其中一个可读辅助副本（只读路由）。指定与可读辅助副本的只读连接具有以下优点：从主副本卸下辅助副本只读工作负荷，以便将资源用于关键任务工作负荷。 如果具有关键任务读工作负荷或不能滞后的工作负荷，应在主副本上运行它。提高承载可读辅助副本的系统的投资回报率。此外，可读辅助副本对只读操作提供稳定的支持，如下所示：有关可读辅助数据库的临时统计信息可优化只读查询。 有关详细信息，请参阅本主题后面的只读访问数据库的统计信息。只读工作负荷使用行版本控制来消除辅助数据库上的阻塞争用。 对辅助数据库运行的所有查询都自动映

58、射到快照隔离事务级别，即使在显式设置了其他事务隔离级别时也是如此。 此外，所有锁定提示都将被忽略。 这消除了读取器/编写器的争用。中间件建设方案中间件分类设计应用中间件主要包括Java应用中间件、数据处理中间件、分布式数据计算中间件和门户中间件等。目前主流的应用服务器中间件Weblogic、Websphere、Tomcat或国产中间件。WebLogic是基于JAVAEE架构的中间件，提供了完整的J2EE应用服务支持，是业界性能评测最好的J2EE服务器，全面支持J2EE的标准规范和其他标准规范（Web Service，SSL，xml等），同时BEA为众多规范组织的制定者之一，积极参与规范的制定，

59、是集群机制，支持分布式的应用；在开发模式下，不用重启部署新Web、EJB应用；目前最新的WebLogic 12c提供云服务。WebSphere是IBM的集成软件平台。它包含了编写、运行和监视全天候的工业强度的随需应变Web应用程序和跨平台、跨产品解决方案所需要的整个中间件基础设施，如服务器、服务和工具。WebSphere提供了可靠、灵活和健壮的集成软件。Tomcat是Apache软件基金会的Jakarta项目中的一个核心项目，由Apache、Sun和其他一些公司及个人共同开发而成。Tomcat技术先进、性能稳定，而且免费，成为目前比较流行的Web应用服务器。表5-5- 3三种主流WEB应用服务

60、器中间件比较表特性WebLogicWebSphereTomcat价格收费（较贵）收费（较贵）免费开源性否否完全开源对技术的支持对业内多种标准的全面支持，包括EJB、JSB、JMS、JDBC、XML和WML，使Web应用系统的实施更为简单，并且保护了投资，同时也使基于标准的解决方案的开发更加简便。对业内多种标准的全面支持，包括EJB、JSB、JMS、JDBC、XML和WML，使Web应用系统的实施更为简单，并且保护了投资，同时也使基于标准的解决方案的开发更加简便。不支持EJB扩展性以其高扩展的架构体系闻名于业内，包括客户机连接的共享、资源pooling以及动态网页和EJB组件群集。以其高扩展的架