1、市级政务云平台建设项目可行性研究报告ii目 录1概述121.1项目名称121.2项目承担单位121.3项目可研编制依据121.3.1编制依据文件和要求121.3.2参考的规划、标准规范等131.4建设目标、内容、周期141.4.1总体建设目标141.4.1.1整体规划目标141.4.1.2建设目标141.4.2建设内容与规模161.4.2.1建设内容161.4.2.2建设规模171.4.3建设周期171.5总投资及资金来源172项目建设单位与信息化现状192.1单位简况192.2本项目涉及的相关信息化资源现状202.2.1区内信息化现状202.2.2网络现状分析222.2.3应用部署情况2222、.2.3.1某区门户网站现状232.2.4IT资源情况292.2.5机房情况312.3拟建项目与已有系统的关系313项目建设的必要性和可行性333.1项目背景333.2项目建设的必要性333.2.1主要问题分析333.2.1.1电子Z务建设集约化程度不高333.2.1.2信息资源共享度较低333.2.2政策指导要求343.2.3是本区各级Z务部门业务应用和发展的需要343.3项目建设的可行性343.3.1建设模式的考虑353.3.2建设模式分析353.3.3关于一家或多家运营商选择的考虑364需求分析384.1用户需求分析384.1.1平台使用对象384.1.2委办局资源域需求384.1.3迁3、移系统调研384.2基础设施平台需求分析394.2.1需求概述394.2.2网络能力需求404.2.3安全能力需求414.2.4计算存储能力需求424.2.5云计算虚拟化需求434.2.6云服务管理系统需求434.2.7统一云管理需求454.2.8服务目录454.3其他需求分析484.3.1容灾备份能力需求484.3.2扩展能力需求484.3.3节能需求484.3.4考核要求494.3.4.1考核内容要求495总体设计515.1总体建设目标515.2建设内容与规模515.2.1建设内容515.2.2建设规模525.3设计原则525.4总体技术架构设计555.4.1设计思路555.4.2服务实现4、架构565.4.3总体逻辑架构575.4.4Z务云体系586项目详细建设方案606.1基础设施平台设计方案606.1.1机房设计606.1.1.1机房服务内容606.1.1.2A级机房建设要求616.1.1.3其他要求636.1.2网络系统设计636.1.2.1设计原则636.1.2.2网络总体架构设计646.1.2.3网络系统详细设计666.1.2.4机房互联设计786.1.3计算存储系统设计786.1.3.1计算处理能力786.1.3.2存储处理能力816.1.3.3计算场景设计856.1.3.4存储场景设计876.1.3.5业务区与集群设计936.1.4云计算虚拟化平台规划956.1.45、.1原则956.1.4.1.1选择OpenStack架构、避免被单一厂商锁定956.1.4.1.2主流云平台技术XEN、KVM技术对比966.1.4.1.3XEN和KVM双引擎，支撑Z务云稳定演进976.1.4.2虚拟化介绍976.1.4.3虚拟化关键技术986.1.4.3.1计算虚拟化986.1.4.3.2存储虚拟化1046.1.4.3.3网络虚拟化1066.1.4.3.4高可用性1106.1.4.3.5高安全性1126.1.4.3.6可管理性1146.1.4.3.7可节能性1156.1.5计算存储选型1156.1.5.1计算存储功能分区建议1156.1.5.2服务器选型方案与规模需求1156、6.1.5.3存储方案选型与容量规划1166.1.6云服务管理系统设计1186.1.6.1运维管理系统规划1196.1.6.2运营管理系统规划1306.1.6.3统一云管理平台1386.2云数据中心容灾与备份规划方案1446.2.1容灾备份等级1446.2.2云平台备份设计1496.2.2.1虚拟机快照备份方案1496.2.2.2备份软件备份方案1556.2.3云平台容灾设计1636.2.3.1主备容灾方案设计1636.2.3.2本地高可用方案设计（推荐）1766.2.3.3灾难恢预案1836.3利旧方案1886.3.1机房利旧1886.3.2网络利旧1896.3.3安全设备利旧1896.3.7、4虚拟资源池利旧1896.3.5设备利旧制度1906.4信息安全系统设计1906.4.1电子Z务安全1906.4.1.1等级保护要求1916.4.1.2等级保护三级安全保护框架1926.4.2云平台安全方案1946.4.2.1网络安全技术实现1946.4.2.2主机安全技术实现1966.4.2.3应用安全技术实现1976.4.2.4虚拟化安全技术实现1986.4.2.5数据安全技术实现1996.4.2.6用户管理技术实现2006.4.2.7安全管理技术实现2006.4.3安全资源池方案详细设计2006.4.3.1安全资源池整体架构方案2036.4.3.2安全组2066.4.3.3虚拟VPN208、66.4.3.4虚拟化防病毒2086.4.3.5虚拟防火墙2096.4.3.6虚拟化入侵防御2106.4.3.7虚拟化Web防护2106.4.3.8虚拟负载均衡2116.5业务迁移规划和设计方案2126.5.1迁移部署计划安排2126.5.2业务迁移服务概述2136.5.3业务迁移设计原则2136.5.4业务系统迁移思路2146.5.5业务迁移流程2156.5.6迁移上云系统清单2176.6某区Z务云演进路线规划2186.6.1技术路线演进2186.6.1.1计算资源虚拟化2186.6.1.2存储资源虚拟化2196.6.1.3网络资源虚拟化2196.6.1.4云管理操作系统2196.6.2总体9、架构演进2206.6.2.1虚拟化数据中心阶段2206.6.2.2云数据中心阶段2206.6.2.3分布式云数据中心阶段2216.7运营运维服务2216.7.1服务保障体系2216.7.1.1ITSS服务体系2216.7.2驻场服务2276.7.3运维团队配置2296.7.4详细服务任务设计2306.7.4.1资源监测2306.7.4.2资源配置2366.7.4.3资源优化2426.7.4.4服务监控2496.7.4.5事件处理2516.7.4.6运维流程2546.7.4.7日常巡检2576.7.4.8备份恢复2596.7.4.9应急预案管理2626.7.4.10服务质量监督和报告2676.810、统一云管演进方向2756.8.1关于运营运维服务管理的深化2756.8.1.1服务计费管理2756.8.1.2服务报告管理2766.8.1.3服务财务管理2766.8.1.4服务需求管理2776.8.1.5服务开发管理2776.8.1.6服务上线管理2786.8.1.7服务满意度管理2796.8.1.7.1服务能力评价指标2796.8.1.7.2服务过程评价指标2826.8.1.7.3任务级评价指标2856.8.1.7.4项目级评价指标2866.8.1.7.5组织级评价指标2886.8.1.7.6企业级评价指标2926.8.1.7.7满意度调查表功能2956.8.2基于CA数字证书的安全身份认11、证2956.8.2.1建设目标2956.8.2.2建设内容2956.8.2.3具体功能应用2966.8.2.3.1终端组建模块2966.8.2.3.2安全接入模块2976.8.2.3.3应用服务模块2976.8.2.3.4系统服务模块2976.8.2.4设备列表2976.8.3基于开源软件的监控平台2996.8.3.1Nagios2996.8.3.1.1Nagios特点2996.8.3.1.2监控的服务2996.8.3.1.3Nagios监控原理3006.8.3.2监控事件管理3016.8.3.2.1事件管理平台接口功能3016.8.3.2.2事件采集3016.8.3.2.3事件过滤3026.12、8.3.2.4事件压制3026.8.3.2.5事件关联3026.8.3.2.6事件分发3026.8.3.2.7告警3036.8.3.2.8事件升级3036.8.3.2.9事件重定义3036.8.3.3系统监控3036.8.3.3.1操作系统监控3036.8.3.3.2数据库监控3046.8.3.3.3应用和中间件监控3056.8.3.3.4业务应用监控3056.8.3.4硬件监控3066.8.3.4.1运行状况监视3066.8.3.4.2故障管理3066.8.3.5网络监控3066.8.3.5.1设备自动发现3066.8.3.5.2网络故障发现3066.8.3.5.3网络协议采集和分析307613、.8.3.5.4网络拓扑发现和管理3076.8.3.5.5拓扑自动发现3076.8.3.5.6拓扑编辑3076.8.3.5.7端口监控和巡检3076.8.3.6存储监控3076.8.3.7门户展示3086.8.3.7.1全局展示3086.8.3.7.2事件告警展现3086.8.3.7.3性能数据展现3086.8.3.7.4业务指标展现3086.8.3.7.5业务流程展现3096.8.3.7.6业务影响分析展现3096.8.3.7.7报表展现3096.8.4基于大数据的监控数据采集、处理和分析3106.8.4.1总体框架3106.8.4.2Cloudera3106.8.4.2.1完全开源开放，避14、免被私有闭源平台绑架3116.8.4.2.2业内最完整的Hadoop堆栈3116.8.4.2.3业内最广泛的合作伙伴生态圈3126.8.4.3监控数据接入3136.8.4.3.1数据接入方案3136.8.4.3.2对于在监控分中心落地数据的接入3156.8.4.3.3对于实时消息流数据的接入3166.8.4.3.4数据接入特性3176.8.4.4监控数据存储3186.8.4.4.1数据类型支撑3186.8.4.4.2HDFS高可用性3196.8.4.4.3HDFS分层存储策略3206.8.4.4.4索引支持3206.8.4.4.5数据增删改操作3216.8.4.4.6压缩策略3216.8.4.15、4.7数据备份恢复策略3216.8.4.4.8数据安全策略3236.8.4.4.9数据平台管理3236.8.4.5监控数据查询3246.8.4.5.1实时查询统计技术解决方案设计3246.8.4.5.2实时自主查询解决方案设计3256.8.4.5.3历史统计技术解决方案3266.8.4.5.4历史查询技术解决方案3276.8.4.6配置要求3286.9系统软件数量及版本需求3306.9.1现有系统软件3306.9.2预备系统软件3306.9.3数据库分布式部署设计3316.9.3.1分布式存储产品特性选型3316.9.3.2应用场景3316.9.3.3主要功能3326.10相关硬件设备数量和参16、数要求3436.10.1设备汇总要求3446.10.2设备参数要求3476.10.2.1网络设备3476.10.2.2服务器3586.10.2.3存储3586.10.2.4备份和灾备设备3606.10.2.5安全设备3627项目组织保障与实施进度安排3707.1项目建设周期3707.2项目实施进度3707.3总体实施路线规划3707.4项目组织保障与培训3717.4.1领导和管理机构3717.4.2项目实施机构3717.4.3运行维护机构3727.4.4人员培训3738项目风险及控制措施3758.1项目风险概述3758.2风险标识3758.3风险估算3758.4风险评价与管理3758.5项目实17、施的外部风险与控制措施3758.5.1风险识别3758.5.2控制措施3768.6项目实施的内部风险与控制措施3768.6.1风险识别3768.6.2控制措施3778.7项目长期运行风险与控制措施3788.7.1风险识别3788.7.2控制措施3799总投资及资金来源3809.1投资建设模式3809.2概算总表3809.3概算明细表3809.4资金来源38610经济及社会效益38710.1经济效益分析38710.1.1一体化、集约化建设，降低建设成本38710.1.2集中管理、统一维护，降低运维成本38710.2社会效益分析38710.2.1以满足全区电子Z务业务应用不断发展的需要38710.18、2.2将建立高效、稳定的信息安全和运行维护体系38710.2.3将构建Z务云计算平台，打造某区智慧电子Z务38811结论与建议38911.1结论38911.2建议390图表目录图2-1：某区Z务外网拓扑结构示意图22表2-1：某区Z务云平台主要业务系统情况表22表2-2：不同分区业务系统的部署资源(服务器)统计表30表2-3：现网服务器明细产品情况统计表30表2-4：现网存储设备明细产品情况统计表30图4-1：某区原有虚拟化平台的网络拓扑结构示意图40图5-1：某区云平台总体技术架构示意图55图5-2：某区云平台服务实现架构示意图57图5-3：某区云平台总体逻辑架构示意图58图5-4：某区Z务19、云体系示意图59表6-1：应用资源需求及业务场景分析表85表6-2：虚拟化适应性分析表86图6-1：典型的FC SAN组网结构示意图88图6-2：典型的IP SAN组网结构示意图90图6-3：存储虚拟化结构示意图92图6-4：业务区与集群设计区分布示意图93表6-3：典型应用虚拟机配置规格示例表94图6-5：统一运维方案设计示意图119表6-4：运维用户角色定义表120图6-6：系统日常运维流程示意图121图6-7：故障处理维护场景示意图124图6-8：主动智能运维流程示意图128图6-9：运营用户角色和角色间关系示意图131图6-11：应用申请部署流程示意图136表6-5：系统计划任务能力表20、137图6-12：平台定位示意图138图6-13：平台功能架构示意图140表6-6：参考的接口技术文档细项设计表142图6-15：安全资源池整体架构示意图204表6-7：安全划分和功能介绍表204图6-16：Z务云安全服务体系设计示意图205图6-17：安全组和规则设置界面示意图206图6-18：VPN Server-Server 模式示意图207图6-19：VPN Client-Server 模式示意图207图6-20：VPN截图界面示意图208图6-21：无代理防病毒示意图208图6-22：虚拟防火墙申请界面示意图209图6-23：虚拟防火墙申请审批后发放界面示意图210图6-24：虚拟负21、载均衡申请界面示意图211图6-25：虚拟负载均衡申请审批后发放界面示意图212图6-26：业务迁移服务流程示意图215表6-8：业务迁移各个阶段需要完成的工作内容表215表6-9：迁移上云系统清单表218图6-27：Z务云演进路线规划示意图218表6-10：系统软件需求列表330表6-11：一个机房的设备要求总数列表344图8-1：项目实施推进进度示意图370图8-2：项目运行维护机构结构示意图373表10-1：本项目概算总表和年度计划安排表380表10-2：本项目概算明细表3801 概述1.1 项目名称“H市H区电子Z务云平台建设项目”，以下简称“本项目”1.2 项目承担单位承担单位： 建22、设地址： 项目负责人： 1.3 项目可研编制依据1.3.1 编制依据文件和要求 国家信息化领导小组关于我国电子Z务建设指导意见的通知（中办发200217号）； 关于大力推进信息化发展和切实保障信息安全的若干意见； 关于大力推进信息化发展和切实保障信息安全的若干意见； 国家电子Z务工程建设项目管理办法（国家发改委令第55号） 关于大力推进信息化发展和切实保障信息安全的若干意见（国发201223号） “十二五”国家Z务信息化工程建设规划(发改高技20121202号) 基于云计算的平台顶层设计指南(工信信函20132号) 信息安全等级保护管理办法（公通字【2007】43号） 电子Z务信息安全等级保护23、实施指南（试行）（国信办200525号）1.3.2 参考的规划、标准规范等某区云平台方案设计、服务管理等需要遵循相关的政策法规、标准。包括但不限于： GB/T 31167-2014信息安全技术云计算服务安全指南 GB/T 31168-2014信息安全技术云计算服务安全能力要求 ISO/IEC17788:2014信息技术云计算概念和词汇 ISO/IEC17788:2014信息技术云计算参考架构 GB/T 21064-2007电子Z务系统总体设计要求 GB/T 20988-2007信息系统灾难恢复规范 GB/T 22239-2008信息系统安全等级保护基本要求 GB/T 22080-2008信息技24、术安全技术信息安全管理体系要求 GB50174-2008电子信息系统机房设计规范 GB50462-2008电子信息系统机房施工及验收规范 云计算中国云计算专家委员会，2010； 云计算核心技术刨析，2011； GB2562-2564,云计算及其关键技术，2009； GB17859-1999计算机信息系统安全保护等级划分准则； GB/T20271-2006信息系统通用安全技术要求； GB/T22239-2008信息安全技术信息系统安全等级保护基本要求； GB/T22240-2008信息系统安全等级保护定级指南； TC260-N0015信息系统安全技术要求，工信部； 云计算关键领域的安全指南云计算25、联盟，2009等。1.4 建设目标、内容、周期1.4.1 总体建设目标通过某区Z务云技术架构规划建设，与现有的平台形成资源统一，能力扩展，服务延伸，为信息化建设提供安全可靠的云服务，为构建服务型政府奠定基础。通过某区Z务云技术架构规划建设，在有效降低重复建设投资、节能环保的基础上，提高基础设施资源的利用率，实现某区信息化基础设施资源的统一规划、统一建设、按需调配、即需即用、有效共享。通过合理规划、小步快跑的方式，在实现建设集约化、信息共享化、服务标准化、效益最大化的同时，满足某区各级用户、各委办局基础设施的应用需求，为某区Z务信息化发展提供有力的信息化支撑保障。1.4.1.1 整体规划目标分三26、阶段进行建设。第一阶段，完成Iaas层面的初步建设，确保区内主要业务系统和各委办局的现有和新建的等保三级及以下非涉密信息系统上云，完成物理层面的集中。第二阶段，在Iaas层面Z务云的基础上搭建区级Z务云Paas平台，提供统一的公共服务，并逐步要求区内新建信息系统按Paas平台规范开发，完成应用资源共建共享。第三阶段，完成区级Z务云Daas平台的建设，实现“云数联动”，在“三个实有”的基础上，逐步完善长效数据更新和数据利用的目标。1.4.1.2 第一期建设目标根据某区已有信息化基础和电子Z务现状，参考上级主管部门及相关单位的调研意见，本区Z务云建设考虑以服务标和建设标相结合的模式。1. 建设模式27、目标其中服务标部分，以政府购买服务的方式，选取2家运营商资质的公司，建设2个云机房，从竞争的服务模式中，获取优惠的服务价格与优质的服务能力。建设标部分，选择1家有实力的集成服务商，建设统一云管平台、采购第三方软件、完成应用系统迁移的相关工作。同时承担第三方技术监督与管理的角色，对接两家云服务商的基础服务，协助政府更好的用好云、管好云。2. 资源规模目标参考各区县Z务云的一期建设的虚拟资源池规模量，初步估算某区Z务云虚拟资源池规模：第一阶段上云的系统预计40个，对生产服务器物理CPU核数的需求，按增加30%的冗余量计算，总规模约为3000核，以1：4的比例估算内存需求规模约为12000GB，存储28、需求规模约为300TB。后续根据建设和实际需求，可平滑进行扩容。3. 安全建设目标云平台网页防篡改要求:云租户互联网应用系统在部署到云平台之前必须采取网页防篡改措施，若云租户自带防篡改措施，需出具该产品的销售许可证或3C产品认证证书；若用户不自带防篡改措施，云平台需主动向云租户提供防篡改措施，未采取网页防篡改措施的云租户互联网应用系统将不得接入云平台。云平台流量清洗要求以及web应用防护要求:建议运营商以基础服务形式提供给云租户流量清洗服务以及web应用防护服务。关于云租户虚拟防火墙:建议由云租户提出需求，由科委审核后方能开通虚拟防火墙策略，原则上按最小授权原则设置防火墙策略。防病毒要求：按照29、主机防护体系的要求提供基础的防病毒服务，同时，在云环境中，按照最新的等保要求，提供虚拟化防病毒服务的服务。要求完成等保测评，并要求分数达到85分以上。4. 应用迁移目标经过前期的摸底调研与分析，此次业务搬迁预估将40个业务系统均将迁移到云计算中心。所有的区内符合等保三级要求，具备迁移上云条件与意愿的系统与单位，将会按照标准的迁移流程进行评估、测试、方案设计后，在汇总为最终的上云计划，交付给云服务商进行迁移实施工作。1.4.2 建设内容与规模1.4.2.1 建设内容某区基础资源平台规划包含如下内容： 规划建设统一的IT资源池基础设施资源包括网络资源、计算和存储资源等，基于云计算的高弹性、高可靠性30、高冗余的特点，采用可行的云计算模式，并与“某区”云计算第一节点实现互联互通。在网络资源建设方面，基于现有的信息网络平台（Z务公共网与Z务办公网），加强网络安全防护，完善网络管理体系。在计算资源方面，应采用虚拟化技术设计高弹性的计算资源池，并满足部门用户对计算资源不断增长的需求。在存储资源方面，应利用存储虚拟化技术，实现异构存储统一整合和分级共享，提高存储资源利用率，能够快速为用户部署存储空间；按实际用量计费；降低存储成本（存储共享、重复数据删除、数据压缩）；实现弹性扩展；系统管理简单。 规划建设统一的云管理运营运维支撑平台在平台运营运维服务方面，建立统一的运营运维服务体系，制定服务标准和规范31、，提供满足需求、响应及时、安全可靠的运维保障服务，包括为保障业务应用的顺利部署、开通，以及网络、硬件、软件、数据、机房环境等安全、稳定、高效运行而进行的一系列策划、实施、检查与改进过程。1.4.2.2 建设规模运用云计算技术，统筹利用已有的计算资源、存储资源、网络资源、信息资源、应用支撑等资源和条件，统一建设并为某区政府各部门提供基础设施、支撑软件、应用功能、信息资源、运行保障和信息安全等服务的基于云计算的互联网综合性服务平台，实现服务资源集中管理，健全现有的技术服务管理模式与队伍。面向云服务商，参考当前某区Z务云第一阶段上云的40个系统的情况，对于虚拟资源池规模量，并对生产服务器物理CPU核32、数的需求，按增加50%的冗余量计算，总规模约为CPU3000核，以1：4的比例估算内存需求规模约为12000GB，存储需求规模约为300TB。后续根据建设和实际需求，可平滑进行扩容。1.4.3 建设周期本次项目整体为三年项目，2018年为建设期，2019年内完成剩余的迁移工作，2020年为服务期。项目启动与建设相关的周期情况如下所示：2018年3月，启动项目实施。2018年6月，针对云机房基础设施与云服务部分内完成设备到货与安装调试，提供云服务。（耗时3个月）。同时完成统一云管理系统的软件定制开发与部署实施工作。（耗时3个月）2018年3月启动迁移相关工作，首批迁移需在2018年6月完成，2033、18年12月完成整体的75%的迁移工作，2019年12月完成整体迁移。2020年完成项目整体的验收。1.5 总投资及资金来源参考市级Z务云和其他区建设整体规模，结合某区实际情况，建设概算三年总投资3990万元，支付给2家运营商的服务费共2400万，支付给集成服务商的建设费用1590万元。本项目建设经费全部投资由区政府财政财力解决。备注：该项目总投资经费中涉及的相关二类费用由发改委审批核定。2 项目建设单位与信息化现状2.1 单位简况某区区科委的主要职责是：(一)贯彻执行国家和本市有关科技与信息化工作的法律、法规、规章和方针、政策,并组织实施。(二)根据本区国民经济和社会发展的总体规划,会同有关34、部门研究制定本区科技发展与信息化发展的战略、规划、计划,并组织实施。(三)负责协调推进高新技术产业、信息技术产业化工作；负责本区高新技术、信息应用技术的创新、成果转化的推进、评估与申报工作；引导和促进信息产业的发展,推进信息化与产业化的融合；受理本区科技进步奖、科技成果鉴定和新产品鉴定的申报工作；依法管理本区技术市场,负责对技术合同进行认定登记。(四)负责指导本区科技产业、信息产业的协调发展工作；负责本区科技进步工作的组织协调；负责相关数据信息的采集、统计、分析工作；负责和组织本区科技专家组的活动,对全区经济、社会重大项目进行咨询,对规划进行论证,为区领导提供决策咨询。(五)研究本区科技投入的35、措施；优化科技资源的配置；参与科技预算编制。(六)负责制定科学技术普及工作规划,实行政策引导,推动科普工作发展；会同有关部门研究制定本区科技人才发展规划及政策；实施科技人才培养工作。(七)组织、协调、指导本区信息化项目建设与应用工作，按区政府批准权限组织规划重大信息化建设项目；会同有关部门组织和管理政府投资信息化项目的推进实施工作；负责部门预算内的政府信息化项目的前置审批；对信息化重大投资项目和本区建设财力信息化项目提出行业主管部门意见。(八)指导协调本区信息资源的开发利用、企业信息化、电子Z务发展和电子商务推广以及社会和经济各领域的信息化应用推进工作；负责社会公共信息资源共享的协调管理；组织36、协调跨部门、跨行业、跨领域的信息化应用；组织、协调智能卡应用推广工作。(九)负责本区信息基础设施建设的规划、协调和管理；组织、指导、推进本区信息通信基础的管线集约化规划建设；负责跨行业、跨部门面向社会服务网络的互联互通；会同有关部门做好区政府门户网站的规划建设和综合事务管理；指导部门网站建设和应用；负责本区社会保障卡的管理工作；协调、指导全区各社会保障卡社区受理点的相关工作。(十)组织协调本区信息安全保障体系建设工作；负责指导和协调信息、安全防范工作；协调处理网络与信息安全重大事件；会同有关部门加强对信息网络安全技术、设备和产品的监督管理；组织本区信息化宣传、普及教育和信息化专业人才预测、规划37、与合作交流等工作。(十一)负责协调指导本区征信服务行业,推动社会诚信体系的建设。(十二)负责本区知识服务业的规划、发展和推进工作。(十三)负责协调推进本区大柏树知识创新与服务贸易圈的规划、发展和推进工作。(十四)负责本区知识产权有关法律法规的宣传指导、执法检查、调处纠纷、涉外知识产权等管理工作。(十五)负责有关行政诉讼应诉工作。(十六)承办区委、区政府和上级主管部门交办的其他事项。2.2 本项目涉及的相关信息化资源现状2.2.1 区内信息化现状为推动我区政府各部门信息化基础硬件整合、应用互联互通、数据资源汇聚共享，我区在2014年尝试对区Z务信息化资源进行云化建设（即：原有虚拟化平台），为区各38、部门在Z务外网上开发运行的业务应用提供底层虚拟化基础平台、应用和数据资源支撑。经过近三年的应用发展，目前该虚拟化平台硬件资源共有CPU192核，物理内存总共1.4TB，存储资源总共23.5TB，虚拟化服务器107台，云化业务系统35个，涉及部门22个。协同OA系统、事中事后监管系统、三大基础数据库（人口、法人、GIS）等一批跨部门、跨平台的应用系统和数据库运行于该平台上，为我区实现整体搭建全区统一的电子Z务云打下了较好的基础。第一阶段上云的范围将以科委现有的云化业务系统为主（按照技术评估结果可能不足35个），并对于区内各委办局自有的信息系统中，选取5-10个应用系统（直到符合条件的系统达到4039、个为止）。l 现有资源规模是按照系统的往年的基本运行需要而配置，在本项目启动后，系统的资源需求会受到以下几个方面的影响：l 应用系统或数据库的备份需求导致的存储资源的增加。l 逐年增长的系统使用量，对于系统的计算资源的增长需求（年增长率15%-20%）l 原有虚拟化环境或硬件环境的计算资源，在折算为虚拟资源过程中的误差。l 项目整体规划所需要的所有虚拟资源池在三年能使用的增长量的预估（30%）因此，在规划第一阶段项目的资源需求量时，需要考虑以上的情况酌情增加资源规模的预估。同时，参考已经完成部分建设的嘉定区提供20个系统年内的资源规模为CPU1040核内存3750GB 存储73TB（不含备份存40、储），长宁区的设计上云系统40个，要求2家云服务商分别提供CPU1000核内存6000GB存储150TB（含备份）以上的可用虚拟化资源。因此，三年内某区Z务云的资源规模需求应当在CPU3000核内存12000GB，存储300TB（含备份）。2.2.2 网络现状分析某区Z务网络如下部署，按照部署情况，主要划分为DMZ区、托管区和Z务核心区。后续托管业务逐步将迁移到DMZ区与Z务核心区，同时设计方案需要完成云机房（如：运营商）与现业务中断时间有资源网络对接。Z务外网拓扑如下图2-1所示：图2-1：某区Z务外网拓扑结构示意图2.2.3 应用部署情况目前某区虚拟化平台主要为各委办局办业务系统，业务系统41、数量约35个。部分业务托管、部分业务集中使用科委资源。主要业务系统情况如下表2-1所列：表2-1：某区Z务云平台主要业务系统情况表应用系统名称设备数量资产归属建设单位OA协同办公系统11台科委科委GIS系统3台科委科委安全生产监督管理系统7台科委安监局事中事后综合监督管理系统2台科委市场局街镇社区管理系统8台科委街镇网格化应急系统1台科委机管局某区决策咨询平台2台科委发改委区一点通系统1台科委民政局区统战人士新管理系统1台科委统战部群团应用系统2台科委总工会、区团委、妇联2.2.3.1 某区门户网站现状某区门户网站现状说明1 基础环境目前某区门户网站的基础设施全部托管在浦东新区金桥联通机房内，42、在机房内分别租用了4个机柜，具体设备存放情况如图所示。其中门户网站使用2个机柜空间，每个机柜分别占据24U和26U。托管网站使用2个机柜空间，其中一个机柜内为托管网站安全设备，目前已使用11U机柜空间，另一个机柜内为广中托管设备，目前已使用20U机柜空间。2 网络安全情况目前某区门户网站群共包括有主门户区域和托管区域：如图上图所示，目前主门户区域分别有二个互联网出口分别为联通和电信链路。出口连接交换机配合下连防火墙实现双机热备，内网部署二台核心交换机实现双机热备，内网中旁路部署有VPN、堡垒机、日志审计等设备。在网络安全方面，出口防火墙嵌入WAF、IPS、DDOS功能抵御互联网攻击，所用远程管43、理需通过VPN设备进行拨号，所有内外网维护管理需通过内网堡垒机进行，同时使用日志服务器收集所有设备日志。其中主门户区域内部网络只存在一个网段，其中托管区域结构较为简单，为互联网直接链接一台出口防火墙，防火墙下连一台二层交换机实现的简单局域网架构，局域网内无其它安全防护设备和措施。3 应用情况目前某区门户网站群内分别部署有，门户网站应用、一体化平台、以及托管应用。l 其中门户网站应用，主要是区门户网站首页包括的相关应用。l 一体化平台共包括7个部门网站及11个网站，部门网站主要为环保局、旧改 、绿化市容局、体育局等部； l 在托管区域内的应用，为市容、广中、政协、民政四个部门托管应用，其中广中应44、用已关闭，民政应用正在改造中。4 服务器情况l 门户服务器目前主门户区域共有18台应用服务器，具体可详见下表。应用类别应用名称型号cpu(核数、型号）内存硬盘大小门户网站应用门户域控服务器IBM x3650 M2Intel Xeon E5504(4核)8G84G/1114G门户空置服务器(门户主data冷备、360控制中心）IBM x3650 M3Intel Xeon E5640（双处理器，每个处理器4核）16G81G/272G门户主data服务器（集群）IBM x3650 Intel Xeon E5540（双处理器，每个处理器核）12G120G/540G门户备data服务器（集群）IBM x45、3650 M3Intel Xeon E5640（双处理器，每个处理器4核）16G47G/271G门户主web服务器IBM x3650 M3Intel Xeon E5640（双处理器，每个处理器4核）16G174G/272G门户备web服务器（冷备）IBM x3650 M2Intel Xeon E5530(4核)8G101G/543G信息公开服务器(备)IBM X3650 M3 INTEL Xeon x5690(6核)16G172G/271G信息公开服务器（主）IBM X3650 M2Intel Xeon E5503(8核)20G240G/540GZ务大厅Web应用(主)华为 RH2288H V46、2Intel Xeon E5-2603(4核)8G32G/930GZ务大厅Web应用(备)IBM X3650 M2Intel Xeon E5503(8核)8G240G/540GZ务大厅Data服务器华为 RH2288H V2Intel Xeon E5-2603(4核)8G278G/930G存储备份一体机（1备1）浪擎 DX2000Intel Xeon E5-2407(4核)8G74G/100G218G/3622G存储备份一体机（挂载data）浪擎 DX2000Intel Xeon E5-2407(4核)8G225G/1860G新一体化应用一体化（政府机关）的web和SQL(主)dell Pow47、erEdge R720Intel Xeon E5-2603（双处理器，每个处理器4核）16G460G/1116G一体化（政府机关）的web和SQL（备）IBM X3650 M2Intel Xeon E5503（双处理器，每个处理器8核）12G250G/1111G网站应用网站群的web应用(主)IBM X3650 M3Intel Xeon X5647（双处理器，每个处理器4核）16G84G/1860G网站群的web应用(备)IBM X3650 M2Intel Xeon E5503（双处理器，每个处理器8核）12G270G/540G网站群的SQL应用IBM X3650 M3Intel Xeon X48、5647（双处理器，每个处理器4核）16G56G/1860G旧一体化平台一体化平台服务器lenovo R520Intel Xeon E5410(4核)8G99G/135Gl 托管服务器应用类别应用名称型号C4-04号机柜防火墙天融信NGFW4000-UF(TG-41410)交换机华为S3700交换机华为S3700中新软件DDOSGFW-7400（闲置为使用）C4-05号机柜防火墙天融信NGFW4000(TG-4424)交换机EXTREME交换机华为S5700（闲置为使用）交换机华为S5700（闲置为使用）交换机华为S5700（闲置为使用）市容局托管服务器1宝德pr1310d市容局托管服务器2宝49、德pr1310d政协提案服务器IBM X3650 M3 生活平台数据库服务器1IBM X3690 X5 生活平台WEB服务器1IBM X3690 X5 生活平台WEB服务器2IBM X3690 X5 WEB服务器IBM：X3650 m4数据库服务器IBM：X3650 m4广中智慧社区IBM：X3650 m4生活平台数据库服务器2IBM X3850 X5 5 安全设备序号货物名称 设备型号数量设备类型1深信服主防火墙AF-30802安全2深信服SSL VPNSSL-VPN-20501安全3门户网站主交换机华为S57002交换机4审计服务器思福迪logbase审计1安全5堡垒机Lasecs-NK-50、50堡垒机1安全6存储备份一体机浪擎 DX20002存储7iGuard网页防篡改网页防篡改5安全2.2.4 IT资源情况1） 不同分区业务系统的部署资源(服务器)参见下表2-2所列：表2-2：不同分区业务系统的部署资源(服务器)统计表行标签服务器数量业务系统数量说明Z务外网托管区域2621实体机Z务外网实体机区域50实体机公众网实体机区域2110实体机虚拟化公众网区域1635虚拟机虚拟化Z务外网区域101虚拟机2） 现网服务器(未损坏)主要包含 IBM、DELL、HP、联想、华为、思科的产品；其中实体机几乎没有续保。参见下表2-3所列：表2-3：现网服务器明细产品情况统计表序列IBMDELLH51、PLENOVOHUAWEICISCOZ务外网托管区域1172600Z务外网实体机区域276458-公众网实体机区域141222-虚拟化公众网区域-16刀片虚拟化Z务外网区域-3） 现网存储设备参见下表2-4所列：表2-4：现网存储设备明细产品情况统计表序号资产品牌资产配置（容量）1EMC 520021TB2EMC 530018TB3Avamar 12003.9TB4群辉NAS14TB结论：1、实体机和虚拟机共200多台，业务系统对性能要求不一，配置以2路、4路服务器为主，部分业务系统部署在虚拟化上，后续虚拟化资源池应满足不同业务的不同性能需求。2、现网的IT设备涉及多厂商多品牌，后续利旧需要考52、虑异构设备统一管理。3、现网大部分实体机保或损坏，未损坏的设备可以续保或利旧作为测试服务器、存储用，并实现业务的逐步迁移。2.2.5 机房情况目前某区科委信息中心的机房位于1号楼地下机房，云平台设计、部署需要考虑机房供电，保障用电供应及用电指标均由云服务商负责。2.3 拟建项目与已有系统的关系参考Z务云的基本建设要求，结合某区的信息化建设思路，明确某区Z务云的核心任务是五个“集中”，即基础设施集中、服务集中、管理集中、数据集中、安全集中、应用集中。原有机房利旧：我区原有的两个机房中，无论设备还是机房本身都仍具备极大的使用价值。在区级云体系与框架设计上，不拘泥与原有框架，而是充分利用各种资源，发53、挥更大的价值。原有平台和应用纳管：将原有的虚拟化平台及应用系统，纳入统一云管理体系，实现从项目申报、项目落地到应用集中、数据共享的全过程管理。针对迁移上云的现有系统或之间在云上新建的系统，提供云平台相关的运营与运维服务。未来，按照客户的需求和云平台的管理制度变化，逐步将不适宜上云个的应用系统或基础设施（即硬件设施）纳入统一信息化管理与服务的范围。3 项目建设的必要性和可行性3.1 项目背景某区Z务云计算平台的建设紧紧围绕区政府、各Z务部门深化电子Z务应用、提高履行职责能力的迫切需要，为各部门实现Z务、业务目标提供公共的技术环境和服务支撑，有效支持Z务部门灵活、快速部署应用业务，满足业务不断发展54、和改革的需要；满足跨地区、跨部门、跨层级信息共享，以及行业系统与政府应用结合的需要；满足大量数据访问、存储和智能化处理的需要；满足安全可靠运行的需要。为了促进服务型政府建设，推动某区Z务数据产业的发展，满足某区电子Z务、电子商务等信息化快速发展的需求，保障信息化建设未来发展中出现的重复建设及信息孤岛问题，非常有必要将某区各部门建设信息系统都需要的基础设施和资源与各自的业务应用剥离出来，集约建设、统一管理、按需使用，形成公共平台支撑各Z务部门的信息化建设。3.2 项目建设的必要性3.2.1 主要问题分析3.2.1.1 电子Z务建设集约化程度不高我区已建成的各类信息系统有效支撑了现阶段政府管理和民55、生服务的需求。但由于规划标准不一，难以支撑政府职能转变需求。亟需加强电子Z务规划、建设、运营的统筹协调，从部门独立建设、自成体系，向跨部门跨行业集约化的Z务云模式转变。3.2.1.2 信息资源共享度较低众多业务系统由于部门化管理，跨条块资源集成难、跨领域业务协同难、跨部门信息共享难的“三跨难”问题仍然存在，极易导致部门间业务协同不便，产生信息孤岛、绩效监测失控等弊端。3.2.2 政策指导要求国家度重视以云计算为代表的新一代信息产业发展，市政府明确了16个区政府自主建设区级云，与市级云在逻辑上实现一体化。全市最终形成“1+16”市、区两级云体系的架构要求。从区级层面来讲，要求参照市级云目标和要求56、，完成所有区级Z务云建设，与市级云在设施资源层面分离、在中间平台层共享、在应用服务层联动。第二，区级云为本区各部门、各单位提供集中式云服务，对市级条线的原有业务系统，在市级相关部门的指导下，结合本区实际，开展Z务云应用。3.2.3 是本区各级Z务部门业务应用和发展的需要从信息化系统的业务角度出发，基础设施的集中后，政府信息化的项目管理单位，省去基础实施资源的规划、维护的工作与安全防护的责任。从信息数据的角度出发，云架构的网络与存储的集约化建设，为数据的汇聚、交换、共享，提供了更为便捷的渠道与基础。从区内信息化系统的统筹管理与监管的角度出发，通过统一的云管平台可以实现全区的设备的集中的信息化管理57、。避免原先的分散管理带来的沟通成本，使得区内信息化的统筹安排与调度成为可能。3.3 项目建设的可行性云计算技术已经成熟，国家相关政策也已经出台，因此建议某区建设统一的电子Z务云。统筹利用已有的计算资源、存储资源、网络资源、信息资源、应用支撑等资源和条件，根据业务需求，新增资源池建设，统一建设并为某区政府、各Z务部门、各委办局提供基础设施、支撑软件、应用功能、信息资源、运行保障和信息安全等服务的基于云计算的服务平台，实现服务资源集中管理，健全现有的技术服务管理模式与队伍。3.3.1 建设模式的考虑本次项目采用了全新的服务购买的模式，而各区县中浦东、崇明、嘉定等区采用的传统的建设模式。而据了解，年58、内拟开始招标的长宁Z务云、杨浦Z务云都包含了服务标（服务购买模式）与建设标（传统模式）。因此，建议在启动某区Z务云的建设前，充分考虑建设模式的选取问题。3.3.2 建设模式分析1、责任边界划分首先，对于建设模式的具体分析之前，必须明确的是建设参与方及其责任分工的问题。按照市Z务云的情况，电信、移动两家运营商负责机房、网络与基本设备的采购，构架云基础。浦东、嘉定等在建设的云则是通过拆分多个包件的模式，分别召集运营商、集成商、厂家等参与Z务云的建设。而年内拟招标的，长宁云与杨浦云项目则会将基础云建设（机房为主）按照服务标的模式选择2家运营商，同时，将集成服务（云管、迁移）等工作交付给集成服务商负责59、。从而实现工作任务的一个合理的分配的目的。2、服务标优缺点分析服务标模式的主要优点是政府可以按需购买服务，对灾备和后续扩容服务有保障，同时对政府财政一次性建设支出压力小，规避将来的资产管理问题。缺点是Z务云的服务边界和服务目录尚不完善，云运营商与应用开发厂商的工作服务边界也较为模糊，导致服务标在招标阶段的需求无法明确，存在后续协调复杂和总体服务价格过高的风险，且如后续要更换云服务商也较为困难。3、建设标优缺点分析建设标模式的主要优点是在上云系统明确的前提下，建设总量和建设内容明确可控，利于集约化建设，服务内容和服务边界容易界定。由于建设方和运营方独立，后续如要更换云服务商也相对灵活。缺点是政府60、前期需要投入一部分资金进行建设，对管理方面的要求更高和更细化，后续同时存在建设部分资产管理问题。综上考虑，我们建议我区Z务云结合两种建设模式的优点，对于服务内容明确、标准化程度高、风险较小的部分采用服务标的模式，对于服务内容需要逐步明确、个性化程度高、风险较大的部分采用建设标的模式。3.3.3 关于一家或多家运营商选择的考虑通过前期调研，综合各个运营商在区内和邻区机房的配置情况，有选择一家或两家运营商两套方案，利弊分析如下，具体两套方案的服务费用测算对比见附件：1.选择两家运营商（市Z务云模式）优点：可综合选取不同运营商的优势资源，根据市Z务云目前建设的进展来看，不同运营商在提供的服务项目和服61、务价格方面有差异，可根据上云系统的不同要求有选择的选取不同运营商。且在系统上云过程中，可综合比较不同运营商的服务和价格，选取合适的运营商提供服务。如后续对某侧运营商服务不满意，可逐步增加另一侧运营商的上云系统数量，兼顾性价比和灵活性；缺点：选取两家运营商总体上会增加采购服务的成本（主要在网络和灾备方面）。在区级统一云管理方面、沟通方面和任务协调方面，要同时对接两家运营商，增加管理和沟通成本和复杂度。后续可能存在两家运营商服务口径不统一，监控调度的难度也同时增加。2.选择一家运营商（嘉定、崇明、浦东等区模式）优点：在前期明确工作界面和服务目录的基础上，只需要对接一个运营商，管理和沟通相对简单。在62、建设方面的复杂度降低，特别在第一阶段系统规模不大的情况下，运营商的建设和维护成本也相对较低。在运营方面，工单派发、云平台监控和上云迁移的接口清晰，如发生故障，后续定责处罚也相对明确。缺点：选取一家运营商容易造成垄断的情况，在服务期内可能发生服务不到位，非标服务定价较高等情况，需要前期明确相应的管理办法和服务要求。在服务期满后，如需要更换运营商，由于前期其他运营商参与较少，可能存在迁移困难的问题。综上考虑，建议我区Z务云选择两家运营商各自提供一个机房，在形成竞争与服务优势的同时，避免大量重复投资。因此，“某区电子Z务云建设项目”不仅必要的，也是可行性。4 需求分析4.1 用户需求分析4.1.1 63、平台使用对象某区Z务云的主要角色包括区政府科委信息中心、平台评测者、平台使用机构。平台使用机构是某区政府、各Z务用户部门，负责向区政府科委信息中心申请相关资源的使用权，以提供给该政府机构的服务对象，如该机构公务员、公众或企业等。4.1.2 委办局资源域需求委办局资源域是指由委办局使用的资源区域，资源域包括两种类型，第一种类型是指根据有特殊需求的委局要求，从某区Z务云机房资源中划分一部分资源给该委办局专享使用，各委办局可以根据本单位的实际需求将该资源域进行再次分配，提供给不同的系统或下属单位使用等，资源支持自运维。此类需求主要针对原有托管的委办局。4.1.3 迁移系统调研在全区范围内的首次全面调64、研中走访21家单位，调研122个系统，排除市级、国家级系统，再经过初步的筛选后得到第一批上云系统的候选系统有51个应用系统。本次项目将会按照标准的上云迁移流程规范，对于这些系统进行评估与测试，最终按照计划进行40个系统的上云实施。并在外来的3年中逐步将区内剩余的符合上云条件的系统或新建的系统迁移到Z务云平台之中。调研包含了单位基本信息与基础设施基本信息，经过整理后得到以下结果：53个系统涉及25家单位，共计96台物理机/虚拟机，折算标准虚拟资源需求量为CPU1680核 内存5.23TB 存储144.2TB，数据增量在101.7GB，互联网网段7个系统，Z务外网网段44个系统。按照应用系统的年扩65、展率为1.5计算，可以得出预期的虚拟资源池规模在CPU2520核 内存7.8TB 存储216.5TB。在综合考虑了容灾备份、内存与系统性能需求等方面的因素后，确认本次项目的云规模的设计容量为：CPU3000核，以1：4的比例估算内存需求规模约为12TB，存储约为300TB。4.2 基础设施平台需求分析4.2.1 需求概述某区电子Z务外网业务系统按照服务对象和使用对象主要分为以下几类：1）公共服务类，如网上办事大厅申报系统等2）各单位专有业务系统为确保各类应用的安全性，云平台架构设计中需要考虑如何满足不同业务的不同资源需求、安全需求等。为了给某区各委办局提供快速高效的云资源，某区Z务云平台需要打66、破传统基于物理盒子构建方式，构建分钟级虚拟数据中心服务平台： 将物理分散的多个数据中心或同一个数据中心的多个资源池灵活构建的一个逻辑的数据中心（虚拟数据中心服务平台） 每个虚拟数据中心具有自运维高效服务平台 虚拟数据中心资源可以来源于分散的多种资源：云与非云，异构云，跨地域 为发保障上层业务的SLA，虚拟数据中心需要具备保障SLA能力 支持上层业务系统快速部署到虚拟数据中心能力 支持上层业务系统全生命周期的管理服务：快速部署，弹性伸缩，运行监控，容灾备份4.2.2 网络能力需求某区原有虚拟化平台的网络拓扑情况，如下图4-1所示：图4-1：某区原有虚拟化平台的网络拓扑结构示意图整体网络建设需要遵67、循利旧原则，采用统一的Z务外网出口，而互联网出口目前是按照各自的网络区域进行分别配置。针对现网情况，网络需求主要体现在如下几个方面： 新平台网络需要接入到某区Z务城域网，满足与原有平台的互联互通。 支持云平台的数据中心网络需要具备快速收敛、高转发性能、易维护、易管理和节能环保等特性，这就需要简化网络架构，降低网络复杂度。 数据中心网络需要具备高可靠性、高可用性。网络设计能有效的避免单点故障，在设备的选择和关键设备的互联时，应提供充分的关键设备冗余、重要业务模块冗余和链路冗余，网络应当达到电信级可靠性。 数据中心网络架构和设备选型方面需要具备高扩展性，不仅满足当前需要，也能满足未来业务扩展需求。68、 安全隔离的需求，实现政府各部门之间网络层面的隔离。 网络虚拟化：减少设备节点，简化配置。 新建云机房应当在满足统一接入现有机房的Z务外网的链路的基础上，各自提供互联网的出口链路服务。4.2.3 安全能力需求某区Z务云平台由于自身对安全的高要求，因此需要平台通过构建互联网区和电子Z务外网区以及安全域来保证业务的安全性、便利性和可服务性。云平台需进行安全域划分，对不同安全域按安全等级要求进行安全管理、用户与身份、数据安全、应用安全、IT基础设施安全（包括网络安全与主机安全）、物理安全等安全防护。基础环境安全的重点是满足云计算环境中等级保护的要求，应从区域边界安全、计算环境安全（主机/虚拟主机）、69、虚拟平台安全三个层面建立三重安全防护体系，科学划分安全域和安全等级，开展安全防护。业务及数据支撑安全的重点是访问控制和数据隔离及加密。健全信息安全管理制度，安全管理水平达到ISO27001要求。信息安全管理的重点是应用安全、认证安全、数据安全的责任界定及相应的管理体系。建立安全管理中心，加强电子Z务信息安全监测，建立和完善电子Z务信息安全应急处置协调机制、指挥调度机制和通报制度；强化安全统一管理、数据库审计、运维审计、日志审计、漏洞扫描等安全管理手段。构建平台安全保障体系，明确服务各方安全职责，加强对数据泄露、账号和服务劫持等安全风险防范。推行信息安全等级保护制度和风险评估，加强信息安全测评，70、定期组织开展信息安全联合检查，健某区各级各部门信息安全管理机制，推进重要部门、重要信息系统安全保障体系建设。在保障服务产品功能、性能的基础上提高平台的安全可靠率，达到70%。针对云平台中使用的现有软硬件产品，能够针对不同的重要级别制定平稳、可行、不影响现行系统的替换方案和调整方案。制定确保采用自主可控、安全可靠软硬件产品，构建平台的制度、规范，明确使用范围、工作责任等。 需针对数据中心内部网络进行安全域划分，对于安全域边界进行网络隔离，定义网络访问控制策略； 需提供云计算平台内虚拟化基础设施的安全保护能力，确保虚拟机的隔离，以及虚拟机自身系统的安全性。4.2.4 计算存储能力需求某区科委信息中71、心机房目前虚拟化服务器107台，新平台建设需要满足现网过保设备承载业务的迁移；同时满足未来五年某区电子Z务业务部署的资源需求。考虑到业务系统性能需求不同、数据存储类型不同（结构化、非结构化、半结构化），因此某区Z务云平台计算需求如下： 云平台需要支持根据业务应用的不同特点分配不同的计算资源，包括采用合理的物理服务器。 能根据业务应用的特点对服务器或存储进行配置满足应用对计算和存储的需要（CPU、内存、网络I/O、存储I/O）。 满足不同数据类型的存储需求，提供SAN、NAS资源池。 计算平台需要和管理平台联动实现对虚拟计算资源的部署和分配。4.2.5 云计算虚拟化需求根据服务器功能分类和业务应72、用的性能需求，经过评估业务应用可以虚拟化后，就可以分别选择不同的虚拟机规格类型。虚拟机规格需要根据各种系统对于CPU、内存、网络和存储的I/O需求不同来进行分类，然后根据操作系统不同，选择不同的虚拟机镜像，然后将这些虚拟机分布在不同的x86物理机上。虚拟化平台管理需要具备如下能力： 基础云资源管理：可对各类硬件资源、虚拟化资源进行统一配置、监控和管理 云平台监控管理: 为用户提供关键性能指标的监控功能，如CPU利用率、内存利用率、磁盘传输速率和网络流量，并提供图形展示界面。 虚拟网络管理: 为用户在Z务云中提供了逻辑隔离的区域，用户可根据业务需求定制网络拓扑、部署云计算资源，实现安全、可靠的私73、有云环境的搭建4.2.6 云服务管理系统需求某区Z务云主要针对各委办局提供相应的资源服务，同时承担全区的资源平台统一运维，因此某区Z务云云服务管理系统主要需求如下：l 运维系统：某区Z务云平台具有平台系统复杂、提供服务众多性、服务对象多样等特点。需要组建统一的基于云计算的运行保障支撑系统为平台提供运行保障服务以保障平台的服务质量达到用户的需求。运行保障服务需要面向基于云计算的平台运行维护者、公共平台的管理者以及平台的使用者（公众、公务人员以及机构用户）。运行保障系统需要运行维护需求主要包括： 实现对虚拟化环境、云计算平台和物理环境的集中监控和管理； 需要管理的对象包括：数据库、操作系统、服务器74、网络设备和安全设备、存储设备、机房设备； 需要建立报表系统，实现对服务管理平台中各种信息的分析和呈现； 支撑系统具有良好的扩展性，以适应平台业务不断的发展；管理平台应当具有良好的开放性，以适应不同环境的管理要求。 结合现状，运行保障服务需求： 新建统一监控平台和云管理，实现计算、存储及虚拟资源以及机房、网络的统一监控、统一管理、统一维护。l 运营系统： 平台需要实现统一的服务受理与交付管理系统，以便用户和平台管理人员实现服务的申请、受理、发放和计量等能力。主要包括： 平台提供统一的服务门户，用户和平台运营管理人员可通过该门户实现服务的在线申请和受理。 平台提供对各类服务的统一管理能力，以便平75、台管理员可以通过目录服务功能实现对服务进行分类、定义、发布、更改、删除、查询等管理操作。 对于通过门户提交的服务申请订单，平台运营管理员可以通过订单管理功能进行处理。 对于使用的平台资源的具体量，公共平台需要能够实现计量，用于公共平台服务能力情况统计分析。 平台需能够为使用服务的用户提供独立的单位用户，用以其管理自己申请的服务。4.2.7 统一云管理需求统一云管平台处于两个ISV的云平台之间，主要面对最终用户（云管理单位、云资源使用单位），以提供各类服务的需求管理、业务管理、资源监控、资源管理、服务管理、计量计费功能为主要任务的云业务管理和服务平台。“统一”是指两个云平台的统一，包括：服务的统76、一、运维的统一、运营的统一、接口的统一。 服务的统一：汇聚两个云平台的服务项的服务目录，提供用户统一的服务查询、下单、服务计量/计费、跟踪、管理等功能。 运维的统一：由统一的界面实现资源监控、运维情况的展现实现各自平台的运维任务、总体情况的汇总，提供用户一个统一的运维状态的控制。 运营的统一：将资源管理、培训等运营任务和服务，统一到一个综合的服务台中，供用户选择、审核、管理。 接口的统一：按照接口的标准化、体系化设计，形成统一的服务、数据、信息、消息、监控等内容的采集与分发。4.2.8 服务目录该表中“服务类别”、“服务子类”应当与招标文件的服务分类汇总表所列的“服务类别”、“服务子类”相对应77、。服务目录应包括但不限于现有表格中所列内容。附：以下为供参考的Z务云服务目录（价格单位为：万元）序号服务类别服务子类服务项服务项计价单位数量单价限价1基础设施服务机房资源服务（物理托管）提供物理托管面积，支持搬迁设备并纳入运维与管理体系中机房空间平米22机房提供物理托管机柜机房机柜个2.53网络资源服务互联网公有IP服务IP服务个0.0254互联网带宽（骨干级）链路1000M755应用负载均衡服务负载实例0.0256安全交换区每IP个0.757视频直播加速流量Mb次0.018计算资源服务CPUCPU核0.0259内存单元内存GB0.02510存储资源服务应用存储空间应用存储TB0.0511数据78、库存储（高性能）数据存储TB0.112NFS/CIFS存储空间500G数据存储TB0.0513近线数据备份服务备份TB0.114离线数据备份服务备份TB0.115数据归档服务备份套0.516软件支撑服务软件支撑服务windows(2008或2012)软件套0.0417国产Linux操作系统服务软件套0.01518国产商业应用中间件软件套0.419开源应用中间件软件套0.1520国产消息中间件软件对0.421开源消息中间件软件对0.422国产商业数据库软件实例0.7523开源数据库软件实例0.2524其它套025安装服务开源中间件安装实施服务VM0.0126开源数据库安装实施服务VM0.015279、7商业中间件安装实施服务VM0.0528商业数据库安装实施服务VM0.07529维护服务开源中间件维护（包含Apache、Tomcat、Jboss等）维护服务套130开源数据库维护（包含Mysql、Postgres等）维护服务套131商业中间件维护维护服务套1.2532商业数据库维护维护服务套1.2533应用入云部署服务应用入云部署服务实施服务次0.7534信息安全技术服务安全防护服务网络访问控制服务安全服务套335入侵防御服务安全服务套0.2536用户安全服务用户管理服务安全服务套0.7537用户身份认证服务安全服务套0.7538安全接入服务VPN接入服务安全服务M0.7539安全管理服务网80、络行为安全审计服务安全服务套0.540安全隐患分析服务安全服务次141数据库审计服务安全服务实例0.7542安全扫描服务常规安全漏洞扫描安全服务次0.1543系统上线安全扫描安全服务VM/次0.1544网站防护服务在线防护WAF安全服务网站0.945网页防篡服务安全服务网站0.75补充安全要求：关于安全部分服务头表然还应满足以下要求。1、提供符合国家等保三级测评要求的安全体系设计，并提供每年的等保测评相关服务（包含测评费用），且按照区内相关安全要求测评分数不低于85分。2、提供满足三级等保要求的安全设备（至少包含：出口防火墙、核心防火墙、入侵防御系统IPS、DDOS流量清洗、WEB应用防火墙、81、负载均衡、VPN、网闸、堡垒机、数据库审计、漏洞扫描）含服务期限内的原厂升级/运维服务工作3、提供专职安全服务团队（含厂商服务）4.3 其他需求分析4.3.1 容灾备份能力需求各委办局需要云平台提供保护用户数据安全的灾备资源服务。因此Z务云平台需要建立统一的数据保护平台。各委办局开通了数据级备份业务之后，可对基于Windows、Linux、Unix操作系统平台的文件、主流数据库和主流应用进行备份和恢复，委办局可自行设置备份策略，自行执行备份和恢复操作。同时平台需要提供异地备份功能，满足系统灾备恢复能力。4.3.2 扩展能力需求能无缝实现对现有业务、应用的拓展，安全稳定，不影响业务运行。4.3.82、3 节能需求节能降耗是IT系统建设中长远关注的重点问题，采取有效策略实现数据中心节能降耗是的重要目标。需求如下 采用先进的节能技术，降低服务器、存储、网络等关键设备的能耗； 采用先进的计算资源虚拟化技术，实现资源共享、提高计算资源使用效率。4.3.4 考核要求Z务云管理单位依据电子Z务云平台服务考核评估方法 (第一版)（电子Z务云平台建设应用工作组2015年2月28日发布）对云平台服务进行考核，考核内容应包含但不限于Z务云平台服务能力评定、Z务云平台服务质量评价和Z务云平台服务使用满意度评价、合同执行考核标准等。按照Z务云管理单位实际购买量，依据考核结果支付服务费用。后期增加的相关需求，由采购83、人按此次中标价格向中标人购买相关服务。依据电子Z务云平台服务考核评估方法 (第一版)进行评分，考核总体得分=服务质量评分*55%(暂定)+服务使用满意度评分*45%(暂定)。总体得分处罚说明60分向中标人扣除考核期内有效的所有资源租赁服务合同总额的15%60分，80分向中标人扣除考核期内有效的所有资源租赁服务合同总额的10%80分，90分向中标人扣除考核期内有效的所有资源租赁服务合同总额的5%在服务期内，云服务商每年需经过考核。4.3.4.1 考核内容要求对于具体的考核内容，将会按照问题的影响程度进行分别的评估。如：Z务云平台应具备高可靠性及冗余性，保证Z务云平台整体的业务连续性不低于99.984、9%等具体的指标将会按照如下表格，在项目正式运行后由运维团队与Z务云的管理单位进行联合制定与具体的考核。Z务云运行过程中可能产生的问题及相应罚款比例序号问题描述考核情况1可用性达不到99.99%（即业务中断时间要求）2数据可靠性达不到99.99%3某网页被篡改4某系统数据丢失5某系统被入侵6云平台全部宕机（非不可抗力造成）7某系统宕机8在云安全监管机构已发出整改通知后未正确处置，造成问题的5 总体设计5.1 总体建设目标通过某区Z务云技术架构规划建设，与现有的平台形成资源统一，能力扩展，服务延伸，为某区政府信息化建设提供安全可靠的云服务，为构建服务型政府奠定基础。通过某区Z务云技术架构规划建设85、，在有效降低重复建设投资、节能环保的基础上，提高基础设施资源的利用率，实现某区信息化基础设施资源的统一规划、统一建设、按需调配、即需即用、有效共享。通过合理规划、小步快跑的方式，在实现建设集约化、信息共享化、服务标准化、效益最大化的同时，满足某区各级用户、各委办局基础设施的应用需求，为某区Z务信息化发展提供有力的信息化支撑保障。5.2 建设内容与规模5.2.1 建设内容某区基础资源平台规划包含如下内容： 规划建设统一的IT资源池基础设施资源包括网络资源、计算和存储资源等，基于云计算的高弹性、高可靠性、高冗余的特点，采用可行的云计算模式，并与“某区”云计算第一节点实现互联互通。在网络资源建设方面86、，基于现有的信息网络平台（Z务公共网与Z务办公网），加强网络安全防护，完善网络管理体系。在计算资源方面，应采用虚拟化技术设计高弹性的计算资源池，并满足部门用户对计算资源不断增长的需求。在存储资源方面，应利用存储虚拟化技术，实现异构存储统一整合和分级共享，提高存储资源利用率，能够快速为用户部署存储空间；按实际用量计费；降低存储成本（存储共享、重复数据删除、数据压缩）；实现弹性扩展；系统管理简单。 规划建设统一的云管理运营运维支撑平台在平台运营运维服务方面，建立统一的运营运维服务体系，制定服务标准和规范，提供满足需求、响应及时、安全可靠的运维保障服务，包括为保障业务应用的顺利部署、开通，以及网络、87、硬件、软件、数据、机房环境等安全、稳定、高效运行而进行的一系列策划、实施、检查与改进过程。5.2.2 建设规模运用云计算技术，统筹利用已有的计算资源、存储资源、网络资源、信息资源、应用支撑等资源和条件，统一建设并为某区政府各部门提供基础设施、支撑软件、应用功能、信息资源、运行保障和信息安全等服务的基于云计算的互联网综合性服务平台，实现服务资源集中管理，健全现有的技术服务管理模式与队伍。面向云服务商，参考当前某区Z务云第一阶段上云的40个系统的情况，对于虚拟资源池规模量，并对生产服务器物理CPU核数的需求，按增加30%的冗余量计算，总规模约为3000核，以1：4的比例估算内存需求规模约为120088、0GB，存储需求规模约为300TB。后续根据建设和实际需求，可平滑进行扩容。5.3 设计原则云计算领域各项技术及产品均处于一个快速发展期，某区Z务云平台建设的技术前瞻性和先进性须在设计方案中得到充分考虑，能够符合主流技术发展趋势，方案总体架构以及产品能够切实达到对某区信息产业业务发展需求作用，同时，还应具有良好的扩展性和升级能力，使系统能顺利地实现向更新一代设备、技术平台的平滑升级。某区Z务云作为未来某区Z务核心业务的载体，由于业务的复杂性和多样性，因此平台设计应能遵守有关的国际标准和行业规范，可以其架构兼容国际、国内主流厂商设备、技术及产品方案，包括国产操作系统等。平台将建成一个可持续运营的89、服务平台，为各局办政府部门提供相应服务、平台的各部分设计均应充分考虑平台的运营需求，并将云平台的运维运营体系作为设计的一个重要部分，为日后的运维需要和运营的建设打下良好的基础。某区Z务云平台技术架构规划设计与建设应当遵循如下原则： 安全可靠性原则l 系统满足高可靠性需求l 系统器件选择要考虑能支持724小时连续长时间大压力下工作；l 系统具有充分的冗余能力、容错能力；l 系统具有专业的技术保障体系以及数据可靠性保证机制；l 对工作环境要求较低，环境适应能力强；l 确保系统具有高度的安全性，提供安全的登录和访问措施，防止系统被攻击；l 异常掉电后不丢失数据，供电恢复后自动重新启动并自动恢复正常连90、接； 先进性原则l 系统必须严格遵循国际标准、国家标准规范要求；l 需符合存储技术以及IT行业的发展趋势，所选用的产品型号已规模上量；l 所有的系统处于先进的技术水平，确保较长时间内技术上不落伍；l 系统的处理能力要达到业内领先，对于本次业务的使用要留有一定的余量，以满足后续升级的需求； 开放性原则l 系统必须支持国际上通用的标准网络存储协议、国际标准的应用开放协议；l 与主流服务器之间保持良好的兼容性；l 兼容各主流操作系统、卷管理软件及应用程序；l 可以与第三方管理平台集成，提供给客户定制化的管理维护手段；l 满足今后的发展，留有充分的扩充余地；l 各主流厂家的硬盘均可接入； 易维护性原则91、l 系统支持简体中文，通俗易懂，操作方便、简单；l 系统具有充分的权限管理，日志管理、故障管理，并能够实现故障自动报警；l 系统设备安装使用简单，无需专业人员维护；l 系统容量可按需要在线扩展，无需停止业务；l 系统功能扩充需要升级时，支持不中断业务升级；l 支持WEB管理方式或集中管理方式； 扩展性原则l 系统易于扩充；l 系统选择标准化的部件，利于灵活替换和容量扩展；l 系统设计遵守各种标准规定、规范； 经济性原则l 综合考虑集中存储系统的性能和价格，最经济最有效地进行建设，性能价格比在同类系统和条件下达到最优。 绿色性原则l 满足环保与节能的要求，噪声低、能耗低、无污染；l 有节能降耗的92、技术手段；l 具备环境管理认证，符合环保规定，包材可回收，支持重复利用。5.4 总体技术架构设计区级云架构：由设施资源层、中间平台层、业务应用层组成，在Z务云管理体系和安全体系保障下，通过各类用户终端，为政府内部提供统一信息化支撑，向社会公众提供高效外部服务。参见下图5-1所示：图5-1：某区云平台总体技术架构示意图5.4.1 设计思路云数据中心的建设是一个复杂、社会化的工程，应立足于较高的建设起点。以长远的观点通盘考虑，应充分考虑目前业务系统的内部整合、资源灵活应用、调配、高可用、统一管理的业务需求。而且在信息技术、实现技术和平台技术等方面都要提出很高的要求。以“统筹规划、资源集约、服务高效93、”为原则，坚持“五统、四化、三集”，某区Z务云平台技术架构的的统一规划、统一建设、统一标准、统一管理、统一运维，实现某区Z务云平台的设计标准化、建设集约化、资源共享化、运维一体化，实现资源集约、数据集中、业务集成。通过技术环境与其承载的数据和业务系统相分离，推动某区政府信息化建设项目的过程优化、内容简化，实现“平台上移、服务下延”，为某区政府信息化建设提供“资源统筹、管理高效、调配弹性、按需分配”的优质服务。5.4.2 服务实现架构考虑到各委办局业务特点，各委办局以虚拟数据中心（VDC）的方式提供资源服务。每个委办局根据业务需求，申请对应的VDC资源，其中根据业务部署的区域不同VDC划分为互联94、网应用与Z务应用，根据负载情况划虚拟化资源池、物理资源池、数据资源池等。统一电子Z务外网出口，统一互联网出口。参见下图5-2所示：图5-2：某区云平台服务实现架构示意图平台需要实现： 模板化VDC，业务分钟级上线：通过预先定义完成的VDC（虚拟数据中心，Virtual Data Center）模板，进行自动业务发放，省去了传统方式所需要的数据中心基础设施规划建设安装调试等复杂繁琐的步骤，一次建模多次使用，大大缩短了建设周期，同时可视化，面向应用的快速建模，用户可以根据不同的业务需要简单灵活地定制。 统一管理：通过统一管理工具及面向用户界面来管理和维护所有数据中心基础设施、IT基础设施和上层应用95、，极大的简化了管理和提高了效率。 跨域资源池灵活调度，提高资源利用率：通过云操作系统，利用虚拟化技术将分散在各个数据中心的计算，存储，网络资源纳入到一个统一的资源池中，实现跨域资源池的灵活调度，满足业务要求。5.4.3 总体逻辑架构某区电子电子Z务云总体逻辑架构如下图5-3所示：图5-3：某区云平台总体逻辑架构示意图某区Z务云根据用户业务系统的服务对象和使用对象的不同，主要包括互联网服务应用、Z务外网办公应用，因此 总体逻辑上在Z务外网划分为互联网区和Z务外网区，跨区进行逻辑隔离。同时两个区进行统一的运营运维管理。业务区根据业务特点划分为虚拟化资源池、物力资源池、数据资源池。存储区进行统一存储96、，根据数据类型的不同划分不同的资源池。如结构化数据采用SAN存储资源，非结构化数据采用NAS存储资源。5.4.4 Z务云体系Z务云体系：以“集中+分布”为建设原则，以政府购买服务的方式，依托Z务外网，统一为各部门提供服务。逐步实现各部门云向区级云分中心整合。全区最终形成“1+N”区级云体系，因此从某区电子Z务云的角度出发的区级云体系如下图5-4所示图5-4：某区Z务云体系示意图6 项目详细建设方案6.1 基础设施平台设计方案6.1.1 机房设计本期项目是Z务信息化发展的重要基础，因此机房的建设应当适应Z务信息化要求的服务、安全、耗能、规模等各方的要求。因此，在机房建设或选取上，遵循市场现有的机97、房建设分级制度，将会参考选取A级机房，并会优先选取具备国家等保三级要求相关标准的机房。6.1.1.1 机房服务内容l 机房空间服务提供Z务云平台设备部署，扩容，现场办公环境。具备在同一层机房场地空间中平滑扩容到100个机柜的能力（按照实际需求）；提供机房同地点处的办公场地及办公环境，供云平台使用单位使用，用于测试、应用部署及后期业务系统迁移等工作。同时，按照电子信息系统机房设计规范GB50174-2008规定的A类机房相关标准为Z务云平台提供一个安全可靠的部署环境。l 机房机柜服务提供设备安全部署可靠运行所需的环境(温湿度、磁场干扰等)、低密度区每机柜不低于3KW，高密度区每机柜不低于5KW。98、遵循国家有关绿色机房的建设要求。同时，按照电子信息系统机房设计规范GB50174-2008规定的A类机房相关标准为Z务云平台提供一个安全可靠的部署环境。l 机柜机位服务可按客户要求部署利旧设备可按客户要求对资源进行物理和逻辑隔离，且需要在机房内划分独立区域，满足多个云平台资源区和独立资源区域划分要求。3. 服务带来价值提供Z务云平台设备部署，扩容，现场办公环境。为Z务云平台提供一个设备安全可靠的部署环境。6.1.1.2 A级机房建设要求序项目要求1空调机房环境温湿度：温度： 冬季：202夏季：232温度变化率5/h相对湿度： 50%5%洁 净 度： 符合标准ASHRAE52-76，粒度0.5m99、m，个数10000粒/dm噪 声： 关闭主设备的条件下，在工作人员正常办公位置处测量不高于68dB(A).(GB)机房单位面积的冷负荷为：257w/m2h系统控制室单位时间换气数：23次/h数据中心机房单位时间换气数：22次/h2防火采用高灵敏度火灾自动报警系统；采用环保型FM200气体灭火系统；FM-200气体火火系统保护区及存储环境温度为054，存储压力25kg/cm2本气体灭火系统能以自动、机械手动和远程启动三种方式启动；设有备用电源，操作时间为24小时。所有气体灭火保护区的维护构件满足一定的抗压要求，其允许压强差不低于1.2kPa。防护区的隔墙和门的耐火极限均不低于0.6h；吊顶的耐火100、极限不低于0.25h灭火系统在启动前能自动检测被保护区区是否有人员存在；火灾发生时，自动声光报警，警示相应区域人员撤离。3门禁系统选用系列感应卡式门禁设备，并具有联机管理功能4防雷满足执行10/350us坡形，可防护雷电流150kA对建筑物的破坏。建筑物内部的计算机机房用电器可承受 10/350us 75kA的雷电流的冲击5地板抬升系统阻燃性： 60REI抗静电性： 105-109隔 音： 大于32DB集中承受力 2000-7000N地板抬升高度350mm分散承受力 15000-35000N/ m26漏水检测系统漏水检测系统可提供24 X 7X365的实时检测。7布线布线系统在每个机架上提供结101、构化布线槽，为每个机架提供局域接入服务。机架布线槽有两种规格：16端口或8端口。采用超五类布线系统。综合布线系统采用下走线方式布线。8机房接地系统根据计算机系统的要求，提供的接地包括交流工作地、安全保护地及防雷保护地，计算机专用直流工作地，其接地电阻1W。机房的静电电压1KV。镀锌钢管、金属软管、金属接线盒外壳等均进行了可靠接地。机柜外壳、金属管道及支架等均接地，中性线则只在变压器处。9机架系统采用19英寸标准网络机柜，机柜高度为42U,机柜深度为800mm,机柜采用全钢材料，承重为600KG。机柜提供可选的风扇单元，可支持冗余的六个风扇。可选走线槽，托隔板，线管理器。10监控系统监控系统可对102、整个数据中心的工作空间进行监视。人员主要出入口及设备较为集中的房间（空调室，机房）设置固定式彩色CCD摄像，在走道等设置旋转式彩色CCD摄像机。存储系统支持对图像进行五个小时的记录、存储。11装修在装修豪华，气派的同时，具体施工指标遵循相关国家标准。12电力供应 强电系统采用双路强电引入，每个机架都通过配电柜引出单独的供电线路到机架，每个机架可用电源功率5KVA13电力供应 UPS系统机房UPS系统和备用柴油发电机系统共同提供IDC冗余电源。UPS 系统的建设容量为断电后满足以下系统用电15-30分钟。机房设备用电；应急照明；门禁系统用电；空调用电；消防系统用电。 14电力供应 备用柴油发电机103、系统柴油发电机系统设计为N+1冗余备份系统，额定功率NIDC 各系统功率之和。设计储油满足油机系统运行时间小时。6.1.1.3 其他要求为兼顾线路成本与应急运维需求，选取的云机房将保证与某区政府直线具体小于5公里。同时，对于云服务商提供的云机房应当是自有资产。且IDC机房应具备良好的硬件条件，包括机房空间、空调、电源、监控、消防、安全及日常办公空间。6.1.2 网络系统设计6.1.2.1 设计原则1. 模块化应考虑到业务的调整及发展，网络结构和系统结构要模块化、易于扩展。POD（Point of Delivery）是是最成熟的设计理念和方法。POD既可以是物理的、也可以是逻辑的数据中心功能模块104、，一个POD，可以包含机柜、服务器及网络设备、以及相应的配套基础设施；特定的POD可以只包含网络资源，或者服务器资源，或者存储资源。POD是数据中心建设的一个基本组件，一个业务分区可以由一个或者几个POD组成，后续业务也将以POD为基本组件进行扩展。模块化部署有如下优点。 易扩展，灵活的模块化设计方式，根据业务需求扩展，缩短规划部署周期。 提高投资利用率，降低维护成本。提高能源利用率，冷热通道分离，符合绿色与节能原则要求。针对电子Z务公共云网络，在互联网区和Z务外网区如需要扩展网络，只需要再添加接入TOR即可。2. 高可靠网络设计中采用冗余网络设计，实现关键设备、链路冗余；关键设备选用高可靠性105、产品，可实现单板、模块热拔插、控制模块设计冗余、电源冗余；减少网络层级，简化网络结构，从组网架构上提高可靠性。在本次电子Z务公共云网络中，可靠性包括设备可靠性，组网可靠性等可靠性设计全方位的提高整网可靠性.3. 安全隔离数据中心网络应具备有效的安全控制。按业务、按权限进行分区逻辑隔离，对特别重要的业务采取物理隔离。以服务器为中心的业务、IP存储备份、管理网络等多个网络进行逻辑隔离，管理网络采取物理隔离。4. 可管理性和可维护性网络应当具有良好的可管理性。为了便于维护，应尽可能选取集成度高、模块可通用的产品。5. 网络自动化通过提供北向API，由上层管理软件通过调用API接口，实现网络自动化，提106、供即时的网络服务。为业务快速上线部署提供网络环境。6.1.2.2 网络总体架构设计对于电子Z务公共云平台网络部署在生产中心机房和灾备中心机房两个专用数据中心机房，根据数据中心承载的业务特点划分为互联网区、Z务外网区、安全管理区、网络核心区、计算区和存储区。这6个区域又可以进一步细分为11个子区域：互联网区、Z务外网区、运行管理区、安全管理区、网络服务区、计算资源区、物理资源区、大数据资源区、桌面云资源区、SAN存储、NAS存储。电子Z务数据中心区域划分序号区域子区域部署产品位置1互联网区互联网区包括为公众提供服务的软硬件新机房2Z务外网区Z务外网区部署各委办局Z务外网业务以及专网业务新机房3管107、理区安全管理区部署满足等保要求的相关安全设备和软件新机房4运行管理区服务运营、运维监控平台新机房5网络核心区网络服务区核心交换机+防火墙、链路负载均衡、DNS服务器等新机房6计算区计算资源区基于OpenStack技术的服务器虚拟化资源池新机房7物理资源区物理服务器资源池，承载技术上不适合部署在虚拟化平台上应用、软件（例如：高IO数据库）新机房8大数据资源区部署Hadoop平台的物理服务器资源池新机房9桌面云资源区服务器虚拟化资源池，部署桌面云虚拟机新机房10存储区域SAN存储FC接口、IP接口的块存储平台和存储虚拟化网关新机房11NAS存储文档、视频、音频、图片等文件存储设备新机房6.1.2.108、3 网络系统详细设计对应逻辑架构，数据中心的物理架构如下所示详细设计特点如下：1. 网络分层设计数据中心融合、虚拟化技术的应用对网络提出了更高的要求，需要更低的延迟、更高的吞吐量和更高的可靠性，为此，数据中心内部核心网络架构采用扁平化二层网络架构（核心层、接入层），使用网络虚拟化技术，核心层交换机承担着核心层和汇聚层的双重任务。核心层采用CSS虚拟集群技术，将两台核心交换机虚拟为一台设备，设备背板共享，交换能力提高。接入层采用堆叠技术，将两台或多台接入交换机虚拟为一台设备，设备背板共享，交换能力提高。扁平化二层网络架构中，采用虚拟集群和堆叠技术，解决链路环路问题和spanning-tree收敛109、问题，解决二层链路环路简化，网络拓扑为树形结构，提高链路利用率和网络的可靠性。二层网络设计的优势如下：l 简化网络结构，降低维护管理成本能够减少网络中的交换机和链路数量，从而降低前期购置成本和后期维护成本。l 网络性能提高，支撑高性能的服务器流量通过减少交换层数量，流量需要穿越的交换机数量也会减少，从而可以缩短延迟，提高应用性能。l 网络利用率提高，支撑云计算的资源池动态调度采用Eth-Trunk链路聚合技术，带宽利用率可以达到100。扁平化的大二层网络设计支持云计算对于计算资源池和存储资源池任意按需调配的要求。l 网络可靠性提高减化的网络通过虚拟集群和堆叠技术，可以消除网络中的可靠性隐患，无110、需运行spanning-tree协议，降低网络的故障收敛时间，从而提高网络可靠性。2. 网络平面设计由于采用了虚拟化技术，云平台的管理系统与计算资源和存储资源需要在网内交换大量的管理和监控数据；虚拟机需要挂载存储区的存储资源，也需要海量的数据在数据中心网内传输；同时，网内还要传输虚拟机的业务数据，为了更好地支持这三类业务数据的传输，在数据中心内部将网络划分管理、业务、存储三个平面，三个网络平面相互隔离，互不影响。l 业务平面用来承载用户端到数据中心各个业务应用系统的流量以及数据中心内部云主机之间的的流量，业务平面按照业务类别的需求进一步划分为不同的业务服务区。l 管理平面用来承载数据中心网络、111、服务器、存储及安全等设备之间的管理数据、指令操作数据以及云计算系统的维护和监控数据。管理平面与业务平面共用核心层交换机，通过VLAN实现两个平面的隔离。l 存储平面用来承载计算子系统和存储子系统之间的存储流量。存储平面网络是一个独立的隔离网络，保证存储网络的服务质量和安全。3. 网络功能区设计按照数据中心云业务特点，将数据中心分成网络核心区、Z务外网区、互联网区、安全管理区、存储备份区等。l 网络核心区数据中心内部网络分为核心与接入2个层次，以及管理、存储、业务3个平面，并且在业务网络平面分成多个业务功能区。并部署防火墙FW、Anti-DDoS、应用负载均衡设备LB、SSL VPN设备等业务网112、关设备以及安全审计软/硬件设备，用于提供IPS/IDS网络安全、负载均衡、网络接入控制等功能。l 互联网区用于数据中心与多个互联网运营商网络互联，为数据中心提供高速的互联网出口链路，实现数据中心与互联网之间的互通。数据中心提供面向公共的业务服务，为整个数据中心提供web应用服务和web服务等。l Z务外网区用于部署政府职能业务，并提供各委办局行业专网的接入，满足政府各部门协同共享办公的需求。l 安全管理区用于数据中心管理，部署运营管理软、硬件设备，实现业务申请、退订和自动化发放功能。部署运维监控平台，监控整个数据中心的设备性能，包括服务器、网络、存储、网络、安全设备等。同时做为带外接入管理使用113、，在紧急情况下，通过维护窗口接入到数据中心。l 存储备份区存储备份区使用单独的网段进行数据传输，数据流与业务平面分离，独立运行，保证链路状态冗余、可用。6.1.2.3.1 网络核心区设计数据中心网络核心层的设计规划图如下图所示。网络核心区二层网络架构设计图 核心层：2台数据中心专用核心交换机采用CSS虚拟集群技术，下行链路选择40GE链路捆绑技术与接入交换机互联，增加带宽的同时也提高了网络链路的可靠性。 接入层：2台万兆接入交换机采用堆叠技术，下行链路根据服务器的物理端口选择GE或10GE链路，上行链路选择10G或40G链路做捆绑，上联到2台核心交换机，增加带宽的同时也提高了网络链路的可靠性。114、 核心交换机和接入交换机之间的四条跨框链路捆绑为一个Eth-Trunk组，网络架构变成树型模式，不需要启用STP协议，从根本上解决环路和spanning-tree收敛问题。6.1.2.3.2 网络服务区设计网络服务区部署防火墙、入侵防御等业务安全设备，为业务区的客户提供可选择的防火墙、IPS、IDS等服务。业务服务区的服务器可以选择防火墙服务、负载均衡服务。组网结构网络服务区网络架构示意图如下图所示。组网对接说明： 网络服务区由两台防火墙FW，两台负载均衡、两台IPS设备组成。业务网关设备均采用双机热备方式部署。 防火墙、LB、IPS等业务网关设备旁挂核心交换机，并通过2条GE电路与核心交换机115、进行互联，分别用于承载入方向和出方向的流量；可以为客户提供有选择性的增值服务，供客户选择。 外部用户访问数据中心业务服务区的业务系统，数据流要先经过网络核心区的核心交换机，再根据用户选择的增值业务服务情况，将流量转发到防火墙和负载均衡、设备。 防火墙通过划分子接口，定义不同安全等级的安全域，对不同业务服务区进行安全防护，实现不同业务服务区间互访的控制，不同业务服务区的安全隔离。 提供虚拟防火墙服务，针对有较高安全防护需求的客户提供虚拟防火墙服务，为客户的网络设置专用的虚拟防火墙，定制个性化的安全防护策略。 防火墙服务访问流程，互联网用户发起业务服务区的连接请求；连接请求通过外联区访问到网络核心116、层的核心交换机；核心交换机将请求的路由指向网络服务区的防火墙；防火墙执行路由过滤后，数据流再回到核心交换机到达要访问的业务系统中。 负载均衡可以保障内部资源的容错性，内部任何一个应用节点出现问题都不会对用户造成任何的影响；负载均衡可以增强业务扩展性，业务扩展时只需要增加相应的内部服务器即可。 IPS设备将用户的应用数据流进行检测和阻拦。6.1.2.3.3 防火墙部署设计网络核心区防火墙一般旁挂在核心交换机上，对于防火墙设计要求包括： 可靠性，能够支持双机备份。 高性能，一般是框式设备，避免成为业务的瓶颈。 扩展性好，能够支持增加板卡满足业务扩展的性能要求。 能够支持虚拟化，满足不同业务分离的要117、求。防火墙旁挂的方式的优势：旁挂方式业务部署灵活，可以根据业务安全等级，选择是在ingress方向通过防火墙，还是egress方向通过防火墙或者都不经过防火墙。每个防火墙与核心交换机都直接连接，保证业务可靠性。防火墙用1个端口连接交换机，使上下行流量分离。在业务增长之后，增加上下行互连端口数量。具体拓扑如下图所示，防火墙运行在三层模式。两个防火墙使用双机热备方式。两防火墙形成VRRP备份组。引流采用核心交换机使用策略路由。防火墙部署设计图6.1.2.3.4 安全管理区设计安全审计区部署满足等保要求的相关安全设备和软件。安全管理区的网络架构示意图如下图所示。安全管理区网络架构图安全管理区包括数据118、库审计、身份认证、运维审计、日志审计、漏洞扫描、网页防篡改、应用监测、接入交换机等设备。6.1.2.3.5 运行管理区设计运行管理区提供数据中心运营、运维能力；提供用户访问自助服务和运营管理员访问运营服务，因此需要考虑较高的可用性和更全面的安全防护措施。同时对数据中心中包括路由器、交换机、防火墙、服务器、存储，以及各种应用软件等系统进行统一管理与监控；同时用于部署运维管理、监控等相关的服务器、控制主机、运维客户端等运维设备。组网结构管理区网络架构示意图如下所示。管理区内服务器资源，存储资源的网络部署方式与业务服务区相同，接入交换机工作在堆叠模式，每台接入交换机上行通过链路聚合与核心交换机相连。119、通过核心防火墙的安全域进行隔离。管理网络交换机旁挂两台防火墙，用于网络隔离和访问权限控制。数据中心的运营管理服务器均部署在业务管理区，运营管理区部署业务数据库，同时通过统一门户实现运营管理。6.1.2.3.6 业务服务区设计业务服务区：是政府机关提供服务的业务区，需要考虑较高的可用性和更全面的安全防护措施；业务服务区包括虚拟资源区、物理资源区和开发测试区等。业务服务区按照层次化、模块化的设计理念，各个功能分区的业务主机通过相应的接入交换机进行汇接，双链路上联到网络核心交换机上。业务服务区的各种业务数据流如下图所示。第一种，是没有特殊服务要求的业务系统。业务流的方向是通过接入层交换机，VLAN透120、传到核心交换机，在核心交换机进行三层终结，直接通过路由的方式到达外联区的防火墙设备；该种情况，业务系统的IP网关设置在三层交换机上。第二种，是只需要LB服务的业务系统。业务流通过接入层交换机，VLAN透传到核心交换机，并通过互联电路VLAN透传到LB设备，进行三层终结；然后通过另一条互联电路路由到核心交换机，并通过路由的方式到达外联区的防火墙设备；LB设备可以实现入流量的应用负载均衡，该种情况业务系统的IP网关设置在LB上。第三种，是只需要防火墙服务的业务系统。业务流通过接入层交换机，VLAN透传到核心交换机，并通过互联电路VLAN透传到防火墙设备（采用虚拟防火墙），进行三层终结；然后通过另一121、条互联电路路由到核心交换机，并通过路由的方式到达外联区的防火墙设备。该种情况业务系统的IP网关设置在防火墙上。第四种，是同时需要防火墙和LB服务的业务系统。该业务流程相当于将第二种和第三种情况进行综合。业务流通过接入层交换机，VLAN透传到核心交换机，首先到达LB设备，再到达防火墙设备，然后通过核心交换机路由到出口防火墙；LB设备可以实现入流量的负载均衡的功能。该种情况，业务系统的IP网关设置在LB设备上。图6- 1业务服务区及管理区网络架构示意图6.1.2.3.7 多租户网络设计不同的租户的资源在数据中心是完全隔离的，为租户的网络资源、计算资源、存储资源提供端到端的隔离。通过虚拟防火墙、VR122、F、VLAN等技术将不同租户之间的云数据中心资源隔离开，租户可以自由设置网络路由、安全策略、绑定弹性IP地址、配置服务器网关等，同时支持不同租户的IP地址的重叠。每个租户的计算资源采用独占的CPU和内存来实现不同租户之间的逻辑隔离，不同租户之间的计算资源不互相影响。存储资源通过数据卷映射到每个租户的虚拟机上，存储上每个数据卷都是逻辑隔离，同一个租户下的存储资源可以互相访问，不同租户之间的存储资源不能访问。能够在以较低成本合理利用资源，优化资源利用率。数据中心必须具备不同租户资源的隔离设计，确保端到端的隔离以及满足租户的安全要求。为了支持多租户，分布式云计算数据中心采用虚拟化技术，在逻辑上划分成123、多个（每个租户）虚拟网络环境，每个虚拟网络拥有独立的路由表、地址空间、安全服务、配置管理。这些依赖于设备虚拟化，包括以下方面：6.1.2.3.8 计算网络设计传统上，在物理服务器层面的安全政策能够顺利实施。然而，服务器虚拟化和流动性带来新的安全挑战和问题，实际上，为了应对这些挑战，虚拟机满足从主机到主机的迁移之后能够正常使用，策略必须基于虚拟机实施并能够跟着虚拟机的迁移而迁移。每个租户的数据流在基础设施的计算层的分离利用以下技术： VLANs提供二层网络不同域之间流量的逻辑隔离。 Port group将具有相同网络属性的虚拟机放在同一个port group中，同一个port group有相同的124、网络策略、安全策略。不同的port group组能够相互隔离。6.1.2.4 机房互联设计为更好的支撑电子Z务，充分利用灾备中心机房实现Z务业务的容灾备份，采用裸光纤方式实现管理网络、业务网络和存储网络进行互联，并接入Z务外网和互联网为相关的单位和市民服务。Z务云机房互联拓扑示意图机房之间的存储层面，通过建立互联的光纤网络，实现灾备数据的快速传输。6.1.3 计算存储系统设计6.1.3.1 计算处理能力6.1.3.1.1 CPU根据电子Z务各类业务系统的特点，对于CPU的处理能力评估如下。计算输入：每分钟业务交易量（TASK），复杂程度比例（S），CPU利用率（C），业务发展冗余（F），峰值交125、易时间（T）。计算过程：tpmC=TASKSF / (TC)TASK：为每分钟业务交易量S：为实际查询业务交易操作相对于标准TPC-C测试基准环境交易的复杂程度比例。由于实际的查询业务交易的复杂程度与TPCC标准测试中的交易存在较大的差异，须设定一个合理的对应值。以普通业务交易为例，一笔交易往往需要同时打开大量数据库表，取出其相关数据进行操作，相对于TPC-C标准交易的复杂度，要复杂很多，通常取值范围为130（取值越大，说明系统越复杂）。C：为主机CPU处理余量。实际应用经验表明，一台主机服务器的CPU利用率不应高于75%，根据业务需求一般设定C=50%，即CPU处理余量为1-0.5=0.5。126、F：为系统未来n年的业务量发展冗余预留，要为将来陆续加入的应用预留30%的处理能力，即如果是为3年的业务发展余量即计算公式为（1+0.3）3=2.197。T：为峰值交易时间根据Z务云平台实际特点，按照最大并发访问压力的情况来计算，对于每秒2000次业务访问量的业务系统，那么每分钟就有120000次业务访问量的业务系统，峰值交易时间为1分钟，在5年内数据库服务器的TPC-C值估算，如检索查询的经验系数取值7.5：tpmC=TASKSF/(TC)=(200060)7.5(1+0.3)5 /(1(1-0.5)= 6683274 tpmC即，需要一台tpmC值为不小于6683274的作为大并发量访问Z127、务业务系统场景下的服务器。6.1.3.1.2 内存根据电子Z务各类业务系统的特点，对于内存的所需容量评估如下。计算输入：关于内存的配置，根据我们的经验，认为内存的消耗主要包括如下几个部分： 主机系统正常运行所需消耗（主要指操作系统消耗）； 数据库运行所需开销； 数据库SGA运行所需正常开销； 联机事务处理消耗；计算过程：内存=操作系统+数据库管理系统+数据库SGA运行连接数*3M因此从上边我们可以看到服务器系统所需内存大小由四部分组成。根据电子Z务业务系统的特点，对于高并发访问的数据库类Z务应用，每个连接占用的内存为2M到3M之间。通常情况下操作系统占用500MB内存，数据库管理系统约占用25128、6MB，内存利用率不大于70%，检索系统数据库的SGA运行需要50G，同时并发查询访问的连接数为2000，则此类高并发访问的数据库Z务应用所需内存为：(512M/0.7+256M/0.7+20003M)/1024+50G=59.45G从而得出需要至少64G内存。6.1.3.2 存储处理能力一般的电子Z务类相关业务通常会从三个维度提出存储的需求： 存储的性能维度 存储架构维度 存储容量维度业务提出存储资源的需求后，需要对设备的IOPS、存储容量、存储带宽进行计算。6.1.3.2.1 存储性能维度存储产品的选择通常是根据存储性能指标，即IOPS值。因为Cache命中率与实际业务相关，所以计算不考虑129、Cache命中。计算输入：服务器的tpmC，IO经验值，未来发展冗余。计算过程：存储性能（IOPS）=TPMC/TSFTPMC：服务器的性能指标T：每分钟的业务交易量，如果按照秒来计算即T=60。S:经验值。根据行业经验，tpmC复杂度是和交易内涵，交易环节，硬件配置，软件效率等综合表现。通常1个tpmC复杂度会有几个读，写，修改等操作组成，大约整体会形成2030个IO左右，我们取稍为高些合理范围内，那么大约为30个IO。由于将来还包括统计查询操作的业务批处理，因此，IO相对较高，根据行业经验，取80100个IO，为此，我们整体IO按50个计算。F:未来发展的冗余，随着业务量和用户数据的增长，130、会对已采购存储产生性能影响，因此在配置存储时会对未来几年做预估，一般按照每年10%30%的发展速度来计算，综合区值为20%，即如果存储是按照5年的规划制定，那么F=（1+20%）5 =2.49按照一般Z务业务模型评估，服务器的TPMC为100万，存储性能按业务发展规划为满足未来3年需求，则要求的存储IOPS为：100万6050(1+20%)3 = 144万 IOPS ;6.1.3.2.2 存储架构维度从存储的结构上划分为IP-SAN、FC-SAN、NAS三种，其中NAS主要做为辅助存储使用，因此本章节的计算，主要是针对IPSAN和FCSAN的选择而制定。 实际带宽值实际带宽=BULS架构衡量标131、准： 应用数据库主要分为OLTP和OLAP两种访问模式，分别为随机读写和顺序读写，根据大型应用的特点，OLTP的应用为OLAP的9倍，即OLTP：OLAP9：1。根据此特点，我们以oracle数据库为例，通常oracle中默认的数据块定义为8KB，针对OLAP通常需要的数据块为64K。B:带宽。为IPSAN或者FCSAN主流带宽值。根据IPSAN和FCSAN的特点，目前主流的网络架构IPSAN的带宽为1000M、FCSAN的带宽为4000M。U：带宽利用率。无论是IPSAN和FCSAN在传输数据是都无法100%的利用带宽，因此次数据值为实际传输数据时的真实比率。通常FCSAN为80%，IPSA132、N为60%L：包头损失率。在数据封装过程中会造成传输效率的丧失，因此此比例将真实的描述出数据在封装过程中的带宽损失比率。通常FCSAN为1（即无损失），IPSAN为20%S：bit和byte的转换值，1Byte=8Bit，值为8。1）IPSAN带宽利用率为60，其中包头分析会损失20性能，因此IPSAN千兆带宽的利用率为：1000M60（120）860M2）FCSAN带宽利用率为80%，因此FCSAN4G的带宽利用率为：4000M808400M 带宽要求的推导过程计算输入：在线并发数，OLTP和OLAP占比计算过程：带宽要求=TASK（X%OLTP 数据块大小+ Y% OLAP数据块大小）架构133、衡量标准：应用数据库主要分为OLTP和OLAP两种访问模式，分别为随机读写和顺序读写，根据大型应用的特点，OLTP的应用为OLAP的9倍，即OLTP：OLAP9：1，因此X为90，Y为10。根据此特点，我们以oracle数据库为例，通常oracle中默认的数据块定义为8KB，针对OLAP通常需要的数据块为64K。按照区政府和各委办局、街道办的规模进行估算，对于一个22500人使用的业务系统，在线并发数为2250人/秒，其中每人每秒提交2个事务请求。带宽要求= 22502（908KB1064KB）59.8M如果按照性能维度和架构维度的计算的结论，需要选择IPSAN。6.1.3.2.3 设备存储容134、量计算计算输入：单盘标称容量、RAID类型和规划、热备盘配置、保险箱盘容量、磁盘总数计算过程：容量需求=当前应用的总容量/存储冗余*未来发展的容量需求当前应用总容量：Z务部门当前所有业务系统针对存储的总容量。存储冗余：磁盘阵列在经过做RAID、增加热备盘后有很大损耗，一般考虑损耗率35%。未来发展容量需求：一个Z务部门应该是处在不断地发展中，随着它的发展，自身的Z务部门人数、用户数都在不断地增长，因此存储需求也在增长，存储按照每年20%的速度增长，如果是考虑3年内的存储的容量需求，那么应该是（1+20%）3=1.7286.1.3.3 计算场景设计6.1.3.3.1 物理服务器物理服务器是传统数135、据中心使用的计算系统，它能够很好的将系统软件的性能表现出来。以下介绍物理服务器在相关场景的具体应用场景。下表6-1将按照应用的类型，同时针对对应的业务场景进行描述。表6-1：应用资源需求及业务场景分析表应用类型应用需求CPU需求内存需求常见业务场景推荐服务器类型通用管理应用系统通用类型LL一般基础管理系统（WEB、检索引擎、DNS、DHCP、AD、FTP、FileServer）二路工具类应用系统工具类型LL基本的工具类应用系统（如打印控制、报表、OCR、流媒体、网页抓取、）二路大访问量应用系统浏览密集型HH政府门户网站、气象查询系统、WEB中间件服务器等四路访问读密集型MH影视播放网站二路计算136、密集型HH高性能计算集群数据库应用服务器数字城管GIS地理信息系统等图像渲染四路访问写密集型HH流媒体数据库数据仓库四路其他特殊需求HH数据库中间件一体机、高端服务器6.1.3.3.2 虚拟化对于不同业务的服务器需求，首先需要判断该业务服务器是否能够采用虚拟化方案，不能虚拟化的则需要采用满足实际需求的服务器进行配置，其他的则建议统一采用虚拟化方式，根据采集或预估的计算资源需要采用相应配置的虚拟机来满足该需求。下列条件下，建议直接使用物理机来满足业务对计算资源的需要： 对服务器运算性能要求特别高，在单个物理服务器上配置最大计算能力的虚拟机依然不能满足业务应用的计算能力要求； 对显卡处理能力要求特137、别高的业务应用； 现有软件许可加密方式不支持虚拟化的场景； 业务应用对服务器有特别板卡要求且板卡不支持在虚拟化环境中运行。根据业务应用的特点，对应用的虚拟化建议如下表6-2所列：表6-2：虚拟化适应性分析表应用类型应用需求CPU需求内存需求网络带宽需求存储空间需求存储IO需求存储带宽需求虚拟化适应性通用管理应用系统通用类型LLLLLL适合大计算量应用系统计算密集型HHMLMM适合大访问量应用系统浏览密集型HHHMML适合说明：H：高、M：中、L：低。对应用虚拟化的适应性也可以采用当前主流的应用分层（Web服务器、App服务器、DB服务器）来进行考虑，通常情况下虚拟化比较适合Web服务器和App138、服务器。DB服务器需要根据业务应用对存储I/O的需求来评估，如果业务应用的DB服务器I/O要求大或DB服务器有HA或集群需要，建议将该种业务应用的DB服务器部署在物理服务器上。根据服务器功能分类和业务应用的性能需求，经过评估业务应用可以虚拟化后，就可以分别选择不同的虚拟机规格类型。6.1.3.4 存储场景设计6.1.3.4.1 FC SANFC SAN存储结构的核心是FC，存储设备与服务器通过HBA卡（Host Bus Adapter）、光纤和FC集线器或FC交换机连接。数据存储系统与服务器之间通过FC实现多对多（Any-To-Any）连接。采用高带宽FC链路，可以避免大流量数据传输时发生阻塞139、和冲突，特别适合高速和不间断数据传输。FC SAN由三个基本的组件构成：接口（如SCSI接口、FC接口等）、连接设备（FC集线器或FC交换机）和通信控制协议。这三个组件再加上附加的存储设备和独立的SAN服务器，就构成一个FC SAN系统。FC SAN提供一个专用的、高可靠的基于光通道的存储网络。 FC SAN是一个专有的、集中管理的信息基础结构，它支持服务器和存储之间任意的点到点的连接，FC SAN集中体现了功能分拆的思想，提高了系统的灵活性和数据的安全性。FC SAN以数据存储为中心，采用可伸缩的网络拓扑结构，通过具有较高传输速率的光通道连接方式，提供SAN内部任意节点之间的多路可选择的数据140、交换，并且将数据存储管理集中在相对独立的存储区域网内。典型的FC SAN组网如下图6-1所示：图6-1：典型的FC SAN组网结构示意图FC SAN优势和特点： 可实现大容量存储设备数据共享。 实现高速计算机与高速存储设备的高速互联，FC存储协议具有高速、低延迟和距离短的特点，计算机在这个网络中是所有外部设备的控制者，因而计算机和存储设备是主从关系，适合传输大块的数据。 可实现灵活的存储设备配置要求。 可实现数据快速备份。 提高了数据的可靠性和安全性。 传输距离有限：光纤的传输距离最大为10公里，如果需要更长的数据传输距离，只能增加光纤中转设备。 FC SAN的高性能带来的另外一个特点就是成本141、较高，从光纤阵列本身到光纤磁盘再到光纤交换设备、光纤HBA卡等周边设备本身成本和维护成本都相对较高。典型应用：大型数据库服务器系统（如：oracle、DB2、Sybase），或者集群部署的数据库服务器。对关键性业务的性能、安全性、稳定性能力要求较高业务需求迫使性能需求不断攀升：初期购置时性能完全满足要求，但是随着不可预估的业务需求攀升导致对底层存储需求快速攀升，而传统存储系统面对这种需求束手无策。分级存储方案：应用服务器，系统整体容量大，高并发访问需求，业务数据二八现象明晰。容灾需求：针对大中型规模容灾系统，对系统要求非常高，因此选择性能更好的FC架构。6.1.3.4.2 IP SANIP技术142、已经成为了网络的主流技术，已经成为整个IT行业中最成熟、最开放、发展最迅速、成本最低、管理最方便的数据通讯方式。在经历了FC SAN发展之后，整个行业开始考虑将FC传输技术替代为更加成熟可靠、成本更低的IP技术，以适应广域网数据应用、大规模服务器数据集中、海量数据存储等应用对新一代存储系统的要求。IP SAN存储技术实际上就是使用IP协议而不是光纤通道将服务器与存储设备连接起来的技术。IP SAN存储是基于IP网络来实现数据块级别存储的方式，除了已获通过的iSCSI标准,还有FCIP、iFCP等协议标准。而iSCSI发展是最快的，已经成为IP存储技术的一个典型代表。基于iSCSI的SAN的目的143、就是要使用本地iSCSI导向器（Initiator）和iSCSI目标（Target）之间来建立SAN。iSCSI协议就是将标准的SCSI存储访问指令，打包到TCP/IP协议中进行传输。基于iSCSI协议构建的IP SAN存储，已崭露头角，成为新一代存储系统的标准，成为IT新时代围绕IP技术进行的网络与存储融合的标志性技术。IP SAN由三个基本的组件构成：iSCSI接口、连接设备（交换设备、网关、路由器、集线器等）和IP通信控制协议。这三个组件再加上附加的存储设备和独立的SAN服务器，就构成一个IP SAN系统。SAN提供一个专用的、高可靠的基于IP链路通道的存储网络，IP SAN允许独立地增144、加它们的存储容量，也使得管理及集中控制（特别是对于全部存储设备都集中在一起的时候）更加简化，使得物理上分离的远距离存储集中变得更容易。典型的IP SAN组网如下图6-2所示：图6-2：典型的IP SAN组网结构示意图IP SAN优势和特点： 采用应用广泛且比较成熟的IP技术构建SAN网络，在享受SAN优势的同时，大大降低连接成本，实现一个低成本、高性能的存储网络平台。 基于开放的iSCSI技术标准构建集中的存储平台，iSCSI不但可以在局域网内部署，还可以在广域网内部署，拓扑结构非常灵活，便于存储系统灵活扩展。 无需改变现有IT构架，初期投入成本低，并充分利用现有网络管理人员，无需额外培训管理145、维护人员，降低管理运维成本。 IP SAN充分利用IP网络优势，摆脱地理限制，可以方便实现备份和容灾。 易于扩展：由于iSCSI存储系统可以直接在现有的网络系统中进行组建，并不需要改变网络体系，加上运用交换机来连接存储设备，对于需要增加存储空间的Z务用户而言，只需要增加存储设备就可完全满足，因此，IP SAN存储系统的可扩展性高。典型应用：中小型数据库服务器系统（如：Sqlserver、Mysql、PGsql）、邮件服务器、DNS服务器、文件服务器、WINS服务器等。非关键性业务：对数据读写能力要求不太高。关键性业务：对数据读写能力要求不太高（如：小型电子Z务）。大量虚拟机部署：随着计算虚拟化146、程度日益提高，大量非核心应用系统以及虚拟桌面均被部署到虚拟机中，虚拟机密度越来越高，对存储的容量、性能、扩展性要求也越来越高。容灾需求：针对中小型规模容灾系统，更加强调性价比，因此选择性价比较高的IP架构。6.1.3.4.3 NAS非结构化数据：办公文档、文本、图片、XML、HTML、各类报表、图像和音频/视频信息等等需求比较大的，可以选择使用NAS。6.1.3.4.4 存储虚拟化存储虚拟化特性能够将不同品牌、型号的存储设备整合为统一的存储池，既能灵活利用旧存储设备，又能增加新存储设备。虚拟化后可以对原有数据进行灵活的管理，包括数据整合、迁移、镜像、远程复制等。存储虚拟化结构参见下图6-3所示147、：图6-3：存储虚拟化结构示意图适用于存储虚拟化的场景如下： 要求异构SAN/IP-SAN存储系统的开放性 要求存储产品利旧 要求异构存储系统之间有效的数据迁移 要求异构存储系统的资源管理 对服务器和存储整合 存储池的性能提升 异构存储环境数据保护与恢复 异构存储环境灾备能力6.1.3.5 业务区与集群设计平台根据业务应用的不同特点采用物理服务器、虚拟机、SAN或NAS、网络或存储连接技术、存储虚拟化技术，并根据业务应用的特点对服务器或存储进行配置,满足Z务应用对计算和存储的需要。根据安全及功能要求不同，将计算及存储资源划分为不同的集群，云计算区、物理资源区、开发测试区、运行管理区等功能区域集148、群。参见下图6-4所示：图6-4：业务区与集群设计区分布示意图计算与存储区部署一套虚拟化软件实现对计算机存储资源的虚拟化，并实现对虚拟资源、业务资源、用户资源的集中管理。提高平台对用户单位服务的灵活性，在设备部署过程中，分为计算资源区和存储资源区。l 资源分配规则建议根据服务器功能分类和业务应用的性能需求，经过评估业务应用可以虚拟化后，就可以分别选择不同的虚拟机规格类型。虚拟机规格需要根据各种系统对于CPU、内存、网络和存储的I/O需求不同来进行分类，然后根据操作系统不同，选择不同的虚拟机镜像，然后将这些虚拟机分布在不同的x86物理机上。由于虚拟机选择不涉及存储选型，因此可以根据CPU和内存的149、配比，将虚拟机分为不同规格，分配给不同应用，表格显示了通常情况下的一些典型应用的配置规格。l 典型应用虚拟机配置规格示例参见下表6-3所列：表6-3：典型应用虚拟机配置规格示例表系统类型型号VCPU内存系统盘网卡标准系列（搜索平台、小型数据库）小型24G40GB18中型48G40GB18大型816G50GB18大数据量访问系列（视频、大型开发平台）中型416G40GB18大型824G50GB18大访问量系列（大并发互联网应用）中型1216G40GB18大型1632G50GB18上面给出了典型应用的规格选择，对于大部分的应用来说，如果需要给出比较匹配的资源需求，需要根据用户的业务场景，收集需要的150、服务器种类和性能要求，并且测出业务在高峰时期对服务器的CPU、内存、IO信息，为后期的数据分析提供原始依据。一般来说有三种收集业务对服务器性能需求的方法：（1）对于政府现有的业务服务器，且数据量是可预计的情况，可以使用各种服务器性能采集工具，通过采集一段时间的服务器关键性能数据（如一个月），收集到对该业务关键的物理服务器的CPU、内存、存储、网络、磁盘IO等关键数据。采集关键是要收集到对于该服务器有重要意义的、至少覆盖一个典型业务周期的数据，以便准确充分的对性能需求进行评估；（2）如果各局办新上某一业务应用，有对于该业务的总业务压力、峰值业务压力、需要的服务器资源、业务增长率等有比较准确的估计151、，则可以根据这些数据，结合业务类型，依据业界通行的性能估算方法（如TPC-C、TPC-W、SPEC 2000、SPEC2005等），计算出该业务对物理服务器的性能需求；（3）如果各局办新上某一业务应用，但没有对该业务的压力和资源需求的数据，但其他政府部门已有大致相同规模的同类应用，则可以参考业界对该类业务应用服务器的性能需求，或采用对该业务进行开发的ISV的推荐硬件需求，作为该服务器的性能需求；数据采集的目的是根据采集到的物理机的信息，分析折算为相当于同等规模的虚拟机的规格，根据我们能提供的物理机的类型，计算得到该物理机上能支撑的虚拟机的数量，再加上管理平台的限制和消耗，得到最终的物理机的配置152、。6.1.4 云计算虚拟化平台规划6.1.4.1 原则选择OpenStack架构、避免被单一厂商锁定为了避免硬件选择和特定虚拟化软件厂家锁定，本次项目选择架构开放、扩展性良好、支持多厂商基础设施的统一平台OpenStack。它具有以下优点：n 架构开放 北向标准OpenStack API，生态系统丰富；不会绑定到一个厂家 ；Apache License，允许随意商业集成。 n 弹性可扩展性好 较容易定制化增加新模块和服务（如新的虚拟化引擎）；级联后可构建大规模的云。n 异构接入能力强 南向异构接入强。异构hypervisor (KVM/XEN/Vmware/LXC), 异构存储, 异构网络，异153、构物理设备n 参与者众多，发展迅猛，行业默认云平台 Bug响应快，每六个月发布一个版本；参与社区的企业300+，开发人员20000。基于OpenStack的云平台对计算、存储、网络进行虚拟化管理，实现虚拟化资源池，满足业务弹性伸缩和快速部署。基于OpenStack架构的云平台将全网基础设施资源虚拟化并构成单一统一的“逻辑资源池”，实现跨所有物理数据中心站点实现全局拉通的管理与调度。服务器、存储、网络和安全设备等IT基础设施资源被全面和深度虚拟化后，通过细粒度的、跨数据中心的资源调度、等核心技术能够实现数据中心资源使用率最大化和全局能效比最大化。主流云平台技术XEN、KVM技术对比成熟度：基于X154、EN的商用产品叫基于KVM的商用版本更成熟，功能更完善架构方面： KVM是Linux内核的一部分，KVM在Linux内核内部部署，可以很容易控制虚拟化进程。KVM更加灵活。由于操作系统直接和整合到Linux内核中的虚拟化管理程序交互，所以在任何场景下都可以直接和硬件进行交互，而不需要修改虚拟化的操作系统。KVM与Kernel融合架构是双刃剑，性能占优，但功能特性受到一定的制约。KVM随着OpenStack的发展，IT厂商不断投入，KVM后期必然会同Xen一样功能齐全。安全方面：Xen平台架构侧重安全性，为保证安全性，各Domain之间对共享区域的访问和映射必须通过Hypervisor授权；KV155、M平台架构侧重性能，牺牲了安全隔离性，VM之间以及与Host Kernel之间对共享区域的访问和映射无需Hypervisor进行授权，故整个访问路径较短使用Linux baremetal内核，无pvops性能损耗。容备方面：基于XEN的商用产品已经具备灾备功能，而基于KVM的商用产品还未补齐。兼容性方面：针对GuestOS、外设等的兼容性，Xen起步早于KVM，在兼容性积累方面Xen优于KVM。 特性方面： KVM和XEN生命周期等基本功能无差异， 高级特性KVM待补齐（如：Host NUMA、Guest NUMA、虚拟化FT、GPU虚拟化、DRS、虚拟机快照、虚拟机异构迁移等）。 XEN和K156、VM双引擎，支撑Z务云稳定演进针对XEN和KVM不同特点，我们建议使用XEN和KVM双引擎。在支撑本期Z务云业务需要的同时，满足了未来云平台技术演进，避免被一个虚拟引擎绑定。 对于虚拟化高级功能无要求，安全可靠性要求不高场景，可以使用KVM虚拟化，如开发测试云、创新性业务。 对于大多数Z务业务场景，对安全、可靠性要求较高场景，适合部署XEN虚拟化。 通过Openstack标准接口，对基于XEN/KVM的虚拟化平台进行统一监管。6.1.4.2 虚拟化介绍随着计算能力的不断提高，单服务器的资源利用率却反而降低，这就引发了计算资源的富余，如图所示：当前服务器CPU利用率仅为10%-15%。低水平的资157、源利用率催生了虚拟化技术的出现。服务器的性能提高也由最初的依赖于CPU频率的增长转化为CPU核数的增加。多核CPU的出现，导致了计算资源由单核CPU的分时复用转变为多核CPU的并行处理。多核多CPU更加速了虚拟化技术的进程。服务器虚拟化通过对服务器物理资源的抽象，将CPU、内存、I/O等服务器物理资源转化为一组可统一管理、灵活调度、动态分配的逻辑资源，并基于这些逻辑资源在单个物理服务器上构建多个同时运行、相互隔离的虚拟机执行环境。通过虚拟化平台提供的虚拟化功能，可实现更高的资源利用率、更低的硬件采购成本和能耗以及更低的维护成本。提供物理服务器或虚拟机或虚拟计算资源，提高资源利用率，提高维护效率158、，减少部署的周期，降低采购和维护设备成本，满足各种业务所需。6.1.4.3 虚拟化关键技术计算虚拟化虚拟化针对高并发，高负载应用场景下的计算性能优化和调度算法优化，发挥多核处理的性能优势，提供多种内存复用技术，并结合芯片辅助虚拟化技术充分发挥平台的性能优势。1、内存复用技术虚拟化提供多种内存复用技术和灵活自动的内存复用策略。对于某些物理内存资源比较紧张的场景，如果用户希望运行超过物理内存能力的虚拟机，以达到节省成本的目的，就需要有内存复用策略来动态地对内存资源进行分配和复用。内存复用策略通过内存复用技术，提升物理内存利用率的同时，尽可能减少对虚拟机性能的影响。客户无需关心何时调用和怎么调用几种159、复用技术，只需简单配置和开启复用策略后就能达到提升虚拟机密度的目的。内存复用技术有以下三种：内存气泡、内存零页共享和内存交换技术。 （1）内存气泡技术(Ballooning)内存气泡技术是一种VMM通过“诱导”客户机操作系统来回收或分配客户机所拥有的宿服务器或虚拟机物理内存的技术。当客户机物理内存足够时，客户机操作系统从其闲置客户机物理机内存链表中返回客户机物理内存给气球；当客户机物理内存资源稀缺时，客户机操作系统必须回收一部分客户机物理内存，以满足气球申请客户机物理内存的需要。通过Balloon Driver模块，从源虚拟机申请可用内存页面，通过Grant Table授权给目标虚拟机，并更新160、虚拟机物理地址和机器地址映射关系表。通过使用Ballooning技术，可以提升内存使用效率。（2）零页共享技术内存零页共享技术作为内存复用技术的一种，能有效地识别和释放虚拟机内未分配使用的零页，以达到提高内存复用率的目的。客户开启零页共享技术后，能实时从虚拟机内部把零页进行共享，从而把其占用的内存资源释放出来给其他虚拟机使用，以创建更多的虚拟机，实现提高虚拟机密度的目的。与内存气泡技术不同，零页共享后的内存页对于虚拟机来说还是可用的，虚拟机可以随时根据需要再收回这部分内存，用户体验相对来说更加友好。用户进程定时扫描虚拟机的内存数据，如果发现其数据内容全为零，则通过修改P2M映射的形式把其指向一161、个特定的零页。从而做到在物理内存中仅保留一份零页拷贝，虚拟机的所有零页均指向该页，从而达到节省内存资源的目的。当零页数据发生变动时，由Xen动态地分配一页内存出来给虚拟机，使修改后的数据有内存页进行存放，因此对于GuestOS来说，整个零页共享过程是完全不感知的。（3）内存交换技术内存交换技术作为内存复用技术的一种，能通过Xen把虚拟机内存数据换出到存储介质上的交换文件中，从而释放内存资源，以达到提高内存复用率的目的。由于内存气泡和零页共享的数量与虚拟机本身的内存使用情况强相关，因此其效果不是很稳定，用户使用内存交换技术，可以弥补上述不足，即可以保证释放出一定量的内存空间出来（理论上所有虚拟机162、内存都能交换出来），但同时也会带来一定程度的虚拟机性能下降。内存交换触发时，根据用户需要告知Xen需要向某个虚拟机交换出一定量的内存页出来，Xen按一定的选页策略从虚拟机中选择相应数量的页后，把页数据保存到存储介质上的交换文件中，同时释放原先存放数据的那些页供其他虚拟机使用。当虚拟机读写的页正好是被换出的页时，在缺页处理时Xen会重新为其分配一页内存，然后从存储介质上的交换文件中把相应的页交换回新分配的内存页中，同时再选择另外一页内存交换出去，从而保证虚拟机对页的正常读写的同时，稳定交换页的数量。这个过程与零页共享一样，对GuestOS都是不感知的。2、Host NUMAHost NUMA主要163、提供CPU负载均衡机制，解决CPU资源分配不平衡引起的VM性能瓶颈问题，当启动VM时，Host NUMA根据当时服务器或虚拟机内存和CPU负载，选择一个负载较轻的node放置该VM，使VM的CPU和内存资源分配在同一个node上。如图1所示，Host NUMA把VM的物理内存放置在一个node上，对VM的vCPU调度范围限制在同一个node的物理CPU上，并将VM的vCPU亲和性绑定在该node的物理CPU上。考虑到VM的CPU负载是动态变化，在初始放置的node上，node的CPU资源负载也会随之变化，这会导致某个node的CPU资源不足，而另一个node的CPU资源充足，在此情况下，Hos164、t NUMA会从CPU资源不足的node上选择VM，把VM的CPU资源分配在CPU资源充足的node上，从而动态实现node间的CPU负载均衡。对于VM的vCPU个数超过node中CPU的核数的VM，如图2所示，Host NUMA把该VM的内存均匀的放置在每个node上，vCPU的调度范围为所有node的CPU。用户绑定了VM的vCPU亲和性，Host NUMA特性根据用户的vCPU亲和性设置决定VM的放置，若绑定在一个node的CPU上，Host NUMA把VM的内存和CPU放置在一个node上，若绑定在多个node的CPU上，Host NUMA把VM的内存均匀分布在多个node上，VM的v165、CPU在多个node的CPU上均衡调度。虚拟化提供复杂的NUMA 调度程序来动态平衡处理器负载，根据当时服务器或虚拟机内存和CPU负载优先把VM的CPU和内存资源分配在同一个node上，并随着资源负载的动态变化对服务器或虚拟机node间的CPU资源做负载均衡。3、CPU QoSHypervisor层根据分时复用的原理实现对虚拟CPU的调度，CPU Qos的原理是定期给各虚拟CPU分配运行时间片，并对各虚拟CPU在物理CPU上运行的时间进行记账，对于消耗完时间片的虚拟CPU将被限制到物理CPU上运行，直到获得时间片。以此控制虚拟机获得物理计算资源的比例。以上分配时间片和记账的时间周期很短，对虚拟166、机用户来说会感觉一直在运行。CPU份额和CPU预留只在各虚拟机竞争计算资源的时候才发挥作用，如果没有竞争情况发生，有需求的虚拟机可以独占物理CPU资源。虚拟化提供CPU QoS（Quality of Service）特性，对虚拟机可获得的物理CPU资源进行限制，平衡VCPU之间的调度。利用公平调度算法分配物理CPU资源，提高物理资源利用率，防止某些虚拟机占用过多物理CPU资源而影响其他虚拟机。支持设置虚拟机的CPU的QoS权重及绝对值上限，确保资源分配合规与可控，隔离用户行为之间的相互影响，同时保证关键业务虚拟机获得所需的计算资源，确保关键客户的用户体验。CPU Qos功能包括三个方面的特性：167、上限、份额和预留。CPU上限 ：控制虚拟机占用物理资源的上限。CPU份额 ：CPU份额是在多个虚拟机竞争物理CPU的时候按比例分配计算资源。CPU预留 ：CPU预留是在多个虚拟机竞争物理CPU的时候最低分配的计算资源。存储虚拟化云计算带来的另一个挑战就是解决大规模虚拟机部署所面临的存储方面的问题，首先是存储I/O性能瓶颈问题，因为存储性能增长速度相比于计算能力的增长要慢，因此对于虚拟化而言，I/O瓶颈和缓慢的存储性能成为主要瓶颈，虚拟化通过提供不同I/O性能优化手段，有效缓解存储瓶颈。其次是存储利用率低的问题，虚拟化提供存储自动精简配置技术，提高存储利用率降低存储硬件的采购成本。再次是大规模部168、署虚拟机的效率问题，虚拟化提供链接克隆技术，可以缩短规模部署虚拟化的时间。1、链接克隆虚拟机链接克隆技术就是根据一个源虚拟机克隆出一个或多个克隆虚拟机，且克隆虚拟机拥有与源虚拟机完全相同的操作系统、应用系统乃至数据和文档。克隆技术可分为完整克隆和链接克隆两种。完整克隆方式下，克隆虚拟机和源虚拟机是两个完全独立的实体，源虚拟机的修改乃至删除不会影响到克隆虚拟机的运行，但缺点是2个虚拟机运行时需要占用2份内存和2份磁盘空间;与之相对应的是链接克隆方式，克隆虚拟机必须在源虚拟机存在的情况下才能运行，但优点是多个克隆虚拟机之间的公共部分(共同来自源虚拟机的部分)可以共用同一份内存空间和同一份磁盘空间，169、因此在服务器服务器或虚拟机资源相同的情况下，采用链接克隆的方式可以支持更多的虚拟机，运行更多的业务，或者运行更多的虚拟桌面，从而使用户的IT成本更低。如图所示，链接克隆技术使相同Guest OS多个虚拟机之间共享母镜像，不再使用一对一的镜像存储机制，而一对一保存虚拟化镜像差异化部分，对应虚拟机都是链接到源虚拟机的副本虚拟机上用户数据盘只创建差异文件,如果改变主虚拟机,变化也会被复制到每一个与之相连接的克隆虚拟机中取代传统的使用模板进程来创建虚拟机的方式，在节省存储空间降低存储成本的同时，实现虚拟机的快速部署，节省大规模系统部署的时间。2、存储瘦分配在传统的存储系统中，当某项应用需要一部分存储空170、间的时候，往往是预先从后端存储系统中划分出一部分足够大的空间预先分配给该项应用，即使这项应用暂时不需要使用这么大的存储空间，但由于这部分存储空间已经被预留了出来，其它应用程序无法利用这些已经部署但闲置的存储容量。这种分配模式一方面使闲置的存储数量不断增加，系统总体拥有成本升高；另一方面用户不得不购买更大的存储容量，才能适应环境，成本进一步加大。解决存储过量供给的最有效的方式，是通过使应用程序只消耗必要的存储资源来将块或块组写入特定卷，优化存储利用，不必再购买或维持超过实际所需的存储。自动精简配置技术的核心原理是“欺骗”操作系统，让操作系统认为存储设备中有很大的存储空间，而实际上的物理存储空间则171、没有那么大，虚拟机始终可以看到完整的逻辑磁盘大小，实际物理磁盘仅占用正在使用的物理磁盘空间。通过使用该技术，可减少对虚拟磁盘的过度调配，降低存储成本。3、存储QOS虚拟化提供存储QoS（Quality of Service）特性，对远程存储设备（IPSAN、FCSAN和VBS）挂载到Dom0上的卷进行IO上限控制，意味着虚拟机存储后端对该卷的任何IO操作都无法超过设置的上限值。存储卷IOPS上限设置涉及卷挂载、卷卸载、卷审计场景，用户需要在挂卷的同时设置对应的IOPS上限，从而保证该卷在分配给虚拟机使用后IO能力得到控制。网络虚拟化虚拟化环境下服务器整合了更多的应用服务，工作负载更加依赖于网络172、I/O，同时随着处理器多核技术的发展，需要充分提高资源利用率，而当前外部IO性能已经跟不上处理器等的发展，需要在系统性能与网络能力之间达到一种平衡，从整合中实现最理想的应用服务。在IO设备上，频繁的VMM切换以及对中断的处理是导致虚拟化效率低下的两个重点因素，虚拟化结合芯片辅助虚拟化技术提供SR-IOV网卡直通等技术，确保用户单位关键应用的性能体验。1、VMDQ在虚拟环境中，hypervisor管理网络I/O活动，随着平台中的虚拟机和传输量增加，hypervisor要求更多的CPU周期以分类数据包，并将其路由到适合的虚拟机中，减少对应用可用的CPU空间。虚拟化利用VMDq（Virtual Ma173、chine Device Queues虚拟机设备队列）技术，针对对虚拟机网络性能有极高要求的场景，在支持VMDq的网卡上，用硬件实现了一个Layer 2分类/排序器，根据MAC地址和VLAN信息将数据包发送到指定的网卡队列中去，这样虚拟机收发包时就不需要Dom0的参与，这种模式极大地提升了虚拟化网络效率。（Intel VMDQ技术原理）Intel VMDq（Virtual Machine Device Queue 虚拟机设备队列）技术，是专门用于提升网卡的虚拟化IO 性能的芯片辅助I/O虚拟化技术，主要解决IO设备上频繁的VMM切换以及对中断的处理是导致虚拟化效率低下的问题，可以减轻hyper174、visor负担、同时提高虚拟化平台网络I/O性能。VMDq技术可以将网络I/O管理负担从hypervisor上卸载掉，多个队列和芯片中的分类智能支持虚拟环境中增强的网络传输流，从应用任务中释放处理器周期，提高向虚拟机的数据处理效率及整体系统性能。2、SR-IOV通常针对虚拟化服务器的技术是通过软件模拟共享和虚拟化网络适配器的一个物理端口，以满足虚拟机的I/O需求，模拟软件的多个层为虚拟机作了I/O决策，因此导致环境中出现瓶颈并影响I/O性能。虚拟化平台提供的SR-IOV是一种不需要软件模拟就可以共享I/O设备I/O端口的物理功能的方法，主要利用iNIC实现网桥卸载虚拟网卡，允许将物理网络适配器175、的SR-IOV虚拟功能直接分配给虚拟机，可以提高网络吞吐量，并缩短网络延迟，同时减少处理网络流量所需的服务器或虚拟机CPU开销。SR-IOV（Single Root I/O Virtualization）是PCI-SIG推出的一项标准，是虚拟通道（在物理网卡上对上层软件系统虚拟出多个物理通道，每个通道具备独立的I/O功能）的一个技术实现，用于将一个PCIe设备虚拟成多个PCIe设备，每个虚拟PCIe设备如同物理物理PCIe设备一样向上层软件提供服务。通过SR-IOV 一个PCIe设备不仅可以导出多个PCI物理功能，还可以导出共享该I/O设备上的资源的一组虚拟功能，每个虚拟功能都可以被直接分配到176、一个虚拟机，能够让网络传输绕过软件模拟层，直接分配到虚拟机，实现了将PCI功能分配到多个虚拟接口以在虚拟化环境中共享一个PCI设备的目的，并且降低了软件模拟层中的I/O开销，因此实现了接近本机的性能。如图所示，在这个模型中，不需要任何透传，因为虚拟化在终端设备上发生，允许管理程序简单地将虚拟功能映射到 VM 上以实现本机设备性能和隔离安全。SR-IOV虚拟出的通道分为两个类型：（1）PF(Physical Function) 是完整的PCIe设备，包含了全面的管理、配置功能， Hypervisor通过PF来管理和配置网卡的所有I/O资源。（2）VF(Virtual Funciton)是一个简化177、的PCIe设备，仅仅包含了I/O功能，通过PF衍生而来好象物理网卡硬件资源的一个切片，对于Hypervisor来说，这个VF同一块普通的PCIe网卡一模一样。3、软件虚拟交换软件虚拟交换功能就是把分布在集群中多台服务器或虚拟机的单一交换机逻辑上组成一个大的集中式交换机，减少每台虚拟交换机需要单独分别配置过程，同时为集群级别的网络连接提供一个集中控制点，使虚拟环境中的网络配置不再以服务器或虚拟机为单位，简化虚拟机网络连接的部署、管理和监控，适合于大规模的网络部署。高可用性虚拟化环境中，物理服务器和存储上承载更多的业务和数据，设备故障时造成的影响更大。虚拟机热迁移和虚拟机热备份技术降低宕机带来的风178、险、减少业务中断的时间。Z务云平台使用的防火墙、交换机、网络安全、服务器、存储等设备都应具备高可靠性及冗余性，即单个设备或单个节点出现故障时候，其他设备/节点可以立刻接管任务，保证Z务云平台整体的业务连续性不低于99.99%。对于其他应用级灾备业务，应根据不同业务类型的特点，制定实际的RPO、RTO指标，在约定的时间内，实现业务系统恢复并对外服务。1、虚拟机热迁移热迁移技术是指把一个虚拟机从一台物理服务器迁移到另一台物理服务器上，即虚拟机保存/恢复(Save/Restore)。首先将整个虚拟机的运行状态完整保存下来，同时可以快速的恢复到目标硬件平台上，恢复以后虚拟机仍旧平滑运行，用户不会察觉到179、任何差异。虚拟机的热迁移技术主要被用于双机容错、负载均衡和节能降耗等应用场景。热迁移提供内存压缩技术，使热迁移效率提升一倍。2、虚拟机热备份在虚拟环境下设置主备虚拟机，在备节点上创建主虚拟机的完整拷贝，包括CPU状态、内存、磁盘操作、QEMU等都进行低延迟的定时同步。备节点虚拟机处于P状态定时检测主节点虚拟机心跳，在指定时间内收不到心跳即认为异常发生,备虚拟机切换到正常运行状态。优势是主备节点可以保持状态完全同步，数据完全一致，缺点是会带来一些性能开销。虚拟化支持虚拟机热备份（FT）技术，可支持多次硬件故障实时切换，当故障发生主备虚拟机倒换后，自动再次形成主备状态，并可支持多核虚拟机。3、虚拟180、资源热插虚拟资源热插功能作为在虚拟化场景下的一个高级特性，在不影响用户业务的情况下，支持动态在线给虚拟机增加或减少VCPU等虚拟资源数量，来实现虚拟机计算资源的动态分配。当前支持VCPU、虚拟内存、虚拟网卡和虚拟磁盘的热插功能。（注：具体支持须由虚拟化平台和Guest OS两者同时支持才能生效）4、虚拟机内存快照虚拟化提供虚拟机内存快照，即在虚拟机的运行状态下，不中断用户的业务，实现虚拟机内存状态的备份，同时，通过该备份文件，可以方便地恢复虚拟机，保证恢复后的虚拟机状态与快照点完全一致，包括：打开了哪些应用程序、窗口，编写一半的文档等，都能如实还原。虚拟机内存快照必须配合存储快照一起使用，保证181、数据一致性，主要用户场景为：创建快照和还原快照。用户通过创建快照可以实时保存虚拟机的状态，包括虚拟机的内存、磁盘等数据信息。创建快照后，会生成一个内存快照文件和存储快照卷。当虚拟机发生故障，或者用户想恢复到之前做快照时刻的虚拟机状态，可以选择相应的内存快照文件和存储快照卷来进行快照还原。快照还原后，虚拟机恢复到快照时间点的状态。高安全性1、VLAN云通过虚拟网桥（支持VLAN功能）实现虚拟交换功能，实现VLAN隔离，确保虚拟机之间的安全隔离。如图所示，处于不同物理服务器上的虚拟机通过VLAN技术可以划分在同一个局域网内，同一个服务器上的同一个VLAN内的虚拟机之间通过虚拟交换机进行通信，而不同182、服务器上的同一VLAN内的虚拟机之间通过交换机进行通信，确保不同局域网的虚拟机之间的网络是隔离的，不能进行数据交换。2、安全组云提供的虚拟机安全组是一组虚拟机的集合，也是关于这组虚拟机的网络安全规则的集合。同一个虚拟机安全组中的虚拟机可能分布在多个物理位置分散的物理机上，一个安全组内的虚拟机之间是可以相互通信，而不同的安全组之间的虚拟机是不允许进行通信的。因此虚拟机安全组的作用是在一个物理网络中，划分出相互隔离的逻辑虚拟局域网，提高网络安全性。3、安全加固云选取业界通用安全扫描工具CIS-CAT对Linux系统的安全建议，在不影响正常业务的前提下实施了对系统的安全加固措施。从文件权限、账户控制183、密码保护等方面提升系统安全性，有效地保护系统免离非法操作和恶意攻击，为用户提供了更为安全的系统环境。4、防火墙云集成SuSEfirewall组件，能提供全方位的网络安全保护。用户可以根据自己的业务状况，配置不同的规则策略，按需阻断网络攻击，提升产品整体网络安全能力。可管理性1、Kbox黑匣子黑匣子作为一个内核模块存在于云 Dom0的内核，其主要功能是在Dom0或Xen发生异常时候能捕获异常信息，并且把这些异常信息通过网络输出、本地存储，或直接输出到系统日志中，为系统异常定位提供强有力支撑。2、一键式收集工具一键式收集工具，用户可以在云出现问题时利用云log命令收集系统的日志信息，发给云开发人184、员协助问题定位。用户也可以收集特定的日志信息。收集的信息主要包括如下内容：（1）收集系统运行环境信息 （2）收集系统日志 （3）收集虚拟化相关信息3、GuestOS故障检测云提供Guest OS故障检测功能，当客户机发生严重故障时（例如Windows系统蓝屏），虚拟机管理程序会监控到客户机故障。虚拟机管理程序可以重启或关闭客户机，从而避免有故障的客户机持续占用计算资源。4、系统故障告警云提供基本的系统故障告警能力，能定期扫描预设的告警项。调用外部接口进行上报并且记录日志，同时对告警项进行跟踪，对已经恢复的告警项进行清理。目前云预设的告警项分为三类：（1）虚拟机运行类：主要对虚拟机运行过程中异常185、状况进行扫描并告警；（2）虚拟机管理类：主要对云虚拟机管理相关的模块进行扫描并告警；（3）资源类：主要对内存、网络、存储等外部资源进行监控并告警。可节能性云提供了休眠唤醒的功能来进行节能降耗。当判断虚拟机无人使用时，主动休眠虚拟机可以节省大量的计算资源给其他需要运行的虚拟机使用。由于休眠是将当前的业务保留起来，当唤醒时，当前业务得以继续运行而不需要重新启动，节省了客户的时间。6.1.5 计算存储选型6.1.5.1 计算存储功能分区建议电子Z务公共云平台功能分区建议为：在互联网区可以部署门户网站等对个人、单位提供服务的公共类应用；在Z务外网区部署包含运行管理区、开发测试区应用、各个委办局的相关业186、务系统，并根据业务的不同需求提供不同的资源服务。6.1.5.2 服务器选型方案与规模需求 服务器架构选择常用的服务器有X86服务器和小型机，X86服务器和小型机在应用领域都有很好的表现，我们推荐采用X86架构的PC服务器，原因如下：l X86服务器在硬件、软件、后期维护、升级等方面的支出都要比小型机低得多；l X86服务器的技术成熟度不断提高，运算能力也不断提高，能够满足更多过去需要运行在小型机上的应用；l X86服务器出货量达到服务器总体市场的95%以上，并且作为一种工业标准化产品，软硬件上有着广泛的兼容，支持的Linux和Windows操作系统本身也有广泛的兼容软件，应用软件获取更加容易，187、因此对于维护管理人员的能力要求不太高，维护管理也比较容易。l X86服务器有广泛的生态系统，各种软硬件厂商数量众多，用户甚础也相当庞大，整个产业有强大在的生命力。在现网的电子Z务公共云平台中，Z务应用主要采用x86服务器部署，考虑到包含不同的数据库应用，因此平台包含虚拟化资源和物理资源，物理资源主要部署Oracle等对性能要求较高的数据库应用。其中虚拟化资源采用2路x86服务器（参考配置：1路为10核CPU，即1台服务器提供20核CPU的计算资源），运行数据库等性能要求较高的业务部署4路x86服务器（参考配置：1台服务器提供40核CPU的计算资源）。考虑到电信机房供电较低，建议采用机架服务器。188、6.1.5.3 存储方案选型与容量规划随着数据集中化和大数据理念的不断深入，数据作为数据中心的核心这个理念得到了更多客户的认同。作为数据存放的存储系统在Z务IT系统中的地位显得越来越重要，选择存储系统不仅要考虑单台存储的容量和性能，更需要从整个存储系统的可靠性、高性能、先进性、开放性、可维护性和管理的方便、数据保护措施的完备性、高效可扩展性、节省用户的投资、降低端到端总成本等维度考虑和设计数据中心的存储系统。 可靠性 对于关键性应用，如果存储系统发生故障或发生宕机现象，会造成严重的后果。所以，在存储系统设计中要采用相应的、恰当的技术手段以保障服务可用性。在考虑技术先进性的同时，还应从系统结构、189、技术措施、设备性能、系统管理等方面着手，确保系统运行的可靠和稳定，达到最大的平均无故障时间。存储系统的可靠性、可用性和可维护性（RAS），是系统选型考虑的重点。 高性能服务的响应速度是保证用户服务质量和满意程度的重要方面。系统高性能确保为用户提供优质的服务，使用户得到满意的响应时间。存储作为数据存取的关键路径，所以存储系统的高性能对整个业务端到端的快速响应至关重要。 先进性采用先进成熟的存储技术满足当前的业务需求，如采用先进的存储网络技术以适应更高的数据、多媒体信息的存取需要，使整个系统在一段时期内保持技术的先进，并具有良好的发展潜力，以适应未来业务发展和技术升级的需要。 开放性存储系统应符合190、国际标准，支持多种网络及网络存储协议标准，提供各种数据传输的接口，以实现标准化并提供开放标准的统一接口，方便不同厂家设备和同一厂家不同设备的互联互通。 可维护性和管理的方便、高效信息的管理和存储给用户带来的一个非常头痛的问题是管理非常麻烦、资源调整难度大。因此，在方案设计中必须遵循一个原则就是实现信息的方便高效、灵活的管理。由于系统本身具有一定复杂性，随着业务的不断发展，系统维护的任务必定会日益繁重。所以在设计中，必须建立一个全面的可维护方案，必须采用智能化、可管理的设备。最终能够实现监控、监测运行状况，合理分配资源、动态配置，迅速确定和排除故障等。 数据保护措施的完备性数据进行集中存储后，其191、安全保护和容灾就显得尤为重要。因为全部的信息都集中到了一个存储系统中，如果没有非常可靠的数据保护和容灾技术势必会严重影响用户的数据安全和关键业务的运转。 可扩展性存储系统不仅需要满足现有应用的存取性能及存储容量需求，也需要随着业务的发展提供良好的存取性能及存储容量的扩展能力。信息是用户不断运营中膨胀最快的资产，因此在设计存储系统的结构时必须考虑系统的规模可扩展性。一方面能够达到不停止应用就可以快速、灵活的扩充的存储容量，另一方面扩展时非常容易地整合原有存储系统和应用系统。一个不断发展的系统，必须具有良好的扩展性。能够根据未来业务的不断深入发展的需要，方便地扩展、提高使用的灵活性。 节省用户的投192、资、降低端到端总成本在设计方案时应以节省用户的投资、降低端到端总成本为目标。一方面尽最大限度的整合原有的设备、技术和网络结构；另一方面充分考虑将来的需求，从体系结构、容量、系统支持能力、以及升级维护费用等方面考虑并保护用户的投资。一个存储系统的设计是根据当前实际和业务需求以及后续业务演进，综合考虑各个维度，设计一个合适的存储系统。本期根据目前业务类型与数据类型，选择FC-SAN存储非结构化数据采用NAS存储。6.1.6 云服务管理系统设计运营运维服务管理支撑系统是某区Z务云的技术支撑系统。该系统为平台运营人员、运维人员、用户提供对应的操作界面和操作系统，提供运行服务、运行维护和运行保障服务提供193、支撑服务。6.1.6.1 运维管理系统规划运维管理系统（以下称维护中心）主要为运维人员提供的维护系统。维护中心模块，是属于数据中心运维层的统一运维管理模块，面向数据中心业务进行场景化运维操作和可视化的状态/风险/效率分析，基于分析能力提供主动和可预见的运维能力。具体功能包括综合分析和人工操作，综合分析包括对告警，性能的综合分析；人工操作包括日常维护操作，以及对传统数据中心资产数据的人工录入和对传统资源（包括机房空间，机柜机框）的发放。维护中心同时也是解决方案的统一维护管理门户入口，作为运维人员的工作平台，在首页上除了提供了维护中心各个功能的链接之外，同时也提供了到各个其他部件管理维护UI的统一194、入口和链接跳转。全系统统一运维方案如下图6-5所示：图6-5：统一运维方案设计示意图在运维管理区部署云资源管理系统和物理设备运维系统，负责运维操作、配置和监控数据采集；在中心节点部署统一运维管理系统（OperationCenter，后续简称OC），在OC上还可以将运维监控数据与业务相关数据进行联动综合分析,提供根因分析、业务影响分析、流量异常分析、容量分析及规划等主动智能运维功能。6.1.6.1.1 权限管理系统支持分权分域功能。1、分权功能系统预置管理员，维护员，监控员三类角色，用户可以根据需要自定义新的角色。预置的三类角色的权限如下运维用户角色定义参见下表6-4所列：表6-4：运维用户角色195、定义表角色权限管理员l 帐号管理l 资源管理l 告警管理l 性能管理l 拓扑管理l 报表管理l 日志管理维护员l 资源管理l 告警管理l 性能管理l 拓扑管理l 报表管理l 日志管理监控员l 资源查看l 告警查看l 性能查看l 拓扑查看l 报表查看l 日志查看2、分域功能用户可以根据实际的情况，创建对应的位置域，再按照域分配给用户，用户只能管理、查看指定位置域的资源。6.1.6.1.2 平台日常维护系统日常运维流程建议如下图6-6所示：图6-6：系统日常运维流程示意图按用户场景，系统提供集中拓扑功能，集中告警功能，并且提供定期报表等；维护中心模块从各部件把消息收集起来，再提供给用户各项功能。 196、集中拓扑功能用户可以从拓扑功能中了解整个多个数据中心，并从拓扑导航到关注的具体设备或系统。系统提供如下功能： 物理位置拓扑显示支持按物理位置查看拓扑，从区域，到数据中心，到数据中心内部各分区，层层展开。用户从拓扑可以同时查看多个数据中心，并展示数据中心之间的联接关系；系统支持多数据中心的分权分域，对有权限的数据中心，可下钻进去。 虚拟逻辑拓扑显示资源是按逻辑概念划分的，包括物理资源和虚拟资源；从逻辑对象维度查看拓扑时，可以选择按资源池查，从资源池管理系统向下层层展开，或者选按Zone，按逻辑分区的方式层层展开。 服务应用拓扑显示：从资源分配使用的维度查看资源，资源是被一个个应用服务使用的，可以197、按服务分组来查看，服务也常归属于指定客户的虚拟数据中心的，可以从虚拟数据中心，到服务，到资源层层展开。 网络IP拓扑显示：网络拓扑结构是指用传输媒体互连各种设备的物理布局，就是用什么方式把网络中的计算机等设备连接起来。拓扑图给出网络服务器、工作站的网络配置和相互间的连接。运维中心的网络拓扑，能按客户自定义的网络层次展示物理设备间的网络连接关系，默认划分接入层、汇聚层、核心层，也能由客户自助定义设备间的连接关系。 拓扑操作可以拓扑图进行放大，缩小，移动图标，调整布局，并且可以在图中增加或删除虚拟节点，使拓扑图更美观和符合用户习惯。 拓扑对象查找可以输入对象名称或IP地址等，搜索对象，搜索到的对象198、进行标示并移到界面中间。 集中告警管理系统收集各子系统数据，进集中的监控和呈现，方便各项操作。多维度告警/事件展现：n 支持多个运维监控维度展现告警/事件：u 按监控对象分类展现告警/事件u 按物理位置展现告警/事件u 按虚拟逻辑展现告警/事件u 按来源系统展现告警/事件u 按客户维度展现告警/事件u 按服务分组展现告警/事件u 按自定义条件展现告警/事件u 按VDC维度展示告警/事件。 报表管理系统对集中的数据，支持灵活的报表功能：n 立即报表，支持立即查看设备的报表数据，包括：u 服务器、虚拟机、网络设备的CPU、内存报表；u 网络设备的接口流量报表；u 存储设备的LUN IOPS报表；u199、 告警统计报表；u 工单报表n 周期报表u 支持周期性生成报表，报表种类同立即报表，周期类型包括：天、周、月、季度。u 客户只需要设置一次报表参数，即可周期提供报表数据。n 自动报表转Emailu 报表支持自动发送到客户指定的Email地址6.1.6.1.3 故障处理维护场景当出现故障时，监控人员告警界面上得到信息，也可能告警自动转短信等得到通知。这时监控人员首先要进行简单的定位，使用上述的告警查看，拓扑查看等功能。参见下图6-7所示：图6-7：故障处理维护场景示意图对于一时没法处理的故障，填工单转到二线维护人员处理。一般地，维护人员专业技术水平相对较高，可以做更深入的分析判断。他们除使用监控200、人员的功能外，还需要一些辅助分析功能。包括性能查看，和资源对象信息的细节查看等。系统提供以下功能。 集中性能管理展示指定设备的性能，以及查看综合性能n 性能TopN排序展示在数据中心范围，对所有设备及虚拟资源的常用性能指标进行峰值TopN排序和均值TopN排序，使管理员能宏观掌握性能压力最大的设备资源信息，包括：u 服务器、虚拟机、网络设备的CPU、内存TopN视图；u 网络设备的接口流量；u 存储读写带宽、读写IOPS、读写IO大小。n 虚拟机星空图虚拟机星空图提供数据中心所有虚拟机利用率分布概览图查看，支持搜索查看单个虚拟机信息，支持数据中心、虚拟化平台、集群三个不同粒度查看虚拟机概况，支201、持按照资源使用率过滤显示n 性能视图自定义支持把用户查看的性能指标、设备参数保存成视图，下次查看直接选择视图即可，不需要重新选择参数 历史性能查看支持把用户查看的性能指标、设备参数保存成视图，下次查看直接选择视图即可，不需要重新选择参数支持对指定对象的指定指标进行历史性能数据查看。n 支持最近1小时历史性能数据展示。n 支持最近1天历史性能数据展示。n 支持最近7天历史性能数据展示。n 支持最近30天历史性能数据展示。n 支持自定义时间范围历史性能数据展示。OperationCenter中采集到的原始性能数据在数据库中默认保留7天,超过7天的原始性能数据转储成文件形式存放。OperationC202、enter中经过汇聚的性能数据在数据库中默认保留3个月,超过3个月的汇聚性能数据成文件形式存放。 拓扑中性能展示支持在拓扑图中选中设备后，以Tip方式显示该设备的性能监控数据：n 服务器，显示CPU、内存、设备不可达率；n 网络设备，显示CPU、内存、接口流量；n 虚拟机，显示CPU、内存、磁盘使用率。 性能统计报表系统提供了性能统计报表功能，可以对历史性能数据进行分类统计，并输出报表。n 支持对指定范围的服务器提供指定指标的性能TOPN报表。n 支持对指定范围的虚拟机提供指定指标的性能TOPN报表。n 支持对指定范围的网络设备提供指定指标的性能TOPN报表。n 支持对指定范围的网络设备端口提203、供指定指标的性能TOPN报表。n 支持对指定范围的块存储提供指定指标的性能TOPN报表。n 支持提供CPU使用率的性能TOPN报表。n 支持提供内存使用率的性能TOPN报表。n 支持提供接口流量的性能TOPN报表。n 支持提供CPU使用率的性能报表。n 支持提供内存使用率的性能报表。n 支持提供接口流量的性能报表。n 支持DC整体的性能统计报表。n 支持LUN IOPS趋势报表。 资源对象管理系统能够能够自动从资源池管理、ITOM基础监控模块自动获取资源对象数据，并将发现的信息纳入资源对象管理。运维人员也可进行资源对象的手工录入、批量导入。运维人员可使用系统提供的多个维度的资源对象视图，进行浏204、览、查看、过滤查找和分组管理。运维人员可查看设备的信息，包括名称、分类、状态、厂商、型号、IP地址等。多维对象视图n 支持按对象分类维度对对象进行查看；n 支持按物理位置（数据中心、机房、区域）维度对对象进行查看；n 支持按虚拟逻辑（资源分区、集群）维度对对象进行查看；n 支持按来源系统维度对对象进行查看；n 支持按客户维度对对象进行查看；n 支持按服务分组维度对对象进行查看；n 支持按VDC维度对对象进行查看；n 支持按自定义条件对对象进行查看；n 支持将不同维度对象告警最高级在视图节点上进行呈现；n 支持在对象列表中呈现具体对象告警统计信息。 自定义对象视图n 支持用户在对象视图中自定义筛205、选模板并保存后在视图树中显示；n 支持用户自定义选择在服务分组、租户视图树中所需呈现的服务分组及租户；n 支持线下自定义；支持线下自定义对象视图中各节点的显示顺序；n 支持用户自定义视图列显示。 对象关联告警事件展现n 支持在选择某条具体对象数据时查看对象详情信息、告警信息、事件、拓扑、性能信息；n 支持线下配置不同对象类型是否显示详情、告警、事件、拓扑、性能信息；n 支持在对象拓扑信息中，针对当前对象进行相关联资源的逐层钻取查看。6.1.6.1.4 主动智能运维有系统正常运行时，维护人员根据个人的专业技能，通过查看系统信息，分析可能出现的问题和风险，提前进行规避。操作示意如下图6-8所示：图206、6-8：主动智能运维流程示意图系统为此提供辅助分析功能，包括普通报表分析和各智能分析功能。 搜索分析功能基于对数据库里的信息进行搜索，提供的是辅助人工分析功能，方便维护人员分析处理问题。n 用户可以指定搜索范围，包括资源对象，告警，事件，日志，知识库等等；n 集中按词条呈现关联信息；n 按搜索到的对象的属性，界面是直接提供常用操作。 云平台健康度分析n 对云平台中的计算资源、存储资源、网络资源、虚拟化资源，按工作负载现状及趋势和告警维度评估数据中心各个层级的健康度状况，识别健康度的瓶颈，并给出改进建议；n 对云数据中心中的计算资源、存储资源、网络资源、虚拟化资源，按剩余容量、资源消耗预测(剩余207、时间)、压力等维度评估数据中心各个层级的风险状况，识别最大的风险，并给出改进建议；n 对云数据中心中的计算资源、存储资源、网络资源、虚拟化资源，按密度、低效运行的状态和低载分布、端口使用率等维护评估数据中心各个层级的效率状况，识别低效的设备资源，并给出改进建议； 云资源容量管理n 提供了按物理位置和虚拟逻辑各个层级的容量快照视图和趋势视图。n 支持根据客户业务需要，灵活定义容量阈值，当容量超过阈值后，能产生不同级别的阈值告警，提醒管理员进行扩容。n 支持根据客户业务需要，客户可以查看容量立即报表，也可以定义容量周期报表，并定期推送给指定客户。6.1.6.1.5 报表管理系统对集中的数据，支持灵208、活的报表功能： 立即报表，支持立即查看设备的报表数据，包括： 服务器、虚拟机、网络设备的CPU、内存报表； 网络设备的接口流量报表； 存储设备的LUN IOPS报表； 告警统计报表； 工单报表 周期报表 支持周期性生成报表，报表种类同立即报表，周期类型包括：天、周、月、季度。 客户只需要设置一次报表参数，即可周期提供报表数据。 自动报表转Email 报表支持自动发送到客户指定的Email地址6.1.6.2 运营管理系统规划6.1.6.2.1 总体架构云服务运营模块整体上分为门户层、服务运营层、资源服务层。门户层承担与用户、管理员交互的能力，主要功能包括： 用户门户：服务申请、资源自助维护、资源209、释放 管理门户：服务目录、服务定义、订单管理、用户管理服务层则基于资源层提供的资源，进行灵活的定制封装，通过服务编排能力，以服务目录的形式呈献给最终用户使用。主要功能包括： 服务目录 服务定义 用户管理 服务目录管理 计量管理资源层承担全局资源管理的功能，将用户的资源申请经过资源调度转换为对本地资源管理子系统的资源部署请求，支持对多个数据中心的多个不同类型资源池进行统一管理的能力，统一分配和调度位于不同数据中心的资源池中的资源，并且根据业务特性、灾备等级等需求，对资源池进行分级、分区的管理。主要功能提供： 集中的模板、镜像管理 资源调度策略管理 多资源池管理 资源监控管理 资源容量管理 资源负210、载管理6.1.6.2.2 用户角色和权限在云服运营模块将用户分为管理侧用户和用户侧用户，其中管理侧有全局业务管理员角色，用户侧用户包含VDC管理员和业务用户两类角色，角色模型如下图6-9所示：图6-9：运营用户角色和角色间关系示意图各角色的权限定义如下：1、全局业务管理员具有如下权限： 资源池管理：资源池接入、资源池容量监控，全局已发放资源查询。 VDC管理：包括创建VDC、指定VDC管理员和VDC申请的审批。 全局服务目录管理：包括服务目录定义和权限设置。 全局应用模板管理：全局应用模板的定义、发布和更新 全局模板和软件包管理：包括软件包、脚本和VM模板 全局用户角色管理：权限、用户、角色管211、理、安全策略、操作日志管理。2、业务用户具有如下权限： 服务生命周期自管理：云主机、云磁盘、物理机、弹性IP、应用等的申请、变更、延期、释放。 服务资源维护：包括已申请资源查询和操作，如云主机的上下电、将云磁盘挂载到云主机等。 申请单管理：查询我的申请单。 操作日志管理：查询我的操作日志。3、VDC业务管理员除了具有业务用户的权限外，还具有如下权限： VDC管理：包括VDC申请、扩容、监控、释放、查看VDC内所有用户的操作日志、在VDC中创建资源并授权给VDC内的用户使用。 VDC用户管理：包括业务用户创建、查询、修改、删除和分配权限。 VPC规划：包括创建VPC、网络、安全组、VPN等。 V212、DC服务目录管理：包括服务目录定义和权限设置。 VDC应用模板管理：包括应用模板的定义、发布和更新。 VDC软件包和模板管理：包括虚拟机模板、软件包和脚本管理。 VDC申请单管理：审批来自业务用户的服务申请和查询整个VDC的申请单。整个系统支持分权分域功能：1、分权：基于上述的角色对用户进行授权2、分域：VDC间通过VDC完全隔离，VDC内各用户只拥有自己申请或者VDC管理员授权给他的资源权限。6.1.6.2.3 服务管理运营系统需要提供完整的服务生命周期管理，将资源池下计算、存储、网络资源以服务的形式提供给用户，用户可以从服务目录上申请，对于已经申请的服务，用户可以使用、维护、变更、释放。V213、DC业务管理员和全局业务管理可以定义服务、管理服务目录、审批用户提交的服务申请。下图6-10是部分服务生命周期管理流程。图6-10：服务生命周期管理流程示意图 服务定义运营系统需要预置开箱即用服务，包括VDC、云主机、云磁盘、物理机等服务，这些预置服务向用户开放所有的服务参数，用户在申请服务时可以选择或输入服务参数，完全由用户自定义所要的服务。例如通过预置服务申请云主机时，用户选择云主机的硬件规格、操作系统版本，配置云主机的网络。除了预置服务，全局业务管理员或VDC业务管理员可以根据部门情况，自定义服务目录。例如，全局业务管理员可以定义“标准测试Linux主机”服务，此服务已经固定使用了哪种操214、作系统类型、硬件规格，甚至云主机所使用的网络、IP地址也是由管理员决定的，用户申请“标准测试Linux主机”时只能输入数量、申请时长，不能由用户决定安装哪种操作系统类型，选择哪种硬件规格。全局业务管理员或VDC业务管理员在服务定义时，可定义项目包括：1.服务名称、描述、图标。2.用户申请服务时可输入哪些服务参数。（例如可以在定义服务时开放云主机规格由用户申请云主机服务时用户自己输入）。3.管理员审批时可以配置哪些服务参数。（例如管理员收到云主机申请后，可以给云主机配置一个静态IP）4.锁定某些服务参数，锁定的服务参数在用户申请服务时没有权限配置。（例如定义云主机服务指定操作系统类型为Win7）215、。5.配置服务的审批策略：需要审批、不需要审批。 服务申请用户可在自助务门户的服务目录中查看到管理员预定义的各类服务，并根据自己的业务需要选择相应的服务提交申请。申请时可以指定服务的规格参数和使用期限； 服务审批VDC 业务管理员可以审批来自VDC内用户提交的服务申请，全局业务管理员可以审批来自VDC 业务管理员提交的VDC服务申请。审批时，审批者可以选择“同意”或者拒绝外，还可以配置一些服务参数，例如虚拟机所使用的网络（审批者可以配置哪些服务参数可以在定义服务阶段配置）。 服务维护业务用户可以对已申请服务进行维护操作，例如VNC登录虚拟机、虚拟机上/下电，虚拟机绑定弹性IP，磁盘绑定虚拟机。216、 服务变更对于已发放的资源，用户可以提出变更申请对服务参数进行变更。如，用户可以申请将一台已发放的4G内存的虚拟机变更为8G内存。 服务释放对于不再使用的资源，用户可以提出释放申请，系统会自动释放用户的资源。也支持服务到期后，由管理员释放资源。对于到期的服务，业务用户和VDC业务管理员登录到租户Portal后，会收到到期提醒。对于已经到期的VDC，用户无法从VDC服务目录下继续申请服务。 服务流程定制运营管理系统基于优化的activity流程引擎，服务申请、变更、释放都是由业务流程驱动完成，用户可以根据业务需求修改系统已经预置好的流程，也可以定制开发全新的业务流程，实现业务快速设计上线的目标。217、系统提供流程设计开发工具包，包含：预置的原子操作，预置的流程和开发者手册，用户可以基于现有预置原子创建新业务流程，也可以新定制原子给需要的流程使用，还可以在当前预置流程的基础上进行更新，满足现场定制需要。6.1.6.2.4 应用管理运营系统需要提供图形化应用模板编排、一键式应用部署、应用监控以及基于监控指标的应用弹性伸缩功能。 应用模板编排支持管理员通过图形化应用模板编辑器编排多层复杂应用，经过测试后的应用模板可以发布服务目录。应用模板是将虚拟机模板、软件包、伸缩组、脚本资源，按照特定的关系有机结合，使用应用模板能够快速部署应用实例。管理员在应用模板编辑时将软件包和脚本拖放到VM模板中，在应用218、部署过程中的VM创建过程中，系统会自动上传并执行该脚本。 应用部署通过应用模板可以一键式部署多节点复杂应用；部署时，系统自动创建云主机、安装操作系统、安装应用软件、配额虚拟网络、配置应用弹性伸缩策略。参见下图6-11所示：图6-11：应用申请部署流程示意图通过应用模板一键式部署应用，支持自动执行以下动作：1.创建云主机。2.配置云主机存储。3.配置云主机网络。4.给云主机安装软件包。5.给云主机执行初始脚本。6.自动创建伸缩组，将云主机加入到伸缩组。7.创建负载均衡器，将云主机加入到伸缩组 应用监控应用在创建成功后，在整个生命周期中，用户要一直对应用进行日常维护，以保证应用提供服务的稳定性。应219、用监控就是对应用进程和应用所在云主机的监控，以便租户能够及时掌握业务异常信息，及时对异常进行处理，保证业务的正常运行。当对应用所在云主机监控时，不需要安装代理程序，可以搜集云主机的CPU、内存、磁盘I/O、网络I/O信息。当对应用进程进行监控时，需要部署了在云主机上部署Hyperic HQ客户端。具体应用监控方案如下图：监控的对象KPI指标主要是进程事务处理相关的统计指标，具体见对应的插件的KPI信息。 弹性伸缩可以通过对应用设置不同的资源使用策略，以达到应用自动伸缩的目的。设置了自动伸缩策略后，系统会自动根据资源策略和应用的资源占用率对应用进行动态伸缩（例如，增加或减少该应用的云主机），使应220、用达到最佳资源占有状态。自动伸缩策略包含组内自动伸缩策略和计划任务。 组内自动伸缩策略组内自动伸缩策略是针对一个应用而言的。当某个应用的CPU、内存资源的占用率较高，或者磁盘写入/读取速度、网络流入/流出速度较高时，系统可以自动为该应用添加云主机，并自动安装云主机的应用软件，以降低应用的整体资源负载，使应用能够健康的运行。同时，当应用的资源占用率很低时，系统可以自动减少该应用所使用的云主机，释放相应的资源，以达到应用间资源的有效复用和节能减排的目的。 计划任务 计划任务是针对伸缩组而言的。时间计划策略允许用户对于不同的应用实现资源的分时复用。用户可以设置计划策略，使得不同的应用分时段的使用系统221、资源。例如，白天让办公用户的云主机使用系统资源，晚上分配资源给公共云主机。系统支持的计划任务能力如下表6-5所列：表6-5：系统计划任务能力表参数名称含义启动时间策略启动的绝对时间停止时间策略停止的绝对时间执行方式执行一次，多次执行，周期执行执行次数在设置为多次执行时生效周期设置为周期执行时生效，支持设置天、周任务ID需定时指定的任务ID6.1.6.3 统一云管理平台6.1.6.3.1 平台定位参见下图6-12所示：图6-12：平台定位示意图本着“自主可控、开放兼容”的设计理念，围绕资源、监控、变更、问题、事件、知识、配置、操作等方面，归纳完善基于人员、流程、工具、技术、制度、管理办法的复合型222、运维体系建设标准规范，设计实现基于实际云服务、管控需求的统一云管平台，并通过统一接入体系实现统一的对接规范，与云服务商、厂商解耦合，实现灵活、随需、开放、可控的总体思路。6.1.6.3.2 设计理念UI设计基于用户操作流的设计理念。l 深入用户分析用户是计算机资源，软件界面信息的使用者，由于目前信息化系统以及相关的信息技术应用范围很广，其用户范围也遍及各个领域。在进行UI设计的同时，必须了解各类用户的习性，技能、知识和经验，以便预测不同类别的用户对界面有什么不同的需要与反应，为交互系统的分析设计提供依据和参考，使设计出的交互系统更适合于各类用户的使用。由于用户具有知识、视听能力、智能、记忆能力223、可学习性、动机、受训练程度、以及易遗忘、易出错等特性，使得对用户的分类、分析和设计变得更加复杂化。为此，基于对信息化应用的深刻理解，设计符合大众操作习惯操作流程，贴近生活的UI风格，使用户容易接受，快速习惯，持久喜爱。l 设定合理的交互方式软件界面是人机之间的信息界面，交互是一个结合计算机科学、美学、心理学、人机工程学等工业和商业领域的行为，其目标是促进设计，执行和优化信息与通信系统以满足用户的需要。在交互过程中，交互设计关系到用户界面的外观与行为，它不完全受软件的约束。界面设计师以及决定如何与用户进行交互的工程师应该在这一领域深入研究。在界面开发过程中，必须贴近用户，站在用户的角度，合理设224、置符合用户操作习惯的界面布局。l 提示和引导用户软件最终是用户的使用工具。因此应该由用户来操作和控制软件。软件响应用户的动作和设定的规则。交互系统的反馈是指用户从机器一方得到信息，表示机器对用户的动作所做的反应。对于用户交互的结果和反馈，提示用户结果和反馈信息，引导用户进行用户需要的下一步操作。在客户端的交互动作中，将设置相应的对话提示，让用户感受操作乐趣，体验交互快感。6.1.6.3.3 功能架构设计统一云管平台是在两个机房的之间，搭建的互联、互通、协调、联动、统一的Z务云管理平台。主要包括八大功能模块，参见下图6-13所示：图6-13：平台功能架构示意图1. 情况总览帮助云管理单位快速了解225、整个云平台的各项情况，包括各类资源信息、服务信息、监控信息等，并通过大屏进行展示。2. 云管业务实现各类云服务业务的管理，包括上云服务管理、云服务管理和退出服务管理，其中：1)上云业务包括现有业务应用系统的迁移上云服务和新建业务应用系统的部署上云服务。2)云服务指各使用单位使用各类云服务（服务目录中包含的各类服务）的全过程跟踪管理。3)退出服务指业务应用系统从云上退出的流程管理。3. 监控告警对各云服务商、机房的各类资源、应用系统的运行情况进行监控，对各类异常情况进行告警。并对各类故障事件进行跟踪管理，实现从监控告警、事件发生，到故障定位、恢复全过程的跟踪。4. 资源管理资源管理可分为使用单位226、和管理单位两个层面。1)对使用单位实现对本单位在用资源的相关查询、查看以及相应的配置管理功能。同时，可进一步查看当前已上云业务应用系统的各类运行情况，并申请各类服务。2)对管理单位实现对云平台本身的各类资源管理功能，包括全平台/云服务商/机房的资源配备情况、运行情况、监控情况、故障记录等信息。或从使用单位的角度，查询查看各单位云资源的使用情况、运行情况及相应的服务情况等信息5. 计量计费需基于服务目录搭建计费模型，针对使用单位实际使用的资源和服务进行计量统计，包括基础设施服务（CPU、内存、存储、网络等）、软件支撑服务、信息安全服务等，结合各云服务商服务目录中的计价规则计算相应的费用，并提供相227、应的账单功能。同时，需设计并优化相应的算法，计算采用云服务模式所产生的效益。6. 统计报告需提供基础报表功能，包括服务报告、事件报告、计量计费报告等。基于各类监控数据，搭建健康检测体系，对平台进行健康度检测和跟踪。基于故障事件记录，计算平台可用性，并形成相应的报告。参考电子Z务云平台服务考核评估方法，基于平台中的各类服务跟踪数据、监控告警信息，故障事件信息对各云服务商的服务能力、质量、满意度进行评估。同时，采用大数据技术，对海量监控数据进行分析，挖掘其中的数据价值，为平台优化配置及服务提供参考。7. 消息通知搭建统一的消息通道，通过邮件、短信、站内消息等途径，发送平台各类消息，包括：服务审批/228、反馈消息、监控告警消息、故障事件消息等。同时发布各类通知、公告，并推送给各云服务商。8. 系统管理实现各类与具体业务无关的配置管理功能，包括：用户管理、角色/权限管理、组织机构管理、云服务商/机房管理、数据字典、流程配置、CA认证集成等功能。6.1.6.3.4 数据接口设计提供各种标准和开放的接口，支持与其它各类系统的集成。主要支持的系统包括邮件与短信平台；统一认证系统如AD和LDAP；与政府OA的集成等。统一接口设计：包含了标准的接口规范与具体的统一云管理与服务平台的接口服务的配置与开发（包含：封装的云运营运维系统的接口、统一应用、服务、管理与监控接口），提供统一云管理与服务平台满足两个云服229、务商提供的云平台运营运维需求，同时为云服务商日常运维和运营过程中产生的新的管理与保障需求，提供对应的开放性的API接口，实现可扩展的定制开发服务，以满足不断增长的运维管理需求。1.接口参见下图6-6所列：表6-6：参考的接口技术文档细项设计表序号接口类型接口分类1认证接口（登录认证、认证校验、登出认证、分权分与校验、当前登录用户密码认证、注销当前登录用户、根据toolId，随机数获取TOKEN）服务管理数据共享2工单接口（工单获取、工单调用、工单反馈、工单分配、工单下发、工单修改、工单删除）工单管理3服务台账（工单获取、运维工单执行、运营工单执行、服务人工折算、工单记录、工单反馈）服务管理4计230、量（网络流量获取、获取计算资源计量表、获取服务资源计量表、主机监控获取、数据库监控获取、资源归属信息获取）计费（计费公式获取、计算折扣、服务目录获取、修改单价、修改折扣、获取协议SLA公式等）计量计费5资源对象接口（获取资源对象类型列表、获取对象属性列表、获取指定类型对象资源列表、获取指定对象详情、增加资源对象、修改资源对象、删除资源对象、获取历史资源变更列表）资源监控6告警时间接口（获取当前告警列表、获取告警详情、获取告警状态、获取历史告警列表、获取告警字典详情、产生告警、告警清除、统计当前告警数量、告警清除扩展接口、第三方上报告警、修改告警对象/级别/备注、修改告警状态、获取事件列表）服务231、管理7性能数据接口（获取实时性能数据、获取历史性能数据、获取性能KPI）资源管理8拓扑接口资源管理9订阅接口（发送邮件、发送短信、订阅通知、取消订阅）服务管理10日志接口（写操作日志、系统日志、安全日志）服务管理11公告接口（获取公告、公告推送、公告作废）公告管理12消息接口（消息接收、消息推送、消息延迟、消息分发）消息管理13CA证书接口CA认证6.2 云数据中心容灾与备份规划方案6.2.1 容灾备份等级国际标准SHARE 78将容灾系统定义成七个层次，这七个层次对应的容灾方案在功能、适用范围等方面都有所不同，所以用户选型应分清层次。本期项目要求云机房提供5级以上的容灾备份设计，其中某区的现232、有机房将作为首选的异地灾备机房使用。面对各种可能的灾难，企业需要方便、灵活地同步基于异构环境下驻留在不同数据库中的数据，这就需要建设一个对各种情况都可以抵御或者化解的本地和异地的容灾系统。但现在，一些计算机信息系统对于容灾机制的考虑还有欠缺，不少计算机信息系统只是做了简单的本地磁盘的不同分区或者是相同系统上不同磁盘的数据备份，只是严格意义上的数据备份系统，称不上容灾系统，例如数据库系统中常用的镜像备份，也就是文件拷贝方式；基于操作系统文件系统复制的方式:以及基于高端联机存储设备（磁盘阵列）之间的数据写操作同步的方式等。在一般灾难时，可以在一定意义上保证数据的完整性，但很难保证用户数据的可靠性和233、安全性，更不用说能向用户提供透明的不间断服务了。真正的容灾必须满足三个要素：先是系统中的部件、数据都具有冗余性，即一个系统发生故障，另一个系统能够保持数据传送的顺畅；其次，具有长距离性，因为灾害总是在一定范围内发生，因而充分长的距离才能够保证数据不会被一个灾害全部破坏；第三，容灾系统要追求全方位的数据复制，也称为容灾的3R（Redundance、Remote、Replication）。而国际标准SHARE 78 对容灾系统的定义有七个层次：从最简单的仅在本地进行磁带备份，到将备份的磁带存储在异地，再到建立应用系统实时切换的异地备份系统，恢复时间也可以从几天到小时级到分钟级、秒级或零数据丢失等。234、目前针对这七个层次，都有相应的容灾方案，所以，用户在选择容灾方案时应重点区分它们各自的特点和适用范围，结合自己对容灾系统的要求判断选择哪个层次的方案。0级：无异地备份0等级容灾方案数据仅在本地进行备份，没有在异地备份数据，未制定灾难恢复计划。这种方式是成本最低的灾难恢复解决方案，但不具备真正灾难恢复能力。在这种容灾方案中，最常用的是备份管理软件加上磁带机，可以是手工加载磁带机或自动加载磁带机。它是所有容灾方案的基础，从个人用户到企业级用户都广泛采用了这种方案。其特点是用户投资较少，技术实现简单。缺点是一旦本地发生毁灭性灾难，将丢失全部的本地备份数据，业务无法恢复。1级：实现异地备份第1级容灾方235、案是将关键数据备份到本地磁带介质上，然后送往异地保存，但异地没有可用的备份中心、备份数据处理系统和备份网络通信系统，未制定灾难恢复计划。灾难发生后，使用新的主机，利用异地数据备份介质（磁带）将数据恢复起来。这种方案成本较低，运用本地备份管理软件，可以在本地发生毁灭性灾难后，恢复从异地运送过来的备份数据到本地，进行业务恢复。但难以管理，即很难知道什么数据在什么地方，恢复时间长短依赖于何时硬件平台能够被提供和准备好。以前被许多进行关键业务生产的大企业所广泛采用，作为异地容灾的手段。目前，这一等级方案在许多中小网站和中小企业用户中采用较多。对于要求快速进行业务恢复和海量数据恢复的用户，这种方案是不能236、够被接受的。2级：热备份站点备份第2级容灾方案是将关键数据进行备份并存放到异地，制定有相应灾难恢复计划，具有热备份能力的站点灾难恢复。一旦发生灾难，利用热备份主机系统将数据恢复。它与第1级容灾方案的区别在于异地有一个热备份站点，该站点有主机系统，平时利用异地的备份管理软件将运送到异地的数据备份介质（磁带）上的数据备份到主机系统。当灾难发生时可以快速接管应用，恢复生产。由于有了热备中心，用户投资会增加，相应的管理人员要增加。技术实现简单，利用异地的热备份系统，可以在本地发生毁灭性灾难后，快速进行业务恢复。但这种容灾方案由于备份介质是采用交通运输方式送往异地，异地热备中心保存的数据是上一次备份的数237、据，可能会有几天甚至几周的数据丢失。这对于关键数据的容灾是不能容忍的。3级：在线数据恢复第3级容灾方案是通过网络将关键数据进行备份并存放至异地，制定有相应灾难恢复计划，有备份中心，并配备部分数据处理系统及网络通信系统。该等级方案特点是用电子数据传输取代交通工具传输备份数据，从而提高了灾难恢复的速度。利用异地的备份管理软件将通过网络传送到异地的数据备份到主机系统。一旦灾难发生，需要的关键数据通过网络可迅速恢复，通过网络切换，关键应用恢复时间可降低到一天或小时级。这一等级方案由于备份站点要保持持续运行，对网络的要求较高，因此成本相应有所增加。4级：定时数据备份第4级容灾方案是在第3级容灾方案的基础238、上，利用备份管理软件自动通过通信网络将部分关键数据定时备份至异地，并制定相应的灾难恢复计划。一旦灾难发生，利用备份中心已有资源及异地备份数据恢复关键业务系统运行。这一等级方案特点是备份数据是采用自动化的备份管理软件备份到异地，异地热备中心保存的数据是定时备份的数据，根据备份策略的不同，数据的丢失与恢复时间达到天或小时级。由于对备份管理软件设备和网络设备的要求较高，因此投入成本也会增加。但由于该级别备份的特点，业务恢复时间和数据的丢失量还不能满足关键行业对关键数据容灾的要求。5级：实时数据备份第5级容灾方案在前面几个级别的基础上使用了硬件的镜像技术和软件的数据复制技术，也就是说，可以实现在应用站239、点与备份站点的数据都被更新。数据在两个站点之间相互镜像，由远程异步提交来同步，因为关键应用使用了双重在线存储，所以在灾难发生时，仅仅很小部分的数据被丢失，恢复的时间被降低到了分钟级或秒级。由于对存储系统和数据复制软件的要求较高，所需成本也大大增加。这一等级的方案由于既能保证不影响当前交易的进行，又能实时复制交易产生的数据到异地，所以这一层次的方案是目前应用最广泛的一类，正因为如此，许多厂商都有基于自己产品的容灾解决方案。如存储厂商EMC等推出的基于智能存储服务器的数据远程拷贝；系统复制软件提供商VERITAS等提供的基于系统软件的数据远程复制；数据库厂商Oracle和Sybase提供的数据库复240、制方案等。但这些方案有一个不足之处就是异地的备份数据是处于备用（Standby）备份状态而不是实时可用的数据，这样灾难发生后需要一定时间来进行业务恢复。更为理想的应该是备份站点不仅仅是一个分离的备份系统，而且还处于活动状态，能够提供生产应用服务，所以可以提供快速的业务接管，而备份数据则可以双向传输，数据的丢失与恢复时间达到分钟甚至秒级。据了解，目前Goldengate公司的全局复制软件能够提供这一功能。6级：零数据丢失第6级容灾方案是灾难恢复中最昂贵的方式，也是速度最快的恢复方式，它是灾难恢复的最高级别，利用专用的存储网络将关键数据同步镜像至备份中心，数据不仅在本地进行确认，而且需要在异地（备241、份）进行确认。因为，数据是镜像地写到两个站点，所以灾难发生时异地容灾系统保留了全部的数据，实现零数据丢失。这一方案在本地和远程的所有数据被更新的同时，利用了双重在线存储和完全的网络切换能力，不仅保证数据的完全一致性，而且存储和网络等环境具备了应用的自动切换能力。一旦发生灾难，备份站点不仅有全部的数据，而且应用可以自动接管，实现零数据丢失的备份。通常在这两个系统中的光纤设备连接中还提供冗余通道，以备工作通道出现故障时及时接替工作，当然由于对存储系统和存储系统专用网络的要求很高，用户的投资巨大。采取这种容灾方式的用户主要是资金实力较为雄厚的大型企业和电信级企业。但在实际应用过程中，由于完全同步的方242、式对生产系统的运行效率会产生很大影响，所以适用于生产交易较少或非实时交易的关键数据系统，目前采用该级别容灾方案的用户还很少。6.2.2 云平台备份设计6.2.2.1 虚拟机快照备份方案6.2.2.1.1 备份设计原则对数据进行备份是为了保证数据的可恢复，消除系统使用者和操作者的后顾之忧。不同的应用环境需要不同的备份解决方案，一般来说，一个完善的备份系统，需要满足以下原则： 稳定性备份系统的主要作用是为系统提供一个数据保护的方法，其自身的稳定性和可靠性就变成了最重要的一个方面。首先，备份系统一定要与操作系统100%的兼容，其次，当事故发生时，能够快速有效地恢复数据。 自动化很多系统由于工作性质，243、对备份开始时间、备份窗口都有一定的限制。在深夜业务系统负荷轻时，适于备份，但会增加系统管理员的负担。因此，备份方案应能提供自动自动备份功能，并能自动管理备份介质设备。在自动备份过程中，还要有日志记录功能，并在出现异常情况时自动报警。 高性能随着业务的不断发展，数据越来越多，更新越来越快，在休息时间来不及备份如此多的内容，在工作时间备份又会影响系统性能。这就要求在设计备份时，尽量考虑到提高数据备份的速度，保证在特点的备份窗口内完成数据的备份。 维持业务系统的有效性备份对业务系统的性能将会产生一定的影响，有时会很大；如何采取有效的技术手段避免备份对服务器系统、数据库系统、网络系统的影响，将是非常重244、要的。同时，需要保证备份系统恢复的数据是有效的，完整的。 操作简单数据备份应用于不同领域，进行数据备份的操作人员也处于不同的层次。这就需要一个直观的、操作简单的图形化用户界面，缩短操作人员的学习时间，减轻操作人员的工作压力，使备份工作得以轻松地设置和完成。 实时性有些关键性的任务是要24小时不停机运行的，在备份的时候，有一些文件可能仍然处于打开的状态。那么在进行备份的时候，要采取措施，实时地查看文件大小、进行事务跟踪，以保证正确地备份系统中的所有文件。6.2.2.1.2 虚拟机快照备份方案虚拟机快照备份VMVM逻辑集群计算资源存储网络存储设备VRM(主备)FusionManager(主备)eB245、ackup备份服务器eBackup备份代理全量快照增量快照操作控制流备份恢复数据流eBackup虚拟机备份方案，是使用eBackup备份服务器，配合FusionCompute的CBT（Changed Block Tracking）及快照功能实现的虚拟机数据备份方案。eBackup通过与FusionCompute配合，对指定虚拟机或虚拟机内指定卷对象按照指定的备份策略进行备份。当虚拟机数据丢失或故障时，可使用备份的历史点数据进行恢复。数据备份的目标端可以为外接的SAN或NAS存储设备。eBackup虚拟机备份方案具有以下功能特点：1、无代理备份，不需要在要备份的虚拟机内安装备份代理软件。2、支持246、虚拟机在线备份，不管虚拟机是开机还是关机都可进行备份。3、支持对多种生产存储上的虚拟机进行备份和恢复，包括与存储虚拟化。4、支持备份到多种备份存储，包括备份服务器外接的SAN或NAS存储设备。5、支持Windows VSS（Volume Shadow Copy Service，卷影复制服务）应用一致性，保证备份数据可恢复。6、支持多种备份类型，包括完全备份、增量备份，并可批量备份。 完全备份支持有效数据备份。 增量备份功能只需备份变化数据块，减少备份数据量，降低了备份虚拟机的成本，并最大限度地缩短了备份窗口。7、支持多种恢复类型，包括恢复到新虚拟机（整机恢复）、恢复到原虚拟机（磁盘恢复）和恢复247、到指定虚拟机（磁盘恢复），并可批量恢复。其中恢复到新虚拟机（整机恢复）仅用于通过FusionCompute创建的虚拟机，不适用于通过FusionManager或桌面云创建的虚拟机。8、支持多种恢复方式，包括虚拟机镜像恢复、虚拟机差量恢复与各种客户操作系统的细粒度文件级恢复。 虚拟机镜像恢复时，恢复的数据量与完全备份相同。 虚拟机差量恢复仅针对存储虚拟化，恢复到原虚拟机时，利用更改数据块跟踪(CBT，Changed Block Tracking)功能只需恢复从备份点到磁盘当前点之间变化的数据块，从而实现快速恢复。 细粒度文件级恢复时，可以只恢复磁盘内的部分文件或目录，而不需要恢复整个磁盘，从而实248、现更快速和有效的恢复。9、生产存储使用存储虚拟化时，支持多种备份数据传输模式，包括LAN、LANSSL、SAN（或LAN-Free）。通过LANSSL加密传输，可以保证备份数据安全；通过SAN（或LAN-Free）传输，可提升备份恢复性能，减少对生产服务器的性能影响。生产存储使用存储时，由于备份网络采用的是内部存储网络，不存在安全性问题。10、支持灵活备份策略。 支持针对不同虚拟机或虚拟机组设置不同备份策略。 支持通过选择虚拟化环境下的容器（如集群）选择需要备份的虚拟机，备份时自动发现容器下新增的虚拟机。 提供多种备份类型，包括全量备份和增量备份。 支持备份数据重复数据删除和压缩。 支持设置备249、份数据保留时间以自动清除过期备份数据。 支持设置备份策略优先级。11、支持并发备份与恢复，单个备份代理支持40个并发任务。12、支持跨FusionCompute站点的虚拟机磁盘的备份和恢复。13、采用备份服务器与备份代理结合的分布式备份架构，一个备份服务器可最多管理64个备份代理（备份服务器同时具有备份代理功能，不需单独部署备份代理服务器），并可通过浏览器统一管理。建议按每个备份代理配置200个虚拟机进行规划配置，可根据虚拟机数量扩展备份代理，最大支持10000个虚拟机备份。14、高可靠性。 备份代理发生故障后，备份代理上的业务分配到其它备份代理运行。 针对操作系统、主机节点以及系统存储损坏等250、不同场景，提供备份系统自身灾难恢复功能。15、易管理和维护。 提供虚拟机模板和物理服务器部署方式。 提供基于GUI（Graphical User Interfaces）和命令行的CLI（Command-Line Interface），进行集中的备份恢复业务和系统管理，为用户提供简单直观的操作维护方式。虚拟机备份方案适用于： 服务器整合、数据中心、一体机、桌面云场景下用户虚拟机的备份与恢复。 生产存储为虚拟存储（基于SAN、NAS或本地磁盘）。6.2.2.1.3 备份容量规划备份存储容量为备份数据保留周期内所有虚拟机的备份数据量，同时需考虑为每台备份处理服务器预留50GB空间供服务器灾备使用，并251、预留20%空间供合并备份集使用。单台虚拟机磁盘空间为A GB，数据日增长B GB，共N台虚拟机需要备份，全备周期为P，增备周期为Q，数据保留周期为R，配置M台备份处理服务器，则备份存储容量为 (A*（R/P+1）+B*R/Q)*N + M*50)/0.8 。采用首次全备、后续均为增备的备份类型时，R/P计为0。例如，单台虚拟机磁盘空间为40 GB，数据日增长0.1 GB，共35台虚拟机需要备份，全备周期为每月，增备周期为每天，数据保留周期为一个月，配置2台备份处理服务器，那么备份存储容量=（全备数据量大小*(数据保留周期/全备周期+1)+增备数据大小*数据保留周期/增备周期）*需备份虚机数量+252、备份处理服务器数量*50G）/0.8=(（40*（30/30+1）+0.1*30/1）*35+2*50)/0.8=3756.25G由于eBackup备份时产生的CBT文件、快照数据需要临时占用主存储的部分空间。这些空间（CBT、快照）与需备份的虚拟机都在同一个LUN里面，为了这部分空间可以共用，建议存储规划时，尽量将需要备份的虚拟机规划在相同的LUN里面。并且需备份虚拟机的主存储至少预留部分空间（建议10%）。如果主存储由于没有多余空间导致备份失败，可以将部分虚机的存储迁走腾出空间。6.2.2.2 备份软件备份方案6.2.2.2.1 备份架构的选择对数据的保护，有多种方法，包括备份、复制、快照253、和数据容灾等等。目前用得最多、最有效的手段是数据备份。而备份的方法也很多，有手工备份、自动备份、LAN-Base备份、LAN-Free备份等。不同的备份方法，其效果不同，主要表现在性能、自动化程度、对现有系统应用的影响程度、管理、可扩展性等方面。传统的LAN备份方式：传统的备份方式系统管理员将磁带机/库或虚拟带库连接在本地备份服务器上，只对本地网络内的数据进行系统备份。在这种方案中，磁带机/库或虚拟带库只由本地服务器进行备份操作，欲备份的数据全部通过网络传输到备份服务器，再经由备份服务器备份到磁带机/库或虚拟带库中。这种方式价格较低，且不需要改变原有的网络架构。SAN备份：SAN存储区域网基于254、高速光纤通道（Fibre Channel）技术，在服务器之间以及服务器和存储设备之间建立了高速的数据传输链路。在SAN内进行大量数据的传输、复制、备份时不再占用宝贵的LAN 资源，使得LAN 的带宽得到极大的释放，服务器能以更高的效率为前端网络客户机提供服务。这种方式能充分发挥SAN高速数据流网络的优势，从而体现出高速磁带设备的性能；SAN备份方式缺点是成本较高，且往往要改变现有的网络架构。NAS系统是用一个装有优化的文件系统和瘦操作系统的专用数据存储服务器，提供跨平台的文件共享功能。NAS产品与客户之间的通讯采用NFS(Network File System)协议、CIFS(Common I255、nternet File System)协议，这些协议运行在IP之上。NAS集成了系统、存储和网络技术，具有扩展性强、使用与管理简单、跨平台文件共享、性能优化等特点另外为了避免由于地震、水灾和火灾等造成数据丢失，实现XXX对关键数据的容灾要求，我们建议采搭建数据远程容灾平台，将XXX数据中心的备份数据通过WAN网络传输到异地灾备数据中心，达到异地灾备的目的。6.2.2.2.2 备份软件的选择备份管理软件的选择对于整个系统的性能至关重要。备份软件要提供良好的备份恢复能力，简便的管理方法和技术领先性；不仅可以胜任目前的备份恢复管理，也提供良好的扩展性与前瞻技术能力。因此，备份软件的选取主要参考以下256、几方面来选择：1、 备份软件是主流的、成熟的产品，有大量的成功案例；2、 备份软件支持能对文件系统、邮件系统、数据库、虚拟机系统、应用系统、台式机以及在线存储系统中的数据进行多项数据管理：数据备份和恢复、文件及邮件归档、在线存储设备快照管理、连续数据复制、内容搜索、数据分析、重复数据删除、备份/归档数据加密。3、 备份软件支持当前主流平台系统，包括用户当前使用的Windows、Linux、AIX、VMware ESX等，而且对上述系统提供系统的裸机恢复支持；对X86平台的异机恢复都有很好的支持，可以将物理服务器恢复到不同品牌机型号的服务器中；将来还支持将物理机恢复到虚拟机中。因此管理员可以很方257、便地对备份的系统以及生产数据，进行同机裸机或者异机裸机恢复，以快速恢复业务系统或者进行可用性恢复验证。4、 备份软件支持智能索引：支持数据对象、数据内容、数据分类等的索引，并采用分布式索引架构，满足大数据时代海量数据管理的需求；5、 备份软件支持统一管理备份设备、介质和备份/恢复任务、用户，针对客户端可统一定义和修改备份计划策略，存储策略和恢复计划策略等。6、 备份软件可以对多备份域进行集中管理，总部备份域定期收集所有备份域的索引记录，实现多中心统一数据查询、恢复和报告；7、 为了保证备份数据安全性，备份软件应支持多个级别的加密方式，包括：客户端加密，介质服务器端，网络和介质服务器加密，仅网络258、加密（介质服务器端解密）、备份磁带加密以及仅备份拷贝加密等等，以满足不同级别的加密需求；8、 可提供全面的系统管理方法，包括：策略管理、安全管理、可用性管理、恢复管理、系统监控、报告以及工作流管理。6.2.2.2.3 备份介质的选择目前市场上可以作为备份设备的有磁带库和磁盘阵列设备。下面从可靠性、性能、可扩展性、投资回报率几个方面来比较一下磁盘存储备份和物理带库备份。l 可靠性物理磁带库完全由机械设备构成，磁带库的机械手、磁带驱动器和磁带均为非封闭的精密部件，它们的可靠性远不像磁带库厂商宣传的那样高，平均无故障使用时间、平均无故障换带次数等关键指标并不能作为实际应用的参考基准，多个部件组合后整259、体系统的可用性将更低：磁带驱动器、磁带存储槽、机械臂系统、控制器、条码扫描系统、磁带入库和磁带出库装置等部件任何的单点故障均可能会导致整个磁带库运转异常，增加宕机时间，甚至影响整个应用系统的正常运转。同时磁带库不具备容错能力，很容易受灰尘、潮湿等环境因素的影响而导致故障。有相当大比例的使用中端以下（包括中端）磁带库的用户至少都经历过一次导致备份失败的磁带库故障。尤其令用户烦恼的是，磁带库修复必须由专业人员进行，而且维修响应时间长，造成日常运营混乱。用户因此而被迫购买多个磁带驱动器，而驱动器恰恰是磁带库中的最主要的昂贵部件，这进一步加大了用户的总体拥有成本。磁盘存储设备没有磁带库设备的介质可靠性260、低、维护成本高等方面的困扰；同时，磁盘阵列采用RAID技术，因而基于磁盘存储的备份设备又具有极强的容错能力。l 性能 技术的发展远远落后于数据量的增长，由于其读写速率低下，因而它已经成为整个备份系统的瓶颈。另一方面，磁带加载所需要的时间，有时候比磁带读写需要的时间还要长，如果用户要恢复的数据在多盘磁带上，那么要进行一次完整的系统恢复将是漫长的过程，恢复性能将极其低下。随着业务的增长，每个系统能留给备份的时间越来越少，为了能够在更短的时间内完成更多数据量的备份，用户只能在磁带库内安装更多的磁带机，这也意味着更高的支出，更高的故障率，当磁带技术更新的时候还意味着更大的投资浪费，更糟糕的是，由于磁带261、库库体设计的限制，能够增加的磁带机数量也是很有限的。磁盘阵列设计在性能上不存在磁带库具有的读写速率瓶颈，同时磁盘存储不存在物理磁带库加载磁带的过程。l 可扩展性随着数据量不断增长，物理磁带库存储空间的扩展就显得极其有限。而如果一开始就采购比较大型的磁带库（如200槽以上），即使采用较低的初始配置，其价格仍然很高。另外磁带库支持的驱动器数目有限，其性能扩展也将受到很大限制。磁盘存储空间的扩展只需要增加更多的磁盘即可，十分方便简捷。l 投资回报率一方面，物理磁带插槽很快就不够用，另一方面，几乎绝大部分磁带库其磁带空间都无法充分利用（由于备份管理上的要求，很多磁带只写入了几十GB甚至几GB的数据，就262、由于保存周期和磁带分类管理等要求，而不能写入新的数据），这样，一台号称几十TB的磁带库，可能只能利用不到一半的空间就必须考虑扩容了。由于物理磁带库较为封闭，大部分配件的维修、更换必须由磁带库原厂商工程师完成，这使得实际故障排除时间难以控制，维修成本也很高。最终，用户会发现，用于数据保护的投资往往超出预期，而备份系统本身又极大地增加了系统维护的工作量，最终的结果却依旧不能令人满意。使用SAN阵列作为备份介质，其优势在于： 1 可以使用备份软件的重删功能，通过备份软件的源端重删功能，大大减少传输数据量，从而降低带宽需求，缩短备份窗口，节省备份设备空间。2 规避了磁带加载卸载对备份性能的影响，其持续263、读写性能达到或超过了中端磁带。3 磁盘阵列设备在用户环境中很常见，一般的系统管理员不需要过多的专业知识都可以自行维护，降低了维护成本。4 磁盘阵列成本较低，降低IT投入。6.2.2.2.4 备份方案设计解决方案解决了传统备份方法的固有缺陷，有效的降低成本，面向包括备份中心（数据中心）和云机房（远程站点）在内的整个架构，保证快速可靠的数据备份和恢复。该方案的具体策略如下，每个云机房（远程站点）点使用独立的存储策略和重删策略，备份站点内部产生的数据，同时，数据中心会将各站点的备份数据首先拷贝一份到备份中心，在拷贝过程中会使用全局重删技术。通过使用重删策略，远程站点和备份中心（数据中心）的冗余数据可264、以完全删除，从而节省备份存储空间。各站点和数据中心汇总到备份中心的备份数据还会复制一份到远程站点2的备份容灾中心。在该方案中，远程站点数据到数据中心的备份是通过WAN完成的，因此大大减少了对生产带宽的损耗；各站点独立备份和数据中心的二次重删策略也使该方案对备份存储容量的要求降低很多。通过平衡LAN和WAN的带宽利用，该方案在有效缩短备份窗口的同时，实现了对所有站点的数据备份进行统一的管理和控制。考虑到客户的业务特点和备份需求，一是数据中心和分支站点的不断增长的数据均需要进行备份；同时各站点的数据管理和保护都须通过数据中心统一控制。我们设计了一款以NAS设备作为后端介质的LAN-base的集中式265、备份解决方案。热备方案设计上，考虑客户现有机房的利旧使用问题，将会以现有的科委机房的虚拟化平台环境为基础，构建备份中心并设置对应的备份机制。同时，考虑到本次项目包含2个云服务上提供的2个云机房以及Z务外网与互联网两个重要网络区域的备份问题，下面结合客户的网络拓扑，对该方案进行详细描述。6.2.2.2.5 备份方案网络拓扑图：备份解决方案网络拓扑方案物理拓扑分为三个部分：备份中心、远程站点1（云机房1）和远程站点2（云机房2）。中心包含：备份管理节点、备份业务节点、备份存储、10GE交换机、以太网交换机（可选）五个组件。备份管理节点上安装备份管理服务组件，负责备份系统的管理；备份业务节点安装备份266、介质服务组件，负责备份数据的写入和恢复数据的读取；备份存储负责备份数据的存储；10GE交换机用于存储与服务器的互联；以太网交换机作为可选配置（可以利用已有的以太网交换机），用于备份系统和生产系统的互联。6.2.2.2.6 备份软件介绍本节介绍备份软件Simpana的主要功能和优势。Simpana为IT部门提供的数据管理工具可以使其数据管理策略现代化，维持固定成本同时提升数据管理效率。通过提供统一管理平台，Simpana软件整合了备份与恢复、归档、复制、资源管理和搜索几大功能模块，简化了IT部门对数据整个生命周期的管理。软件关键特征： 统一平台为跨存储、区域和操作系统的数据管理、保护和恢复提供了267、一个统一平台。 集成应用和数据库保护自动化、策略驱动的SnapProtectTM技术支持生产领域存储平台和应用。用户可以通过调整现有存储投入来有效缩短备份窗口，加速各级数据保护的恢复速度。 虚拟环境的数据保护利用Simpana软件SnapProtect技术和虚拟服务器代理(Virtual Server Agent) 和介质代理 (Media Agent) 几乎可以消除备份操作对生产服务器业务的影响。该软件支持数千台虚拟机的备份业务，同时支持基于阵列的快照，因此可以保证数百个虚拟机应用(Oracle, SQL Server, SAP, DB2和MS Exchange)同时在几分钟内完成备份。 提268、供基于磁盘的高级数据保护功能，包括删除重复数据、控制虚拟磁盘库、支持第三方磁盘硬件设备和更多的快照功能。 对虚拟环境、关键应用程序、数据库及服务器提供数据保护和恢复能力。关键优点： 为桌面PC机、远程办公及数据中心提供统一数据保护方案，可以降低成本和复杂度。 通过磁盘快速备份满足备份时间需求和提高存储介质利用率。 支持多厂家存储环境下的更多种灵活的灾难恢复方案。6.2.3 云平台容灾设计6.2.3.1 主备容灾方案设计6.2.3.1.1 SAN复制标准方案方案架构图生产中心到灾备中心的数据同步，使用存储LUN的同步/异步远程复制功能完成。生产中心OceanStor 18000/V3的LUN用于269、保存业务数据和虚拟机数据。容灾管理软件OceanStor ReplicationDirector只需在灾备端部署1套即可，可部署在物理机或者虚拟机上。方案支持的应用不限于图中Oracle RAC、FusionSphere和VMware，具体支持请参见方案规格。也可以交叉部署，一部分生产业务部署在生产中心，一部分生产业务部署在灾备中心，互为灾备。SAN复制标准方案，指存储之间通过LUN的远程复制功能（包括同步远程复制和异步远程复制）将数据从生产中心同步至灾备中心进行异地保护。该方案支持丰富的应用类型，通过容灾管理软件可以支持大多数常见的生产应用感知，实现快速的容灾测试、演练、切换和回切。通过Oc270、eanStor 18000/V3/T Series的LUN远程复制技术实现，可支持同步或者异步方式。方案优点： 方案实现简单、高效可靠。 使用容灾管理软件OceanStor Replication，一键式完成常见数据库应用、VMware vSphere和FusionSphere的快速测试、演练、故障恢复和回切。 支持存储高中低端阵列之间的同步和异步远程复制。 配合OceanStor 18000/V3异构虚拟机特性，扩展性好。6.2.3.1.2 NAS复制标准方案方案架构图生产中心到灾备中心的数据同步，使用存储NAS异步远程复制功能完成。生产中心OceanStor 18000/V3的文件系统用于271、保存文件数据。容灾管理软件OceanStor ReplicationDirector只需在灾备端部署1套即可，可部署在物理机或者虚拟机上。方案支持HyperReplication文件系统异步远程复制采用基于对象层的方式进行数据复制。也可以交叉部署，一部分生产业务部署在生产中心，一部分生产业务部署在灾备中心，互为灾备。NAS复制标准方案，指通过存储的文件系统异步远程复制功能，将数据从生产中心同步至灾备中心进行异地保护。该方案常用于非结构化场景，多为文件保存环境，通过容灾管理软件可以支持快速的容灾测试、演练、切换和回切。通过OceanStor 18000/V3的文件系统异步远程复制技术实现。方案优272、点： 方案实现简单、高效。 基于ROW快照确保文件系统一致性，性能好。 支持在线重删压缩，性能无损。 使用容灾管理软件OceanStor Replication，一键式完成快速测试、演练、故障恢复和回切。 支持存储高中低端阵列之间的异步远程复制。6.2.3.1.3 存储复制扩展方案扩展方案1扩展方案架构图1阵列同步/异步复制均使用OceanStor 18000/V3的远程复制功能。此处生产中心业务LUN有两种存在形态：镜像和直接接管异构存储LUN，对V3镜像卷或者对接管后的LUN使用OceanStor 18000/V3复制。生产中心和灾备中心均可使用OceanStor 18000/V3接管异构273、存储阵列。容灾管理软件OceanStor ReplicationDirector只需在灾备端部署1套即可，可部署在物理机或者虚拟机上。方案支持的应用不限于图中Oracle RAC、FusionSphere和VMware，具体支持请参见方案规格。存储支持异构虚拟化接管，可以直接将现网其它品牌存储（兼容性列表内）的LUN映射给OceanStor V3，然后映射给业务主机使用。通过OceanStor V3接管的异构存储LUN，可以直接通过存储的阵列复制功能，将数据同步至灾备中心，实现异地主备容灾。指存储通过自身的卷镜像特性，实现存储与第三方存储之间构建本地高可用环境，也可以支持单个存储内的高可用生产274、环境。再通过LUN的远程复制功能（包括同步远程复制和异步远程复制）将数据从生产中心同步至灾备中心进行异地保护。该方案支持丰富的应用类型，通过容灾管理软件可以支持大多数常见的生产应用感知，实现快速的容灾测试、演练、切换和回切。通过OceanStor 18000/V3的异构虚拟化和卷镜像特性实现本地高可用，再通过LUN远程复制技术实现，异地灾备可支持同步或者异步方式。方案优点 方案实现简单、高效可靠。 本地第三方存储故障，业务零中断，可利旧原存储阵列。 使用容灾管理软件OceanStor Replication，一键式完成常见数据库应用、VMware vSphere和FusionSphere的快速275、测试、演练、故障恢复和回切。 支持存储高中低端阵列之间的同步和异步远程复制。扩展方案2扩展方案架构图2阵列同步/异步复制均使用OceanStor 18000/V3的远程复制功能。此处生产中心业务LUN为VIS6600T提供的镜像卷，实际数据存放在存储和第三方存储上，任意IO写到镜像卷后进行镜像双写，以确保存储数据的高可用。生产中心和灾备中心均可使用OceanStor 18000/V3接管异构存储阵列。容灾管理软件OceanStor ReplicationDirector只需在灾备端部署1套即可，可部署在物理机或者虚拟机上。方案支持的应用不限于图中Oracle RAC、FusionSphere和276、VMware，具体支持请参见方案规格。此方案支持一键式容灾测试、演练和故障恢复至灾备中心，但是回切时需要手动干预并恢复数据至生产中心。OceanStor VIS6600T虚拟化网关设备支持异构虚拟化接管，可以直接将现网其它品牌存储（兼容性列表内）的LUN和存储的LUN映射给VIS6600T，通过VIS6600T构建镜像卷，然后映射给业务主机使用。OceanStor V3的LUN可以通过存储的远程复制功能将生产数据同步至灾备中心，实现异地主备容灾。指利用虚拟化网关设备VIS6600T，在生产中心构建镜像卷，数据双写至存储和第三方存储阵列，构建本地高可用生产环境。再通过LUN的远程复制功能（包括同277、步远程复制和异步远程复制）将数据从生产中心同步至灾备中心进行异地保护。该方案支持容灾管理软件实现部分业务的快速容灾测试、演练、切换，但是由于生产中心本身的业务LUN来自于VIS6600T，而非直接由存储提供，从灾备中心回切至生产中心时需要手工干预。通过OceanStor VIS6600T的虚拟化和镜像卷特性实现本地高可用，再通过存储的LUN远程复制技术实现，异地灾备可支持同步或者异步方式。方案优点 本地生产环境高可用，任意一台存储故障，业务零中断。 利旧原存储阵列。 使用容灾管理软件OceanStor Replication，一键式完成常见数据库应用的快速测试、演练、故障恢复。 支持存储高中低278、端阵列之间的同步和异步远程复制。6.2.3.1.4 数据库应用层容灾方案Data Guard的备库上面，这样可以最大化的减少故障时间，提高数据库的可用性。用“RMAN DUPLICATE FROM ACTIVE DATABASE”创建备库，在创建的过程中不需要关闭主库。也可以交叉部署，一部分生产业务部署在生产中心，一部分生产业务部署在灾备中心，互为灾备。Oracle Data Guard物理备用数据库通过重做应用技术进行维护并与生产数据库保持同步。生产数据库的重做日志数据随附在物理备库中，该物理备库使用介质恢复将更改从重做日志数据应用到备用数据库。使用重做应用，备份数据库在物理上与生产数据库保279、持一致。该方案支持实时查询的物理备用 (Physical Standby with Real Time Query)，自动故障切换和转换，自动修复数据库坏块等功能。并且可以实现快速的容灾测试、演练、切换和回切。Data Guard是通过传输和运行数据库日志文件，来保持生产和容灾数据库的数据一致性。物理standby数据库从物理上提供了与生产数据库在数据块级的一致性镜像。物理standby数据库通过Redo Apply技术来保障数据镜像能力。一旦数据库因某种情况而不可用时，standby数据库将正常切换或故障切换为新的生产数据库，以达到无数据损失或最小化数据损失的目的，为业务系统提供持续的数据服280、务能力。方案优点 在任何中断意外的情况下保持生产数据库的高可用性，并在计划维护期间最大限度地减少停机时间。 将只读负载分流到同步备用数据库，从而增加主数据库的容量并提高其性能，并且Active Data Guard保证只读查询与对主数据库执行的查询具有相同的读取一致性保证。 保证数据库不受到坏块的影响，自动修复坏块对应用程序和用户来说是透明的。 当实施Oracle补丁集或升级到新的 Oracle 版本时，Data Guard备用数据库还可以用于最大限度地减少计划停机时间。GoldenGate方案架构图生产中心OceanStor 18000/V3的LUN用于保存数据库业务数据。GoldenGat281、e利用捕捉进程(Extract Process)在源系统端读取Online Redo Log或Archive Log，确定需要进行的复制（增、删、改）操作，并通过队列(Extract 队列)，将相关信息传送到目标系统。目标系统端的数据收集进程(collector 进程)接受相关内容，通过Replicate 进程创建实现数据复制或同步的SQL语句，并在目标系统中予以执行。当生产站点Oracle RAC节点故障时，为了让GoldenGate能继续工作，至少需要将和恢复相关的GoldenGate文件放到一个共享的路径下（例如Oracle ACFS）：这些文件包括Checkpoint文件和Trail文282、件。数据库也可以交叉部署，一部分生产业务部署在生产中心，一部分生产业务部署在灾备中心，互为灾备。GoldenGate使用active-passive模式来实现live standby，做主备库，同时可以在备库分担查询负载压力。配置active-passive模式的目的是为了主库因计划和非计划的中断后可以失败转移到一个完整复制主库数据的备份数据库上。在主库失败的案例中，Oracle GoldenGate的Manager和Replicat进程与一个数据库协同工作，在主系统恢复后从备库将数据恢复到主库，使两个系统相等。在适当的时候，将用户移回主系统，Oracle GoldenGate再一次被配置为准283、备模式，以准备将来的failover。Oracle GoldenGate 软件架构包含三个主要组件：捕获、跟踪文件和交付。这种模块化方式让每个组件可以独立运行，从而加快数据复制并确保数据完整性。捕获模块只移动提交的事务，过滤掉中间活动和回滚的操作。这不但减少了基础架构负载，还避免了潜在的数据不一致。通过事务组合和可选的压缩特性，该模块还可获得进一步的优化。交付模块按照每个事务提交的顺序及事务在源数据库中的事务环境将其应用到目标数据库，从而确保目标数据库的一致性和引用完整性。Oracle GoldenGate交付模块从最新的跟踪文件读取更改的数据，然后使用相应关系数据库管理系统的原生SQL将这些284、数据应用到目标数据库。交付可适用于任何使用开放数据库连接的数据库。交付模块按照每个事务提交的顺序及事务在源数据库中的事务环境将其应用到目标数据库，从而确保目标数据库的一致性和引用完整性。方案优点 保证主备环境间事务数据的实时，低影响的捕获和传输，保持事务的完整性。 支持异构源和目标，满足不同的延迟需求。 在容灾站点支持实时查询，节省了生产站点的开销，提高了生产站点的性能。 在线跨平台数据迁移和数据库升级，最大限度减少宕机时间。6.2.3.1.5 方案对比方案对比表方案实现技术优点缺点SAN复制标准方案使用OceanStor 18000/V3/T系列LUN远程复制（同步/异步）实现。方案实现简单285、可靠，支持常见数据库应用、VMware vSphere和FusionSphere的快速测试、演练和故障恢复。支持存储高中低端阵列之间复制。存储之间，如果有第三方存储系统，需要配合OceanStor 18000/V3的异构虚拟化特性解决。NAS复制标准方案使用OceanStor 18000/V3 文件系统远程复制（异步）实现。支持多数海量数量小文件系统的异地灾备，使用文件系统的ROW快照实现，数据一致性有保证，复制性能较好。支持在线性能无损的重删压缩。支持存储高中低端阵列之间复制。只支持对象层复制，数据一致性在文件系统层。存储复制扩展方案使用OceanStor 18000/V3 存储卷镜像+存286、储LUN远程复制支持存储与第三方存储的卷镜像，构建本地高可用方案，再通过存储复制构建主备容灾。支持常见数据库应用、VMware vSphere和FusionSphere的快速测试、演练、故障恢复和回切。支持存储高中低端阵列之间复制。生产中心OceanStor 18000/V3整体全故障时，本地第三方存储系统无法立即对上提供业务，需要人工干预才能在生产中心继续运行，或者切换至灾备中心提供业务。VIS6600T镜像+存储LUN远程复制支持存储与第三方存储通过VIS600T提供镜像卷，构建本地高可用方案，再通过存储复制构建主备容灾。生产中心任意一台存储故障业务零中断。支持常见Oracle数据库应用、287、LUN的快速测试、演练和故障恢复。支持存储高中低端阵列之间复制。不支持通过容灾管理软件快速从灾备中心回切至生产中心，需要手工执行。数据库应用层方案Data Guard通过Fast-Start Failover实现快速故障转换，一旦主库不可用，observer就会自动的切换到指定的备库上面。另外自动坏块修复功能可以保证数据库不受到坏块的影响，自动修复坏块对应用程序和用户来说是透明的。Data Guard通过物理和逻辑的方式在备用机上还原数据库的日志，因此不支持异构数据库，一般来说也不支持异构的操作系统;GoldenGateGoldenGate不但可以对SCHEMA的数据进行同步，还可以对个别的表288、进行数据同步。GoldenGate通过分析主数据库的日志来完成tail文件，因此支持异构数据库，也支持异构的操作系统。GoldenGate可以提供秒一级的大量数据实时捕捉和投递，异步复制方式，无法实现同步复制。在发生故障时需要进行手动切换，故障修复后需要手动进行恢复。6.2.3.1.6 容灾管理软件介绍OceanStor ReplicationDirector是可视化的数据中心存储容灾管理软件。OceanStor ReplicationDirector（简称ReplicationDirector）是面向用户数据中心存储容灾业务的管理软件，实现容灾双活、主备、两地三中心等容灾环境的管理，具备多种289、数据库应用与虚拟化环境的容灾管理功能，简单高效的完成容灾业务配置，清晰可视的掌控系统容灾业务的运行情况，快速方便的完成数据恢复和测试演练。ReplicationDirector能够提供简化管理的容灾拓扑展示与端到端监控功能特性，直观清晰的展示容灾方案的状态与变化，实时监控相关设备，实现业务灾难切换前就识别问题与故障并协助用户排除，规避影响业务和增加成本的容灾切换发生。ReplicationDirector功能特性：稳妥的应用数据保护方式使用远程复制和快照的方式对数据进行保护。完善的应用程序兼容性支持Oracle、SQL Server、DB2、NTFS、Exchange、VMware vSphe290、re、FusionSphere云平台、存储LUN等。灵活、智能的应用系统保护策略ReplicationDirector可自动感知服务器上已经安装的应用程序，并针对不同的数据对象定制灵活的时间策略和保护方式。全面的应用系统保护方式支持任务关联功能，完全匹配真实的应用环境和应用策略。方便直观的管理模式ReplicationDirector提供了直观方便的管理平台“ReplicationDirector Server”，真正实现应用服务器、应用系统、存储系统的一站式数据保护和容灾管理。6.2.3.2 本地高可用方案设计（推荐）本地高可用解决方案通过存储虚拟化技术，接管现网存储。采用OceanStor291、系列VIS镜像、HyperMirror或HyperMetro实现存储层面的双活，实现两阵列间的互备保护。两台存储设备上的LUN被虚拟化为一个虚拟的卷，主机写操作通过卷虚拟化镜像技术同时写入这两个存储设备，保持数据实时一致。其中任何一个存储设备故障，虚拟卷仍能提供正常的IO读写能力，主机业务不受影响。待存储设备恢复正常后，存储虚拟化设备将增量数据后台同步到修复的存储设备，整个过程对主机“透明”，不会影响主机业务。同时结合主机层集群技术如Oracle RAC，Windows MSFC，VCS等实现业务连续性本地高可用解决方案，当故障发生时，确保备用服务器，备用网络和备用存储能快速自动的实现业务的冗292、余访问。避免但设备故障引发的业务长时间中断。6.2.3.2.1 VIS本地高可用组网VIS本地高可用逻辑组网图 增加设备，建立物理连接。FC网络中增加2台VIS设备和1台阵列，增加VIS和阵列的到FC交换机的冗余物理链路。 FC交换机创建zone。FC交换机中，划zone增加阵列到VIS，VIS到主机集群的逻辑连接关系，此时不激活。 配置主机组。VIS中增加应用集群的主机/主机组，两个阵列增加VIS主机/主机组。 停业务，取消阵列到主机映射。停止主机应用，在阵列上移除到主机原有映射。 激活zone。激活FC交换机的zone配置，在阵列设备管理中增加VIS主机的启动器，在VIS设备管理中增加应用293、的启动器。 阵列映射给VIS。将现有阵列LUN改成映射给VIS。 VIS创建卷并映射给主机。VIS上扫描逻辑磁盘，创建卷，映射给主机。 （可选）如果使用多路径，需要先安装多路径软件。 启业务。启动应用，运行业务，检查数据完整性。添加镜像。将阵列LUN映射给VIS，在VIS扫描逻辑盘，添加为镜像卷，完成数据初始同步6.2.3.2.2 HyperMirror本地高可用组网（可选）HyperMirror（同步镜像）本地高可用逻辑组网图6.2.3.2.3 HyperMetro本地高可用组网（可选）阵列本地高可用（HyperMetro）方案架构6.2.3.2.4 方案选择和对比存储虚拟化网关、存储阵列和294、主机层管理软件应用软件的适合场景和比较方案类型适合场景方案优点方案缺点VIS上层应用类型多数据敏感，不与应用绑定对业务连续性要求很高可以是异构存储搭配上层应用比较灵活阵列数据零丢失读性能有近一倍提升兼容异构阵列主机故障切换由上层集群软件决定，部署灵活需要增加VIS虚拟化网关设备HyperMIrror上层应用类型多数据敏感，不与应用绑定对业务连续性要求很高可以是异构存储搭配上层应用比较灵活阵列数据零丢失兼容异构阵列不需要额外的存储网关设备，只需新增1台OceanStor V3存储阵列实施和管理简单接管异构的阵列故障，需要手工恢复业务HyperMetro上层应用类型多数据敏感，不与应用绑定对业务连295、续性要求很高可以是异构存储搭配上层应用比较灵活阵列数据零丢失兼容异构阵列不需要额外的存储网关设备实施和管理简单需要新增2台OceanStor V3存储设备数据库或应用镜像（RAC）应用需要支持存储管理和镜像只要求保护该应用，如Oracle要求数据零丢失对业务连续性要求很高可以是异构存储搭配Oracle ASM构建镜像RAC集群完成故障自动切换数据零丢失复制数据量很少应用数据的一致性由Oracle保证支持异构阵列部署只要求保护该应用，如Oracle消耗主机IO资源，数据库性能略有下降(约10%)要求应用管理员管理SF上层应用类型多数据敏感，不喜欢与应用绑定主机独立安装磁盘管理软件主机集群软件和应296、用很灵活阵列层数据零丢失兼容异构存储部署灵活故障切换时，集群应用会有短暂停顿上层应用数据是否丢失由集群软件和应用保证单阵列+主节点同时故障，集群无法启动主机层要单独安装软件和管理磁盘消耗主机IO资源LVM使用Linux，AIX环境通过主机磁盘管理软件管理磁盘可以是异构存储搭配阵列层数据零丢失兼容异构存储AIX平台性价比很高故障切换时，集群应用会有短暂停顿上层应用数据是否丢失由集群软件和应用保证，LVM不保证消耗主机IO资源，主机层额外管理磁盘MirrorHA上层应用类型多能承受短暂的业务中断对数据一致性要求高可以是异构存储搭配上层应用很灵活主机层数据零丢失兼容异构存储部署灵活暂时只支持Linu297、x平台同步镜像,Windows平台是异步镜像不能与其它集群软件同时使用消耗主机IO资源，主机层额外管理磁盘6.2.3.3 灾难恢预案6.2.3.3.1 预案的制定原则灾难恢复预案的制定要遵循完整性、易用性、明确性、有效性和兼容性的原则。完整性是指灾难恢复预案（以下称预案）应包含灾难恢复的整个过程，以及灾难恢复所需的尽可能全面的数据和资料；易用性是指预案应运用易于理解语言和图表，并适合在紧急情况下使用；明确性是指预案应采用清晰的结构，对资源进行清楚的描述，工作内容和步骤应具体，每项工作应有明确的责任人；有效性是指预案应尽可能满足灾难发生时进行恢复的实际需要，并保持与实际系统和人员组织的同步更新；298、兼容性是指灾难恢复预案应与其他应急预案体系有机结合。6.2.3.3.2 预案的制定流程通常，预案的制定过程如下： 初稿的制订：按照风险分析和业务影响分析所确定的灾难恢复内容，根据灾难恢复等级的要求，结合单位其他相关的应急预案，撰写出灾难恢复预案的初稿。 初稿的评审：单位应对灾难恢复预案初稿的全面性、易用性、明确性、有效性和兼容性进行严格的评审。评审应有相应的流程保证。 初稿的修订：根据评审结果，对预案进行修订，纠正在初稿评审过程中发现的问题和缺陷，形成预案的修订稿。 预案的测试：应预先制订测试计划，在计划中说明测试的案例。测试应包含基本单元测试、关联测试和整体测试。测试的整个过程应有详细的记录299、，并形成测试报告。预案的审核和批准：根据测试的记录和报告，对预案的修订稿进一步完善，形成预案的报批稿，并由灾难恢复领导小组审核和批准，确定为预案的执行稿。6.2.3.3.3 灾难恢复预案的培训和演练为了使相关人员了解信息系统灾难恢复的目标和流程，熟悉灾难恢复的操作规程，单位应按以下要求，组织灾难恢复预案的教育、培训和演练： 在灾难恢复预案规划的初期就应开始灾难恢复观念的宣传教育工作。 应预先对培训需求进行评估，开发和落实相应的培训/教育课程，保证课程内容与预案的要求相一致。 应事先确定培训的频次和范围，事后保留培训的记录。 预先制订演练计划，在计划中说明演练的场景。演练的整个过程应有详细的记录300、，并形成报告。灾难恢复预案演练应保证至少每年一次。6.2.3.3.4 灾难恢复预案的管理1. 保存与分发经过审核和批准的灾难恢复预案，应按以下原则执行： 由专人负责保存与分发。 具有多份拷贝在不同的地点保存。 分发给参与灾难恢复工作的所有人员。 在每次修订后所有拷贝统一更新，并保留一套，以备查阅，原分发的旧版本应予销毁。2. 维护和变更管理为了保证灾难恢复预案的有效性，应从以下方面对灾难恢复预案进行严格的变更管理： 业务流程、信息系统以及人员的变更都应在灾难恢复预案中及时反映。 预案在测试、演练和灾难发生后实际执行时，其过程均应有详细的记录，并应对测试、演练和执行的效果进行评估，同时对预案进行301、相应的修订。灾难恢复预案还应定期评审和修订，至少每年一次。6.2.3.3.5 灾难恢复流程当影响业务连续运行的灾难发生时，如果能够通过生产中心系统内部的冗余架构和本地的恢复手段来消除，则优先采用本地恢复；如果无法本地恢复，必须采用容灾系统的设备或设施以实现应用接管或者需要从灾备中心恢复数据时，则进入灾难恢复流程。为能尽早、尽快恢复应用系统的运行，各责任工作组必须按灾难应对计划进行应用系统的恢复。灾备中心完成接管后，系统存在无灾备保障的风险，因此应尽快恢复生产中心运行环境，将业务由灾备中心回切到生产中心，或将恢复后的生产中心作为当前系统的灾备中心，使得应用系统回复到有灾备保障的正常状态。数据级容302、灾系统恢复流程数据级灾备恢复范围：当生产中心应用系统数据丢失或破坏时，灾备中心的数据副本将通过远程复制、磁带等方式，传送到生产中心，以恢复生产中心应用系统的运行。恢复流程如下：1、灾难上报灾难及故障通常由一线值班人员最先发现。由于值班人员未必有能力判断灾难影响，这阶段的主要工作是收集资料上报执行组进行灾难评估。当生产中心应用系统数据丢失或破坏需要从集中灾备中心恢复时，即构成上报条件。灾难上报过程执行要点： 在灾难出现的情况下，应尽量保证人员的安全。 收集资料：受影响设备/设施/环境情况：服务器、光纤交换机、存储、磁带库、磁带、网络设备、广域网线路、电源、空调、电线、光纤等；机房环境破坏情况。 303、灾难情况：灾难原因，地震、雷电、风灾、雹灾、雪灾、水灾等自然灾害；污染；火灾、水灾等结构性破坏；外部黑客、计算机病毒、软硬件故障等人为破坏/过失等；员工伤亡情况，灾难发生时间、估计恢复时间，其他情况。 向执行组汇报资料，由执行组进行灾难评估。 灾备中心监控人员发现生产系统故障告警无法与生产中心联系时，应负责上报。2、灾难评估灾难恢复执行组根据灾难引发原因，目前业务和系统的情况、可行的恢复手段、所需的恢复时间，决定采用何种恢复方式的建议，编制灾难评估报告，并且提交评估报告给领导小组。灾难评估执行要点 值班的执行组成员根据上报资料，初步了解情况。 尽可能邀请相关人员召开会议。 分析资料包括不限于以304、下内容： 受影响设备/设施/环境情况：服务器、光纤交换机、存储、磁带库、磁带、网络设备、区域广域网线路、电源、空调、电线、光纤等；机房环境破坏情况。 灾难情况：灾难原因，如地震、雷电、风灾、雹灾、雪灾、水灾等自然灾害；污染；火灾、水灾等结构性破坏；外部黑客、计算机病毒、软硬件故障等人为破坏/过失等；员工伤亡情况。 灾难严重程度、灾情的发展趋势；如需要，咨询多方技术人员（员工，集成商，合作伙伴，设备供应商等）。 研究可行的应对措施，估计恢复时间；尽快完成评估，尽早提交评估报告。 提交评估报告给相关领导组审阅，确定数据恢复方式。3、数据恢复建议灾备中心和生产中心相关灾难恢复人员根据灾难应对计划执行305、手册相关步骤，完成数据恢复工作。数据恢复过程执行要点： 暂时中断生产中心到集中灾备中心的数据复制设置。 确认生产中心公司生产环境应用系统已经恢复完毕。 工作人员将数据副本恢复到系统中。 检查操作日志，补回灾难期间离线作业的数据，并进行检查，确保业务数据的完整性，一致性。 启动应用系统。 重新启动生产中心到集中灾备中心的数据复制设置。4、消息发布措施为了制止和减少流言，公司高层领导应出面稳定员工、合作伙伴、股东等的不安情绪，因此需要有统一的渠道完成对内对外的沟通。消息发布过程对内措施执行要点： 最好由专人负责，以维持信息的一致性。 除常用的通讯手段（如电话）外，应考虑备份的通讯手段，如Email306、Web、电台等。消息发布过程对外措施执行要点： 对外公布信息必须统一口径。 负责对外发布新闻的成员必须具备随机应变的能力。 通过培训，员工应了解对外发布新闻的行政管理组联系方法，做到不与任何非灾难恢复成员讨论该灾难事件。行政管理组成员要预先建立和领导的沟通渠道、流程，落实与传媒会见的时机、时间和地点。6.3 利旧方案6.3.1 机房利旧目前，某区科委具备两个可使用的机房。其中，已经部署了部分虚拟化设备且正常投入使用中，而剩余的空间仍然具备30个以上的机柜容量与空间。无论设备还是机房都仍具备极大的使用价值，因此，在本次的Z务建设中，拟将现有的设备统一纳管到Z务云的管理平台中，而机房则主要负责数307、据交换与灾备中心两个主要的任务。本期项目要求云机房提供5级以上的容灾备份设计，其中某区的现有机房将作为首选的异地灾备机房使用。注：现有机房将保留等保三级的基本建设要求，因此，所有的利旧计划与建设都需要按照响应的安全要求来实施。6.3.2 网络利旧现有的核心交换机、汇聚交换机构建的Z务网主干网络与互联网出口网络将会全部保留。整个网络将会按照国家与地方的网络安全要求，分别与云机房进行对接。现有的网络交换与汇聚将会以现有的网络主干为主，来覆盖区内各委办局。具体的利旧网络设备情况请见网络现状分析中的现有网络架构图。6.3.3 安全设备利旧对于从云机房接入现有的Z务网的部分，现有的安全设备将会继续按照原308、有的安全体系配置，以保障安全的服务。包括防火墙、安全区域分割、WAF等安全设备。6.3.4 虚拟资源池利旧现有虚拟资源池主要指现有的Vmware环境的虚拟资源，包括已经使用的计算资源、存储资源等。l 按照迁移计划表，对于部分系统完成迁移上云工作。l 按照数据备份中心，完成备份管理、热备中心的构建。l 提供统一云管理平台的部署。l 形成重要业务数据的交换中心，搭建数据交换平台、资源目录服务中心等。6.3.5 设备利旧制度根据系统迁移上云计划，预估上云涉及30台以上的现有服务器，对于此部分服务器后续的利旧问题，原则上由科委统一评估，综合考虑服务器的现有配置、维保情况、报废年限等因素，有四种后续计划。设计并制定相关的设备利旧制度规范。l 利旧上云，对于此部分服务器，可考虑放置到运营商的机房中，继续服务；l 备份服务器，对于此部分服务器，可作为区内本地备份用，也可作为备用服务器，为后续利用；l 原单位留用，对于此部分服务器，可