电子政务云平台建设构想Word文档下载推荐.docx

上传人:b****6 文档编号:18910769 上传时间:2023-01-02 格式:DOCX 页数:9 大小:23.13KB
下载 相关 举报
电子政务云平台建设构想Word文档下载推荐.docx_第1页
第1页 / 共9页
电子政务云平台建设构想Word文档下载推荐.docx_第2页
第2页 / 共9页
电子政务云平台建设构想Word文档下载推荐.docx_第3页
第3页 / 共9页
电子政务云平台建设构想Word文档下载推荐.docx_第4页
第4页 / 共9页
电子政务云平台建设构想Word文档下载推荐.docx_第5页
第5页 / 共9页
点击查看更多>>
下载资源
资源描述

电子政务云平台建设构想Word文档下载推荐.docx

《电子政务云平台建设构想Word文档下载推荐.docx》由会员分享,可在线阅读,更多相关《电子政务云平台建设构想Word文档下载推荐.docx(9页珍藏版)》请在冰豆网上搜索。

电子政务云平台建设构想Word文档下载推荐.docx

无法利用这些众多的资源来解决突发冲击和备份的问题,达不到云计算真正按需分配、弹性扩展的目的。

1.3出路

目前各级政府的职能部门的业务系统应用众多,应用软件的系统架构、开发语言平台、中间件及数据库存在较大的差别。

因此当前阶段的政务云建设可以按以下两步的策略实施:

第一步:

以laaS(InfrastructureasaService,基础设施即服务)的模式为

主,通过云计算技术实现计算、网络、存储资源的“云化”,这样可以保证不改变上层业务系统应用的架构与部署,做到平台的通用型以及与上层应用的无关性,能够让

更多委办局的业务应用迁移到云平台,保证让云平台真正用起来。

第二步:

在laaS的基础上,构建PaaS(PlatformasaService,平台即服务)模式服务,提供统一的软件系统架构及开发平台,实现中间件、数据库的标准统一,逐步将上层应用转变成接口统一、数据标准的架构。

让各政府职能部门数据横向互通与接口变的更简单,真正让云计算为政务业务服务。

二、电子政务云基本架构

从目前的政务云整体建设来看,省级、地市级都有自己的建设规划,而且除了由各省政务信息中心承建的政务云平台之外,其它政府职能机关也都有自己内部的业务云建设规划,整体模式如下图2-1所示:

图2-1:

政务云建设模式

从目前的建设现状来看,省政务云、地市政务云、业务云之间都是相互割裂的,彼此之

间资源无法共享和借用,数据调用也非常困难。

未来的政务云建设应满足以下要求:

实现政务云的分层分级管理,省政务云平台中可以看到下级各地市的公共资

源及业务运行状态,地市云平台中也能够在授权的情况下看到上级云平台中与本地

市相关的公共资源及业务运行状态;

地市政务云、各委办局业务云数据及业务能够向省政务云备份,降低地市、各

委办局的业务备份成本;

当地市政务云、各委办局业务云资源遇到突发情况(如公务员报考查询、台风信息发布等)本地云资源不够时,可以快速的将地市业务应用迁移到省政务云平台

中,实现资源的快速扩展与负载均衡;

省政务云平台中可以根据政务业务的特性,针对常用的、通用的业务应用(如WEB门户、Mail等),制定相应的应用模板下发到地市政务云平台中,各地市可以用此模板快速在本地部署相应的业务,实现业务快速交付的同时,也能够实现全省内的应用统一,便于运维与数据互通。

统一政务业务应用的开发架构与数据服务,便于政务云平台与各业务云之间的数据调用,实现政务数据的跨平台互通。

按照云计算的技术架构,结合政务云当前的建设现状及目标,政务云的IaaS、PaaS平

台的系统架构如下图2-2所示:

图2-2:

政务云平台系统框架

硬件层:

构建服务器、网络、存储资源池,考虑到多租户及不同安全级别的业务隔离,各资源池可能是物理或逻辑上的多个构建。

IaaS层:

IaaS层主要包括虚拟化层及云服务层。

通过虚拟化技术,实现资源与物理设备的解耦合,满足业务系统快速部署与迁移。

通过云服务层实现资源的自助申请,各租户的组织管理与业务流审批,以及对租户申请的资源进行自动化编排与交付。

PaaS层:

PaaS层需要实现统一的认证授权,统一的数据服务与跨平台的开发及运行环境,保证未来业务应用后台数据统一、架构统一,为跨平台部署及政务数据共享提供基础。

业务层:

为保证对现有政务业务应用系统的良好兼容,能够让更多的委办局将业务迁移到政务云平台中,需要提供兼容非云环境下的虚拟机,不改变现有的软件部署环境,将业务迁移部署到虚拟机(VM)上。

三、电子政务云建设难点分析

当前阶段电子政务云的建设难点主要体现在以下几个方面:

1.4政务私有云的建设标准

目前市面上云计算厂商及产品众多,但由于相关标准缺乏,各厂商产品所实现的功能、后台数据格式、对应用的支撑架构千差万别。

这也导致在进行政务云建设时,虽然都叫政务云,但每朵云最络实现的效果、支撑的业务、流程管理均不一样,除了网络可以互通过外,数据很难互通,更不用提云间的资源共享了。

单靠政府的力量来推动整个云计算产业链的标准化比较困难,需要很长一段时间的过程。

但是针对政务云,它是云计算技术在政务应用下的特殊子集,是政府的私有云应用。

政府是完全有能力推动政务云的建设标准的,将平台架构标准化、组织管理标准化、业务流程标准化、数据服务标准化、功能实现标准化,对云计算厂商提出明确的要求,以此统一各省、地市政务云建设标准,真正实现资源共享与互通,改善重复、效率低下、各自为政的政务云建设。

1.5政务应用的云化

当前的政务应用从硬件部署环境来看,有部署在x86物理服务器或小型机上的,也有部

署在虚拟化平台的虚拟机(VM)上,同样是部署在虚拟机上的应用,由于各地的虚拟化平台供应厂商不一样,VMwareESX平台、CitrixXen平台、MicrosoftHyper-V平台、开源KVM平台、国产其它虚拟化平台等都会存在。

从政务应用软件的开发模型来看,有基于.net架构开发的、有基于Java开发的、有基于LAMP架构(Linux+Apache+MySQL+PHP)、也有基于Hadoop分式式架构开发等等。

受限于应用的硬件部署环境和软件开发模型,并不是所有政务应用都适合采用云计算模式进行部署。

要将现有的政务应用部署到云平台上,需要对政务应用、服务交付模式进行综合评估,即所谓的“云化”评估。

现阶段政务应用的云化,现阶段可考虑采用“小步快走”的策略,先对简单易部署的业务系统进行云化:

优先考虑部署在x86单机应用系统和已经部署在虚拟机上的业务系统,借

助现有P2V和V2V工具直接进行云化;

考虑到系统业务数据规模,优先考虑无数据库服务器或者sqlserver为后

端数据库的业务系统;

部署方式来看,为了简化首次部署,对于全国联网应用,暂不考虑云化。

1.6政务应用的迁移

从目前各地已上线的政务云项目来看,虽然云基础平台已经搭建起来,但云平台上支撑运行业务应用数量非常少,而且基本都是非关键业务应用。

大多是承建单位自身的一些重要性、实时性要求不高的非关键业务,对于一些关键业务依然在传统的数据中心内运行,并没有迁移到云平台上,每年的扩展、升级依然维持传统模式不变;

另外对于除承建单位之外的其它委办局单位,也不愿意将其业务应用迁移到政务云平台中。

导致上述现象的原因主要有两个方面:

1.对政务云平台的可靠性、稳定性信心不足:

云计算是近几年来新兴的技术

与服务模式,产品的可靠性与稳定性需要用时间和具体的项目实践来考验。

因此在政务云项目建设时应采用“试点+分步迁移”的方式部署,先在一个项目中进行试点部署,先不非关键的业务开始,逐步迁移到云平台中。

2.对政务云安全的担心:

云安全是一个比较大的话题,目前来看很难由一个厂商能够实现完整的云安全解决方案,总得来看政务云对云安全的担心主要体现在多租户的隔离上,要让各委办局将自己的业务迁移到公共政务云平台上,如何保证各委办局之间的隔离是需要考虑的。

对于多租户的隔离,可以采用目前比较成熟的物理设备虚拟化及物理设备软件化等技术,实现在政务公共云平台中,为

各委办局分配虚拟设备(如虚拟防火墙、虚拟路由器、虚拟交换机等),各委办局利用虚拟设备在公共云平台上构建属于自己的虚拟私有数据中心(VPDC),实现与传统私有数据中心同样的基础设施架构。

1.7地市、各委办局二级云存在的必然性

政务云建设的理想目标是实现资源的集中与整合,降低政务信息化的总体拥有成本

(TCO)。

但现阶段要实现省级政务云“一云统天下”是不现实的,有如下诸多实际的问题需要考虑:

1.业务应用的特殊性:

各委办局均有不少业务应用是直接由国家部委纵向统一下发的,这些业务应用往往是一些关键的应用,此类应用各委办局是不会迁移到政务共享云内的,而且国家部委也不一定允许此类应用放在共享云中。

2.数据的二级集中:

目前各委办局的业务数据很多是基于“省一地市”两级集中的,地市有自己的业务数据,此类应用系统当前阶段就实现省级统一集中是

很困难的,需要在各地市进行业务部署。

3.应用系统的运维:

政务云的建设虽然可以降低IT的运维成本,但从实际的项目建设来看,省级共享政务云中心所能承接的运维通常仅局限在基础设施层

面,要实现对各委办局、各地市业务应用系统层的运维是没有相应能力保障的。

综上所述,现阶段的政务云建设短期内要实现省级政务云“一云统天下”是很困难的,必需允许各地市、各委办局有自身的“二级云”的存在,同时受限于对云平台的稳定、可靠、安全的担心,省级政务云平台初期的建设应重点关注标准、流程、架构的制定,考虑“分步建设、逐步迁移”的模式。

四、电子政务云解决方案

1.8政务云框架

结合上述对电子政务云现状、架构及难点的分析,对于XX省政务云平台的框架构如下

图4-1所示:

图4-1:

xx省政务云框架

省政务专享云:

利用阿里云计算平台构建省级政务专享云平台,与目前的阿里

公有云隔离,此专享云专为xx省政务云服务,部署省级数据集中的业务应用,同时为下属各地市二级云提供突发时的资源借用及数据备份;

制定标准化的WEB门户、

Email业务应用模板,下发至地市二级云平台,快速生成标准化的应用并部署;

通过阿里云的PaaS平台,提供统一的政务应用数据服务、软件开发平台,为后续实现应用的统一提供基础。

地市政务云&

委办局业务云:

采用H3Cloud云计算解决方案构建各地市及委办局业务云,利用H3Cloud与阿里云的“云彩虹技术”,实现地市云业务虚拟机向省政务专享云的备份与恢得,同时地市云资源突发不够时将业务虚拟机Burst到省政

务专享云运行,实现资源突发快速扩展。

1.9分层分级组织资源管理

由于地市、各委办局二级云当前存在的必然性,以及政府职能部门的纵向性,对于政务云的建设,分层分级的组织资源管理是对云平台的基本要求,如下图4-2所示:

图4-2:

政务云分层分级组织资源管理

xx省政务云的建设分为省级和地市级两层:

省政务专享云内需要管理的资源分为本地资源与远程资源两

大类:

其中本地资源又分为各委办局使用的资源和地市临时云资源两种,地市临时云

资源是指当地市云中心遇到突发资源不够时,借用的省专享云资源,本地资源的虚拟机都是运行在省政务专享云的物理服务器上;

远程资源是由省厅下发的统一模板或部署在地市政务云中的纵向性业务应用,此类资源的虚拟机运行在地市政务云的物理服务器上,但其应用系统的控制与管理都是由省厅统一进行的。

地市政务云:

地市政务云内需要管理的资源也分为本地资源与远程资源两大

类:

其中本地资源公为地市各委办局使用的资源与省厅下发的业务源资源两种。

远程

资源是地市借用的省厅政务专享云资源,此类资源的虚拟机运行在省厅政务专享云的物理服务器上,但其应用系统的控制与管理由地市政务云管理员来负责。

1.10资源的申请与审批流程设计

省政务专享云的资源管理与使用包括以下三类人员:

1.系统管理员:

省厅政务专享云的系统管理员,管理整个专享云内的所有资源,为各个组织管理员分配资源及操作权限。

2.组织管理员:

各委办厅局对应的IT管理员,负责管理本组织(某一个委办厅局)内的云资源管理与分配,以及对云服务最终用户申请的审批。

3.云服务用户:

各委办局厅业务部门主管,云资源的使用方,负责根据业务的需求提出资源使用申请需求。

具体的云服务申请与审批流程如下图4-3所示:

图4-3:

省政务专享云资源的申请与审批

首先由系统管理员给各组织管理分配云资源,包括虚拟机数量、存储空间、操

作权限等。

当用户需要上一套应用系统时,由用户在自助门户上申请相应的资源,提交工单电子流给组织管理员。

组织管理员负责对用户的申请进行合理性审批,审批通过后云管理平台会自动对其需要的资源进行编排,交付给用户使用。

地市政务云资源正常的申请与审批流程与省政务专享云类似,如下图4-4所示:

图4-4:

地市政务云资源的申请与审批

与省政务专享云不同场景主要有两个:

地市局云资源不足:

当地市局由于某种突发需求(如公务员报考、特殊气象查询等),本地资源无法满足访问需求时,地市局政务云管理员可以主动向省厅政务专享云申请计算资源,将一部分业务交由省厅政务专享云资源处理,以满足突发需求。

省厅应用纵向下发:

由于政府职能部门纵向管理架构,为了避免一项业务需要在全体系内发布时,省厅部署快、地市局部署慢,业务无法同时上线的问题,省厅管理员可以直接将配置好的业务虚拟机模板下发至各地市局政务云,政务云管理员进行简单配置即可上线。

从而简化了部署过程,大大提高业务部署速度。

1.11高可用平台设计

政务云平台承载的省厅、地市局政府部门日常业务以及应对作为应对突发事件的平台,虚拟化和云管理平台作为政务云的核心,在设计部署时除了需要充分考虑整个政务云的高可靠性之外,还需重点关注政务云的灵活性和可扩展性。

下面从可靠性、灵活性、可扩展性三方面对云平台进行规划:

可靠性:

HighAvailability

将省厅或者地市局政务云中计算资源组合成为一个具有共享资源池的集群,一旦某台服务器主机或虚拟机发生故障,虚拟化平台会立即响应并在集群内另一台服务器主机上重新启动所有受影响的虚拟机,从而将非计划停机降到最低。

图4-5:

高可靠性HA示意图

灵活性:

DRS

当省厅、地市局政府各部门业务在政务云上运行后,政务云还需具有自动调整的能力,

达到资源的最大化利用,以应对不断变化的用户访问和突发需求情况。

动态资源调整是指

提供的动态负载均衡特性引入一个自动化机制,通过持续地平衡容量,将虚拟机迁移到

有更多可用资源的主机上,确保每个虚拟机在任何节点都能及时地调用相应的资源。

图4-6:

DRS示意图

可扩展性:

DRX

在遇到特别大的突发业务时,需要启动多台虚拟机才能完成对服务的响应。

那么,政务云应该具备自动化的可扩展性,即在需求突增时自动的复制虚拟机,共同对外提供服务。

可扩展性可以两种场景:

省厅及各地市局内部云计算中心:

当一台虚拟机无法满足访问需求时,虚拟化平台可以自动复制虚拟机,共同对外提供服务。

图4-7:

本地的动态资源扩展

地市局扩展至省厅政务专享云:

当地市局所能调配的云资源都无法满足访

问需求时,就借用省厅政务专享云中的地市临时云资源共同提供服务。

图4-8:

云间的动态资源扩展

1.12多租户安全隔离

云计算安全问题一直是部署云计算首要考虑的问题,特别是在大型的政务云中多租户环境下安全问题显得尤为重要。

目前实现多租户安全隔离目前主要有两种方式:

VEPA

利用802.1Qbg(EVB)标准能够很好的解决多租户隔离问题(IEEE802.1Qbg标准

是由IEEE802.1工作组制定的一个新标准)。

采用支持802.1QbgVEPA标准的vSwitch与支持802.1QbgVEPA标准物理交换机,实现了计算资源与网络资源的深度融合,从而实现多租户流量的精确控制,保证多租户环境的安全。

图4-9:

基于VEPA的多租户隔离

虚拟设备

将原本需要物理交换机、路由器、防火墙、负载均衡等网络设备完成的工作交由软件

的交换机(vSwitch)、路由器(vSR)、防火墙(vFW)、负载均衡(vLB)设备完成。

实现精确到每一个用户的全面控制,确保多租户环境下云数据中心安全。

基于虚拟设备的多租户隔离

1.13业务迁移规划

针对政务应用目前的部署现状,对省厅及地市局现有业务可采用逐步迁移、逐步扩展的思路,初期可构建最小的资源池,将现有数据中心内的政务业务按照业务类型、重要程度的不同,逐步向资源池内迁移,同时迁移后将空闲出来的服务器加入到资源池内,实现设备的利旧及资源池的扩展。

具体可分以下几个步骤:

建设完善的核心网络支撑平台:

保证后续应用迁移及业务扩展时网络能够平滑支持,而且不会中断之前已迁移到云平台和未迁移到云平台中的业务应用;

搭建云计算基础资源池及管理平台:

保证云计算laaS平台的最小工作

环境,构建计算、存储资源池。

同时充分考虑对现有IT设备(服务器、存储等)

的兼容性,便于后续进行资源池整合。

第三步:

业务的P2V迁移:

初期可以对非关键应用进行迁移,保证迁移过程中不影响其它应用。

第四步:

资源池的整合与扩展:

将已迁移到云平台中的业务应用之前所归属的物理服务器、存储资源逐步整合到云计算资源池中,实现对现有设备的利旧,最大化的保证投资,同时进一步扩大云计算资源池。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 自然科学

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1