集团云数据中心管理平台-规划设计
集团云数据中心管理平台详细规划设计
目录
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》（https://www.360docs.net/doc/772644131.html,/）
《OpenStack High Availability Guide》（https://www.360docs.net/doc/772644131.html,/）
《OpenStack Operations Guide》（https://www.360docs.net/doc/772644131.html,/）
《OpenStack Architecture Design Guide》（https://www.360docs.net/doc/772644131.html,/）
2设计综述
2.1设计原则
结合集团当前的实际现状及未来三年业务发展需求，此次云计算规划的考虑原则如下：
1、关注IT能力的快速提升
IT能力包括业务服务能力和运维能力上。业务服务能力上，从技术层面来说，包括物理硬件资源、云计算资源抽象层、统一的应用平台以及应用软件。运维能力则包括了人员、流程、工具等各个方面。
图1 IT能力组成示意
对于云计算技术的选择以及运维工具的选择上，在技术对比之外，更应关注于选择本身是否能给集团带来业务服务能力以及运维能力的快速提升上，并以此作为评判的基本原则。
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，资源弹性调度分配的功能。
2)Neutron组件
Neutron是OpenStack的网络模块，它是系统平台的位置，提供配置命令及参数检查，并把网络功能用一种逻辑组织起来；但是无论底层的plugin最终是用软件SDN还是硬件交换机来加速，Neutron自身并不提供任何网络功能，它只是一个架子。Neutron的网络功能大部分是Plugin提供的，除了DHCP和L3-agent等的某些部分功能。
3)Keystone组件
Keystone为所有的OpenStack组件提供认证和访问策略服务，它依赖自身REST（基于Identity API）系统进行工作，主要对（但不限于）Swift、Glance、Nova等进行认证与授权。
目前Keystone 还有一些功能欠缺，如没法基于角色的授权，web管理用户等。另外社区版本实现keystone的高可用还是比较困难。同时大规模部署，这也会是瓶颈
4)Glance组件
Glance是一套虚拟机镜像发现、注册、检索组件。通过镜像管理，可以将镜像存储到以下任意一种存储中：本地存储，NFS，swift，sheepdog和Ceph等Glance目前功能已经比较完备，更多的是在支持更多类型的存储方式以及Bug修复上。
5)Cinder组件
Cinder的功能是实现存储服务，根据实际需要快速为虚拟机提供设备创建、挂载、回收以及快照备份控制等。Cinder包括API、调度Scheduler和存储适配cinder-volume 3个服务，其中cinder-volume可以部署到多个节点上。cinder-scheduler和nova-scheduler类似，根据服务寻找合适的服务器cinder-volume，发送消息到cinder-volume节点，由cinder-volume提供弹性云存储服务。
6)Swift组件
Swift为OpenStack提供一种分布式、持续虚拟对象存储，它类似于Amazon Web Service的S3简单存储服务。Swift具有跨节点百级对象的存储能力。Swift 内建冗余和失效备援管理，也能够处理归档和媒体流，特别是对大数据（千兆字节）和大容量（多对象数量）的测度非常高效。
7)Horizon组件
Horizon是一个用以管理、控制OpenStack服务的Web控制面板，它可以管理实例、镜像、创建密匙对，对实例添加卷、操作Swift容器等。严格意义来说，Horizon不会为Openstack 增加一个功能，他更多的是一个演示Demo。不过对于
很多用户来说，了解Openstack基本都是从Horizon，dashboard开始。Horizon只是使用了Openstack部分API功能，很多功能需要用户自行开发。
部署架构
节点划分
OpenStack的具体部署一般都遵从“四种节点”的原则
1.OpenStack Controller node：
控制节点是整个Openstack控制枢纽，可以将各种API服务和内部工作组件如Database、Message queue、DNS、NTP、Keystone等服务集成到一起，Openstack 实现了松耦合的架构思想，因此所有的组件都可以在任意Node中安装组合，视乎实际情况而定。包含组件如下：
?Keystone相关组件
?Glance的两个进程组件
?Nova-api，Nova-conducter，Nova-Scheduler
?Neutron Server
?数据库服务(MySQL)
?消息服务(RabbitMQ或QPid)
2.OpenStack Compute node：
从nova-scheduler的角度看，Compute node是最小的调度(schedule)单元，从nova-compute的角度看，其自是计算资源的拥有者。每一个Compute node 对应一个KVM虚拟机及其相关的ML2 Plugin agent。OpenStack Compute node包含组件如下：
?Nova-Compute
?Neutron ML2 Plugin agent
?KVM虚拟化系统
3.Neutron Controller node
Neutron Controller node是整个OpenStack系统中的网络控制节点，实现全网内部网络和外部网络的划分已经2-7层虚拟化网络模型的构建。Neutron Controller node包含组件如下：
?Neutron L3 Agent
?L2 Agent
?LBaas
?VPNaas
?FWaas
?Metadata Agent
4.Storage Controller Node
存储节点，包含组件如下:
?Cinder-Vloume
?Swift相关组件
?OpenStack平台高可用架构
高可用部署
构建高可用性的OpenStack（High-availability OpenStack），也就是建立冗余备份，常用策略有：
?集群工作模式。多机互备，这样模式是把每个实例备份多份，没有中心节点，比如分布式对象存储系统Swift、nova-network多主机模式。
?自主模式。有时候，解决单点故障（SPoF）可以简单的使用每个节点自主工作，通过去主从关系来减少主控节点失效带来的问题，比如nova-api
只负责自己所在节点。
?主备模式。常见的模式active-passive，被动节点处于监听和备份模式，故障时及时切换，比如mysql高可用集群、glance、keystone使用Pacemaker
和Heartbeat等来实现。
?双主模式。这种模式互备互援，RabbitMQ就是active-active集群高可用性，集群中的节点可进行队列的复制。从架构上来说，这样就不用担心
passive节点不能启动或者延迟太大了。
开源OpenStack HA的部署原则如下：
?能A/A 尽量A/A，不能的话则A/P ；
?有原生（内在实现的）HA方案尽量选用原生方案，没有的话则使用额外的HA 软件比如Pacemaker 等；
?需要考虑负载均衡；
?方案尽可能简单，不要太复杂；
https://www.360docs.net/doc/772644131.html,认为，在满足其HA 要求的情况下，可以实现IaaS 的99.99% HA，但是，这不包括单个客户机的HA。具体各节点HA设计如下：
1.OpenStack Controller node HA设计
（1）Active/Passive HA方案
可以使用Pacemaker + Corosync 搭建两节点集群实现A/P HA 方案。由主服务器实际提供服务，在其故障时由Pacemaker 将服务切换到被服务器。OpenStack 给其组件提供了各种Pacemaker RA。对Mysql 和RabbitMQ 来说，可以使用Pacemaker + Corosync + DRBD 实现A/P HA。具体配置可参考《OpenStack High Availability Guide》。
该HA 方案的问题是：
?主备切换需要较长的时间
?只有主提供服务，在使用两个节点的情况下不能做负载均衡
?DRBD 脑裂会导致数据丢失的风险。A/P 模式的Mysql 的可靠性没有Mysql Galera 高。
因此，在已经看到实际部署中，这种方案用得较少，业界只看到Oracle 公司的OpenStack平台在使用这种方案。
（2）Active/Active HA 方案
该方案至少需要三台服务器，它由三台机器搭建成一个Pacemaker A/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 提供负载均衡，或者将RabbitMQ host list 配置给OpenStack
组件。
?HAProxy：向API，RabbitMQ 和MySQL 多活服务提供负载均衡，其自身由Pacemaker 实现A/P HA，提供VIP，某一时刻只由一个HAProxy
提供服务。在部署中，也可以部署单独的HAProxy 集群。
?Memcached：它原生支持A/A，只需要在OpenStack 中配置它所有节点的名称即可
2.Neutron Controller Node HA设计
Neutron 包括很多的组件，比如L3 Agent，L2 Agent，LBaas，VPNaas，FWaas，Metadata Agent 等Neutron 组件，其中部分组件提供了原生的HA 支持。这些组件之间的联系和区别
（1）L2 Agent HA：
L2 agent 只在所在的网络或者计算节点上提供服务，因此它是不需要HA的。
（2）L3 Agent HA
L3 Agent 比较特殊，因为它是所有openstack （core）services 中唯一一个有状态的，因此，不能使用传统的在多个节点上部署多个实例使用LB来做HA。Neutron 本身的调度器（scheduler）支持在多个网络节点上部署多个L3 Agent，但是，由L3 Agent 管理的Virtual Router自身需要有HA的实现，Juno版本中引入VRRP方案（由VRRP/Keepalived 控制VR 的VIP和VMAC的failover）来支持L3 agent HA
3.OpenStack Cmpute及虚拟机HA设计
在测试环境中，我们常常将虚机创建在本地磁盘上，那么，在机器宕机的话，