集团云数据中心管理平台-规划设计

集团云数据中心管理平台详细规划设计目录1前言 (2)1.1背景 (2)1.2文档目的 (2)1.3适用范围 (2)1.4参考文档 (2)2设计综述 (3)2.1设计原则 (3)2.2设计思路 (5)2.3建设目标 (7)3集团云计算规划 (8)3.1整体架构规划 (8)3.2云管理平台规划 (8)3.2.1云平台 (9)1前言1.1背景集团信息中心中心引入日趋成熟的云计算技术，建设面向全院及国网相关单位提供云计算服务的电力科研云，支撑全院各个单位的资源供给、数据共享、技术创新等需求。

实现云计算中心资源的统一管理及云计算服务统一提供；完成云计算中心的模块化设计，逐渐完善云运营、云管理、云运维及云安全等模块的标准化、流程化、可视化的建设；是本次咨询规划的主要考虑。

1.2文档目的本文档为集团云计算咨询项目的咨询设计方案，将作为集团信息中心云计算建设的指导性文件和依据。

1.3适用范围本文档资料主要面向负责集团信息中心云计算建设的负责人、项目经理、设计人员、维护人员、工程师等，以便通过参考本文档资料指导集团云计算数据中心的具体建设。

1.4参考文档《集团云计算咨询项目访谈纪要》《信息安全技术信息系统安全等级保护基本要求》（GB/T 22239-2008）《信息系统灾难恢复规范》（GB/T20988-2007）《OpenStack Administrator Guide》（/）《OpenStack High Availability Guide》（/）《OpenStack Operations Guide》（/）《OpenStack Architecture Design Guide》（/）2设计综述2.1设计原则结合集团当前的实际现状及未来三年业务发展需求，此次云计算规划的考虑原则如下：1、关注IT能力的快速提升IT能力包括业务服务能力和运维能力上。

业务服务能力上，从技术层面来说，包括物理硬件资源、云计算资源抽象层、统一的应用平台以及应用软件。

运维能力则包括了人员、流程、工具等各个方面。

图1IT能力组成示意对于云计算技术的选择以及运维工具的选择上，在技术对比之外，更应关注于选择本身是否能给集团带来业务服务能力以及运维能力的快速提升上，并以此作为评判的基本原则。

2、采用开放的架构开放本身有两个含义：源代码开放和标准开放。

源代码开放，允许集团可以拥有完全的掌控，可以修改或则增加新的功能满足集团自身的需要；标准开放意味着集团可以通过各种符合标准的产品构成自己的云计算方案图2开放架构的两方面含义对于集团而言，标准开放比源代码开放更重要。

源代码开放虽然能够让集团拥有完全的掌控，但由于人力的持续投入，以及业务重心的考虑，所谓的“完全的掌控”并不一定能够获得；而标准开放可以避免受单个实体控制（使单个实体受益），这是集团更应关注的。

3、关注资源的弹性资源的弹性来自于集团的业务需求，也是重要的设计原则。

资源的弹性体现在各个层面。

硬件层面更多的表现为资源可以线性扩展，可以快速部署；IAAS平台层面则需要能够支撑管控规模的线性扩展；云资源层面则真正实现资源的弹性，可以随着业务量的增多而弹性增加，也可以随着业务量的萎缩而弹性收缩；应用层面的弹性则更多的体现在灵活的部署上。

4、其他通用原则除去上述集团应该特别关注的原则外，整个规划设计还需要考虑下述通用原则：图3其他通用原则汇总⏹高可用性：结构的高可用性，资源的冗余部署，逻辑关系的松耦合设计，不会因为任何一个模块发生故障而影响业务的开展。

具体来说，包括物理网络、云计算资源、云计算平台、业务应用自身等各个层面的高可用。

⏹安全性：安全区域合理规划，安全策略精细化部署，安全策略进行统一的管理，能够满足未来业务发展对安全的需求。

⏹灵活性：满足业务与应用系统灵活多变的资源分配及部署需求。

⏹可管理性：结构简单、健壮，易于管理和维护，满足监管要求及日常运维的需求，并提供及时发现和排除故障的能力。

⏹性能：采用的技术应带来性能的提升，至少本身不会带来性能的大幅下降。

2.2设计思路集团云计算的服务对象包括业务及科研体系、运维体系、管理层，未来则可能面向集团，甚至其他企业提供服务。

每个服务对象对云计算的关注和诉求均存在不同。

具体分析各个对象的需求，可以发现：⏹自有业务体系：能够方便、快速的获得所需IT资源，不愿介入IT本身的管理维护，业务系统不中断；⏹其他业务体系：对云内隔离的疑虑，对云内安全的需求，对可靠性保证的担忧；⏹管理层：关注投资收益比，能方便的获得投资决策数据，包括业务的经营数据，IT的运营数据；⏹运维体系：平台可靠，易于管理，业务快速自愈能力，弹性扩展能力，运维工作量低，完善的安全防护；⏹建设者：建设者和运维体系可以是一个实体，但基于对象考虑它有其独特的需求。

初始能够快速建设，后续能够快速的扩容，建设周期短，人员投入少，建设质量有保证；针对各个对象需求分析总结，云计算的规划思路主要在于标准化模块化、资源池化、资源服务化、云容量的可视化、运维部署自动化、资源高可用、云安全服务、运维场景化这些方面，具体分析见下面的表格。

表1对前面的规划思路进行归纳分类，云计算的规划主要需要考虑下面的六点：⏹物理资源的模块化、标准化；⏹资源池化；⏹统一管理平台（统一平台的资源服务化、云容量的可视化、运维部署自动化）；⏹业务连续性；⏹云安全服务；运维场景化；后面针对每一点分别进行具体分析。

2.3建设目标结合集团IT架构现状和未来业务发展的需求，我们给出的解决建议有采用标准化硬件基础设施建设；建设云计算高可用架构的统一资源池；建设统一的云管理平台；构建统一的PaaS平台；构建运维体系、流程和工具；建设基于等保的安全体系，最终达到IT资源统一云化、科研环境平台化、业务应用服务化、运维管理自动化的云计算建设目标。

3集团云计算规划3.1整体架构规划日前，集团发布信息通信新技术推动智能电网和“一强三优”现代公司创新发展行动计划（以下简称行动计划），推进大数据、云计算、物联网和移动互联等新技术在智能电网和“一强三优”现代公司建设中的创新应用。

集团未来三年云计算整体蓝图，需要构建多中心的“科研云”，全面提升集团未来的业务创新能力，保障业务快速安全交付。

对于其中同城云数据中心内的建设，则可以划分为物理资源层、虚拟化平台层、云服务层，以及贯穿各个层面的运维管理层整个科研云涵盖IaaS、PaaS、SaaS服务，提供完整的云计算服务；同时科院云是符合等保三级和集团合规要求的安全可靠的云；同时建设统一的运营、运维管理体系贯穿整个科研云各个层面；构建集团统一的云服务门户，通过云服务门户统一对内对外提供云服务，支持科研各应用领域：3.2云管理平台规划针对集团此次云计算的建设，从基础网络、云网络、计算、存储、云平台、安全、运维和容灾八个领域对云计算进行规划设计，基于开源的高可用的商用云计算架构，各组件松耦合、模块化、标准化，实现云计算的灵活性，最终实现统一的资源池化、统一资源管理和统一资源交付的目标。

3.2.1 云平台3.2.1.1云平台建设目标云资源管理平台作为云平台的核心内容之一，需要包含前端运营与后端运维两部分服务内容。

集团云平台建设目标：以云服务平台作为企业云业务统一入口，提供集团IT资源服务化的整合引擎，实现资源服务化、运维部署自动化。

集团构建内外网2朵私有云，云与云之间物理隔离，每朵云有4个资源池，由云门户统一提供云计算服务。

3.2.1.2云平台架构规划云资源管理平台作为云平台的核心内容之一，需要包含前端运营与后端运维两部分服务内容。

运营服务需满足异构云平台的统一账号管理、统一业务管理规范、异构云资源的统一调度和管理，在保证平台稳定性、安全性的前提下，最大程度地支持用户自助服务，实现资源的创建申请、释放申请、自动伸缩，以及云主机、云数据库、负载均衡等服务管理内容，其逻辑架构如下图所示：我们建议集团采用OpenStack构建自己的云平台，下面具体分析一下整个OpenStack的架构，并给出云平台规划。

OpenStack分析OpenStack是一个由NASA（美国国家航空航天局）和Rackspace合作研发并发起的，以Apache许可证授权的自由软件和开放源代码项目。

项目目标是提供实施简单、可大规模扩展、丰富、标准统一的云计算管理平台。

OpenStack通过各种互补的服务提供了基础设施即服务（IaaS）的解决方案，每个服务提供API 以进行集成。

OpenStack发展速度非常快，其社区拥有超过130家企业及1350位开发者，除了有Rackspace 和NASA 的大力支持外，还有包括Dell、Citrix、Cisco、Canonical等重量级公司的贡献和支持，这些机构与个人都将OpenStack作为基础设施即服务（IaaS）资源的通用前端。

设计原则在Openstack官方网站上，介绍了整个OpenStack设计的基本原则，翻译过来如下：1)可扩展性和伸缩性是我们的主要目标；2)任何影响到可扩展性和伸缩性的功能都必须是可选的；3)所有的环节必须是异步的，如果不能异步实现，参考第二条设计原理；4)所有的基础组件必须能横向扩展；5)始终使用无共享的架构，如果不能实现，参见第二条；6)所有的都是分布式的，尤其是逻辑。

把逻辑放在状态应该存在的地方从上述原则可以明显的看出，Openstack整个架构设计极其追求可扩展性和伸缩性，这也是Openstack平台可以管理如此众多形态各异、架构各异的各种资源的主要原因。

组件介绍OpenStack整个体系由众多组件构成，其中主要的组件及其功能见下表：表2其中Nova、Swift、Glance、Keystone、Horizon、Neutron、Cinder七个组件为核心组件，这几个组件无论功能完善程度还是稳定性均得到了很好的保证，并经过了大量实践检验，下面具体对这七个核心组件进行介绍。

1)Nova组件Nova是OpenStack计算的弹性控制器。

OpenStack云实例生命期所需的各种动作都将由Nova进行处理和支撑，这就意味着Nova以管理平台的身份登场，负责管理整个云的计算资源、网络、授权及测度。

虽然Nova本身并不提供任何虚拟能力，但是它将使用libvirt API与虚拟机的宿主机进行交互。

Nova通过Web 服务API来对外提供处理接口，而且这些接口与Amazon的Web服务接口是兼容的。

Nova模块在OpenStack的架构中属于最为成熟的模块，商用时需修改的代码量较小，但是需要通过插件的方式兼容适配诸如Vmware Esxi，H3C Cas，Ctrix Xen等不同厂商的计算虚拟化软件。

从而提供原生KVM不具有虚拟机HA，资源弹性调度分配的功能。