文章目录
Openstack 概念
OpenStack 通过多种补充服务提供了 IaaS 解决方案，每一种服务均提供了相应的应用程序接口简称 API，以促进各组件之间的整合。被用来提供公有云以及私有云的建设以及管理。OpenStack是一个支持公有云、私有云和混合云等各种云计算类型的开源云计算平台项目，其主要目的是简化云计算的实施部署、提供海量扩容的云计算平台和丰富完善的云计算功能集。用于控制数据中心计算、存储和网络资源池的云操作系统，在OpenStack中，云管理员对资源池的全部管理和控制都可以通过Dashboard仪表板实现，同时通过Web接口界面实现对用户资源的供给和控制，OpenStack的核心项目主要是计算服务、网络服务和存储服务，并通过Dashboard将这三大服务呈现给用户，实现云用户与数据中心资源池的交互。
主要功能模块
Identity（身份认证服务）—Keystone
Keystone身份认证服务：引入令牌机制来保护用户对资源的访问，用于访问openstack服务的API以及资源，一个令牌可以在特定时间内生效，可在任意时间释放。用户使用云中的资源是通过访问服务的方式实现，如提供计算服务的Nova，提供镜像服务的Glance,提供对象存储服务的Swift。
Keystone为整个OpenStack项目其他子系统提供以下服务：
User：
指代任何使用OpenStack的实体，可以是真正的用户，其他系统或者服务，当User请求访问OpenStack时，Keystone会对其进行验证。
Credentials：
凭证证书，可以简单理解为用户名和密码。是User用来证明自己身份的信息
Authentication：
是Keystone验证User身份的过程
Token：
令牌，用来实现单点登录，是各模块之间调用的认证令牌。Token是由数字和字母组成的字符串，User成功Authentication后，它由Keystone分配给User
Project：
用于将OpenStack的资源（计算、存储和网络）进行分组和隔离。用户信息管理，包括用户/租户基本信息，项目project管理。根据OpenStack服务的对象不同，Project可以是一个客户（公有云，也叫租户）、部门或者项目组（私有云）。
Service：
服务，其为基于OpenStack标准REST API对外提供的服务。例如，Nova云主机服务就是Compute，弹性云硬盘是Volume, Keystone服务就是identify，镜像Glance服务是Image等。Service包括Compute (Nova)、BlockStorage (Cinder)、Object Storage (Swift)、ImageService (Glance)、Networking Service (Neutron)等
Endpoint：
服务端点，其为提供服务的Server端。Endpoint是一个网络上可访问的地址，通常是一个URL。Service通过Endpoint暴露自己的API。Keystone负责管理和维护每个Service的Endpoint。
Role：
安全包含两部分：Authentication（认证）和Authorization（鉴权）。Authentication解决的是“你是谁？”的问题。Authorization解决的是“你能干什么？”的问题。Keystone是借助Role来实现Authorization的，Keystone定义Role用户角色，与权限相关 包括超级管理员admin、普通成员member等。
Tenant：
租户项目将使用对象/管理对象分组整合的容器可以是一个消费者（consumer）、账户（account）、组织（organization）或者项目（project）。在Nova云主机中，tenant对应项目project，如“满分网正式环境”，但是其在云存储中对应account。
认证流程如图所示：
认证流程解说：
<1>： 开始客户端，需要使用用户名、密码访问Keystone获取初始token, Keystone通过查询user表、检查口令，生成token。token包含用户的基本信息和有效时间，存储至token模型里面。客户端获取该初始token，能够调用不需要tenantId的API，如Keystone里面有关tenants的查询接口，但是如果调用其他服务，如计算Compute、存储Volume等API服务接口，必须要用到tenantId。此时初始的token无效，必须用项目编号，tenantId进行再次重新认证，获取新的token。
<2>： 可以用第一步获取的初始token令牌加上用户名、密码，查询当前用户的Tenant项目，再选择需要操作的项目tenantId重新认证，获取认证后的新token在24小时内有效。Keystone返回的新token报文里面包含各个服务的服务端endpoint地址，接下来就可以用新token访问这些endpoint提供的服务，如查询镜像列表。
<3>： 调用服务端endpoint服务，比如调用计算compute，查询当前租户提供的镜像列表接口v2/images。endpoint服务端REST API接口服务需要检查当前令牌token是否合法，需要调用Keystone接口再次确认，如果有效，则检查权限。
<4>： 检查权限环节，在上文Keystone中基本没有涉及，其实服务端的REST API可以被哪些角色访问是由提供服务的endpoint模块决定的，定义在/etc/{service}/policy.json文件里面
<5>： 客户端在调用其他的服务时，都会重复执行检查token和权限的操作
Dashboard（控制面板服务）—Horizon
Image Service（镜像服务）—Glance
镜像服务Glance
允许发现 注册和获取虚拟机镜像。它提供了一个REST API,允许查询虚拟机镜像的元数据，并获取一个现存的镜像。可以将虚拟机镜像存放到各种位置，从简单的文件系统到对象存储系统，如OpenStack Swift项目，默认是存储在本地文件系统上的。其实在生产环境中这个模块本身不存储大量的数据，需要挂载后台存储swift来存放实际的镜像数据。 在OpenStack环境中，镜像是用于在计算节点生成虚拟机。脱离了镜像服务，就无法创建虚拟机，所以镜像服务是OpenStack的一个核心服务。
Glance 的主要组件：
<1> glance-api： 用于接收镜像API的调用，如镜像发现，恢复及存储等，对外提供REST API 接口，响应用户发起的镜像查询 获取 和存储的调用 如果是与image metadata（元数据）相关的操作，glance-api会把请求转发给glance-registry；如果是与image自身存取相关的操作，glance-api会把请求转发给该image的store backend。
<2> glance-registry： 用于存储 处理和恢复镜像的元数据，元数据包括镜像的大小和类型等，它是一个内部服务接口，不建议暴露给普通用户。
<3> database： 用于存放镜像的元数据，可以根据需要选择数据库 如mysql sqlite等
<4> storage repository for image files： glance不需要存储任何镜像，而是将镜像存储在后端仓库中
<5> Store backend ： Glance自己并不存储image，真正的image是存放在backend中的。Glance支持多种backend。
Glance镜像的格式：
1, RAW： 是一种没有格式的磁盘文件类型，raw对数据不做任何修饰更改，直接保存原始的状态，也更容易和其他镜像格式进行转换。
2, QCOW2： 主要特性是磁盘文件大小可以动态按需增长，不会占用所有实际磁盘空间大小，与RAW相比，QCOW2可以节省磁盘容量。
3, VHD： 微软公司产品使用的磁盘格式，如需在openstack上使用Hyper-V类型的虚拟化，就应上传VHD格式的镜像文件。
4, VMDK： 是VMware公司产品使用的磁盘格式。开放的通用格式，QEMU和VirtualBox也提供对VMDK格式的支持。
5, VDI： 是oracle公司的VirtualBox虚拟软件使用的磁盘格式。
6, ISO： ISO是指一种存档数据文件在光盘上的格式。
7, AKI ARI AMI： 是Amazon公司的AWS所用的镜像格式。
Linux镜像很小，通过Web UI上传很快，操作会很顺畅。如果要上传的镜像比较大（比如好几个GB），CLI是更好的选择
Block Storage（块存储服务）—Cinder
OpenStack集群中的存储通常分为块存储、对象存储和文件系统存储，块存储是通过SAN或iSCSI等存储协议将存储设备端的卷（Volume）挂载到虚拟机上并进行分区和格式化，然后挂载到本地文件系统使用的存储实现方式；在OpenStack中，块存储是使用最多的数据存储实现方式，并且由Cinder项目提供，Cinder是OpenStack集群中提供块存储服务的独立项目，其前身为Nova项目中的Nova-Volume子项目，并在OpenStack的F版本后独立成为OpenStack的核心项目。存储的分配和消耗是由块存储驱动器或后端配置的驱动器决定的。还有很多驱动程序可用: NAS/SAN、 NFS、ISCSI、 CEPH 等。
块存储适合性能敏感性业务场景,例如数据库存储大规模可扩展的文件系统或服务器需要访问到块级的裸设备存储。典型情况下，块服务API和调度器服务运行在控制节点上。取决于使用的驱动，卷服务器可以运行在控制节点、计算节点或单独的存储节点之上。 块存储服务为OpenStack中的实例提供持久的存储，块存储提供一个基础设施，用于管理卷以及和OpenStack计算服务交互，为实例提供卷、快照、卷类型等功能。站在实例的角度，挂载的每个卷都是一块独立的硬盘。Cinder提供了从创建卷到删除卷整个生命周期的管理。功能就是实现存储服务，根据实际需要快速地为虚拟机提供块存储设备的创建、挂载、回收及快照备份控制等。
Cinder弹性云存储 包括API、调度Scheduler和存储适配cinder-volume 3个服务，其中cinder-volume可部署至多个节点上。
调度器cinder-scheduler与nova-scheduler类似，根据服务寻找合适的存储服务器cinder-volume，发送消息至cinder-volume节点，由cinder-volume提供弹性云存储服务。
Cinder具体功能是:
●提供REST API接口，使用户能够查询和管理卷、卷快照以及卷类型;
●协调卷的创建请求，合理优化存储资源的分配;
●通过驱动架构支持多种后端存储方式，包括LVM、NFS、Ceph和其他诸如EMC、IBM等商业存储产品和方案。
Cinder服务涉及到以下组件
1, Cinder-Api：cinder-api为Cinder组件对外的唯一窗口, 用于接受REST请求，cinder-api向外界暴露若干HTTPREST API接口
2, Cinder-Volume：用来与块存储服务和cinder-scheduler进程进行直接交互或通过消息队列交互，当用户请求一个存储资源时，有cinder-api负责接收请求，cinder-scheduler负责调度资源，而真正执行存储任务的是cinder-volume。这样的工作机制使得存储架构非常容易扩展，当存储资源不足时，可增加存储节点（运行cinder-volume）。当客户的请求量太大调度不过来时，可增加调度（运行cinder-scheduler）。cinder-volume自身并不管理真正的存储设备，存储设备是由volume provider管理的。cinder-volume与volumeprovider一起实现volume生命周期的管理
3, Cinder-Scheduler:Cinder-Scheduler守护进程会选择最优存储节点来创建卷，其工作机制与Nova-Scheduler类似。当需要创建卷时，Cinder-Scheduler 根据存储节点的资源使用情况选择一个最合适的节点来创建卷。
4, Cinder-Backup 守护进程:Cinder-Backup服务提供任何种类备份卷到一个备份存储提供者。就像Cinder-Volume服务，它与多种存储提供者在驱动架构下进行交互。为块存储卷（Volumes）提供了备份服务，要实现Volumes的备份，需要提供备份存储驱动的实现，目前比较常见的备份存储后端由Swift提供。与Cinder-volume类似，Cinder-backup也通过Driver插件架构的形式与不同的存储备份后端交互。
5, 消息队列 Cinder项目的不同内部服务组件之间通过Queue进行消息交互，如Cinder-volume与Cinder-scheduler之间的信息交互。
Object Storage（对象存储服务）—Swift
Swift是OpenStack原生的对象存储，是由OpenStack开源云计算项目中RackSpace 贡献的子项目。是一种以REST API方式提供数据访问的存储实现方式。Swift的目的是使用普通硬件来构建冗余的、可扩展的分布式对象存储集群，存储容量可达PB级。Swift适用于多种场景，既可以为虚拟机提供镜像存储，也可以为网盘产品提供存储引擎。
Swift对象存储目前已广泛应用到生产系统中，具有以下的众多优势：
1）极高的数据持久性。Swift在5个Zone、5×10个存储节点的环境下，数据复制份数为3，数据持久性的SLA能达到10个9。
2）完全对称的无中心架构（采用最终一致性哈希环），各节点完全对等。
3）无限的可扩展性，包括存储容量和性能的可扩展。
4）确保无单点故障。
5）开源、简单可依赖的架构，易于搭建。
Swift提供了RESTful API作为访问的入口，Swift存储的每个对象都是一个RESTful ，拥有一个唯一的URL，用户可以发送HTTP请求将一些数据传到Swift对象存储上，也可以从Swift请求一个存储对象，至于该对象的形式和存储位置并不需要用户关心。
Swift主要组件：
代理服务（Proxy Server）：对外提供对象服务 API，会根据环的信息来查找服务地址并转发用户请求至相应的账户、容器或者对象服务；由于采用无状态的 REST 请求协议，可以进行横向扩展来均衡负载。
认证服务（Authentication Server）：验证访问用户的身份信息，并获得一个对象访问令牌（Token），在一定的时间内会一直有效；验证访问令牌的有效性并缓存下来直至过期时间。
缓存服务（Cache Server）：缓存的内容包括对象服务令牌，账户和容器的存在信息，但不会缓存对象本身的数据；缓存服务可采用 Memcached 集群，Swift 会使用一致性散列算法来分配缓存地址。
账户服务（Account Server）：提供账户元数据和统计信息，并维护所含容器列表的服务，每个账户的信息被存储在一个 SQLite 数据库中。
容器服务（Container Server）：提供容器元数据和统计信息，并维护所含对象列表的服务，每个容器的信息也存储在一个 SQLite 数据库中。
对象服务（Object Server）：提供对象元数据和内容服务，每个对象的内容会以文件的形式存储在文件系统中，元数据会作为文件属性来存储，建议采用支持扩展属性的 XFS 文件系统。
复制服务（Replicator）：会检测本地分区副本和远程副本是否一致，具体是通过对比散列文件和高级水印来完成，发现不一致时会采用推式（Push）更新远程副本，例如对象复制服务会使用远程文件拷贝工具 rsync 来同步；另外一个任务是确保被标记删除的对象从文件系统中移除。
更新服务（Updater）：当对象由于高负载的原因而无法立即更新时，任务将会被序列化到在本地文件系统中进行排队，以便服务恢复后进行异步更新；例如成功创建对象后容器服务器没有及时更新对象列表，这个时候容器的更新操作就会进入排队中，更新服务会在系统恢复正常后扫描队列并进行相应的更新处理。
审计服务（Auditor）：检查对象，容器和账户的完整性，如果发现比特级的错误，文件将被隔离，并复制其他的副本以覆盖本地损坏的副本；其他类型的错误会被记录到日志中。
账户清理服务（Account Reaper）：移除被标记为删除的账户，删除其所包含的所有容器和对象。
Compute（计算服务）—Nova
Nova处于Openstak架构的中心，是OpenStack最核心的服务，负责维护和管理云环境的计算资源,其他组件都为Nova提供支持：Glance为VM提供image。Cinder和Swift分别为VM提供块存储和对象存储。Neutron为VM提供网络连接。
nova-api（API Server）对外统一提供标准化接口。各子模块，如计算资源、存储资源和网络资源子模块通过相应的API接口服务对外提供服务。API接口可以相互调用。在OpenStack的Folsom版本发行后，Nova-volume和Nova-network被独立成为块存储Cinder项目和网络Quantum（Neutron）项目，而Nova自身的功能模块也被不断细分，除了Nova-Compute和Nova-API功能模块，以及消息队列和数据库之外，Nova项目还构建了Nova-cert、Nova-Conductor、Nova-consoleauth和nova-console等模块。但是原有Nova项目中的Nova-network模块并没有被抛弃，即Neutron项目与Nova-network目前仍然在并行开发维护中。Nova在设计过程中使用了中心化数据库思想，即各个服务组件共同使用相同的数据库
各模块职责如下。
Nova-api ：nova-api就是整个Nova的入口。它接收用户请求，将指令发送至消息队列AMQP指定的主题Topic，由订阅相应主题Topic的守护进程接收和执行相关指令消息。nova-api包括两大部分，一部分是WSGI API，一部分是RPC API。前者是面向公众的服务接口，包括数据封装格式转换和数据校验；后者是标准化服务的内部实现，包括数据库操作消息传递等，比如compute-api、network-api、volume-api，统称API Server。
nova-compute：是主要的执行守护进程，职责是基于各类虚拟化技术Hyperivisor实现创建和终止虚拟机。nova-compute有两个工作：接收消息队列中的执行指令并执行相关指令，如部署KVM虚拟机；维护数据库相关模型的状态数据。nova-compute整合了计算资源CPU/内存、存储（nova-volume）、网络（nova-network）3类资源部署管理虚拟机，实现计算能力的交付。
nova-volume/Cinder：的职责是创建、挂载和卸载持久化的磁盘虚拟机，就是为虚拟机增加块设备存储（硬盘）。nova-volume初步解决了云计算里存储资源池的存储问题。nova-volume可以用iSCSI和分布式文件系统CEPH的Rados Block Device实现。在Folsom版本后，块存储云硬盘管理新增了Cinder子系统（nova-volume继续保留）。
nova-network：的 职责是实现网络资源池的管理，包括IP池、VLAN、网桥接口、防火墙等的管理。接收AMQP消息队列指令消息并执行。nova-network解决云计算网络资源池的网络问题。在Folsom版本后，Nova-network被独立成为网络Quantum（Neutron）项目。
nova-schedule：的职责是调度虚拟机在哪个物理宿主机上部署。接收消息队列指令并执行。该模块是非常值得挖掘和深入发展的，特别是在大规模数据中心以及跨地域的数据中心实现整体的资源调度部署的时候，其调度算法也可以根据性能优先、使用效率优先、节能环保优先的不同策略实现不同的业务目标。AMQP消息中间件目前采用了RabbitMQ，也可以用任何AMQP协议的消息中间件，如Apache的Qpid。笔者认为消息中间件的引入是Nova整个技术架构的核心和亮点。通过消息中间件，实现了服务接口与实现解耦以及子系统之间的消息通信，实现了分布式的部署管理。
nova-conductor：nova-compute需要获取和更新数据库中instance的信息。但nova-compute并不会直接访问数据库，而是通过nova-conductor实现数据的访问，nova-compute访问数据库的全部操作都放到nova-conductor中，而且nova-conductor是部署在控制节点上的。这样就避免了nova-compute直接访问数据库，增加了系统的安全性。
Network（网络服务）—Neutron
Neutron是一个由分布式组件构成的网络服务，其内部组件包括Neutron Server、插件代理（PluginAgent）、DHCP代理、L3代理和计量代理（MeteringAgent）等其他SDN服务、OpenStack的网络服务由Neutron项目提供，Neutron允许OpenStack用户创建和管理网络对象，如网络、子网、端口和路由等，而这些网络对象正是其他OpenStack服务正常运行所需的网络资源，Neutron还提供了用以配置、管理各种网络服务的API，如L3转发、NAT、负载均衡、防火墙和v*n等高级网络服务。
Neutron架构图：
内部组件通信架构图：
关于Neutron服务组件的功能和作用描述如下。
Neutron Server: Neutron Server主要运行在网络节点上，其组件包括Neutron-server服务进程和neutron-plugin服务，或者说Server API与插件构成了Neutron Server。或者说Server API与插件构成了Neutron Server。
Neutron Server的主要作用在于对外提供OpenStack网络服务API及其扩展。API接收请求后负责调用相应的Plugin进行请求处理，而Plugin又负责调用PluginAgent进行最终的任务处理并维护OpenStack网络逻辑状态，因此Plugin是Neutron中主要的数据库访问者。
Plugin Agent： 插件代理是最终的网络提供者（Network Provider），即租户网络服务请求在经过Neutron Server和Plugin之后，最终通过PluginAgent来实现租户网络请求任务。Plugin -+Agent（neutron–agent）服务主要运行在计算节点并管理本地虚拟交换机配置，用户选用的Plugin决定了计算节点所运行的Plugin Agent，因为Plugin与Agent总是相互对应的。插件代理服务需要访问消息队列以便和插件服务进行交互，同时插件代理需要访问数据库以便存储网络变更信息。因此插件代理也是Neutron中主要的数据库访问者。
DHCP Agent: DHCP Agent服务（neutron-dhcp-agent）主要为租户网络提供DHCP服务，DHCPAgent对于Neutron支持的全部网络Plugins都是相同的，即DHCP代理并不依赖用户选用的Plugin。DHCPAgent服务也需要访问消息队列以便同网络Plugins进行交互。
L3 Agent: L3 Agent在Provider类型的网络中并不是必须的，而在Self-Service网络中却是必须的。L3Agent服务主要在外网访问租户网络中的虚拟机时提供L3 Route功能。L3 Agent也需要访问消息队列。
Network Provider Service: Network ProviderService又称SDN Service，即网络SDN服务，其主要作用在于向租户网络提供额外的网络服务。SDNService通过REST APIs通信渠道与Neutron-server、Neutron-plugin和neutron-agent服务进行交互。
Neutron内部各个组件代理与Neutron Server和Plugins之间以RPC的形式进行通信，而SDN Service以REST APIs的形式访问Neutron Server和相应的插件代理。
网络支持组件：
1: 网络 类似于实际的物理环境中的网络，OpenStack 网络用于连接云主机或路由器。除此之外，还包含子网、网关以及DHCP服务等。OpenStack网络分为内部网络和外部网络，内部网络一般用于连接虚拟机， 而外部网络一般用于连接宿主机外面的网络。
2: 子网（Subnet）代表的是一个IP段和相关的配置状态。子网IP和网络配置信息通常被认为是网络服务为租户网络和供应商网络提供的原生IPAM。当某个网络上有新的端口被创建时，网络服务便会使用子网提供的IP段为新端口分配IP。
3: 端口 端口类似于实际网络中的网络接口，用于连接终端设备或另外一个网络。不同的是，OpenStack中端口连接的一般都是虚拟设备接口，如虛拟机的虚拟网卡或者路由器的虚拟接口等。端口还描述了相关的网络配置，例如可以在端口上配置MAC地址和IP地址。
4: 路由器 路由器用于连接OpenStack的内部网络和外部网络。类似实际路由器功能，支持NAT功能，通过绑定浮动IP地址还可以实现地址映射。Neutron分别提供了二层(L2)交换和三层(L3)路由抽象的功能，对应于物理网络环境中的交换机和路由器。
OpenStack网络中,对于二层交换机有两种的抽象方式,一种是通过Linux bridge实现，另外一种是通过OpenvSwitch实现。在一些早期OpenStack版本中，默认使用的是OpenvSwitch,而在Ocata版本中，多节点手动安装默认使用的是Linuxbridge两种方式都可以实现二层网路的抽象。从功能上来说OpenvSwitch更加强大，但是Linux bridge实现比较简单。
网络类型：
1．Local ：local网络与其他网络和节点隔离。local网络中的instance只能与位于同一节点上同一网络的instance通信，local网络主要用于单机测试。Local Network的特点是不会与宿主机的任何物理网卡相连，也不关联任何的VLAN ID。
2．Flat： flat网络是无vlan tagging的网络。flat网络中的instance能与位于同一网络的instance通信，并且可以跨多个节点。
在Flat网络中，不同计算节点上的全部实例接入同一个大二层网络内，全部实例共享此网络，不存在VLAN标记或其他网络隔离技术。接入Flat网络的全部实例通过数据中心核心路由接入Internet，相对于其他的网络类型，Flat网络是最简单的网络类型。
3．Vlan： vlan网络是具有802.1q tagging的网络。vlan是一个二层的广播域，同一vlan中的instance可以通信，不同vlan只能通过router通信。vlan网络可以跨节点，是应用最广泛的网络类型。
VLAN网络允许用户使用外部物理网络中的VLAN ID创建多个租户或供应商网络。VLAN网络通过VLAN ID进行二层网络的隔离，相同VLAN ID内部的实例可以实现*通信，而不同VLAN之间的实例通信则需要经过三层路由的转发。由于VLAN网络可以实现灵活多样的网络划分与隔离，故VLAN网络是生产环境中使用最为普遍的网络。而在云计算环境中，VLAN网络主要用于私有云环境中，对于大型公有云数据中心，在租户增加的情况下，VLAN ID的限制是VLAN网络的一大弊端。
4．Vxlan： vxlan是基于隧道技术的overlay网络。vxlan网络通过唯一的segmentation ID（也叫VNI）与其他vxlan网络区分。vxlan中数据包会通过VNI封装成UPD包进行传输。因为二层的包通过封装在三层传输，能够克服vlan和物理网络基础设施的限制。
5．Gre ：gre是与vxlan类似的一种overlay网络。主要区别在于使用IP包而非UDP进行封装。不同network之间在二层上是隔离的。以vlan网络为例，network A和network B会分配不同的VLAN ID，这样就保证了network A中的广播包不会跑到network B中。当然，这里的隔离是指二层上的隔离，借助路由器不同，network是可能在三层上通信的
network必须属于某个Project（Tenant租户），Project中可以创建多个network。network与Project之间是1对多关系
Telemetry（计量服务）—Ceilometer
Ceilometer是OpenStack项目中的数据采集服务，提供监控和计量服务，为报警、统计或计费提供数据。ceilometer能把OpenStack内部发生的几乎所有事件收集起来，然后为计费和监控以及其他服务提供数据支撑。
Ceilometer所采集的数据范围主要包括虚拟机实例性能数据（如CPU、磁盘IO和网络IO等）以及Cinder、Glance和Neutron等服务项目的资源使用情况，Ceilometer通过对OpenStack服务项目的数据收集，从而为上层的计费、结算或者监控应用提供统一的资源使用数据依据。Ceilometer是一个相对较新的项目，其最初随OpenStack的Folsom版本发行，随后功能不断得到完善，尽管官方默认的Ceilometer后端存储为MongoDB，但是Ceilometer支持DB2、HBase和SQLAlchemy等后端数据库存储。
Ceilometer数据采集过程：
Ceilometer的各个服务中，与采集相关的服务是Ceilometer-collector、Ceilometer-agent-central、Ceilometer-agent-compute、Ceilometer-agent-notification。
Ceilometer的Agent负责数据采集，采集到的数据通过RPC、UDP或File方式Publish出去，具体的Publish方式通过Pipeline控制。
在Ceilometer的数据采集Agent中，Agent-notification负责收集各个组件推送到消息队列框架oslo-messaging的消息，Agent-compute仅负责收集计算节点虚拟机的CPU、内存和IO等信息，Agent-compute仅部署在OpenStack计算节点上，Agent-central通过各个组件的API进行有用数据的采集。
Ceilometer的数据采集方式主要分为两种，即Poll轮询和主动监听。
Agent-compute和Agent-central采用的是Poll轮询监听，即需要定期Poll轮询以采集信息，而Agent-notification为主动监听方式，其只需监听AMQP中的Queue即可采集到信息，Ceilometer的Agent采集到的数据可以汇聚到Ceilometer-collector，再由Ceilometer-collector持久化保存在后端数据库，或者直接以Publish的方式传递给外部的监控或计费等应用程序，此外，外部应用程序还可以通过Ceilometer的API从数据库中访问Ceilometer采集到的数据。