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

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

《集团云数据中心管理平台规划设计.docx》由会员分享，可在线阅读，更多相关《集团云数据中心管理平台规划设计.docx（18页珍藏版）》请在冰豆网上搜索。

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

集团云数据中心管理平台

详细规划设计

1前言

1.1背景

集团信息中心中心引入日趋成熟的云计算技术，建设面向全院及国网相关单位提供云计算服务的电力科研云，支撑全院各个单位的资源供给、数据共享、技术创新等需求。

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

1.2文档目的

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

1.3适用范围

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

1.4参考文档

《集团云计算咨询项目访谈纪要》

《信息安全技术信息系统安全等级保护基本要求》（GB/T22239-2008）

《信息系统灾难恢复规范》（GB/T20988-2007）

《OpenStackAdministratorGuide》（http:

//docs.openstack.org/）

《OpenStackHighAvailabilityGuide》（http:

//docs.openstack.org/）

《OpenStackOperationsGuide》（http:

//docs.openstack.org/）

《OpenStackArchitectureDesignGuide》（http:

//docs.openstack.org/）

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整个体系由众多组件构成，其中主要的组件及其功能见下表：

表2OpenStack主要组件列表

组件名

组件功能简介

Nova

计算服务

Swift

对象存储服务

Glance

镜像服务

Keystone

认证服务

Horizon

UI服务

Neutron

网络服务

Cinder

块存储服务

Ceilometer

监控服务

Heat

集群服务

Trove

数据库服务

Sahara

大数据服务

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

1）Nova组件

Nova是OpenStack计算的弹性控制器。

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

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

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

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

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

2）Neutron组件

Neutron是OpenStack的网络模块，它是系统平台的位置，提供配置命令及参数检查，并把网络功能用一种逻辑组织起来；但是无论底层的plugin最终是用软件SDN还是硬件交换机来加速，Neutron自身并不提供任何网络功能，它只是一个架子。

Neutron的网络功能大部分是Plugin提供的，除了DHCP和L3-agent等的某些部分功能。

3）Keystone组件

　Keystone为所有的OpenStack组件提供认证和访问策略服务，它依赖自身REST（基于IdentityAPI）系统进行工作，主要对（但不限于）Swift、Glance、Nova等进行认证与授权。

目前Keystone还有一些功能欠缺，如没法基于角色的授权，web管理用户等。

另外社区版本实现keystone的高可用还是比较困难。

同时大规模部署，这也会是瓶颈

4）Glance组件

Glance是一套虚拟机镜像发现、注册、检索组件。

通过镜像管理，可以将镜像存储到以下任意一种存储中：

本地存储，NFS，swift，sheepdog和Ceph等

Glance目前功能已经比较完备，更多的是在支持更多类型的存储方式以及Bug修复上。

5）Cinder组件

Cinder的功能是实现存储服务，根据实际需要快速为虚拟机提供设备创建、挂载、回收以及快照备份控制等。

Cinder包括API、调度Scheduler和存储适配cinder-volume3个服务，其中cinder-volume可以部署到多个节点上。

cinder-scheduler和nova-scheduler类似，根据服务寻找合适的服务器cinder-volume，发送消息到cinder-volume节点，由cinder-volume提供弹性云存储服务。

6）Swift组件

Swift为OpenStack提供一种分布式、持续虚拟对象存储，它类似于AmazonWebService的S3简单存储服务。

Swift具有跨节点百级对象的存储能力。

Swift内建冗余和失效备援管理，也能够处理归档和媒体流，特别是对大数据（千兆字节）和大容量（多对象数量）的测度非常高效。

7）Horizon组件

Horizon是一个用以管理、控制OpenStack服务的Web控制面板，它可以管理实例、镜像、创建密匙对，对实例添加卷、操作Swift容器等。

严格意义来说，Horizon不会为Openstack增加一个功能，他更多的是一个演示Demo。

不过对于很多用户来说，了解Openstack基本都是从Horizon，dashboard开始。

Horizon只是使用了Openstack部分API功能，很多功能需要用户自行开发。

部署架构

节点划分

OpenStack的具体部署一般都遵从“四种节点”的原则

1.OpenStackControllernode：

控制节点是整个Openstack控制枢纽，可以将各种API服务和内部工作组件如Database、Messagequeue、DNS、NTP、Keystone等服务集成到一起，Openstack实现了松耦合的架构思想，因此所有的组件都可以在任意Node中安装组合，视乎实际情况而定。

包含组件如下：

⏹Keystone相关组件

⏹Glance的两个进程组件

⏹Nova-api，Nova-conducter，Nova-Scheduler

⏹NeutronServer

⏹数据库服务（MySQL）

⏹消息服务（RabbitMQ或QPid）

2.OpenStackComputenode：

从nova-scheduler的角度看，Computenode是最小的调度（schedule）单元，从nova-compute的角度看，其自是计算资源的拥有者。

每一个Computenode对应一个KVM虚拟机及其相关的ML2Pluginagent。

OpenStackComputenode包含组件如下：

⏹Nova-Compute

⏹NeutronML2Pluginagent

⏹KVM虚拟化系统

3.NeutronControllernode

NeutronControllernode是整个OpenStack系统中的网络控制节点，实现全网内部网络和外部网络的划分已经2-7层虚拟化网络模型的构建。

NeutronControllernode包含组件如下：

⏹NeutronL3Agent

⏹L2Agent

⏹LBaas

⏹VPNaas

⏹FWaas

⏹MetadataAgent

4.StorageControllerNode

存储节点，包含组件如下:

⏹Cinder-Vloume

⏹Swift相关组件

⏹OpenStack平台高可用架构

高可用部署

构建高可用性的OpenStack（High-availabilityOpenStack），也就是建立冗余备份，常用策略有：

⏹集群工作模式。

多机互备，这样模式是把每个实例备份多份，没有中心节点，比如分布式对象存储系统Swift、nova-network多主机模式。

⏹自主模式。

有时候，解决单点故障（SPoF）可以简单的使用每个节点自主工作，通过去主从关系来减少主控节点失效带来的问题，比如nova-api只负责自己所在节点。

⏹主备模式。

常见的模式active-passive，被动节点处于监听和备份模式，故障时及时切换，比如mysql高可用集群、glance、keystone使用Pacemaker和Heartbeat等来实现。

⏹双主模式。

这种模式互备互援，RabbitMQ就是active-active集群高可用性，集群中的节点可进行队列的复制。

从架构上来说，这样就不用担心passive节点不能启动或者延迟太大了。

开源OpenStackHA的部署原则如下：

⏹能A/A尽量A/A，不能的话则A/P；

⏹有原生（内在实现的）HA方案尽量选用原生方案，没有的话则使用额外的HA软件比如Pacemaker等；

⏹需要考虑负载均衡；

⏹方案尽可能简单，不要太复杂；

OpenStack.org认为，在满足其HA要求的情况下，可以实现IaaS的99.99%HA，但是，这不包括单个客户机的HA。

具体各节点HA设计如下：

1.OpenStackControllernodeHA设计

（1）Active/PassiveHA方案

可以使用Pacemaker+Corosync搭建两节点集群实现A/PHA方案。

由主服务器实际提供服务，在其故障时由Pacemaker将服务切换到被服务器。

OpenStack给其组件提供了各种PacemakerRA。

对Mysql和RabbitMQ来说，可以使用Pacemaker+Corosync+DRBD实现A/PHA。

具体配置可参考 《OpenStackHighAvailabilityGuide》。

 该HA方案的问题是：

⏹主备切换需要较长的时间

⏹只有主提供服务，在使用两个节点的情况下不能做负载均衡

⏹DRBD脑裂会导致数据丢失的风险。

A/P模式的Mysql的可靠性没有MysqlGalera高。

因此，在已经看到实际部署中，这种方案用得较少，业界只看到Oracle公司的OpenStack平台在使用这种方案。

（2）Active/ActiveHA方案

该方案至少需要三台服务器，它由三台机器搭建成一个PacemakerA/A集群，在该集群的每个节点上运行：

⏹API服务：

包括nova-api,neutron-server，glance-registry,nova-novncproxy，keystone，httpd等。

由HAProxy提供负载均衡，将请求按照一定的算法转到某个节点上的API服务。

由 Pacemaker提供VIP。

⏹内部组件：

包括nova-scheduler，nova-conductor，nova-cert等。

它们都是无状态的，因此可以在多个节点上部署，它们会使用HA的MQ和DB。

⏹RabbitMQ：

跨三个节点部署RabbitMQ集群和镜像消息队列。

可以使用HAProxy提供负载均衡，或者将RabbitMQhostlist配置给OpenStack组件。

⏹HAProxy：

向API，RabbitMQ和MySQL多活服务提供负载均衡，其自身由Pacemaker实现A/PHA，提供VIP，某一时刻只由一个HAProxy提供服务。

在部署中，也可以部署单独的HAProxy集群。

⏹Memcached：

它原生支持A/A，只需要在OpenStack中配置它所有节点的名称即可

2.NeutronControllerNodeHA设计

Neutron包括很多的组件，比如L3Agent，L2Agent，LBaas，VPNaas，FWaas，MetadataAgent等Neutron组件，其中部分组件提供了原生的HA支持。

这些组件之间的联系和区别