koll-ansible部署功能组件说明
Kolla-Ansible deploys containers for the following OpenStack projects:
- Aodh : 数据采集由ceilometer负责，采样的数据存储由gnocchi负责，告警功能由aodh负责（其中统计数据通过gnocchi提供的接口进行获取，本身的告警配置数据保存在mysql中）
- Barbican：为包含云服务在内的任何环境提供密钥管理功能，1密钥：包括对成算法中的密钥，非对称算法中的密钥（包括公钥），数字签名的密钥等。其底层通过plugin设计支持不同的软硬件（HSM）。2证书：通过plugin的方式提供证书的颁发，验证等功能。Pike版本废气。3二进制数据
- Bifrost：https://docs.openstack.org/kolla-ansible/latest/reference/bifrost.html是一套ansible操作手册，使用ironic自动完成将基本映像部署到一组已知硬件的任务。提供了一次性操作系统部署的模块化实用程序，尽可能少的操作要求。在通过bifrost部署的系统中，我们定义了许多类的主机。 控制主机：控制主机是将要安装 Kolla和kolla-ansible的主机，并且通常是从中管理云的位置。部署主机：部署主机通过bifrost deploy容器并用于配置云主机。云主机：云主机运行openstack控制平面，计算和存储服务。裸机计算主机：在通过Ironic向租户提供裸机计算服务的云中，这些主机将运行裸机租户工作负载，在只有虚拟化计算的云中，此类主机不存在。 部署过程：1在控制主机上安装并配置kolla和kolla-ansible 2在部署主机上部署bifrost.3实用bifrost构建基于操作系统映像，并实用此影响配置云主机。 4在由bifrost调配的云主机上部署openstack服务
- Blazar：Blazar 是openstack的资源预定服务。blazar使用户能够在特定时间段内保留特定类型/数量的资源，并根据用户的预定将这些资源租赁给用户。Compute host: reserve and lease with a unit of a whole host
- Instance: reserve and lease with a unit of a flavor
- Ceilometer
- Cinder
- CloudKitty： https://blog.csdn.net/zhongbeida_xue/article/details/78458849
- 云计算是一种按需付费的服务模式，但现在的ceilomter,gnocchi,aodh,panko项目的稳步并进算是让其峰回路转。计费模型是实现计费的核心，一般能允许用户根据实际需求设定计费规则并且根据收集到资源数据进行准确的费用计算。Cloudkitty实现了多种计费模型noop，hashmap和pyscripts，允许同时启动多个计费模型，并根据设置的优先级完成执行费用计算。Cloudkitty中的pyscripts计费模型使用门槛较高，hashmap计费模型成为了使用价值最高，易用性最强的计费模型 https://blog.csdn.net/linshenyuan1213/article/details/75039897 1计费服务对象Tenant Fetcher:Tenant Fetcher是用来获取合法的计费服务对象， 即cloudkitty要知道需要对谁的资源进行计费， 2 计费源数据收集collector 和统一化Transformer单纯从计费角度来看，计费源有两类，一类是静态资源，比如如虚拟机实例、镜像、云硬盘、浮动IP；一类是动态资源，比如网络流量。对于静态资源一旦被创建，那么它的单价就固定，只需根据其生命周期按时间长短计费即可；对于动态资源需要统计计量情况进行计算费用。这就意味着计费的数据源应该包括event和measurement两部分，但当前Cloudkitty在计费数据收集方面没有加入事件分析能力。
这一步除了计费源数据的收集，还有一个十分重要的工作就是把这些数据转化为统一格式输入给计费引擎。Cloudkitty中的transformer模块将针对不同collector的不同类型的服务数据进行格式统一。 计费引擎RatingOrchestrator类是Cloudkitty计费引擎的具体实现，支持多线程，支持多种计费模型同时运行，并能指定优先级。在计费策略上Cloudkitty采用的是周期轮询计费的方式，默认是每一小时对云环境中所需计费的资源进行费用核算，并将费用数据持久化存储起来。还有一个大周期是当月内，如果rated_data_frames表中的数据是空的时候，每次启动cloudkitty-processor就会重新计算当月内每小时的费用。 费用数据的存储Storage前面提到Cloudkitty的计费引擎是周期性计算资源费用的，而这个周期可以根据实际情况修改，只要能在一个计费周期内完成所有资源的费用计算即可。
- 这一步除了计费源数据的收集，还有一个十分重要的工作就是把这些数据转化为统一格式输入给计费引擎。Cloudkitty中的transformer模块将针对不同collector的不同类型的服务数据进行格式统一。 计费引擎RatingOrchestrator类是Cloudkitty计费引擎的具体实现，支持多线程，支持多种计费模型同时运行，并能指定优先级。在计费策略上Cloudkitty采用的是周期轮询计费的方式，默认是每一小时对云环境中所需计费的资源进行费用核算，并将费用数据持久化存储起来。还有一个大周期是当月内，如果rated_data_frames表中的数据是空的时候，每次启动cloudkitty-processor就会重新计算当月内每小时的费用。 费用数据的存储Storage前面提到Cloudkitty的计费引擎是周期性计算资源费用的，而这个周期可以根据实际情况修改，只要能在一个计费周期内完成所有资源的费用计算即可。
- 这一步除了计费源数据的收集，还有一个十分重要的工作就是把这些数据转化为统一格式输入给计费引擎。Cloudkitty中的transformer模块将针对不同collector的不同类型的服务数据进行格式统一。 计费引擎RatingOrchestrator类是Cloudkitty计费引擎的具体实现，支持多线程，支持多种计费模型同时运行，并能指定优先级。在计费策略上Cloudkitty采用的是周期轮询计费的方式，默认是每一小时对云环境中所需计费的资源进行费用核算，并将费用数据持久化存储起来。还有一个大周期是当月内，如果rated_data_frames表中的数据是空的时候，每次启动cloudkitty-processor就会重新计算当月内每小时的费用。 费用数据的存储Storage前面提到Cloudkitty的计费引擎是周期性计算资源费用的，而这个周期可以根据实际情况修改，只要能在一个计费周期内完成所有资源的费用计算即可。
- CongressCongress是一个基于异构云环境的策略声明、监控、实施、审计的框架（policy-as-a-service）。Congress从云中不同的服务获取数据，输入到congress的策略引擎，从而验证云中的各服务状态是否按照设置的策略运行。功能：监控云中的策略冲突，预防策略冲突，矫正策略冲突。Congress会实现“记录策略及冲突的历史记录”功能用于策略的审计
- Designate：OpenStack Designate提供了DNSaaS（DNS即服务）的功能，其目标就是要赋予OpenStack提供这种云域名系统的能力，云服务商可以使用Designate就能够很容易建造一个云域名管理系统来托管租户的公有域名。
- Freezer:openstack环境中的数据备份一直存在着众多痛点，影响了openstack备份，1 novaCinder备份方式存在不一致性2备份数据不方便统一的管理 3无法进行有效的周期性备份4没有好的备份链管理5对旧备份的删除不智能。openstack环境数据备份中急需一套好的备份方案，而freezer在解决上述问题中也有较好的表现，Freezer是一套开源的备份软件， 它能帮助你自动的进行数据备份和还原动作。旨在为OpenStack提供数据备份环境的解决方案。Freezer从OpenStack Liberty 版本开始引入支持，以前的版本支持需要做微量的修改。解释了Freezer已经是OpenStack的一套数据备份的解决方案，Freezer具体可以做哪些工作： （1）BackupJob数据备份：主要用于数据的备份任务，FS：基于文件的数据备份，Mysql：对Mysql数据库进行有效的备份 .MongoDB:对MongoDB数据库进行有效的备份 4SQL Server：对Microsoft sql server数据库进行有效备份 5OpenStack novainstance(nova):对OpenStack云主机进行备份 6OpenStack Cinder volume(Cinderor Cindernative):对 Openstack云硬盘进行备份。目前Freezer对云银盘的备份主要有两种方式1Freezer自主的一套对云硬盘的备份机制(Cinder) 2Freezer编排Cinder Backup的方式进行备份(Cindernative) Resotre Job数据还原：数据的还原任务 AdminJob:备份数据管理：对备份数据的管理， 主要用户整理备份链以及旧备份的删除任务。 ExecJob命令以及脚本的执行：执行命令以及脚本。
- 额外特性： 1多平台支持 2备份数据的多存储支持 3备份数据的一致性笑颜 4备份数据的压缩以及加密 5备份数据可支持增量全量 6备份数据的上传带宽的限速 7对备份链的整理
Freezer的不足之处
1． Freezer 社区开发人员目前过少
2． 数据备份尚未对Ceph支持
3． 目前还无法对OpenStack进行整体的备份
4． 对计算节点的服务进行监控，保护业务的不间断性
- Karbor ：是OpenStack中提供应用数据保护服务的项目，让各个厂商的数据保护软件通过标准接入到openstack,为OpenStack提供增强的备份，复制，迁移等数据保护即服务(Data Protection as a Service)能力Karbor致力于解决虚拟机备份难，无标准备份接口的现状，云平台数据保护对客户而言至关重要，OpenStack的开放性允许不同厂商的虚拟化平台软件可以直接接入，但这种开放性也导致了异构平台很难统一进行数据保护，现有的数据保护方式都是以各个厂商的虚拟化平台为核心。http://baijiahao.baidu.com/s?id=1570103341544166&wfr=spider&for=pc
- Kuryr ：容器近几年非常流行,有很多项目都考虑将容器与SDN结合。Kuryr就是其中一个项目。Kuryr项目在OpenStackbigtent下,目的是将容器网络与openstackNeutron对接
- Magnum :Magnum是OpenStack中一个提供容器集群部署的服务。Magnum时一个Pass层的OpenStack项目 3 Magnum使用Heat部署一个包含docker和kubernetes的操作系统镜像。让容器集群运行在虚拟机(Virtual Machine)或者裸机中
- Manila；
OpenStack共享文件系统服务（manila）为虚拟机提供文件存储。共享文件系统服务提供了一个管理和配置文件共享的集合。该服务还支持共享类型的管理以及支持共享快照，前提是需要驱动程序支持。共享文件系统服务由以下组件组成：manila-api验证请求并将其路由到共享文件系统服务的WSGI应用程序。manila-data一个独立的服务，其目的是处理数据操作，如复制，共享迁移或备份。manila-scheduler安排和路由请求到适当的共享服务。调度程序使用可配置的过滤器和计量器来路由请求。筛选计划程序是默认筛选器，可在后端的各种属性（如容量，可用区和其他功能）上启用筛选。manila-share管理提供共享文件系统的后端设备。manila共享服务通过使用共享后端驱动程序作为接口与后端设备进行通信。共享驱动程序可以以两种模式之一运行，无论是否处理共享服务器。共享服务器通过共享网络导出文件共享。共享文件系统服务中的共享服务器不由驱动程序管理时，网络要求应该在共享文件系统服务的带外处理。Messaging queue在共享文件系统进程之间路由信息。
- Mistral :Mistrial是mirantis公司为openstack开发的工作流组件，提供WorkFlow as a service。 典型的用户用例包括云平台的任务计划服务（Cloud Cron），任务调度（Task Scheduling）， 复杂的运行时间长的业务流程服务。目前项目还在开始阶段。
Murano
Murano是Mirantis贡献的，并且也进了OpenStack Namespace。也和K8S集成了，用户可以通过Murano使用K8S的功能，可以通过Murano部署Pod、Service、Replication Controller等。Murano主要是在OpenStack基础上提供应用目录服务。Muarno和Solum之间其实是有关系的，Solum主要是用来开发应用的，Solum把应用开发完后，可以通过Murano来发布。用户可以通过Murano挑选自己需要的应用服务，通过应用服务组合构建自己的应用。
Murano也是通过Heat部署应用，Kubernetes和Murano集成之后，现在K8S也已经成为Murano的一个应用服务了。
图9所示是Murano的一个工作流，可以看到它的使用很简单。首先创建用户的应用环境，然后为应用环境添加应用服务，接下来部署应用环境，应用环境会通过OpenStack的Heat来部署。
- Octavia;octavia自kilo版本从neutron lbaas项目中分离出来，通过管理一系列amphora(vm、containers, or bare metal servers)来完成负载均衡的功能。其框架结构也是一个典型的openstack项目框架。api作为项目入口，rpc来作为组内模块之间通信的中介，controller及数据库来保证数据存储及一致性，使用功能实现使用driver来保证能够实现兼容性。
- Panko: Panko负责Event数据存储
- Rally : 性能测试工具，tempest集成功能测试
- Searchlight :为各种OpenStack云服务极大地提高了用户的搜索能力和性能。 它通过将用户搜索查询从现有的API服务器上卸载并将其数据建立索引以实现这一点。弹性搜索是基于Lucene的搜索服务器。它提供了一个分布式的、可伸缩的、接近实时的、面向方面的、支持多租户的全文搜索引擎，具有RESTful web界面和无模式的JSON文档。在Apache许可的条件下，弹性搜索作为开放源码开发并发布
- Senlin ：
把OpenStack中同类对象的集合称为集群（Cluster）。集群由节点（node）组成。同一集群内的每个节点都是用相同的Profile创建出来的。注意，这里的节点和集群都是抽象对象（Object），具体是什么可通过插件（Plugins）进行定制和扩展。比如，早期的Senlin版本中，node只支持Nova Server（即Nova创建的VM）和Heat Stack（即通过Heat部署的包含计算存储和网络的一系列资源）。今年新增加对docker的支持，即node可以是一个Container。后续可能还会增加对裸机的管理，基于Ironic来实现。
除Profile可扩展外，对集群和节点进行管理的策略（Policy）也支持扩展（同样基于Plugins机制）。目前Senlin项目中已经支持的策略主要包括：部署（包括region级和zone级）、删除、扩容、负载均衡、健康管理等
- Solum :
该项目聚焦于在OpenStack IaaS平台上，构建PaaS层的持续集成/持续交付（CI/CD）应用，可以简单理解为是一个应用程序App的集成开发平台，当然，它可以做很多事情。Murano是一个App Store（应用存储）服务，而Solum可以将开发的应用程序App发布到Murano中。
它可以实现公有云、私有云或异构云之间的应用可移植性（究其本质是将应用服务docker容器化，而docker可以无差别的运行在异构环境中）；通过OpenStack的编排服务Heat实现跨开发者、跨测试、跨生产环境地简化应用程序生命周期管理；集成Git、Jenkins/GitHub持续集成以及集成各种开发环境，如Eclipse、IntelliJ、Komodo等。
- 对于开发人员：通过一个自动化的CI/ CD流程，提供一个易于使用和快速开发应用的OpenStack环境。
- 对于发布管理：通过支持不同的环境（dev、test、staging、prod）和权限（即谁可以部署到prod），提供简化应用程序生命周期管理的能力。
- Tacker:Tacker是一个在OpenStack内部孵化的项目, 他的作用是NVF管理器，用于管理NVF的生命周期。 Tacker的重点是配置VNF, 并监视他们。如果需要，还可重启和/或扩展（自动修复）NVF。整个进程贯穿ETSIMANO所描述的整个生命周期。
- Trove:数据库服务
- Vitrage：
Vitrage是openstack里面提供根因分析(RCA)服务的组件。
用来组织、分析和扩展openstack的告警和事件，对问题产生的根本原因进行推导，为系统产生推导后的告警或者设置推导后的状态。
- Vmtp
- Watcher:Watcher提供一个完整的优化循环链：从度量接收器，到优化处理器和操作计划应用程序。Watcher的目标在于提供一个强大的框架，可以实现广泛的云优化目标，包括减少数据中心运营成本，通过智能虚拟机迁移提高系统性能，提高能源效率等。此外，Watcher可供用户定制丰富的资源优化目标与策略算法。
- Zun: Zun是Openstack中提供容器管理服务的组件,
基础架构组件
- Cinder，Glance和Nova的Ceph实施。
- Collectd， Telegraf， InfluxDB， Prometheus和 Grafana进行性能监控。
- Elasticsearch和 Kibana搜索，分析和可视化日志消息。
- Etcd是一个分布式可靠的键值存储。
- Fluentd作为统一日志记录层的开源数据收集器。
- Gnocchi时间序列存储数据库。
- HAProxy和 Keepalived以实现高可用性的服务及其端点。
- MariaDB和Galera集群 提供高度可用的MySQL数据库。
- Memcached分布式内存对象缓存系统。
- MongoDB作为Ceilometer和Gnocchi的数据库后端。
- 为Neutron 打开vSwitch和Linuxbridge后端。
- RabbitMQ作为服务之间通信的消息传递后端。
- Redis是内存数据结构存储。
Kolla-Ansible为以下基础架构组件部署容器：