电子政务云的建设规划
发表于2013-10-21 15:36
摘要：政务云结合了云计算技术的特点，对政府管理和服务职能进行优化、整合，并通过信息化手段在政务云上实现各种业务流程办理和职能服务，为政府各级部门提供可靠的基础IT 服务平台，实现资源的共享、弹性与快速交付。政务云同时能加强对政府业务运作的有效监督，提高政府工作效率，并为社会公众提供服务...
从当前全国的云计算建设的情况来看，虽然各地的项目建设如火如荼，但普遍存在以下几个方面的共性问题：
人云亦云。以云计算立项，但实际上是数据集中的建设，将基于数据集中的项目均称之为“云计算”，概念的包装远偏离云计算技术与服务模型本身。
虚拟化即云。仅利用服务器虚拟化软件（如VMware ESX等），对现有机房的服务器及新增服务器进行虚拟化整合，将现有的业务应用由物理机部署迁移至虚拟机部署。但并没有实现云计算的“自助申请、自动化编排、快速交付”的核心价值，不是真正意义的“云计算”。
缺乏云业务。已部署了服务器、存储、网络、虚拟化软件、云平台软件搭建了真正的云平台，但此平台上并没有运行关键的业务应用，各委办局也不愿意并自己的业务应用迁移到云平台上，“云”的效应并没有真正发挥出来。
建设分散。同一个省份、同一个体系内有多个云计算项目建设，大小不一，标准与架构也都不同，云计算中心资源及运维缺乏纵向统一管理，更谈不上资源互通共享。无法利用这些众多的资源来解决突
发冲击和备份的问题，达不到云计算真正按需分配、弹性扩展的目的。
目前各级政府的职能部门的业务系统应用众多，应用软件的系统架构、开发语言平台、中间件及数据库存在较大的差别。想解决上述问题，可以按以下两步的策略实施政务云建设。
第一步 以IaaS（Infrastructure as a Service，基础设施即服务）的模式为主，实现计算、网络、存储资源的“云化”，这样可以保证不改变上层业务系统应用的架构与部署，做到平台的通用型以及与上层应用的无关性，能够让更多委办局的业务应用迁移到云平台，让云平台真正用起来。
第二步 在IaaS的基础上，构建PaaS（Platform as a Service，平台即服务）模式服务，提供统一的软件系统架构及开发平台，实现中间件、数据库的标准统一，逐步将上层应用转变成接口统一、数据标准的架构。让各政府职能部门数据横向互通与接口变的更简单，真正让云计算为政务业务服务。
下文将从电子政务云的基本架构、建设难点以及针对难点的解决方案几方面进行分析阐述。
一、 电子政务云基本架构
从目前的政务云整体建设来看，省级、地市级都有自己的建设规划，而且除了由各省政务信息中心承建的政务云平台之外，其他政府职能机关也都有自己内部的业务云建设规划，基本模式如图1所示。
图1. 政务云建设模式
从建设现状来看，省政务云、地市政务云、业务云之间都是相互割裂的，彼此之间资源无法共享和借用，数据调用也非常困难。但从实际需求的角度出发，未来的政务云建设必须满足以下5个要求：
分级管理。实现政务云的分层分级管理，省政务云平台中可以看到下级各地市的公共资源及业务运行状态，地市云平台中也能够在授权的情况下看到上级云平台中与本地市相关的公共资源及业务运行状态。
向上备份。地市政务云、各委办局业务云数据及业务能够向省政务云备份，降低地市、各委办局的业务备份成本。
快速扩展。当地市政务云、各委办局业务云资源遇到突发情况（如公务员报考查询、台风信息发布等）本地云资源不够时，可以快速的将地市业务应用迁移到省政务云平台中，实现资源的快速扩展与负载均衡。
快速部署。省政务云平台中可以根据政务业务的特性，针对常用
的、通用的业务应用（如Web门户、Mail等），制定相应的应用模板下发到地市政务云平台中，各地市可以用此模板快速在本地部署相应的业务，实现业务快速交付的同时，也能够实现全省内的应用统一，便于运维与数据互通。
平台互通。统一政务业务应用的开发架构与数据服务，便于政务云平台与各业务云之间的数据调用，实现政务数据的跨平台互通。
按照云计算的技术架构，结合政务云当前的建设现状及目标，政务云的IaaS、PaaS平台的系统架构分为硬件层、IaaS、PaaS和业务层（如图2所示）。
图2. 政务云平台系统框架
硬件层：构建服务器、网络、存储资源池，考虑到多租户及不同
安全级别的业务隔离，各资源池可能是物理或逻辑上的多个构建。
IaaS层：IaaS层主要包括虚拟化层及云服务层。通过虚拟化技术，实现资源与物理设备的解耦合，满足业务系统快速部署与迁移。通过云服务层实现资源的自助申请，各租户的组织管理与业务流审批，以及对租户申请的资源进行自动化编排与交付。
PaaS层：PaaS层需要实现统一的认证授权，统一的数据服务与跨平台的开发及运行环境，保证未来业务应用后台数据统一、架构统一，为跨平台部署及政务数据共享提供基础。
业务层：为保证对现有政务业务应用系统的良好兼容，能够让更多的委办局将业务迁移到政务云平台中，需要提供兼容非云环境下的虚拟机，不改变现有的软件部署环境，将业务迁移部署到虚拟机(VM)上。
二、电子政务云建设难点分析
政务私有云标准的确立
目前市面上云计算厂商及产品众多，但由于相关标准缺乏，各厂商产品所实现的功能、后台数据格式、对应用的支撑架构千差万别。这也导致在进行政务云建设时，虽然都叫政务云，但每朵云最终实现的效果、支撑的业务、流程管理均不一样，除了网络可以互通过外，数据很难互通，更不用提云间的资源共享了。
单靠政府的力量来推动整个云计算产业链的标准化需要很长一段时间的过程。但是针对政务云，它是云计算技术在政务应用下的特殊子集，是政府的私有云应用，政府是有能力推动政务云的建设标准
的，通过对云计算厂商提出明确的要求，将平台架构标准化、组织管理标准化、业务流程标准化、数据服务标准化、功能实现标准化，以此统一各省、地市政务云建设标准，真正实现资源共享与互通，改善重复、效率低下、各自为政的政务云建设。
政务应用的云化
当前的政务应用从硬件部署环境来看，有部署在x86物理服务器或小型机上的，也有部署在虚拟化平台的虚拟机（VM）上，同样是部署在虚拟机上的应用，由于各地的虚拟化平台供应厂商不一样，VMware ESX平台、Citrix Xen平台、Microsoft Hyper-V平台、开源KVM平台以及其他国产的虚拟化平台等都会存在。
从政务应用软件的开发模型来看，有基于.Net架构开发的、有基于Java开发的、有基于LAMP架构（Linux+Apache+MySQL+PHP）、也有基于Hadoop分式式架构开发等等。
受限于应用的硬件部署环境和软件开发模型，并不是所有政务应用都适合采用云计算模式进行部署。要将现有的政务应用部署到云平台上，需要对政务应用、服务交付模式进行综合评估，即所谓的“云化”评估。现阶段政务应用的云化，可考虑采用“小步快走”的策略，先对简单易部署的业务系统进行云化：
优先考虑部署在x86单机应用系统和已经部署在虚拟机上的业务系统，借助现有P2V和V2V工具直接进行云化。
考虑到系统业务数据规模，优先考虑无数据库服务器或者SQL Server为后端数据库的业务系统。
为了简化首次部署，对于全国联网应用，暂不考虑云化。 政务应用的迁移
从各地已上线的政务云项目来看，虽然云基础平台已经搭建起来，但云平台上支撑运行业务应用数量非常少，基本都是非关键业务应用：重要性和实时性要求都不高。关键业务并没有迁移到云平台上，每年的扩展、升级依然维持传统模式不变；另外承建单位之外的其他委办局单位，也不愿意将其业务应用迁移到政务云平台中。原因主要有两个方面：
对政务云平台的可靠性、稳定性信心不足。云计算是近几年来新兴的技术与服务模式，产品的可靠性与稳定性需要用时间和具体的项目实践来考验。针对这个顾虑可以在政务云项目建设时应采用“试点+分步迁移”的方式部署，先在一个项目中进行试点部署，从非关键的业务开始，逐步迁移到云平台中。
对政务云安全的担心。政务云对云安全的担心主要体现在多租户的隔离上，要让各委办局将自己的业务迁移到公共政务云平台上，如何保证各委办局之间的隔离是需要考虑的。对于多租户的隔离，可以采用目前比较成熟的物理设备虚拟化及物理设备软件化等技术，在政务公共云平台中，为各委办局分配虚拟设备（如虚拟防火墙、虚拟路由器、虚拟交换机等），各委办局利用虚拟设备在公共云平台上构建属于自己的虚拟私有数据中心（VPDC），实现与传统私有数据中心同样的基础设施架构。
二级云存在的现实性。政务云建设的理想目标是实现资源的集
中与整合，降低政务信息化的总体拥有成本（TCO）。但现阶段要实现省级政务云“一云统天下”是不现实的，有如下诸多实际的问题需要考虑：
业务应用的特殊性。各委办局均有不少关键的业务应用是直接由国家部委纵向统一下发，此类应用暂不会迁移到政务共享云。
数据的二级集中。目前各委办局的业务数据很多是基于“省—地市”两级集中的，地市有自己的业务数据，省级统一集中具有很大难度，需要在各地市进行业务部署。
应用系统的运维。从实际的项目建设来看，省级中心所能承接的运维通常仅局限在基础设施层面，要实现对各委办局、各地市业务应用系统层的运维缺少相应保障。
综上所述，现阶段的政务云建设短期内要实现省级政务云“一云统天下”是很困难的，必需允许各地市、各委办局有自身的“二级云”的存在，同时受限于对云平台的稳定、可靠、安全的担心，省级政务云平台初期的建设应重点关注标准、流程、架构的制定，考虑“分步建设、逐步迁移”的模式。
三、电子政务云解决方案
结合上述对电子政务云现状、架构及难点的分析，下文以具体某个省政务云平台为例，介绍H3C电子政务云解决方案（如图3所示）。
1. 政务云框架
图3. 某省政务云框架
省政务专享云
利用公有云平台（以下以阿里云为例说明）构建省级政务专享云平台，与目前的阿里公有云隔离，此专享云专为某省政务云服务，部署省级数据集中的业务应用，同时为下属各地市二级云提供突发时的资源借用及数据备份；制定标准化的Web门户、Email业务应用模板，下发至地市二级云平台，快速生成标准化的应用并部署；通过阿里云的PaaS平台，提供统一的政务应用数据服务、软件开发平台，为后续实现应用的统一提供基础。
市政务云&委办局业务云
采用H3Cloud云计算解决方案构建各地市及委办局业务云，利用“云彩虹技术”实现地市云业务虚拟机向省政务专享云的备份与恢得，同时地市云资源突发不够时将业务虚拟机Burst[p1] 到省政务专享云运行，实现资源突发时快速扩展。
2. 分层分级组织资源管理
由于地市、各委办局二级云当前存在的必然性，以及政府职能部门的纵向性，对于政务云的建设，分层分级的组织资源管理是对云平台的基本要求（如图4所示）。
图4. 政务云分层分级组织资源管理
某省政务云的建设分为省级和地市级两层：
省政务专享云
省政务专享云内需要管理的资源分为本地资源与远程资源两大类：其中本地资源又分为各委办局使用的资源和地市临时云资源两种，地市临时云资源是指当地市云中心遇到突发资源不够时，借用的省专享云资源，本地资源的虚拟机都是运行在省政务专享云的物理服务器上；远程资源是由省厅下发的统一模板或部署在地市政务云中的
纵向性业务应用，此类资源的虚拟机运行在地市政务云的物理服务器上，但其应用系统的控制与管理都是由省厅统一进行的。
地市政务云
地市政务云内需要管理的资源也分为本地资源与远程资源两大类：其中本地资源公为地市各委办局使用的资源与省厅下发的业务源资源两种。远程资源是地市借用的省厅政务专享云资源，此类资源的虚拟机运行在省厅政务专享云的物理服务器上，但其应用系统的控制与管理由地市政务云管理员来负责。
3. 资源的申请与审批流程设计
省政务专享云的资源管理与使用面向以下三类人员：
系统管理员：省厅政务专享云的系统管理员，管理整个专享云内的所有资源，为各个组织管理员分配资源及操作权限。
组织管理员：各委办厅局对应的IT管理员，负责管理本组织（某一个委办厅局）内的云资源管理与分配，以及对云服务最终用户申请的审批。
云服务用户：各委办局厅业务部门主管，云资源的使用方，负责根据业务的需求提出资源使用申请需求。
具体的云服务申请与审批流程如图5所示：
图5. 省政务专享云资源的申请与审批
第一步，首先由系统管理员给各组织管理分配云资源，包括虚拟机数量、存储空间、操作权限等。
第二步，当用户需要上一套应用系统时，由用户在自助门户上申请相应的资源，提交工单电子流给组织管理员。
第三步，组织管理员负责对用户的申请进行合理性审批，审批通过后云管理平台会自动对其需要的资源进行编排，交付给用户使用。
地市政务云资源正常的申请与审批流程与省政务专享云类似，不同场景主要体现在资源不足和应用的纵向下发（如图6所示）。
图6. 地市政务云资源的申请与审批
地市局云资源不足。当地市局由于某种突发需求（如公务员报考、特殊气象查询等），本地资源无法满足访问需求时，地市局政务云管理员可以主动向省厅政务专享云申请计算资源，将一部分业务交由省厅政务专享云资源处理，以满足突发需求。
省厅应用纵向下发。由于政府职能部门纵向管理架构，为了避免一项业务需要在全体系内发布时，省厅部署快、地市局部署慢，业务无法同时上线的问题，省厅管理员可以直接将配置好的业务虚拟机模板下发至各地市局政务云，政务云管理员进行简单配置即可上线。简化部署过程，大大提高业务部署速度。
4. 高可用平台设计
政务云平台承载的省厅、地市局政府部门日常业务以及应对作为应对突发事件的平台，虚拟化和云管理平台作为政务云的核心，在设计部署时除了需要充分考虑整个政务云的高可靠性之外，还需重点关注政务云的灵活性和可扩展性。
可靠性：High Availability
将省厅或者地市局政务云中计算资源组合成为一个具有共享资源池的集群，一旦某台服务器主机或虚拟机发生故障，虚拟化平台会立即响应并在集群内另一台服务器主机上重新启动所有受影响的虚拟机，从而将非计划停机降到最低（如图7所示）。
图7. 高可靠性HA示意图
灵活性：DRS
当省厅、地市局政府各部门业务在政务云上运行后，政务云还需具有自动调整的能力，达到资源的最大化利用，以应对不断变化的用户访问和突发需求情况。动态资源调整是指
提供的动态负载均衡特性引入一个自动化机制，通过持续地平衡容量，将虚拟机迁移到有更多可用资源的主机上，确保每个虚拟机在任何节点都能及时地调用相应的资源（如图8所示）。
图8. DRS示意图
可扩展性：DRX
在遇到突发业务时，需要启动多台虚拟机才能完成对服务的响应。因此政务云应该具备自动化的可扩展性，即在需求突增时自动的复制虚拟机，共同对外提供服务。
在省厅及各地市局内部云计算中心——本地资源扩展。当一台虚拟机无法满足访问需求时，虚拟化平台可以自动复制虚拟机，共同对外提供服务（如图9所示）。
图9. 本地的动态资源扩展
地市局扩展至省厅政务专享云——云间资源扩展。当地市局所能调配的云资源都无法满足访问需求时，就借用省厅政务专享云中的地市临时云资源共同提供服务（如图10所示）。
图10. 云间的动态资源扩展
5. 多租户安全隔离
云计算安全问题一直是部署云计算首要考虑的问题，特别是在大型的政务云中多租户环境下安全问题显得尤为重要。实现多租户安全隔离目前主要有两种方式：
VEPA
利用802.1Qbg（EVB）标准能够很好的解决多租户隔离问题（IEEE802.1Qbg标准是由IEEE802.1工作组制定的一个新标准）。采用支持802.1Qbg VEPA标准的vSwitch与支持802.1Qbg VEPA标准物理交换机，实现了计算资源与网络资源的深度融合，从而实现多租户流量的精确控制，保证多租户环境的安全（如图11所示）。
图11. 基于VEPA的多租户隔离
虚拟设备
将原本需要物理交换机、路由器、防火墙、负载均衡等网络设备完成的工作交由软件的交换机（vSwitch）、路由器（vSR）、防火墙（vFW）、负载均衡（vLB）设备完成。实现精确到每一个用户的全面控制，确保多租户环境下云数据中心安全（如图12所示）。
图12. 基于虚拟设备的多租户隔离
6. 业务迁移规划
针对政务应用目前的部署现状，对省厅及地市局现有业务可采用逐步迁移、逐步扩展的思路，初期可构建最小的资源池，将现有数据中心内的政务业务按照业务类型、重要程度的不同，逐步向资源池内迁移，同时迁移后将空闲出来的服务器加入到资源池内，实现设备的利旧及资源池的扩展。如图13所示，具体可分以下4个步骤进行。
图13. 业务迁移步骤
第一步，建设完善的核心网络支撑平台。保证后续应用迁移及业务扩展时网络能够平滑支持，而且不会中断之前已迁移到云平台和未迁移到云平台中的业务应用。
第二步，搭建云计算基础资源池及管理平台。保证云计算IaaS平台的最小工作环境，构建计算、存储资源池。同时充分考虑对现有IT设备（服务器、存储等）的兼容性，便于后续进行资源池整合。
第三步，业务的P2V迁移。初期可以对非关键应用进行迁移，保证迁移过程中不影响其它应用。
第四步，资源池的整合与扩展。将已迁移到云平台中的业务应用之前所归属的物理服务器、存储资源逐步整合到云计算资源池中，实现对现有设备的利旧，最大化的保证投资，同时进一步扩大云计算资源池。
电子政务云的建设规划
发表于2013-10-21 15:36
摘要：政务云结合了云计算技术的特点，对政府管理和服务职能进行优化、整合，并通过信息化手段在政务云上实现各种业务流程办理和职能服务，为政府各级部门提供可靠的基础IT 服务平台，实现资源的共享、弹性与快速交付。政务云同时能加强对政府业务运作的有效监督，提高政府工作效率，并为社会公众提供服务...
从当前全国的云计算建设的情况来看，虽然各地的项目建设如火如荼，但普遍存在以下几个方面的共性问题：
人云亦云。以云计算立项，但实际上是数据集中的建设，将基于数据集中的项目均称之为“云计算”，概念的包装远偏离云计算技术与服务模型本身。
虚拟化即云。仅利用服务器虚拟化软件（如VMware ESX等），对现有机房的服务器及新增服务器进行虚拟化整合，将现有的业务应用由物理机部署迁移至虚拟机部署。但并没有实现云计算的“自助申请、自动化编排、快速交付”的核心价值，不是真正意义的“云计算”。
缺乏云业务。已部署了服务器、存储、网络、虚拟化软件、云平台软件搭建了真正的云平台，但此平台上并没有运行关键的业务应用，各委办局也不愿意并自己的业务应用迁移到云平台上，“云”的效应并没有真正发挥出来。
建设分散。同一个省份、同一个体系内有多个云计算项目建设，大小不一，标准与架构也都不同，云计算中心资源及运维缺乏纵向统一管理，更谈不上资源互通共享。无法利用这些众多的资源来解决突
发冲击和备份的问题，达不到云计算真正按需分配、弹性扩展的目的。
目前各级政府的职能部门的业务系统应用众多，应用软件的系统架构、开发语言平台、中间件及数据库存在较大的差别。想解决上述问题，可以按以下两步的策略实施政务云建设。
第一步 以IaaS（Infrastructure as a Service，基础设施即服务）的模式为主，实现计算、网络、存储资源的“云化”，这样可以保证不改变上层业务系统应用的架构与部署，做到平台的通用型以及与上层应用的无关性，能够让更多委办局的业务应用迁移到云平台，让云平台真正用起来。
第二步 在IaaS的基础上，构建PaaS（Platform as a Service，平台即服务）模式服务，提供统一的软件系统架构及开发平台，实现中间件、数据库的标准统一，逐步将上层应用转变成接口统一、数据标准的架构。让各政府职能部门数据横向互通与接口变的更简单，真正让云计算为政务业务服务。
下文将从电子政务云的基本架构、建设难点以及针对难点的解决方案几方面进行分析阐述。
一、 电子政务云基本架构
从目前的政务云整体建设来看，省级、地市级都有自己的建设规划，而且除了由各省政务信息中心承建的政务云平台之外，其他政府职能机关也都有自己内部的业务云建设规划，基本模式如图1所示。
图1. 政务云建设模式
从建设现状来看，省政务云、地市政务云、业务云之间都是相互割裂的，彼此之间资源无法共享和借用，数据调用也非常困难。但从实际需求的角度出发，未来的政务云建设必须满足以下5个要求：
分级管理。实现政务云的分层分级管理，省政务云平台中可以看到下级各地市的公共资源及业务运行状态，地市云平台中也能够在授权的情况下看到上级云平台中与本地市相关的公共资源及业务运行状态。
向上备份。地市政务云、各委办局业务云数据及业务能够向省政务云备份，降低地市、各委办局的业务备份成本。
快速扩展。当地市政务云、各委办局业务云资源遇到突发情况（如公务员报考查询、台风信息发布等）本地云资源不够时，可以快速的将地市业务应用迁移到省政务云平台中，实现资源的快速扩展与负载均衡。
快速部署。省政务云平台中可以根据政务业务的特性，针对常用
的、通用的业务应用（如Web门户、Mail等），制定相应的应用模板下发到地市政务云平台中，各地市可以用此模板快速在本地部署相应的业务，实现业务快速交付的同时，也能够实现全省内的应用统一，便于运维与数据互通。
平台互通。统一政务业务应用的开发架构与数据服务，便于政务云平台与各业务云之间的数据调用，实现政务数据的跨平台互通。
按照云计算的技术架构，结合政务云当前的建设现状及目标，政务云的IaaS、PaaS平台的系统架构分为硬件层、IaaS、PaaS和业务层（如图2所示）。
图2. 政务云平台系统框架
硬件层：构建服务器、网络、存储资源池，考虑到多租户及不同
安全级别的业务隔离，各资源池可能是物理或逻辑上的多个构建。
IaaS层：IaaS层主要包括虚拟化层及云服务层。通过虚拟化技术，实现资源与物理设备的解耦合，满足业务系统快速部署与迁移。通过云服务层实现资源的自助申请，各租户的组织管理与业务流审批，以及对租户申请的资源进行自动化编排与交付。
PaaS层：PaaS层需要实现统一的认证授权，统一的数据服务与跨平台的开发及运行环境，保证未来业务应用后台数据统一、架构统一，为跨平台部署及政务数据共享提供基础。
业务层：为保证对现有政务业务应用系统的良好兼容，能够让更多的委办局将业务迁移到政务云平台中，需要提供兼容非云环境下的虚拟机，不改变现有的软件部署环境，将业务迁移部署到虚拟机(VM)上。
二、电子政务云建设难点分析
政务私有云标准的确立
目前市面上云计算厂商及产品众多，但由于相关标准缺乏，各厂商产品所实现的功能、后台数据格式、对应用的支撑架构千差万别。这也导致在进行政务云建设时，虽然都叫政务云，但每朵云最终实现的效果、支撑的业务、流程管理均不一样，除了网络可以互通过外，数据很难互通，更不用提云间的资源共享了。
单靠政府的力量来推动整个云计算产业链的标准化需要很长一段时间的过程。但是针对政务云，它是云计算技术在政务应用下的特殊子集，是政府的私有云应用，政府是有能力推动政务云的建设标准
的，通过对云计算厂商提出明确的要求，将平台架构标准化、组织管理标准化、业务流程标准化、数据服务标准化、功能实现标准化，以此统一各省、地市政务云建设标准，真正实现资源共享与互通，改善重复、效率低下、各自为政的政务云建设。
政务应用的云化
当前的政务应用从硬件部署环境来看，有部署在x86物理服务器或小型机上的，也有部署在虚拟化平台的虚拟机（VM）上，同样是部署在虚拟机上的应用，由于各地的虚拟化平台供应厂商不一样，VMware ESX平台、Citrix Xen平台、Microsoft Hyper-V平台、开源KVM平台以及其他国产的虚拟化平台等都会存在。
从政务应用软件的开发模型来看，有基于.Net架构开发的、有基于Java开发的、有基于LAMP架构（Linux+Apache+MySQL+PHP）、也有基于Hadoop分式式架构开发等等。
受限于应用的硬件部署环境和软件开发模型，并不是所有政务应用都适合采用云计算模式进行部署。要将现有的政务应用部署到云平台上，需要对政务应用、服务交付模式进行综合评估，即所谓的“云化”评估。现阶段政务应用的云化，可考虑采用“小步快走”的策略，先对简单易部署的业务系统进行云化：
优先考虑部署在x86单机应用系统和已经部署在虚拟机上的业务系统，借助现有P2V和V2V工具直接进行云化。
考虑到系统业务数据规模，优先考虑无数据库服务器或者SQL Server为后端数据库的业务系统。
为了简化首次部署，对于全国联网应用，暂不考虑云化。 政务应用的迁移
从各地已上线的政务云项目来看，虽然云基础平台已经搭建起来，但云平台上支撑运行业务应用数量非常少，基本都是非关键业务应用：重要性和实时性要求都不高。关键业务并没有迁移到云平台上，每年的扩展、升级依然维持传统模式不变；另外承建单位之外的其他委办局单位，也不愿意将其业务应用迁移到政务云平台中。原因主要有两个方面：
对政务云平台的可靠性、稳定性信心不足。云计算是近几年来新兴的技术与服务模式，产品的可靠性与稳定性需要用时间和具体的项目实践来考验。针对这个顾虑可以在政务云项目建设时应采用“试点+分步迁移”的方式部署，先在一个项目中进行试点部署，从非关键的业务开始，逐步迁移到云平台中。
对政务云安全的担心。政务云对云安全的担心主要体现在多租户的隔离上，要让各委办局将自己的业务迁移到公共政务云平台上，如何保证各委办局之间的隔离是需要考虑的。对于多租户的隔离，可以采用目前比较成熟的物理设备虚拟化及物理设备软件化等技术，在政务公共云平台中，为各委办局分配虚拟设备（如虚拟防火墙、虚拟路由器、虚拟交换机等），各委办局利用虚拟设备在公共云平台上构建属于自己的虚拟私有数据中心（VPDC），实现与传统私有数据中心同样的基础设施架构。
二级云存在的现实性。政务云建设的理想目标是实现资源的集
中与整合，降低政务信息化的总体拥有成本（TCO）。但现阶段要实现省级政务云“一云统天下”是不现实的，有如下诸多实际的问题需要考虑：
业务应用的特殊性。各委办局均有不少关键的业务应用是直接由国家部委纵向统一下发，此类应用暂不会迁移到政务共享云。
数据的二级集中。目前各委办局的业务数据很多是基于“省—地市”两级集中的，地市有自己的业务数据，省级统一集中具有很大难度，需要在各地市进行业务部署。
应用系统的运维。从实际的项目建设来看，省级中心所能承接的运维通常仅局限在基础设施层面，要实现对各委办局、各地市业务应用系统层的运维缺少相应保障。
综上所述，现阶段的政务云建设短期内要实现省级政务云“一云统天下”是很困难的，必需允许各地市、各委办局有自身的“二级云”的存在，同时受限于对云平台的稳定、可靠、安全的担心，省级政务云平台初期的建设应重点关注标准、流程、架构的制定，考虑“分步建设、逐步迁移”的模式。
三、电子政务云解决方案
结合上述对电子政务云现状、架构及难点的分析，下文以具体某个省政务云平台为例，介绍H3C电子政务云解决方案（如图3所示）。
1. 政务云框架
图3. 某省政务云框架
省政务专享云
利用公有云平台（以下以阿里云为例说明）构建省级政务专享云平台，与目前的阿里公有云隔离，此专享云专为某省政务云服务，部署省级数据集中的业务应用，同时为下属各地市二级云提供突发时的资源借用及数据备份；制定标准化的Web门户、Email业务应用模板，下发至地市二级云平台，快速生成标准化的应用并部署；通过阿里云的PaaS平台，提供统一的政务应用数据服务、软件开发平台，为后续实现应用的统一提供基础。
市政务云&委办局业务云
采用H3Cloud云计算解决方案构建各地市及委办局业务云，利用“云彩虹技术”实现地市云业务虚拟机向省政务专享云的备份与恢得，同时地市云资源突发不够时将业务虚拟机Burst[p1] 到省政务专享云运行，实现资源突发时快速扩展。
2. 分层分级组织资源管理
由于地市、各委办局二级云当前存在的必然性，以及政府职能部门的纵向性，对于政务云的建设，分层分级的组织资源管理是对云平台的基本要求（如图4所示）。
图4. 政务云分层分级组织资源管理
某省政务云的建设分为省级和地市级两层：
省政务专享云
省政务专享云内需要管理的资源分为本地资源与远程资源两大类：其中本地资源又分为各委办局使用的资源和地市临时云资源两种，地市临时云资源是指当地市云中心遇到突发资源不够时，借用的省专享云资源，本地资源的虚拟机都是运行在省政务专享云的物理服务器上；远程资源是由省厅下发的统一模板或部署在地市政务云中的
纵向性业务应用，此类资源的虚拟机运行在地市政务云的物理服务器上，但其应用系统的控制与管理都是由省厅统一进行的。
地市政务云
地市政务云内需要管理的资源也分为本地资源与远程资源两大类：其中本地资源公为地市各委办局使用的资源与省厅下发的业务源资源两种。远程资源是地市借用的省厅政务专享云资源，此类资源的虚拟机运行在省厅政务专享云的物理服务器上，但其应用系统的控制与管理由地市政务云管理员来负责。
3. 资源的申请与审批流程设计
省政务专享云的资源管理与使用面向以下三类人员：
系统管理员：省厅政务专享云的系统管理员，管理整个专享云内的所有资源，为各个组织管理员分配资源及操作权限。
组织管理员：各委办厅局对应的IT管理员，负责管理本组织（某一个委办厅局）内的云资源管理与分配，以及对云服务最终用户申请的审批。
云服务用户：各委办局厅业务部门主管，云资源的使用方，负责根据业务的需求提出资源使用申请需求。
具体的云服务申请与审批流程如图5所示：
图5. 省政务专享云资源的申请与审批
第一步，首先由系统管理员给各组织管理分配云资源，包括虚拟机数量、存储空间、操作权限等。
第二步，当用户需要上一套应用系统时，由用户在自助门户上申请相应的资源，提交工单电子流给组织管理员。
第三步，组织管理员负责对用户的申请进行合理性审批，审批通过后云管理平台会自动对其需要的资源进行编排，交付给用户使用。
地市政务云资源正常的申请与审批流程与省政务专享云类似，不同场景主要体现在资源不足和应用的纵向下发（如图6所示）。
图6. 地市政务云资源的申请与审批
地市局云资源不足。当地市局由于某种突发需求（如公务员报考、特殊气象查询等），本地资源无法满足访问需求时，地市局政务云管理员可以主动向省厅政务专享云申请计算资源，将一部分业务交由省厅政务专享云资源处理，以满足突发需求。
省厅应用纵向下发。由于政府职能部门纵向管理架构，为了避免一项业务需要在全体系内发布时，省厅部署快、地市局部署慢，业务无法同时上线的问题，省厅管理员可以直接将配置好的业务虚拟机模板下发至各地市局政务云，政务云管理员进行简单配置即可上线。简化部署过程，大大提高业务部署速度。
4. 高可用平台设计
政务云平台承载的省厅、地市局政府部门日常业务以及应对作为应对突发事件的平台，虚拟化和云管理平台作为政务云的核心，在设计部署时除了需要充分考虑整个政务云的高可靠性之外，还需重点关注政务云的灵活性和可扩展性。
可靠性：High Availability
将省厅或者地市局政务云中计算资源组合成为一个具有共享资源池的集群，一旦某台服务器主机或虚拟机发生故障，虚拟化平台会立即响应并在集群内另一台服务器主机上重新启动所有受影响的虚拟机，从而将非计划停机降到最低（如图7所示）。
图7. 高可靠性HA示意图
灵活性：DRS
当省厅、地市局政府各部门业务在政务云上运行后，政务云还需具有自动调整的能力，达到资源的最大化利用，以应对不断变化的用户访问和突发需求情况。动态资源调整是指
提供的动态负载均衡特性引入一个自动化机制，通过持续地平衡容量，将虚拟机迁移到有更多可用资源的主机上，确保每个虚拟机在任何节点都能及时地调用相应的资源（如图8所示）。
图8. DRS示意图
可扩展性：DRX
在遇到突发业务时，需要启动多台虚拟机才能完成对服务的响应。因此政务云应该具备自动化的可扩展性，即在需求突增时自动的复制虚拟机，共同对外提供服务。
在省厅及各地市局内部云计算中心——本地资源扩展。当一台虚拟机无法满足访问需求时，虚拟化平台可以自动复制虚拟机，共同对外提供服务（如图9所示）。
图9. 本地的动态资源扩展
地市局扩展至省厅政务专享云——云间资源扩展。当地市局所能调配的云资源都无法满足访问需求时，就借用省厅政务专享云中的地市临时云资源共同提供服务（如图10所示）。
图10. 云间的动态资源扩展
5. 多租户安全隔离
云计算安全问题一直是部署云计算首要考虑的问题，特别是在大型的政务云中多租户环境下安全问题显得尤为重要。实现多租户安全隔离目前主要有两种方式：
VEPA
利用802.1Qbg（EVB）标准能够很好的解决多租户隔离问题（IEEE802.1Qbg标准是由IEEE802.1工作组制定的一个新标准）。采用支持802.1Qbg VEPA标准的vSwitch与支持802.1Qbg VEPA标准物理交换机，实现了计算资源与网络资源的深度融合，从而实现多租户流量的精确控制，保证多租户环境的安全（如图11所示）。
图11. 基于VEPA的多租户隔离
虚拟设备
将原本需要物理交换机、路由器、防火墙、负载均衡等网络设备完成的工作交由软件的交换机（vSwitch）、路由器（vSR）、防火墙（vFW）、负载均衡（vLB）设备完成。实现精确到每一个用户的全面控制，确保多租户环境下云数据中心安全（如图12所示）。
图12. 基于虚拟设备的多租户隔离
6. 业务迁移规划
针对政务应用目前的部署现状，对省厅及地市局现有业务可采用逐步迁移、逐步扩展的思路，初期可构建最小的资源池，将现有数据中心内的政务业务按照业务类型、重要程度的不同，逐步向资源池内迁移，同时迁移后将空闲出来的服务器加入到资源池内，实现设备的利旧及资源池的扩展。如图13所示，具体可分以下4个步骤进行。
图13. 业务迁移步骤
第一步，建设完善的核心网络支撑平台。保证后续应用迁移及业务扩展时网络能够平滑支持，而且不会中断之前已迁移到云平台和未迁移到云平台中的业务应用。
第二步，搭建云计算基础资源池及管理平台。保证云计算IaaS平台的最小工作环境，构建计算、存储资源池。同时充分考虑对现有IT设备（服务器、存储等）的兼容性，便于后续进行资源池整合。
第三步，业务的P2V迁移。初期可以对非关键应用进行迁移，保证迁移过程中不影响其它应用。
第四步，资源池的整合与扩展。将已迁移到云平台中的业务应用之前所归属的物理服务器、存储资源逐步整合到云计算资源池中，实现对现有设备的利旧，最大化的保证投资，同时进一步扩大云计算资源池。