四、OpenStack入门 之 各组件解析（进阶）

OpenStack入门 之 各组件解析（进阶）

学习目标：

掌握更多组件的架构和功能

本次笔记的内容有：

Ceilmeter 组件解析

Heat 组件解析

Trove 组件解析

Sahara 组件解析

Ironic 组件解析

1. Ceilometer组件解析

又称为 OpenStack Telemetry（远程测量收集数据），是 OpenStack 里面做 metering 的项目。Ceilometer 的主要目的是 为计费提供数据支持。 OpenStack 本身不提供计费的功能，Ceilometer 会给人在做二次开发的时候实现计费功能带来很大的便利。

[ 计费用和监控用计量数据的区别？]

侧重点 不一样。Seilometer 是计量与计费相关的数据，这些数据作为消息在网络中传输的时候，都是会经过签名的，从信息安全的角度看，签名的最大的用处是具有 不可抵赖性，涉及到计费应用的时候是很重要的。当然，Ceilometer 现在也增加了更多其它的功能，帮助运维人员去实现更多的监控功能，逐渐地减少甚至是省去一些重新开发部署一套监控系统的工作，降低整个系统的复杂性。

[ Ceilometer 的三个要点：]

原始数据的来源

数据的存储

如何提供给第三方系统（比如说。二次开发的计费系统）

[ 原始数据的来源主要有三个途径：]

通过 MQP 消息中间件收集各个组件发出来的消息

通过 Ceilometer 的一些 agent 来调用 OpenStack 各个 component 的 api 获得数据，这里的 component 包括 Swift、Cinder、Neutron，Trove，Sahara，Ironic

如果要有效的采集和 Nova 相关的数据或者说和 OpenStack 的计算服务相关的数据，通过在每个计算节点上运行 Ceilometer 的 polling agent 获得虚拟机的信息

[ 数据的存储：]

Ceilometer 的存储也是依赖第三方后端来实现的，默认的后端数据库是 MongoDB，是一个 key- value 数据库，当然现在也支持其它数据库包括 HBase、MySQL，首选 MangoDB。

[ 第三方系统：]

最主要的使用方式就是第三方系统，通过调用 Ceilometer API 获得计量数据，设置报警条件和预值，监听报警，进一步去实现计费和监控功能，具体使用的时候涉及到 Ceilometer 怎么设置，每项数据通过调用什么 API 获得，怎么设置报警的预值等等

2. Heat 组件解析

又被称为 openStack Orchestration，Heat 是在 OpenStack 里面提供 Orchestration 服务的组件。把一个 IT 系统的各个模块和资源组织、调度起来，形成一套完整的可以实现一些业务功能的有机的系统。

AWS 里面有一个 CloudFormation 的东西，Heat 和这个比较像，按照用户写的模版，或者说脚本，把 OpenStack 里边的各种资源给它实例化并且组织起来，形成一个完整的应用，这些脚本在 Heat 里叫作 Template，Template 生成的东西叫作 Stack。Template 里面会写清楚创建一个 Stack 需要用到哪些资源，然后这些资源的相互关系是怎么样的，这里面的资源包括我们说的虚拟机、卷（云硬盘）、用户、IP 地址等等都是属于这地方所表述的资源。

Heat 的主要任务就是负责这个 Stack 的生命周期：创建、更新和销毁。

[ Template 的组成：]

description 注释

parameters 参数

resources 资源

outputs 输出

部分截图：





[ 更复杂的结构：]

创建一个 Wordpress 网站，创建一个三层架构的网站…

PS：Heat 可以和 Ceilometer 配合使用来实现 auto scaling 也可以兼容 cloudformation 的模版

3. Trove 组件解析

[ Trove 的功能：]

根据用户的请求创建一个包含数据库的虚拟机（VM Instance），根据用户给的参数比如说数据库的类型、用户名密码等等，对数据库进行安装配置。

[ 数据库的建立：]

创建虚拟机后由 Trove 去安装；也可以用户选择事先做好 Trove 的镜像（镜像里已经装好数据库了）。后者的效率会更高一些。

[ Trove 支持的数据库有：]

关系型数据库 MySQL

NoSQL 型数据库 MongoDB、Cassandra

[ 四个组件：]

Trove API 提供 RESTful API，无状态的，可以横向扩展，可以做负载均衡，可以接比较多的用户请求。

Trove Taskmanager 完成具体管理命令的执行，比如：创建实例、销毁实例、管理实例的生命周期、操作数据库等等。主要的工作方式就是去监听这个 RabbitMQ 中间件，发 MQP 这样一些调用的请求，然后去实现这些请求。

Trove-conductor 负责和数据库交互，与 Nova Conductor 比较类似，运行在 host 上。

Guest agent 运行在要去运行数据库服务的虚拟机里面，每一类数据库都有自己对应的 agent，让 Trove 对一个更多的数据库就要自己写对应的数据库的 agent，也是 OpenStack 常用的一种方式了。

[ Trove 面临的挑战：]

不支持自动配置数据库的 HA

4. Sahara 组件解析

[ Sahara 的功能：]

在 OpenStack 上快速创建 Hadoop 集群，利用 Iaas 上空闲的计算能力做大数据的离线处理（设计 Sahara 的初衷）

[ Sahara的架构如图所示：]



注意图中的几个地方，Sahara Dashboard、plugins、Swift（存储持久化数据）、RESTful API

[ Sahara 有两种使用模式：]

IaaS 模式/管理模式

PaaS、DAaaS 模式/用户模式/EDP模式（DAaaS，Data-analysis-a-Service模式）

[ 关于IaaS 模式有几个概念需要弄清楚：]

（1）节点：是用来 运行 Hadoop 集群的机器。指的是 Sahara 所 provition 的这个 Hadoop 集群的节点，实际上往往是一些虚拟机，也可以是一些物理节点。

（2）节点组：是按照节点的类型来划分的

（3）节点组模板：定义节点组。一个关于节点组模板配置文件例子如下

{
"name":"test-master-templ",
"flavor_id":"2",
"plugin_name":"vanilla",  # 声明用的是Hadoop哪个发行版的版本名
"hadoop_version":"1.2.1",  # 版本号
"node_processes":["jobtracker","namenode"] # 需要运行的哪些进程
}

（4）集群：一个完整的 Hadoop 集群，集群在 Sahara 里怎么定义呢？它是通过集群模板来定义集群的。下面是集群模板的例子：

{
"name":"demo-cluster-template",
"plugin_name":"vanilla",
"hadoop_version":"1.2.1",
"node_groups":[
{
"name":"master",     # 这是节点组的name
"node_group_template_id":"b1ac3f04-c67f-445f-b06c-fb722736ccc6",     # 引用节点组模板
"count":1    # 这个集群里面，这个节点组包括了几个节点数量
}

{
"name":"workers",
"node_group_template_id":"dbc6147e-4020-4695-8b5d-04f2efa978c5",
"count":2
}]
}

我们往往把这个 Hadoop 里面运行 jobtracker 和 namenode 的节点叫作 master 节点，把运行 task tracker 和 data node 的节点叫作 worker 节点。所以上面的例子就是由一个 master 节点和两个 worker 节点组成。

[ 关于 EDP 模式：]

前提：在 OpenStack 里面至少要创建一个 Hadoop 集群，也可以是多个；

准备工作：上传要处理的数据，我们需要很清楚我们需要处理的数据是放在哪里的，编写 Job 并且上传，需要给 Sahara 一个三元组，就是在调用 EDP API 的时候它的参数（1.用哪个集群来处理这堆数据；2.这个数据的元和素在哪里，要处理的数据在哪里放着的，然后处理完之后存哪里去；3.我们要运行的 Job 是什么）

5. Ironic 组件解析

虚拟化环境中涉及到存储 IO 的时候会不会出现性能问题？确实是存在的，尽管虚拟化 Hypervisor 都已经优化的很好了，计算方面的性能损耗已经很低了，但是说到 IO 特别是虚拟机还会用到 Cinder 后端来做 Volume，这个问题确实是存在的。

OpenStack 是通过 Ironic 来实现对物理机械的管理，用物理机器来实现云服务。



如何 launch 一个 Baremetal Server 的工作流程



我们可以看到，这个物理节点上 Nova Compute 调用的 Ironic API，实际上 launch 的物理机器节点或者说实际提供计算资源的物理节点是由 Ironic Conductor 远程管理的，通过两个东西，一个叫作 PXE，一个叫作 IPMI 来远程管理物理机器，如下图所示



那么，为什么会有这样的逻辑？因为 Ironic 实际上是从 Nova 一个部分演化出来的。



所以 Ironic 通过 Nova Compute 组件去调用 Ironic 的 API，然后再通过 Ironic Conductor 去管理一个远程的实际提供计算资源的计算节点。（Ironic 以前就是 Nova 的一个 Driver）

实际上如何用物理机器去组云，用 OpenStack 去管理一堆物理机器来实现云服务是一个很复杂的事情。

网络 MOOC 学习笔记
From 高校帮 《OpenStack 入门 @讲师 李明宇》
By 胡飞 From BUAA
at 2016/4/3 12:48:23