OpenStack架构分析

1、总体架构

下图是OpenStack各Services之间的相互关系。

Nova：管理VM的生命周期

Neutron：为其它组件提供网络连接服务，负责创建和管理L2、L3网络。

Glance：管理VM镜像

Cinder：提供块存储服务

Keystone：为其它组件提供认证和权限管理服务

Ceilometer：提供监控告警和计量计费服务

Horizon：为用户提供一个基于Web的自服务Portal

Swift：提供对象存储服务

Trove：提供数据库服务

Ironic：提供裸金属管理服务

Heat：提供资源编排能力

Sahara：提供在OpenStack上构建大数据服务的能力

下图是各Services的组件及相互关系。

 

下图是部署Openstack所需要的硬件主机要求。

Controller Node

控制器节点为核心节点，运行身份服务，映像服务，计算的管理部分，网络的管理部分，各种网络代理和仪表板。它还包括支持服务，如SQL数据库，消息队列和NTP。

块存储，对象存储，编排和遥测服务的一部分为控制器节点的可选配置。

Compute Node

计算节点为核心节点，运行Nova的Compute部分。可以部署多个计算节点。

Block Storage Node

块存储节点为可选节点，包含块存储和共享文件系统服务为虚机提供磁盘。可以部署多个块存储节点。

Object Storage Node

对象存储节点为可选节点，包含对象存储服务用于存储帐户，容器和对象的磁盘。服务需要两个节点，可以部署多个对象存储节点。

下图为各服务组件部署总揽：

 

2、Nova

2.1、Nova功能

 

Nova是OpenStack最核心的Service，负责维护和管理云环境中的计算资源。主要有如下功能：

虚拟机生命周期管理

虚拟机资源动态调整

虚拟机迁移

主机管理

集群管理

密钥对管理

2.2、Nova架构

 

nova-api

接收和响应客户的 API 调用。

除了提供 OpenStack 自己的API，nova-api 还支持 Amazon EC2 API和特殊管理API。

nova-scheduler

虚机调度服务，负责决定在哪个计算节点上运行虚机

nova-compute

管理虚机的核心服务，通过调用 Hypervisor API 实现虚机生命周期管理。

Hypervisor

常用的 Hypervisor 有 KVM，Xen， VMWare，Hyper-V，Docker，LXC 等

nova-conductor

nova-compute 经常需要更新数据库，比如更新虚机的状态。

出于安全性和伸缩性的考虑，nova-compute 并不会直接访问数据库，而是将这个任务委托给 nova-conductor。

nova-console

用户可以通过多种方式访问虚机的控制台：

nova-novncproxy，基于 Web 浏览器的 VNC 访问

nova-spicehtml5proxy，基于 HTML5 浏览器的 SPICE 访问

nova-xvncproxy，基于 Java 客户端的 VNC 访问

nova-consoleauth

负责对访问虚机控制台提供 Token 认证

nova-cert

提供 x509 证书支持

Database

Nova 会有一些数据，比如虚机构建时间和运行时状态信息，需要存放到数据库中，一般使用 MySQL。

Message Queue

Nova 包含众多的子服务，这些子服务之间需要相互协调和通信。为解耦各个子服务，Nova 通过 Message Queue 作为子服务的信息中转站。OpenStack 默认是用 RabbitMQ 作为 Message Queue。

2.3、Nova部署方案

在控制节点上部署nova-api、nova-scheduler、nova-console、Database、Message Queue、nova-cert、nova-conductor和nova-consoleauth组件；

在计算节点上部署 Hypervisor和nova-compute组件。

2.4、Nova各模块协同工作的例子：虚机创建

1. 客户（可以是 OpenStack 最终用户，也可以是其他程序）向 API（nova-api）发送请求：“帮我创建一个虚机”
2. API 对请求做一些必要处理后，向 Messaging（RabbitMQ）发送了一条消息：“让 Scheduler 创建一个虚机”
3. Scheduler（nova-scheduler）从 Messaging 获取到 API 发给它的消息，然后执行调度算法，从若干计算节点中选出节点 A
4. Scheduler 向 Messaging 发送了一条消息：“在计算节点 A 上创建这个虚机”
5. 计算节点 A 的 Compute（nova-compute）从 Messaging 中获取到 Scheduler 发给它的消息，然后在本节点的 Hypervisor 上启动虚机。
6. 在虚机创建的过程中，Compute 如果需要查询或更新数据库信息，会通过 Messaging 向 Conductor（nova-conductor）发送消息，Conductor 负责数据库访问。

 

3、Glance

3.1、Glance功能

Glance提供的是Image Service，具体功能如下：

1. 提供REST API让用户能够查询和获取镜像及元数据
2. 支持多种存储方式存储镜像，包括普通文件系统、Swift、Amazon S3等等
3. 支持快照功能。例如，对虚拟机实例进行快照操作，以创建新的镜像

3.2、Glance架构

glance-api

glance-api是系统后台运行的服务进程。对外提供REST API，响应image查询、获取和存储等操作请求。如果请求与image metadata相关，它会把请求转发给glance-registry；如果请求与image自身存取相关，则把请求转发给该image的store backend。

glance-registry

glance-registry负责处理和存取 image 的 metadata，例如 image 的大小和类型。Glance支持的image格式包括：Raw、vhd、vmdk、VDI、ISO、QCOW2、aki、ari、ami。

database

Image的metadata保存在database中，默认使用MySQL。

Glance-Store

Glance自己并不存储image，真正的image存放在backend中。

Glance支持的backend包括：

1. A directory on a local file system（默认配置）
2. GridFS
3. Ceph RBD
4. Amazon S3
5. Sheepdog
6. OpenStack Block Storage (Cinder)
7. OpenStack Object Storage (Swift)
8. VMware ESX

3.3、Glance部署

Glance的所有组件都部署在控制节点上。

 

4、Cinder

4.1、Cinder功能

OpenStack 提供 Block Storage Service 的是 Cinder，其具体功能是：

1. 提供 REST API 使用户能够查询和管理 volume、volume snapshot 以及 volume type，实现volume生命周期管理
2. 提供 scheduler 调度 volume 创建请求，合理优化存储资源的分配
3. 通过 driver 架构支持多种 back-end（后端）存储方式，包括 LVM，NFS，Ceph 和其他诸如 EMC、IBM 等商业存储产品和方案

4.2、Cinder架构

 

cinder-api

接收 API 请求，调用 cinder 其他子服务的处理客户端请求。

cinder-scheduler

scheduler 通过调度算法选择最合适的存储节点创建 volume。

cinder-volume

管理 volume 的服务，与 volume provider 协调工作，管理 volume 的生命周期。运行 cinder-volume 服务的节点被称作为存储节点。

cinder-volume 自身并不管理真正的存储设备，存储设备是由 volume provider 管理的。cinder-volume 与 volume provider 一起实现 volume 生命周期的管理。

Volume provider

数据的存储设备，为 volume 提供物理存储空间。

cinder-volume 支持多种 volume provider，每种 volume provider 通过自己的 driver 与cinder-volume 协调工作。

Message Queue

在块存储进程之间传递信息。

4.3、Cinder部署

Cinder一般如下部署：

Cinder-api 与 Cinder-scheduler 部署在控制节点上。

Cinder-volume 与 Cinder-provider 部署在各个块存储节点上。

Message Queue 与 Database 使用 Openstack 全局的MQ与DB服务，部署在控制节点上。

Cinder-volume 与 Cinder-provider 中分别配置提供卷存储及对象存储的后端服务地址。

 

5、Neutron

5.1、Neutron功能

Neutron 为整个 OpenStack 环境提供网络支持，包括二层交换，三层路由，负载均衡，防火墙和 VPN 等。

5.2、Neutron架构

Neutron Server

对外提供 OpenStack 网络 API，接收请求，并调用 Plugin 处理请求。管理网络、子网和端口，以及端口的IP。

Plugin

处理 Neutron Server 发来的请求，以框架方式，维护 OpenStack 逻辑网络状态， 并调用 Agent 处理请求。

 

Agent

处理 Plugin 的请求，负责在提供网络服务的虚拟或物理网络设备，例如 Linux Bridge，Open vSwitch 或者其他支持 Neutron 的物理交换机上真正实现各种网络功能。

包括以下Agent:

L2 Agent，连接虚拟机到网络端口

L3 Agent，为虚拟机访问外部网络提供服务，负责其它层三服务，比如负载均衡等

DHCP Agent，负责DHCP配置，为虚拟机分配IP

 

将Neutron架构展开，将会得到以下更详细的架构图：

1. Neutron 通过 plugin 和 agent 提供的网络服务。
2. plugin 位于 Neutron server，包括 core plugin 和 service plugin。
3. agent 位于各个节点，负责实现网络服务。
4. core plugin 提供 L2 功能，ML2 是推荐的 plugin。
5. 使用最广泛的 L2 agent 是 linux bridage 和 open vswitch。
6. service plugin 和 agent 提供扩展功能，包括 dhcp, routing, load balance, firewall, 等

5.3、Neutron部署

Neutron的组件部署分为两种：Provider部署和Self-service部署。

Message Queue 与 Database 使用 Openstack 全局的MQ与DB服务，一般部署在控制节点上。

Provider Network:

Provider网络主要采用2层（桥接/交换）服务和网络的VLAN分段。本质上，它将虚拟网络桥接到物理网络，并依靠物理网络基础设施来实现第3层（路由）服务。具体部署如下：

如图所示，将Server、ML2 Plug-in、Linux Bridge Agent和DHCP Agent部署在控制节点上；

将Linux Bridge Agent部署在计算节点上。

 

Self-service Networks:

Self-service网络允许使用诸如VXLAN的覆盖分段方法的自助服务网络的第3层（路由）服务来增强提供商网络选项。本质上，它使用NAT将虚拟网络路由到物理网络。具体部署如下：

如图所示，将Server、ML2 Plug-in、Linux Bridge Agent、DHCP Agent和L3 Agent部署在控制节点上；

将Linux Bridge Agent部署在计算节点上。

6、Keystone

6.1、Keystone功能

Keystone（OpenStack Identity Service）在OpenStack框架中负责身份验证、服务规则和服务令牌的功能。

Openstack所有的组件都依赖Keystone(单点的)，它集成了三个功能：

1. 管理身份验证(managing authentication)：验证用户身份
2. 授权(authorization):基于角色role的权限管理
3. 服务目录(catalog of services)：提服务目录(ServiceCatalog：包括service和endpoint)服务，类似于UDDI服务的概念，用户(无论是Dashboard, APIClient)都需要访问Keystone获取服务列表，以及每个服务的地址(Openstack中称为Endpoint)。

6.2、Keystone架构

Keystone-all

Keystone-all包含三类组件:

1. Server, 一个集中化的服务，使用RESTful接口提供认证和授权服务。
2. Drivers, 指的是被集成到server内的驱动或者服务后端，它们被用来在openstack组件之外的库中访问身份信息（比如, SQL databases or LDAP servers).
3. Modules, 中间件运行在正在使用认证服务的openstack组件的地址空间，这些模块(中间件)拦截服务请求，提取用户的credentials，并且把它们发送给server去认证授权，在openstack中间件与openstack组件直接的整合操作使用Python Web Server Gateway Interface，即wsgi

Database

由Drivers对接的数据库，用于记录认证、授权信息与状态，通常为mysql。

LDAP

可选的目录服务，由Drivers对接。

将keystone具体展开可以得到如下的架构图：

Keystone API

Keystone API划分为Admin API和Public API：

1. Public API不仅实现获取版本以及相应扩展信息的操作，同时包括获取Token以及Token租户信息的操作；
2. Admin API主要提供服务开发者使用，不仅可以完成Public API的操作，同时对User、Tenant、Role和Service Endpoint进行管理操作。

Router

Keystone Router主要实现上层API和底层服务的映射和转换功能，包括四种Router类型。

1. AdminRouter

负责将Admin API请求映射为相应的行为操作并转发至底层相应的服务执行；

1. PublicRouter

与AdminRouter类似；

1. PublicVersionRouter

对系统版本的请求API进行映射操作；

1. AdminVersionRouter

与PublicVersionRouter类似。

Services

Keystone Service接收上层不同Router发来的操作请求，并根据不同后端驱动完成相应操作，主要包括六种类型； 

1. Identity Service 

Identity Service提供关于用户和用户组的授权认证及相关数据。

1. Resource Service

Resouse服务提供关于projects和domains的数据

1. Assignment Service 

Assignment Service提供role及role assignments的数据

1. Token Service 

Token Service提供认证和管理令牌token的功能，用户的credentials认证通过后就得到token

1. Catalog Service

Catalog Service提供service和Endpoint相关的管理操作（service即openstack所有服务，endpont即访问每个服务的url）

1. Policy Service 

Policy Service提供一个基于规则的授权驱动和规则管理

Backend Driver

Backend Driver具有多种类型，不同的Service选择不同的Backend Driver。

6.3、Keystone部署

Keystone部署在控制节点上。

 

7、Horizon

7.1、Horizon功能

Horizon是一个web接口，使得云平台管理员以及用户可以管理不同的OpenStack资源以及服务。功能如下：

提供一个Web界面操作OpenStack系统

使用Django框架基于OpenStack API开发

支持将session存储在DB、Memcached

支持集群

7.2、Horizon架构

Horizon内部为Diango的架构, 外部表现为调用各组件提供的API进行对组件操作。

7.3、Horizon部署

Horizon部署在控制节点。

 

8、Ceilometer

8.1、Ceilometer功能

Ceilometer组件用于监视和计量OpenStack云计费，基准测试，可扩展性和统计目的。提供以下功能：

1. 主动轮询测量与OpenStack服务相关的数据。
2. 通过监视服务发送的通知来收集事件和计量数据。
3. 将收集的数据发布目的主机。

8.2、Ceilometer架构

Ceilometer-api

在一个或多个中央管理服务器上运行，以从数据存储提供数据访问。

Collector

在中央管理服务器上运行，并将收集的数据无修改的分发到数据存储或外部使用者。

Agent-notification

在中央管理服务器上运行，从消息队列中的自定义信息以构建事件和计量数据。

Agent-compute

在每个计算节点上运行，轮询统计资源利用率信息。将来可能有其他类型的代理，但现在我们的重点是创建计算代理。

Agent-central

在中央管理服务器上运行，以轮询统计与虚拟机或计算节点无关的资源利用率信息。可以启动多个代理来水平扩展服务。

Alarm-evaluator

在一个或多个中央管理服务器上运行，以确定何时发生由于关联的统计趋势在滑动时间窗口上超过阈值时警报。

Alarm-notifier

在一个或多个中央管理服务器上运行，以允许设置基于样本集合的阈值评估的警报。

Alarm-api

在一个或多个中央管理服务器上运行，以提供对存储在数据存储中的警报信息的访问。

Alarm-listener

在中央管理服务器上运行，并确定何时基于针对事件定义的规则生成的触发警报。

8.3、Ceilometer部署

如上所述，除了Agent-compute部署在计算节点外，其他组件都部署在控制节点上。

 

9、Swift

9.1、Swift功能

Swift提供对象存储服务，它通过基于RESTful HTTP API存储和检索任意非结构化数据对象，具有高度容错的数据复制和横向扩展架构。

9.2、Swift架构

Proxy-server

接受OpenStack对象存储API和原始HTTP请求以上传文件，修改元数据和创建容器。它还向Web浏览器提供文件或容器列表。

Object-server

管理存储节点上的实际对象（例如文件）。

Account-server

管理使用对象存储定义的帐户。

Container-server

管理对象存储器中的容器或文件夹的映射。

将Swift架构展开，将会得到以下更详细的架构图：

1. 代理服务（Proxy Server）：对外提供对象服务 API，会根据环的信息来查找服务地址并转发用户请求至相应的账户、容器或者对象服务；由于采用无状态的 REST 请求协议，可以进行横向扩展来均衡负载。
2. 认证服务（Authentication Server）：验证访问用户的身份信息，并获得一个对象访问令牌（Token），在一定的时间内会一直有效；验证访问令牌的有效性并缓存下来直至过期时间。
3. 缓存服务（Cache Server）：缓存的内容包括对象服务令牌，账户和容器的存在信息，但不会缓存对象本身的数据；缓存服务可采用 Memcached 集群，Swift 会使用一致性散列算法来分配缓存地址。
4. 账户服务（Account Server）：提供账户元数据和统计信息，并维护所含容器列表的服务，每个账户的信息被存储在一个 SQLite 数据库中。
5. 容器服务（Container Server）：提供容器元数据和统计信息，并维护所含对象列表的服务，每个容器的信息也存储在一个 SQLite 数据库中。
6. 对象服务（Object Server）：提供对象元数据和内容服务，每个对象的内容会以文件的形式存储在文件系统中，元数据会作为文件属性来存储，建议采用支持扩展属性的 XFS 文件系统。
7. 复制服务（Replicator）：会检测本地分区副本和远程副本是否一致，具体是通过对比散列文件和高级水印来完成，发现不一致时会采用推式（Push）更新远程副本，例如对象复制服务会使用远程文件拷贝工具 rsync 来同步；另外一个任务是确保被标记删除的对象从文件系统中移除。
8. 更新服务（Updater）：当对象由于高负载的原因而无法立即更新时，任务将会被序列化到在本地文件系统中进行排队，以便服务恢复后进行异步更新；例如成功创建对象后容器服务器没有及时更新对象列表，这个时候容器的更新操作就会进入排队中，更新服务会在系统恢复正常后扫描队列并进行相应的更新处理。
9. 审计服务（Auditor）：检查对象，容器和账户的完整性，如果发现比特级的错误，文件将被隔离，并复制其他的副本以覆盖本地损坏的副本；其他类型的错误会被记录到日志中。
10. 账户清理服务（Account Reaper）：移除被标记为删除的账户，删除其所包含的所有容器和对象。

9.3、Swift部署

Swift服务需要将Proxy-server部署在控制节点上；Object-server、Account-server和Container-server部署在对像存储节点上。

 

10、Sahara

10.1、Sahara功能

在Openstack上提供基于Hadoop的大数据功能。Sahara通过配置Hadoop版本、集群拓扑和节点硬件详细信息等参数，在OpenStack扩展Hadoop集群的功能。

10.2、Sahara架构

Sahara-all

展开Sahara后，可以得到更详细的架构图：

Sahara架构包括几个组件：

Auth组件 - 负责客户端认证和授权，与OpenStack身份服务（keystone）通信。

DAL(Data access layer) - 数据访问层，在DB中保留内部模型。

SSAL(Secure strage access layer) - 安全存储访问层 - 将认证数据（如密码和私钥）保存在安全存储中。

Provisioning Engine - 负责与OpenStack计算（Nova），编排（Heat），块存储（Cinder），映像（Clance）和DNS（Designate）服务通信的组件。

Vendors Plugins - 可插入机制，负责在配置的虚拟机上配置和启动数据处理框架。现有的管理解决方案（如Apache Ambari和Cloudera Management Console）也可以用于此目的。

EDP​​ - 弹性数据处理（EDP），负责安排和管理由sahara提供的集群上的数据处理作业。

REST API - 通过REST HTTP接口暴露萨哈拉功能。

Python Sahara Client - python客户端。

Sahara Dashboard -  位于Horizon的GUI。

10.3、Sahara部署

Sashara的各组件都部署在控制节点上。

 

11、Ironic

11.1、Ironic

Ironic服务使物理服务器容易配置为云化的虚拟机。

11.2、Ironic架构

Ironic-api

提供RESTful API服务，用于管理裸机服务器。

Ironic-conductor

负责执行与裸机部署相关的所有活动。功能通过API服务公开。

Drivers

支持异构硬件的各种驱动程序。

11.3、Ironic部署

其中的Ironic-api和Ironic-conductor组件部署在控制节点上；Drivers部署在计算节点上。

 

12、Trove

12.1、Trove功能

Trove组件是OpenStack的数据库即服务（Database as a Service）功能，允许用户快速方便地利用关系数据库。

12.2、Trove架构

Trove-api

Trove-api服务提供了一个RESTful API，支持JSON和XML来配置和管理Trove实例。轻量级请求通过在该服务直接处理或者通过直接访问guestagent处理，比如获取实例列表、获取实例规格列表等。

Trove-taskmanager

Trove-taskmanager是调度处理层，主要是处理较重的请求，比如创建实例、实例resize等。它会通过Nova、Swift的API访问Openstack基础的服务，而且是有状态的，是整个系统的核心。

Trove-conductor

Trove-conductor是guestagent访问数据库的代理层，主要是为了屏蔽掉guestagent直接对数据库的访问。

Trove-Guestagent

Trove-guestagent运行在虚拟机中，用于接受Trove对虚拟机的管理。

12.3、Trove部署

Trove-Guestagent部署在计算节点外，其他的Trove组件都部署在控制节点上。

 

13、Heat

13.1、Heat功能

Heat 是一个基于模板来编排复合云应用的服务。它目前支持亚马逊的 CloudFormation 模板格式，也支持 Heat 自有的 Hot 模板格式。

模板的使用简化了复杂基础设施，服务和应用的定义和部署。模板支持丰富的资源类型，不仅覆盖了常用的基础架构，包括计算、网络、存储、镜像，还覆盖了像 Ceilometer 的警报、Sahara 的集群、Trove 的实例等高级资源。。

13.2、Heat架构

Heat-api

Heat-api 组件实现 OpenStack 天然支持的 REST API。该组件通过把 API 请求经由 AMQP 传送给 Heat engine 来处理 API 请求。

Heat-api-cfn

Heat-api-cfn 组件提供兼容 AWS CloudFormation 的 API，同时也会把 API 请求通过 AMQP 转发给 heat engine。

Heat-engine

Heat-engine 组件提供 Heat 最主要的协作功能。

13.3、Heat部署

Heat的各组件都部署在控制节点上。

 

14、Manila

14.1、Manila功能

Manila是File Share Service，文件共享即服务，用来提供云上的文件共享，支持CIFS协议和NFS协议。

14.2、Manila架构

Manila-api

Mania-api提供RESTful API，对请求进行身份验证和路由。

Manila-scheduler

Manila-scheduler负责选择和调manila-share。

Manila-share

Manila-share负责管理共享文件服务设备，特别是后端设备。

14.3、Manila部署

Manila-api和Manila-scheduler是安装在控制节点上；Manila-share安装在共享节点上，这里的共享节点指提供文件共享目录的节点。

 

15、Magnum

15.1、Magnum功能

Magnum为用户提供容器管理服务，现在可以为用户提供Kubernetes as a Service、Swarm as a Service，主要目的是能让用户可以很方便的通过OpenStack云平台来管理k8s，swarm，这些已经很成型的Docker集群管理系统，使用户很方便的使用这些容器管理系统来提供容器服务。

15.2、Magnum架构

Magnum API

Magnum API主要是处理client的请求，将请求通过消息队列发送到backend，在magnum，后台处理主要是通过magnum-conductor来做的。

Magnum Conductor

Magnum conductor的主要作用是将client的请求转发到对用的backend，backend在Magnum的官方术语叫CoE(Container Orchestration Engine)。支持的backend有k8s，Swarm，Docker等等

Magnum Client

向Magnum发请求的对像，可以是RESTful API或是CLI命令调用。

15.3、Magnum部署

如构架力所示，Magnum的组件都部署在控制节点上。

16、其他服务

Application Catalog service (murano)

Murano是OpenStack的Application Catalog服务，推崇AaaS(Anything-as-a-Service)的概念，通过统一的框架和API实现应用程序快速部署和用程序生命周期管理的功能来降低应用程序对底层平台(OpenStack层和虚拟化层)的依赖。

Clustering service (senlin)

Senlin是专为管理其他OpenStack服务中同类对象而设计的集群服务, 能够为编程/管理OpenStack云提供一个阵列数据类型。

DNS service (designate)

Designate提供了DNSaaS（DNS即服务）的功能，其目标就是要赋予OpenStack提供云域名系统的能力，云服务商可以使用Designate就能够很容易建造一个云域名管理系统来托管租户的公有域名。

Governance service (congress)

Congress是一个基于异构云环境的策略声明、监控、实施、审计的框架（policy-as-a-service）。Congress从云中不同的服务获取数据，输入到congress的策略引擎，从而验证云中的各服务状态是否按照设置的策略运行。

Infrastructure Optimization service (watcher)

Watcher是OpenStack中提资源优化服务组件，提供一个完整的优化循环链：从度量接收器，到优化处理器和操作计划应用程序。Watcher的目标在于提供一个强大的框架，可以实现广泛的云优化目标，包括减少数据中心运营成本，通过智能虚拟机迁移提高系统性能，提高能源效率等。此外，Watcher可供用户定制丰富的资源优化目标与策略算法。

Key Management service (barbican)

云服务在内的任何环境提供密钥管理功能。

Message service (zaqar)

Zaqar是OpenStack社区中为WEB和移动应用开发者提供的多租户消息服务。利用Zaqar, 开发者可以在SaaS以及移动应用组件之间传递消息, OpenStack组件也可以向终端用户提供消息通知服务。NFV Orchestration service (tacker)

Tacker用于OpenStack中 NFV编排和VNF 的管理。完全基于欧洲电信标准协会行业规范组（ETSI ISG）定义的MANO框架。在Tacker中，OpenStack Nova、 Neutron、Cinder等组件集体作为 VIM虚拟基础设备管理。

Rating service (cloudkitty)

Cloudkitty为OpenStack提供计费服务。

Root Cause Analysis service (vitrage)

Vitrage是OpenStack RCA（Root Cause Analysis）服务，用于组织、分析和扩展OpenStack报警和事件，直接检测到问题之前推断问题的根本原因。

Search service (searchlight)

Searchlight的目的是优化搜索的能力和性能，为不同的OpenStack云服务提供用户查询。

Telemetry Alarming service (aodh)

Aodh主要提供配置和管理OpenStack告警服务

Telemetry Time Series Database service (gnocchi)

Gnocchi主要用来提供资源索引和存储时序计量数据。

Workflow service (mistral)

Mistral是工作流组件，提供Workflow As a Service.典型的应用场景包括任务计划服务Cloud Cron,任务调度Task Scheduling, 复杂的运行时间长的业务流程等。