市大数据中心项目应急灾备中心基本建设方案_第1页
市大数据中心项目应急灾备中心基本建设方案_第2页
市大数据中心项目应急灾备中心基本建设方案_第3页
市大数据中心项目应急灾备中心基本建设方案_第4页
市大数据中心项目应急灾备中心基本建设方案_第5页
已阅读5页,还剩29页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

省电子政务应急灾备中心

某市分中心

项目建议书

目录

第1章项目概述................................................................-4-

1.1项目名称.................................................................-4-

1.2项目概况.................................................................-4-

1.3主要结论和建议..........................................................."4-

第2章项目建设的必要性........................................................-5-

2.1某省电子政务外网概述.....................................................-5.

2.2某省电子政务灾备系统现状及问题..........................................-5-

2.3项目建设必要性...........................................................-6-

第3章项目需求分析............................................................-7-

3.1业务承载范围需求.........................................................-7-

3.2网络需求.................................................................-7-

3.3存储容量需求.............................................................-7-

3.4分险防控需求.............................................................-7-

3.5容灾系统能力需求.........................................................-8-

3.5.1容灾系统的容灾对象...................................................-8-

3.5.2信息系统灾难恢复目标RPO与RTO....................................................................-9-

3.5.3标准灾难恢复能力等级体系.............................................-9-

3.5.4信息系统灾难恢复目标与灾难恢复能力等级体系的关系..................-10-

3.5.5容灾系统能力需求分析................................................-11-

第4章总体设计...............................................................-12-

4.1建设思路.................................................................-12-

4.2建设原则................................................................-12-

4.3建设目标................................................................-13-

4.3.1近期目标.............................................................-13-

4.3.2中远期目标...........................................................-13-

4.4总体架构................................................................-14-

第5章容灾系统解决方案.......................................................-15-

5.1灾备中心架构概述........................................................-15-

5.2灾备云平台建设..........................................................-18-

5.2.1灾备网络建设........................................................-18-

5.2.2灾备云平台建设......................................................-19-

5.3信息与网络安全建设......................................................-22-

5.3.1管理层面.............................................................-22-

5.3.2技术层面............................................................-22-

5.4灾备管理体系建设.......................................................-24-

5.4.1灾难恢复应急架构....................................................-24-

5.4.2灾备决策的条件和流程...............................................-25-

5.4.3灾难管理技术恢兔步骤...............................................-25-

5.4.4灾难恢复演练........................................................-26-

5.4.5灾难恢复培训........................................................-26-

5.5运维管理体系建设.......................................................-26-

5.5.1运维管理内容........................................................-26-

5.5.2运维管理组织方案....................................................-27-

第6章投资估算...............................................................-31-

6.1投资估算的有关说明.....................................................-31-

6.2项目总投资估算.........................................................-31-

6.2项目建设总投资估算.....................................................-32-

第7章项目建议...............................................................-33-

第1章项目概述

1-1项目名称

某省电子政务应急灾备中心某分中心建设项目(以下简称“某市应急灾备中

心”)。

1.2项目概况

项目投资估算:19817万元。

应急灾备中心选址:在某大数据中心机房内。

建设规模:机架:160个;服务器:最少需安装1272台,最大可安装1600

台;存储容量:10PB,出口带宽初期500M,远期可达到50GB。灾备中心整体

规模可以满足某省省、市两级政务云未来5到10年灾备服务需求。

1.3主要结论和建议

随着电子政务的深入发展,我省各级政务部门己经越来越依赖信息化工作手

段履行其政务职能,对政务信息系统的可靠性和连续性提出了更高的要求,攻务

信息系统一旦中断,将会对政务部门履行政务职能及经济社会正常运转造成重大

影响。在国家“十二五”规划中,明确规定进一步深化政务信息化建设工作,而灾

备信息化已经成为了政务信息化的重点方向,但目前,在政务信息系统业务数据

灾备体系建设方面,我省存在灾备能力不足、技术比较薄弱、项目经验不足等一

系列的问题,己无法满足各级政务部门对政务信息系统数据、应用保护的需求。

因此,我省应加快某市应急灾备中心建设,以防止突发灾难对我省电子攻务

外网信息系统、关键数据产生重大破坏,保障社会经济、秩序稳定。

第2章项目建设的必要性

2.1某省电子政务外网概述

随着国家电子政务网络建设和应用的不断推进,电子政务网络在减少重复建

设、节约投资方面己初见成效,在促进网络互联互通、资源共享、业务协同等方

面所发挥的作用也日益凸显。截止到2012年,国家电子政务外网已连接31个省

(自治区、直辖市)、304个市(地、州、盟)、1689个县(市、区),接入国家

政务部门和相关单位77个及省级以下政务部门24400个。政务外网已经成为我

国连接政务部门最多、网络覆盖面最广的政务公用网络。

在国家发展和改革委员会、国家电子政务外网管理中心的关心支持下,在省

委、省政府的正确领导下,我省认真贯彻落实国家电子政务战略,依照国家电子

政务外网总体规划开展了我省电子政务外网建设,建成了上联国家电子政务外网,

下联21个市(州)、183个县(市、区),横向连接全省所有政务部门的电子政

务外网网络,部分地区完成了向乡镇村一级的延伸。目前,我省依托政务外网,

开展了行政审批电子监察系统、政府信息公开目录管理、省政府公文传输、应急

指挥、民政减灾、视频会议等一系列大型公共应月,电子政务外网已成为我省覆

盖范围最广、应用数量最多的电子政务公共网络平台。

2.2某省电子政务灾备系统现状及问题

电子政务建设是当前乃至今后一个时期我省信息化工作的重点。电子政务业

务系统的连续性和安全性十分重要,电子政务的数据安全更是重中之重,基于数

据的灾难备份是电子政务信息安全的最后一道防线,国家相关部门至今已发布一

系列文件对电子政务领域的灾难备份建设进行指导和监督。而目前我省很多玫务

部门还没有建立电子政务数据备份容灾系统,或应用水平较低。其主要表现在:

(1)对灾备的重要性、紧迫性认识还不到位。部分单位和人员将灾备中心

建设单纯等同为数据库数据的备份、复制。

(2)基本灾难备,分措施和统一的技术标准缺乏。许多重要应用系统尚未建

立基本的数据级灾难备份措施,不具备恢复能力:没有专业的备份软件和存储设

备对关键业务数据进行集中、自动备份;各系统各份时间的随意性较大,无统一

的备份策略;重要应用系统灾难备份建设的标准不统一。

(3)存储资源利用率低,存储资源无法共享。

(4)数据恢复过程复杂。当系统出现问题时,数据恢复需要过多的人工干

预,灾难恢复非常复杂。

上述问题导致现有电子政务灾备系统己无法完全满足各部门对重要信息数

据系统灾难备份的需要,也不符合国家对重要信息数据系统灾难备份的要求。

2.3项目建设必要性

随着近几年政务网络覆盖面的拓展,依托政务网络的我省各级政务部门业务

应用也逐步普及和兴起,数据与业务处理日趋集中,由此产生的大量重要数据信

息•般都保存在各部门的服务器硬盘和存储系统上,这些重耍数据信息直接关系

到社会生活和经济活动的方方面面,如网上行政审批和电子监察系统、政府信息

公开平台系统等,并且随着政务网络和业务应用的进一步发展,各部门的重要信

息数据和应用系统将与时俱增,一旦因火灾、地震、失窃、病毒等外因,或误操

作等人为因素引起系统瘫痪、数据毁损,将给单位和个人带来重大损失,对社会

生活和经济活动造成不可估量的影响,因此,对于电子政务相关信息的安全性和

可靠性要求越来越高,应急灾备系统的作用愈发我得重要。

建设某省电子政务应急灾备中心某分中心,可以有效解决目前条块分割、灾

备系统重复建设、灾备能力不均衡的现象,实现各部门间信息资源共享;有利于

促进全省电子政务外网应用的发展能够更好地服务各政务部门;也有利于提高我

省政务信息系统灾备能力,提高应急管理体系水平。

第3章项目需求分析

3.1业务承载范围需求

依据“三不三百”原则(不在同一个电网、不在同一个江河流域、不在同一个

地震带,相距三百公里以上),某市应急灾备中心可以满足我省省、市(除某市、

西昌市外)两级政务云平台非涉密电子政务外网业务应用异地灾备需求。

3.2网络需求

某市应急灾备中心灾备服务网络需依托某市大数据中心电子政务外网构建,

并需对现有电子政务外网进行适应性地升级改造。同时,某市应急灾备中心需具

备互联网接入能力,能通过MPLSVPN等技术隔离手段实现非涉密专网的连接

和业务承载。

3.3存储容量需求

需满足未来3年的我省省、市(除某市、西昌市外)两级政务云平台非涉密

电子政务外网业务应用异地灾备对存储的需求。

灾备存储主要用于保存实时复制数据、历史备份数据、快照以及备份日志等

内容,因此,在设计某市应急灾备中心存储容量时,应充分考虑满足保存上述数

据的需求。

3.4分险防控需求

对于某市应急灾备中心来说,风险分析的范围主要考虑省、市两级各政务部

门所在地区范围和与之在经济、业务上有紧密联系的邻近地区的交通、电讯、能

源及其他关键基础设施遭到严重破坏,或造成此地区的大规模人口疏散或无法联

系后所面对的可能性风险,同时还需要考虑省级各政务部门电子政务信息系统中

断所造成的系统性风险。

目前在省级电子政务外网各应用系统中,总体来看,数据的可靠存放和备份

主要存在以下方面的风险:

(1)缺乏针对硬件故障、天灾(地震、雷击等)、人祸(机房火灾、机房进

水、电力故障等)和渐变式灾难(人为操作失误、系统软件BUG、病毒、黑客

等)的全面而有效的数据保护措施和恢复手段。

(2)接入电子政务外网的政府单位数量众多,地理位置和应用环境非常复

杂,普通的备份和恢复手段实现困难,造价高昂、管理复杂。

(3)电子政务外网系统涵盖的应用及信息数据的种类非常多,不同的应用

对容灾保护的需求各不相同,接入电子政务外网的政府单位政务应用系统平台复

杂,操作系统有Windows、Unix、Linux等,数据库有Oracle、SQLServer等,

其中的数据都有不同层次的容灾需求。

3.5容灾系统能力需求

3.5.1容灾系统的容灾对象

根据容灾对象的不同,容灾系统包含三个层次,分别是数据容灾、系统容灾

和应用容灾。

数据容灾:就是构建异地的数据备份系统,保证工作数据能及时、完整地复

制到备份系统中,保证数据的完整性、可靠性和安全性。数据容灾只保证关键工

作数据的备份,并没有一整套冗余的可运营的业务系统。当灾难发生时,恢复业

务需要较长时间。对于RTO要求高的容灾系统就需要更高层次的容灾。

系统容灾:就是通过对信息系统关键配置和关键进程的备份,保证运行信息

系统本身的高可用性。系统容灾和数据容灾共同构成了基础容灾系统,要实现工

作系统的快速灾难恢复,两者缺一不可。

应用容灾:也称'1%务容灾,是指在基础容灾系统上,构建一整套与本地工作

系统同构的异地备份应用系统。在正常工作的情况下,主、备系统间互为备份。

当灾难发生时备用系统能自动接管工作系统,提供连续、不间断的应用服务,从

而保证了业务的连续性。一般对RPO和RTO目标较高的用户,都需保证对应用

的容灾。

应用容灾系统往往需要融合以负载均衡、应用集中和隔离、系统运行参数监

控等为基础的分布式资源调度(DistributedResourceScheduler,DRS)技术,以

发现、隔离故障,并及时迁移和重分配资源实现系统的连续运行,并在整个过程

中尽可能实现自动化,而这些都是虚拟化技术的优势。

3.5.2信息系统灾难恢复目标RPO与RTO

衡量容灾系统的安全性和可靠性有两个重要指标:

(1)恢复点目标(RecoverypointobjectRPO),是指从灾难发生到可以让业

务恢复正常运行的时间段内,允许丢失的最大数据量。

(2)恢复时间目标(Recoverytimeobject,)是指从信息系统下线开始,到

系统恢复至正常运作,所能容忍的业务停止服务的最长时间,也就是从灾难发生

到业务系统恢复服务所需的最短时间周期。

RPO和RTO越小,表示系统的可用性越高,也意味着容灾系统建设的投入

越大。在某市应急灾备中心建设中,将根据自身业务的性质和特点确定合适的

RPO和RTO目标。

353标准灾难恢复能力等级体系

为了提高重要信息系统应对灾害的能力,国家标准化管理委员会于2007年

11月1日发布了《信息系统灾难恢复规范》一一GB/T20988-2007(以下简称“国

标”),在国标中,规定了一个灾难恢复的六级体系,按照从第一级到第六级的顺

序级别依次升高。总结归纳如下:

第1级:基本支持。即只能在本地进行数据备份,数据本地场外保存。当灾

难发生时,只有很低的灾难恢复能力,而且无法保证'业务的连续性。

第2级:备用场地支持。在本地进行备份,数据场外存放,当灾难发生后,

能在预定时间内调配所需要的通信线路和网络设备到备用场地进行业务恢复。

第3级:电子传输和部分设备支持。将本地数据进行备份,并通过通信网络

将关键数据定时批量送往备用场地保存。当灾难发生时,对系统关键数据进行恢

复。该级别的数据备份成本低,但存储介质难管理,当灾难出现时,损失的数据

量大。

第4级:电子传输及完整设备支持。在异地建立一个数据备份站点,并配备

灾难恢复所需的全部数据处理设备并处于就绪状态或运行状态。每天多次利用通

信网络将关键数据定时批量传送至备用场地.当灾难发生时,利用备份站点的数

据进行恢复。它与第3级别的灾难容忍程度相同,但它采用网络进行数据复制,

两站点数据同步程度高。

第5级:实时级数据传输及完整设备支持。在异地建立一个与源应用系统完

全相同的备用系统,采用远程数据复制技术,通过网络将关键数据实时复制到备

用场地。当灾难发生时,关键数据可以确保零丢失,但是应用系统的恢复需要一

定时间,业务连续性较差。

第6级:数据零丢失和远程集群支持。在异地建立一个与源应用系统完全相

同的备用系统,利用远程实时备份,实现数据零丢失。当灾难发生时,备用系统

完全接替源问题系统进行工作,并且可以实现数据零丢失。

由此可见,灾难恢复能力等级越高,对于信息系统的保护效果越好,但同时

成本也会急剧上升。因此,需要根据成本风险平衡原则(即灾难恢复资源的成本

与风险可能造成的损失之间取得平衡),确定业务系统的合理的灾难恢复能力等

级。对于多个业务系统,不同业务可采用不同的灾难恢复策略。

3.5.4信息系统灾难恢复目标与灾难恢复能力等级体系的关

恢复时间目标(RTO)和恢复点目标(RPO)与信息系统灾难恢复能力等级

具有一定的对应关系,某市应急灾备中心应根据我省政务云平台业务特点和信息

技术的应用情况制定相应的灾难恢复能力等级要求和指标体系。

灾难恢复能力等级与信息系统灾难恢复目标(RTO,RPO)对应关系如下:

灾难恢复能力RTORPO

第1级2天以上1天至7天

第2级24小时以上1天至7天

第3级12小时以上数小时至1天

第4级数小时至2天数小时至1天

第5级数小时至2天0至30分钟

第6级数分钟0

3.5.5容灾系统能力需求分析

某市应急灾备中心未来将会承载省、市两级政务云平台业务应用灾备需求,

政务云平台业务应用的稳定运行,关系到政府工作的高效、有序开展,关系到国

计民生大计,因此,结合政务云平台业务实际,同时考虑距离因素及当前可用技

术等多方面因素,将某市应急灾备中心容灾层次设定为数据级容灾和应用容灾兼

具,以应用级容灾为主;RT0<=4小时,RPO<=30分钟;容灾级别定义在5级。

针对上述容灾目标,对某市应急灾备中心容灾系统提出如下具体要求:

(1)支持当前主流的操作系统如Windows系列和Linux常见发行版本,并

在操作上实现统一的处理过程,降低平台系统配置和客户端配置的复杂度。

(2)应用容灾和数据备份相统一。最大程度增强重要应用系统的数据完整

性和在线能力,解决除电力故障等整体性不可抗拒因素外的普通系统宕机引起的

系统离线问题。

(3)系统可扩展性强。容灾系统基于云计算平台,充分利用云计算平台良

好的扩展性,保证容灾系统具有较强的扩容功能。随着政务应用业务拓展,可以

进行灵活的容灾系统调整和应用规模扩大。

(4)业务应用的高连续性。基于云计算平台,实现主、备机之间的短时间

切换,并辅助数据备份功能,实现业务系统的高可用性(HA)

(5)系统利用率高。充分利用云计算平台的高资源利用率,既在建设上节

省投资,又在能耗上节能环保。

第4章总体设计

4.1建设思路

在某省政务云总体规划的框架下,以前期调研成果为基础,立足某省省、市

两级政务业务应用需求实际,坚持以顶层设计、统筹规划、先易后难、分步实施、

整合共享为原则,以提高某省政务信息系统灾备能力和应急管理体系水平为建设

目标,借助云计算等先进技术手段,构建自主可控的面向省、市(除某市和西昌

市以外)两级政务云平台的共享型数据级和应用级异地灾备中心——某省电子政

务应急灾备中心某分中心。

4.2建设原则

(一)统筹规划、多元推动

综合考虑省、市两级各政务部门的灾备需求,衔接信息化发展相关规划及工

作部署,统筹规划某市灾备中心建设,鼓励社会力量参与灾备设施中心建设,提

倡使用社会化数据灾备服务,充分调动政府部门、电信运营商、第三方灾备服务

提供商、核心设备厂商等多方力量,共同推进灾备能力建设。统筹规划,建设统

一的灾备中心,降低风险成本、人力成本和维护成本。

(二)立足需求、务实发展

坚持以实际灾备需求为立足点,合理确定某市应急灾备中心规模和等级,准

确定位灾备中心服务市象和模式,统筹集约化各部门灾备需求。充分利用某市大

数据中心资源,建设某市应急灾备中心。着力避免一哄而上、脱离需求、贪大求

全、产能过剩的局面。

(三)平战结合、提高效能

在突出灾备能力建设的同时,体现平战结合思想,更加注重应急实战演练,

切实提高重耍信息系统和信息资源抵御突发性信息安全风险的能力。科学进行功

能统筹,使某市应急灾备中心具备业务承载、数据交换、负载分担、云计算等常

态综合功能。依托某市大数据中心资源建设某市灾备中心,可以避免灾备资源长

期闲置,充分挖掘灾备资源的利用潜力,开发和拓展增值业务,充分发挥灾备资

源的综合效益。

(四)技术先进、节能环保

利用后发优势,广泛借鉴国内外灾备中心建设运行经验,实现灾备中心的跨

越式发展和绿色可持续运行。灾备中心IT设备的能源消耗只占整个灾备中心能

耗的3()%,而制冷设备的能源消耗要占到50%-60%,其他如灯光照明将占到

10%o通过合理规划布局,充分利用某市地域以及气候优势,再结合云计算、虚

拟化技术等新兴技术,不仅可以大大降低某市灾备中心的能耗,而且可以通过分

布式负载均衡、共享使用模式等分摊或减少制冷设备的能耗,实现降低碳排放和

绿色发展。

4.3建设目标

4.3.1近期目标

依托我省电子政务外网,建设某市应急灾备中心,构建自主可控的共享型数

据级和应用级异地灾备中心。为我省省级政务云平台提供数据级、应用级异地灾

备服务。

4.3.2中远期目标

在实现省级政务云平台数据级和应用级容灾的基础上,按照国家灾备标准,

为我省距离某市30()公里以上的具备条件的城市提供市级政务云平台数据级、应

用级异地灾备服务,实现重要信息系统同省异地数据级、应用级共享式信息互备,

逐步建设和形成我省信息系统灾难备份体系。

4.4总体架构

除攀枝花市、西昌市之外的其他19个地级市

图4-1某省政务云灾备总体架构

根据我省政务云建设愿景及实际发展需要,在某市构建面向省政务云平台和

19个市级政务云平台的共享型数据级、应用级异地灾备中心。通过构建“1+1+1”

的核心运行体系,实现我省政务云灾备体系建设•体化、协同化发展,真正把某

市应急灾备中心打造成我省政务云平台灾备中心建设的典范。

构建“1+1+1”的异地灾备核心运行体系,即1张网、1中心、1平台。

——1张网:指异地灾备专网。利用现有电子政务外网建设我省政务云平台

灾备专网。

—I中心:指某市应急灾备中心。充分发挥某独有的区位优势。在某市建

设面向我省省、市(除某市和西昌市)两级政务云平台的共享型异地数据级、应

用级应急灾备中心。

——1平台:指灾备管理平台。利用云计算技术构建某市应急灾备中心灾备

云平台,实现灾备资源按需分配和统一管理,提高灾备资源利用率。利用远程数

据复制技术,实现实时、弹性、灵活的政务云应用容灾和业务持续性保护。

第5章容灾系统解决方案

5.1灾备中心架构概述

图5-1某市应急灾备中心架构

某市应急灾备中心统一规划建设,构建统一的运维管理平台,供管理员对灾

备中心资源统一调度和分配,以及进行演练和切换的管理。专业化运作,使各容

灾用户不再需要单独自建、更新和升级技术环境。基于服务提供的模式满足各容

灾用户灾备需求。

从业务角度,将整个灾备中心容灾平台分为容灾演练区、非核心业务灾备区

和核心业务灾备区。

(1)容灾演练区

某市应急灾备中心的核心作用是为了在发生灾难事件导致数据不可恢复时,

能够将重要的信息数据进行有效的恢复,将各接入用户的损失降到最低,因此,

为了确保灾备中心中的灾备数据在需要时能够恢复,必须设立一套行之有效的数

据恢复及演练机制,并设立一个独立于备份环境的恢复演练环境。

容灾演练区的作用主要有:

1、对灾备数据进行可用性、完整性的验证;

2、模拟真实系统平台下,测试灾备数据的可恢复性。为了满足各个接入用

户应用系统定期(半年或一年)灾难恢复演练的需要,设计考虑同时满足不同接

入用户进行数据可用性演练。

(2)非核心业务灾备区

对省、市两级政务云平台RPO、RTO值要求较低的核心业务提供异地数据

级和应用级灾备服务。

(3)核心业务灾备区

对省、市两级政务云平台RPO、RTO值要求较高的核心业务提供数据级和

应用级灾备服务。

从实际功能角度,将整个灾备中心容灾平台分为数据容灾区和应用容灾区。

无论是容灾演练区,还是核心、非核心业务灾备区,均可实现数据级和应用级容

灾。

(1)数据容灾区

・实现功能

数据容灾区主要解决省、市两级政务云平台数据容灾需求。当省、市两级政

务云平台发生灾难后,可以通过灾备中心的数据恢复源政务云平台,从而提升省、

市两级政务云平台业务系统数据的可靠性。

•实现方式简述

考虑到各容灾用户生产系统对于存储的容量和性能要求不一,同时随着数据

量的增长,需要提供更大的存储空间,因此,数据级容灾区域采用存储资源池技

术,将存储组成一个大存储资源池,根据各容灾月户提交的数据容灾需求,分配

对应的存储空间,存储资源池应用了存储Thinproving技术,可以预先给各容灾

用户分配足够大的空间,同时可以监控实际数据写入量,根据数据增量情况,逐

步新增实际存储容量,不影响容灾用户使用的情况下,又有效的减少灾备的中心

前期的投入。

(2)应用容灾区

・实现功能

应用容灾区主要解决省、市两级政务云平台应用容灾需求。当省、市两级政

务云平台灾难发生时,可以快速容灾切换,将容灾用户业务切换至某市应急灾备

中心对外提供服务。

•实现方式简述

应用级容灾区需要部署与容灾用户生产环境1:1的服务器资源,采用专业

容灾备份软件。通过容灾备份软件所提供的数据增量复制技术实时截获省、市级

政务云平台源端服务器上的数据变化,并将变化了的数据以增量异步复制形式实

时发送到目标服务器,实现源端服务器和某市应急灾备中心目标端服务器保持文

件的一致性,同时为应对逻辑错误,在目标端启月定时快照操作,当最终数据被

破坏时,从快照中提取历史数据,将数据恢复到逻辑错误点前的状态C

5.2灾备云平台建设

5.2.1灾备网络建设

图例:

干把演

「出口路由器万九旗

1RF则化

核心交换

汇聚交换机

灾备

云主机

攀枝花应急实备中心

•灾备云存储

灾备管理平台

图5・2某市应急灾备中心网络拓扑规划

租用通信运营商线路,实现某应急灾备中心核心出口路由与省级电子政务外

网相连,初期设计出口带宽500M,远期逐步达到50Go利用MPLSVPN技术在

省、市两级政务云平台与某市应急灾备中心之间建立容灾备份虚拟业务专网

(VPN),保障数据传输安全。

2台核心交换机,分别通过10GE链路与接入层交换机、GE链路与管理网

交换机和出口路由器互连,两台核心交换机部署IRF虚拟化。

接入层每组采用2台接入交换机,每台接入交换机与核心交换机采用10GE

链路交叉互连,两台接入交换机部署IRF虚拟化,与核心交换机实现跨设备链路

捆绑,消除二层环路,并实现链路负载分担。

管理网交换机分别连接服务器的L0接口实现服务器的带外管理。同时与

某市应急灾备中心灾务管理平台服务器互连。上行采用2*GE链路与两台核心交

换机互连,并实现链路捆绑。

分层分区设计思路:根据业务进行分区,分成计算区、存储区和管理区。计

算、存储区域内二层互通,区域间VLAN隔离;根据每层工作特点分为核心层

和接入层,网关部署在核心层。

5.2.2灾备云平台建设

5.2.2.1灾备服务器

根据前期的调研分析,在考虑未来3年业务增量的情况下,省级政务云平台

计算资源需求最少达到4148个CPU核心;运行内存需求最少达到16848GB。参

照省级政务云平台规模,初步考虑除某市和西昌市以外,其他19个市(州)计

算资源需求最少达到39406个CPU核心;运行内存需求最少达到157624GBo

省、市两级政务云平台计算资源需求合计:最少达到43554个CPU核心,

运行内存需求最少达到174472GB

某市应急灾备中心建成后,将为省、市两级政务云平台提供数据级、应用级

灾备服务。因此,在考虑设计灾备平台处理性能时,应综合考虑省、市级政务云

平台对处理性能的需求。

由于只在灾难发生时才会将省、市两级政务云平台应用切换至灾备中心,当

源平台恢复正常后,应用会切换回原有政务云平台,灾备云平台只发挥临时业务

接管的作用。而且,同一时段发生全省性的政务云平台应用无法使用的概率也非

常小。因此,在不影响业务正常开展的情况下,灾备云平台服务器整体处理性能

配置可以相对较低。

综合以上考虑,某市应急灾备中心计算、内存资源按省、市两级政务云平台

计算、内存资源总和的70%的设计,计算资源需求为30488个CPU核心,运行

内存需求为12I952GB。

建议灾备服务器配置:

设备名称配置建议数量单位

2*E5-2650Lv3(L8GHz/12核/30MB/65W);6*16GB

RDIMMDDR4内存;2*300GB热插拔SAS硬盘

计算资源(15K);2*双端口千兆网卡(RJ45接口);可扩充

1272台

池服务器万兆网卡模块;1*双端口、8GB、FCHBA卡,LC接

口;RAID卡支持RAID0、1、10、5、6/DVD/冗余

电源/冗余风扇

S.2.2.2灾备存储

根据前期的调研分析,在考虑省级政务云平台未来3年业务增量的情况下,

省级政务云平台存储容量需求规模为:最少达到257TB。参照省级政务云平台存

储规模,初步考虑除某市和西昌市以外,其他19个市(州)政务云平台存储需

求规模最少达到:3.7PB。

省、市两级政务云平台存储容量需求规模合计为:3.95PB。

根据以上分析,同时综合考虑备份日志、快照、实时复制数据等因素,某市

应急灾备中心存储容量初期设计配置10PB。

建议灾备存储配置:

名称配置描述数量单位

系统

架构分布式架构

架构

操作

专业存储操作系统

系统

支持

支持NFS,SMB

协议

协议支持

访问支持NIS,MicrosoftActive

控制Directory,LDAP

省级政务

其他

云分布式SNMP1套

协议

存储

单一

标配1PB存储容量,系统最大可支持

存储容量文件

40PB存储容量

系统

系统

可靠性可靠组网全冗余部署,无单点故障

横向

可扩展性支持200节点线性扩展

扩展

名称配置描述数量单位

后端

支持10GE/40GEInfiniband/GE组网

组网

组网类型

前端

支持10GE/40GEInfiniband/GE组网

组网

节点

本次配置74个分布式节点

数量

单节

节点配置1块2TB6GSAS7.2K3.5inSSD硬盘;

点存

3块4TB6GSAS7.2K3.5inch硬盘单

储容

名称配置描述数量单位

系统

架构分布式架构

架构

操作

专业存储操作系统

系统

支持

支持NFS,SMB

协议

协议支持

访问支持NIS,MicrosoftActive

控制Directory,LDAP

其他

SNMP

协议

单一

标配4.5PB存储容量,系统最大可支持

存储容量文件

40PB存储容量

系统

市级政务

系统

云分布式2套

可靠性可靠组网全冗余部署,无单点故障

存储

横向

可扩展性支持200节点线性扩展

扩展

后端

支持10GE/40GEInfiniband/GE组网

组网

组网类型

前端

支持10GE/40GEInfiniband/GE组网

组网

节点

本次配置154个分布式节点

数量

单节

节点配置1块2TB6GSAS7.2K3.EinSSD硬盘;

点存

7块4TB6GSAS7.2K3.5inch硬盘单

储容

5.3信息与网络安全建设

遵照信息安全等级保护《GB/T22239-2008》的三级标准要求设计某应急灾

备中心信息与网络安全管理体系。

531管理层面

目前省级电子政务外网平台已完成等保三级建设,因此在安全管理层面,某

应急灾备中心与省级电子政务外网平台的安全管理规范将保持一致,主要包含相

关的安全管理制度、安全管理机构的设置和人员配备、人员的安全管理、系统建

设管理(方案设计、产品采购与使用、工程实施、测试验收、系统交付)、系统

运维管理以及整体的变更控制等内容,具体管理内容和措施将参照省级电子玫务

外网平台的安全管理规范、制度、策略执行。

5.3.2技术层面

5.3.2.1物理安全防护

物理机房各区域系统(核心骨干区域、动力区域、仓储区域、报警监控区域)

设计使用定制的电子卡,由数据中心专职人员保管。机房中的物理设备、配件耗

材的安置或存放与所有办公区域和公共区域隔离,机房中的重要部件,如核心网

络设备的网络模块,精密存储介质等,放在专门的电子加密保险箱存放,且由专

人进行保险箱的开关。仓储系统中的任何配件,均需授权工单和授权人员才能领

取,且需要对其进行记录,定期对物资进行盘点跟踪。机房内部的每个区域,或

外部走廊区域,或内部计算区域,都使用摄像机,数据中心安全保障人员7*24

小时分段巡逻,对所有基础设施进行7*24小时集中视频监控。

机房内采用冗余电力系统,主电源和备用电源具备相同的供电能力,机房内

采用空调系统保障服务器或其他设备在恒温环境下运行,并对中心机房的温湿度

进行机密电子监控,一旦发生告警可采取相应措施。另外在设备冷风区域对冷风

通道密封,充分提高制冷效率。机房配备火灾探测系统,探测系统的传感器应部

署在机房的天花板和地板下,利用热、烟雾和水传感器来实现,当火灾或烟雾事

件触发时,在着火区提供声光报警。在机房还应配备手动灭火装置,机房管理人

员应定期组织灭火演练培训I。

由于某应急灾备中心机房规划选址在某大数据中心内,并且某大数据中心已

设计并制定了上述相关安全配套机制及措施,遵守即可,因此,无需另行设计部

署应急灾备中心物理安全防护措施。

5・3.2.2网络安全防护

某应急灾备中心的网络架构遵照三层网络模型(核心、汇聚、接入),在网

络上通过VLAN划分不同区域(容灾演练区、非核心业务容灾区、核心业务容

灾区、管理平台区、数据灾备区、应用灾备区)各区域通过各接入层交换机上内

置防火墙功能进行访问控制,控制粒度为端口级,有完整的访问行为审计记录。

对于灾备中心的网络边界完整性采用PORTAL的准入方式,保证网络连接的合

规性。

省级政务云平台到某巾应急灾备中心的数据芍输中,应急灾备中心可能会受

到DDOS攻击和非授权的用户访问,需要对这些攻击和非法访问加以限制,以

保护灾备中心存储设备的安全。在核心交换机前端部署专业的抗DDOS的流量

检测和流量清洗设备,可以对DDOS攻击进行有效的防护。另外在某应急灾备

中心的核心交换机前单独部署入侵防范IPS系统,防范来自外部的IP碎片攻击、

网络蠕虫攻击、木马后门攻击、端口扫描及强力攻击等安全威胁。

5.3.23主机安全防护

在本项目建议书中,规划的服务器及存储,均采用虚拟化技术,实现资源利

用的最大化,因此主机安全防护层面,需要考虑到恶意代码防范、主机脆弱性检

测、资源控制等问题,因此,设计部署防病毒软件,检测主机系统的恶意代码,

部署漏洞扫描系统,对全网的系统(网络、数据库、系统)进行漏洞管理,使用

服务器虚拟化自带的管理系统,对各VM进行有效的控制(包括VM隔离、VM

系统监视、VM最小权限等安全策略)。

5.3.2.4应用安全防护

某应急灾备中心是在异地建立的一个与源应用系统完全相同的备用系统,采

用远程数据复制技术,通过网络将关键数据实时复制到灾备中心。因此在应用安

全(应用系统的身份鉴别、访问控制、安全审计机制)方面,某应急灾备中心与

省级及各地市现有生产应用安全防护内容将保持一致。另外,数据传输的保密性、

完整性也是应用安全防护中的一个重要环节,因此数据传输上,建议在省级攻务

云平台到某市应急灾备中心的传输链路两端防火墙设备之间运行MPLSVPN协

议,并且基于电子政务网络专门组建用于共享容灾备份的虚拟业务专网(VPN),

双保险保证数据在传输过程中的端到端安全性。

5・3.2・5数据安全防护

在数据安全防护方面,主要在数据访问授权以及数据存储上,结合应急灾备

中心需要建设统一的基础设施管理系统,实现对路由器、交换机、安全、存储、

服务器等基础设施的综合管理,建立规范的安全运维管理系统,实现对管理人员

访问资源(路由器、交换机、安全设备、存储设备、服务器)的统一账号管理、

统一认证管理、统一授权管理以及统一审计管理,有效加强内部运维人员安全操

作规范,保障数据安全。另外,结合网络安全、主机安全以及应用安全的几个不

同维度的安全保障机制,可以有效的保护存储数据的安全性。

5.4灾备管理体系建设

5.4.1灾难恢复应急架构

根据某市应急灾备中心的实际业务情况以及人员情况,成立灾难恢复应急小

组,建立架构,明确分工。设置从灾难恢复总指挥、灾难恢复组长、各应用和架

构的恢复组长、具体的各应用架构的恢复成员等岗位。在灾难发生或容灾演练时,

各岗位的职责不同。

1)灾难恢复总指挥:负责与上级沟通、下达灾难切换的指令、召集容灾恢

复组织所有成员;

2)灾难恢复组长:协调各组的容灾恢复进程、及时向灾难总指挥汇报容灾

恢复进展、协调外部厂商资源;

3)各应用架构的恢复小组组长:联系本小组涉及到的外部厂商工程师、负

责下达技术恢复操作指令、负责本小组内成员的工作分配、及时向灾难恢复组长

汇报容灾恢复进展;

4)各应用架构的吸复小组成员:负责对本小组负责的内容进行具体的容灾

恢复操作、及时向本小组组长汇报灾难恢复的进展。

5.4.2灾备决策的条件和流程

1)灾难决策:归纳和总结出进行灾难恢复的条件,作为灾难切换的前提;

2)数据中心整体进行灾难切换的条件:将明确列出进行数据灾难切换的条

件。例如网络中断多少小时无法恢复、重大自然灾害等;

3)单应用系统进行容灾切换的条件:根据单个应用和架构具体情况,明确

列出灾难切换各种条件。例如:服务发生故障,多少小时无法修复完成时,作为

灾难切换的前提;

4)决策流程:由灾难恢复总指挥向领导进行汇报,得知明确的灾难切换的

指示后,再下达灾难切换的命令。同时,可根据当时具体情况及灾难恢复条件,

直接进行切换指令的下达,实现应用系统的快速容灾切换。

543灾难管理技术恢复步骤

技术恢复步骤设计作为灾备项目中对当初设计的RTO、RPO保障的重要环

节,往往是以技术恢复文档集合的形式体现,此类文档需要达到以下标准:

1)技术恢复文档集合覆盖从整体架构到具体应用架构的所有进行灾难恢复

对象,覆盖从灾难切换到回切的所有文档;

2)技术恢复文档严格遵照实际情况进行书写;

3)技术文档操作步骤必须清晰明了,并具备较强的可操作性。在恢复小组

人员发生流动的情况下,新的成员加入可依照文档快速的上手和操作;

4)技术文档中必须明确恢复过程中的相关要素恢复先后顺序。在进行灾难

恢复和回切过程中,各小组严格依照技术文档中的恢复顺序进行操作,避免发生

小组之间的相互影响。

当进行容灾演练时,各小组成员须依照文档中的操作、流程进行恢复演练操

作。整个恢复过程应做到有条不紊,避免了因文档缺失或更新不及时所造成的技

术恢复时间浪费。

5.4.4灾难恢复演练

灾备的目的是为了恢复,演练的目的是为了发现问题,并熟悉操作和流程。

某市应急灾备中心须定期组织如下多种形势演练:

I)桌面演练:定时召集灾难恢复小组成员,采用头脑风暴形式,模拟灾难

发生情景,各小组成员讨论恢复演练过程中可能发生的状况,发现问题后改进恢

复演练预案文档;

2)模拟演练:定时选择某套核心系统,在不影响正常业务进行的前提条件

下,进行灾难恢复演练;

3)实战演练:定期进行实战容灾恢复演练,以验证整个数据中心或者单个

核心应用系统发生灾难时,能否达到当初项目设计之初的RPO和RTO指标。

5.4.5灾难恢复培训

为了提高各恢复小组成员对自身维护系统的熟悉程度,某市应急灾备中心依

据内部或外部资源,定期对各小组成员进行其维护的系统知识层面的培训。在此

基础上,定时进行灾难恢复制度和文档的培训,让灾难恢复小组的每位成员都能

在真实灾难发生时,并能以最快的速度对其维护的系统进行恢复。

5.5运维管理体系建设

5.5.1运维管理内容

5.5.1.1基础设施管理

建设统一的基础设施管理系统,实现对路由器、交换机、安全、存储、服务

器等基础设施的统一管理。建立资源、业务与用户的统一拓扑视图,方便管理员

从各个维度对数据中心的各种资源进行管理。

5.5.1.2IP资源管理

采用图形化的配置管理工具,帮助用户对ACL、QoS、SLA等IP资源进行

管理,并根据网络运行和性能优化的需要,实现对QoS服务质量、ACL安全策

略、SLA服务水平等管理策略的动态调整。提供虚拟化管理功能,包括虚拟化

网络管理和虚拟服务器管理。用户可以在拓扑图中看到虚拟化网络及其设备的各

种状态,并且对网络虚拟化技术等进行配置和管理,还应提供对虚拟机(VM)、

虚拟机链路、物理服务器的性能监控,并实现各虚拟服务器和网络设备间拓扑关

系的展示;配合虚拟服务器实现动态资源迁移。

5.5.L3应用和流量管理

在不影响灾备业务系统运行的同时,从各个角度对业务和流量进行监控和管

理。从多个维度监视各种灾备作业、网络和服务器等的运行情况,自定义监视器

功能,允许用户对灾备作业进行定制化监控,以满足用户的个性化需求。

5.5.1.4IT运维流程管理

在IT服务管理——ITIL规范的基础上,通过用户帮助平台、CMDB配置管

理数据库、知识库等流程管理功能,并结合网管平台自身的基础设施管理能力和

IP资源配置能力,打通了IT运维流程与网络配置管理之间的界限,整合IT服务

与业务流程。提供运维报表开发平台,灵活抽取监控数据,定期生成可定制化报

表。

5.5.2运维管理组织方案

5.5.2.1运维组织机构及职能

项目运维小组的主要职能包括:运维规范及制度管理、需求管理、数据管理、

IT安全管理、系统维护、硬件维护、网络维护。具体如下图所示:

图5・3运维职能示意图

其相应的职能如下:

(1)运维规范及制度管理:负责信息化系统的IT维护标准、IT维护制度、

IT维护流程的设计、制定、管理。

(2)需求管理:负责对信息化系统的使用部门的具体需求及问题进行收集、

整理、评审等工作。

(3)数据管理:负责信息化系统数据的导入导出、备份、数据维护以及数

据质量的管理。

(4)IT安全管理:负责依据《中华人民共和国保守国家秘密法》、《中华人

民共和国计算机信息系统安全保护条例》保障信息系统的安全、有序、稳定运行。

负责IT系统安全体系的建设、规范制定和管理、IT系统安全体系维护规范制定

和管理。

(5)软件维护:负责业务应用平台软件、操作系统、中间件、数据库软件

等内容的日常维护操作、告警监控、故障排查。

(6)硬件维护:负责信息化系统的服务器、存储、交换机、路由器等硬件

设备的维护操作、告警监控、故障排查等。

5.5.2.1运维及管理的规范

管理方针与政策

规定程序记录寰单操作手册

R便

曙1

冏K

府ft

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论