OpenStack既是一个社区，也是一个项目和一个开源软件，提供开放源码软件，建立公共和私有云，它提供了一个部署云的操作平台或工具集，其宗旨在于：帮助组织运行为虚拟计算或存储服务的云，为公有云、私有云，也为大云、小云提供可扩展的、灵活的云计算。OpenStackd开源项目由社区维护，包括OpenStack计算（代号为Nova），OpenStack对象存储（代号为Swift），并OpenStack镜像服务（代号Glance）的集合。 OpenStack提供了一个操作平台，或工具包，用于编排云。
OpenStack是一个开源的云计算管理平台项目，是一系列软件开源项目的组合。由NASA(美国国家航空航天局)和Rackspace合作研发并发起，以Apache许可证（Apache软件基金会发布的一个自由软件许可证）授权的开源代码项目。
OpenStack 支持 KVM、Xen、Lvc、Docker 等虚拟机软件或容器，默认为 KVM。通过安装驱动，也支持 Hyper-V 和 VMware ESXi，不过有些功能暂时不支持。
OpenStack 采用 Python 语言开发，遵循 Apache 开源协议，因此相比 CloudStack 来说，更轻量化，效率更高。
Openstack是一个云平台管理的项目，它不是一个软件。这个项目由几个主要的组件组合起来完成一些具体的工作。Openstack是一个旨在为公共及私有云的建设与管理提供软件的开源项目。它的社区拥有超过130家企业及1350位开发者，这些机构与个人将 Openstack作为基础设施即服务资源的通用前端。Openstack项目的首要任务是简化云的部署过程并为其带来良好的可扩展性。本文希望通过提供必要的指导信息，帮助大家利用 Openstack前端来设置及管理自己的公共云或私有云。
Openstack是由 Rackspace和NASA共同开发的云计算平台，帮助服务商和企业内部实现类似于 Amazon ec2和S3的云基础架构服务( Infrastructure as a Service)。 Openstack包括两个主要模块:Nova和 Swift。前者是NASA开发的虚拟服务器部署和业务计算模块;后者是 Backpack开发的分布式云存储模块，两者可以一起用，也可以分开单独用。 Openstack是开源项目，除了有 Rackspace和NASA的大力支持外，后面还有包括Dell、 Citrix、 Cisco Canonical这些重量级公司的贡献和支持，发展速度非常快，有取代另一个业界领先开源云台 Eucalyptus的态势。
基于互联网的相关服务的增加、使用和交付模式
这种模式提供可用的、便捷的、按需的网络访问,迚入可配置的计算资源共享池
这些资源能够被快速提供,只需投入很少的管理工作,戒不服务供应商迚行很少的交互
通常涉及通过互联网来提供劢态易扩展且经常是虚拟化的资源
云计算服务模型
IaaS是Infrastructure as a server的缩写，意思是基础设施即服务。云端公司把IT环境的基础设施建设好，然后直接对外出租硬件服务器或者虚拟机。消费者可以利用所有计算基础设施，包括处理CPU、内存、存储、网络和其它基本的计算资源，用户能够部署和运行任意软件，包括操作系统和应用程序。消费者不管理或控制任何云计算基础设施，但能控制操作系统的选择、存储空间、部署的应用，也有可能获得有限制的网络组件（例如路由器、防火墙、负载均衡器等）的控制。如下图所示：
云端公司一般都会有一个自助网站，用户可以向云端公司签订租赁协议以获取一个账号，登录之后可以管理自己的计算设备：开关机、安装操作系统、安装应用软件等。
Iaas优缺点：
IaaS型租用方式对用户来说优点很明显，就是非常灵活，也是自由度最大的一种类型。用户可以决定安装什么操作系统，以及是否需要安装或者安装什么类型的数据库，安装什么软件等等。就像自己买了台电脑，如何使用是你全权做主。
不过缺陷也很明显，除了管理维护量大之外，还有一个缺陷就是：计算资源严重浪费。操作系统、数据库以及中间件本身就要消耗大量的计算资源，而这些消耗对于租户而已是必须的但是又是无用的，因为用户只是想要运行软件。
PaaS是Platform as a Server的缩写，意思是平台即服务，即把运行用户所需的软件的平台作为服务出租。如下图所示：
云端公司要做事情就是运行软件所需要的下7层部署完毕，然后再PssS上划分小块（习惯称之为容器）对外出租，租户只需要安装和使用软件就可以了。
平台软件层包括操作系统、数据库、中间件和运行库，但是并不是每一个软件都需要这4部分的支持，需要什么是由软件决定的。所以PaaS又分为2种，半平台PaaS和全平台PaaS。
1、半平台PaaS：只安装操作系统，其他的租户自己去解决。这样会比较麻烦，因为你需要有较强的技术实力，而且需要耗费部分资源去安装软件运行需要的、的中间件、运行库、数据库。
2、全平台PaaS：安装应用软件依赖的全部平台软件，也就是4部分全部准备完毕。不过大家也知道，世界上的应用软件如此庞大，支撑他们的语言、数据库、中间件、运行库可能都不一样，PaaS云端公司不可能全部都去安装，所以他们支持的软件是有限的。
相对于IaaS来说，PaaS租户的灵活性降低了，只能在云端提供的有限平台范围内做软件，但是优点也很明显，能够最大化利用租用的资源和不需要租户有高深的IT技术。
SaaS是Software as a Server的缩写，意思是软件即服务。把软件租出去，用户连安装都不需要了。同样来看图：
对比PaaS略微有一点不同，应用软件是云端公司来安装、运维的，租户使用软件，需要管理的是这些软件产生的数据信息。
一般来说SaaS适用的软件都有如下的特点：
（1）复杂：软件庞大、安装复杂、使用复杂、运维复杂，单独购买架构昂贵，例如ERP、CRM、BI等。
（2）模块化：按功能模块划分，需要什么功能就组什么模块。
（3）多租户：多个企业用户同时操作，使用同一个软件而不是互相干扰。当然，数据是逻辑隔离的，不同用户的数据检索字段之一必然是用户身份信息。
（4）多币种多语言多时区的支持
DaaS是Date as a Server的缩写，意思是数据即服务。云端公司负责建立全部的IT环境，收集用户需要的基础数据并且做数据分析，最后对分析结构或者算法提供编程接口，让数据成为服务。
如图：
DaaS是大数据时代的象征，能做DaaS服务的云端公司需要从数据积累、数据分析和数据交付三方面积累自身的核心竞争力。
Openstack项目虽然诞生时间不长,但其发展之迅速,在云计算领域的影响力扩展,使得这个年轻的项目成为业内所有人都不得不关注的焦点。
2010年 Openstack项目成立。该项目由美国国家航空航天局(NASA)和 Rackspace合作研发, Apache许可证开源目前为止共有以下版本:
1.Austin——Openstack发布的第一个版本,这是第一个开源的云计算平台。
2.Bexar——Openstack发布的第二个版本,添加了IPv6的支持、影像传递技术,以及Hyper-V和Xen等虚拟服务器功能。
3. Catus——Openstack发布的第三个版本,添加了虚拟化功能、自动化功能以及一个服务目录。
4. Diablo——Openstack发布的第四个版本,增加了新的图形化用户界面和统一身份识别管理系统。
5. Essex——Openstack发布的第五个版本,完善了 Keystone认证,删除了对 Windows Hyper-V支持的相关代码。
6.Folsom——2012年9月 Open Stack发布的第六版。 Folsom包括了 Nova swift、 Horizon Keystone、 Glance原有的五个子项目之外,又多增 Quantum和 Cinder两项。 Quantum支持了数个现有的虚拟网络套件,如 Open vSwitch、Ryu网络操作系统( Network Operation System,NOS)等,也包括了 Cisco、 Nicira和NEC等厂商提供的虚拟网络套件等, Quantun可以让Open Stack的IaS平台能采用软件定义网络( Software Defined network,SDN)的技术,如OrperFlow。Cinder则加强了区块( Block)与磁盘区( Volume)的储存能力。
7.Grizly——2013年4月Open Stack基金会发布的第七个版本。 Grizzly新增近230个新功能,涉及计算、存储、网络和共享服务等方面。例如 Open Stack计算虚拟化-计算使用“Cells”管理分布式集群,使用“NoDB”主机架构,以减少对中央数据库的依赖。
8.Havana——2013年10月 Open Stack基金会发布的第八个版本。 Havana除了增加Open Stack Metering( Ceilometer)和 Open Stack Orchestration(Heat)两个新组件外,还完成了400多个特性计划,修补了3000多补丁。
9. Icehouse——2014年4月 Open Stack基金会发布的第九个版本。新版本提高了项目的稳定性与成熟度,提升用户体验的一致性,特别是针对存储方面。联合身份验证将允许用户通过相同认证信息同时访问 Open Stack私有云与共有云。新项目 Trove( DB as a service)现在已经成为版本中的组成部分,它允许用户在 Open Stack环境中管理关系数据库服务。
10.Juno——2014年10月 OpenStack基金会发布的第十个版本。新增包括围绕 Hadoop和 Spark集群管理和监控的自动化服务和支持软件开发、大数据分析和大规模应用架构在内的342个功能点,标志着 Open Stack正向大范围支持的成熟云平台快速前进。自 Openstack项目成立以来,超过200个公司加入了该项目,其中包括AT&T、AMD、 Cisco、Dell、IBM、 Intel、 Red hat等。目前参与 Openstack项目的开发人员有17000,来自139个国家,这一数字还在不断增长中。来自咨询机构 Forrester的分析表示, OpenStack已经逐步成为事实上( de facto)的基础架构云(IaaS)标准。
尽管 Open Stack从诞生到现在已经变得日渐成熟，基本上已经能够满足云计算用户的大部分的需求。但随着云计算技术的发展， Open Stack必然也需要不断地完善。Open Stack已经逐渐成为市场上主流的一个云计算平台解决方案。结合业界的一般观点和调查中关于 Open Stack用户的意见， Open Stack需要完善的部分大体上可以归纳为以下几个方面:
(1)增强动态迁移:虽然 Open Stack的Nova组件支持动态迁移，但实质上 Open Stack尚未实现真正意义上的动态迁移。在 Open Stack中因为没有共存储只能做块迁移，共享迁移只能在有共享存储的情况下才被使用。
(2)数据安全:安全问题一直是整个云计算行业的问题，尽管 Open Stack中存在对用户身份信息的验证等安全措施，甚至划分出可以单独或合并表征安全信任等级的域，但随着用户需求的变化和发展，安全问题仍然不可小觑。
计费和数据监控:随着 Open Stack在公有云平台中的进一步部署，计费和监控成为公有云运营中的一个重要环节。云平台的管理者和云计算服务的提供者必然会进一步开发Open Stack的商业价值。尽管 Open Stack中已经有 Ceilometer计量组件，通过它提供的API接口可以实现收集云计算里面的基本数据和其他信息，但这项工程目前尚处于完善和测试阶段，还需要大量的技术人员予以维护和支持。
Open Stack的各个服务之间通过统一的REST风格的API调用，实现系统的松耦合。它内部组件的工作过程是一个有序的整体。诸如计算资源分配、控制调度、网络通信等都通过AMQP实现。 Open Stack的上层用户是程序员、一般用户和 Horizon界面等模块。这三者都是采用 Open Stack各个组件提供的API接口进行交互，而它们之间则是通过AMQP进行互相调用，它们共同利用底层的虚拟资源为上层用户和程序提供云计算服务。
OpenStack既然是一个开源的云平台项目，它的主要任务是给用户提供IaaS服务。
QEMU是一个纯软件的计算机硬件仿真器。通过单独运行QEMU来模拟物理计算机，具有非常灵活和可移植的特点，利用它能够达到使用软件取代硬件的效果。
一般情况下，OpenStack可以部署在Ubuntu的Linux操作系统上，为了进一步提高QEMU的运行效率，往往会增加一个KVM硬件加速模块。KVM内嵌在Linux操作系统内核之中，能够直接参与计算机硬件的调度，这一点是QEMU所不具备的。一般的QEMU程序的执行必然要经过程序从用户态向内核态的转变，这必然会在一定程度上降低效率。所以QEMU虽然能够通过转换对硬件进行访问，但在OpenStack中往往采用KVM进行辅助，使得OpenStack的性能表现得更为良好。
但需要说明的是KVM需要良好的硬件支持，有些硬件本身如果不支持虚拟化的时候，KVM则不能使用。
Libvirt是一个开源的、支持Linux下虚拟化工具的函数库。实质上它就是为构建虚拟化管理工具的API函数。Libvirt是为了能够更方便地管理平台虚拟化技术而设计的开放源代码的应用程序接口，它不仅提供了对虚拟化客户机的管理，也提供了对虚拟化网络和存储的管理。
最初的 Libvirt是只针对Xen而设计的一系列管理和调度Xen下的虚拟化资源的API函数，目前高版本的 Libvirt可以支持多种虚拟化方案，包括KVM、QEMU、Xen、 VMware、 VirtualBox等在内的平台虚拟化方案，又支持 Openvz、LXC等 Linux容器虚拟化系统，还支持用户态Linux(UML)的虚拟化，它能够对虚拟化方案中的Hypervisor进行适配，让底层 Hypervisor对上层用户空间的管理工具可以做到完全透明。
模块松耦合：与其他开源软件相比，OpenStack模块分明。添加独立功能的组件非常简单。有时候，不需要通读整个OpenStack的代码，只需要了解其接口规范及API使用，就可以轻松地添加一个新的模块
控制性：完全开源得平台，提供API接口，方便与第三方技术集成
兼容性：OpenStack兼容其他公有云，方便用户进行数据迁移
可扩展性：模块化设计，可以通过横向扩展，增加节点、添加资源
灵活性：OpenStack也需要不同的组件。但是OpenStack的组件安装异常灵活。根据自己得需要建立相应基础设施、增加集群规模。
二次开发容易：OpenStack发布的OpenStack API是Rest-full API。其他所有组件也是采种这种统一的规范。因此，基于OpenStack做二次开发，较为简单。而其他3个开源软件则由于耦合性太强，导致添加功能较为困难。
行业标准：众多IT领军企业已经加入到OpenStack项目
OpenStack覆盖了网络、虚拟化、操作系统、服务器等各个方面。它是一个正在开发中的云计算平台项目，根据成熟及重要程度的不同，被分解成核心项目、孵化项目，以及支持项目和相关项目。每个项目都有自己的委员会和项目技术主管，而且每个项目都不是一成不变的，孵化项目可以根据发展的成熟度和重要性，转变为核心项目。以下为各项核心项目的解释：
Congress（策略服务）
Designate（DNS 服务）
Freezer（备份及还原服务）
Magnum（容器支持）
Mistral（工作流服务）
Monasca（监控服务）
Searchlight（索引和搜索）
Senlin（集群服务）
Solum（APP集成开发平台）
Tacker（网络功能 虚拟化）
Trove（数据库服务）
OpenStack是由一系列具有RESTful接口的Web服务所实现的，是一系列组件服务集合。如下图为OpenStack的概念架构，我们看到的是一个标准的OpenStack项目组合的架构。这是比较典型的架构，但不代表这是OpenStack的唯一架构，我们可以选取自己需要的组件项目，来搭建适合自己的云计算平台，设计的基本原则如下：
按照不同的功能和通用性来划分不同项目并拆分子系统
按照逻辑计划、规格子系统之间的通信
通过分层设计整个系统架构
不同的功能子系统间提供统一的API接口
架构图详解：
上图的核心为虚拟机，所有组件围绕虚拟机，为它提供服务。可将上图的架构分为三个部分：
全局组件：
keystone：为所有服务模块提供认证与授权
ceilometer：度量、监控所有数据资源
horizon ：UI平台管理，提供一个web管理页面，与底层交互
外部辅助组件：
ironic 提供裸金属环境
trove 提供管理数据库服务（控制关系型和非关系型数据库）
heat，sahara 提供对数据管理和编排
内部核心组件：
glance：提供镜像服务
neutron：提供网络服务
swift：提供对象存储资源
cinder：提供块存储资源
nova：管理实例的生命周期，并负责调取以上四个资源给虚拟机使用。
具体流程：
云平台用户在经过Keystone服务认证授权后，通过Horizon或者Reset API模式创建虚拟机服务，创建过程中包括利用Nova服务创建虚拟机实例，虚拟机实例采用Glance提供镜像服务，然后使用Neutron为新建的虚拟机分配IP地址,并将其纳入虚拟网络中，之后在通过Cinder创建的卷为虚拟机挂载存储块,整个过程都在Ceilometer模块资源的监控下，Cinder产生的卷(Volume)和Glance提供的镜像(Image) 可以通过Swift的对象存储机制进行保存。
如上图所示，OpenStack由几个独立的部分组成，成为OpenStack服务。所有服务都是通过身份服务进行身份验证。各个服务通过公共API相互交互，除非需要特权管理员命令。
在内部，OpenStack服务由几个进程组成，所有服务至少有一个API进程，它监听API请求，预处理它们并将它们传递给其他部分。除身份服务外，实际工作由不同的流程完成。
对一个服务进程之间的通信，使用AMQP消息代理。服务的状态存储在数据库中。在部署和配置OpenStack云时，您可以选择多种消息代理和数据库解决方案，例如RabbitMQ，MySQL、MariaDB和SQLite。
用户可以通过Horizon Dashboard实现基于Web用户界面，命令行客户端以及通过浏览器插件或curl工具法术API请求来访问OpenStack。对于应用程序，可以使用多SDK。最终，所欲这些访问方法都会向各种OpenStack服务发出REST API调用。
glance：提供镜像服务
neutron：提供网络服务
swift：提供对象存储资源
cinder：提供块存储资源
以上四个核心组件将各种的功能传递给nova，再由noca传递给虚拟机
附加：
消息队列
常用的三种类型，包括rabbitmq、 rocketmq、kafka，是两个独立的服务之间，消息传递的载体，解决消息在传输是请求的高并发问题，会以容器的方式，存储消息列表（包括请求、交互、报文），划分重要等级放入队列中，逐个处理，处理完的会自动删除。
通过分层设计整个系统架构
不同的功能子系统间提供统一的API接口
全局架构来看：OpenStack包括相互独立的服务组件。所有服务均可通过一个公共身份服务进行身份验证。除了那些需要管理权限的命令，每个服务之间均可通过公共API进行交互。所以，API即是每个服务内部和外部的交界处，隔离了内外。
服务之间交互过程：每个服务又由若干组件组成，包含多个进程。每个服务至少有一个API进程，用于侦听API请求，对这些请求进行预处理，（ 预处理就是将请求暴露出来的API接口，给keystone进行认证，如果认证通过，则放入队列等待被处理。） 然后将它们传送到自己服务后端的其他组件，对请求进行处理，而不是API进程去处理。也就是说除了认证服务，实际工作都是由具体的进程完成的。
服务内各个进程之间的通信：使用AMQP消息代理。服务的状态存储在数据库中。
总结：
分层角度:OpenStack包括若干个服务的独立组件，例如上图的核心组件以及一些可选组件，向nova、keystone、Horizon等，我们先去找到这些组件，然后再去分析下一层
每个组件里有各自的一些服务，所有服务都需要通过keystone进行身份验证，每个服务之间又可以关联若干个组件，每个服务至少有一个API进程，通过去监听API的请求，并对这些请求进行预处理，并将它们发送到相对于该服务的其他组件，服务之间可以通过公共API进行交互
服务之间的通信使用AMQP消息代理，将服务的状态信息存储在数据库中
OpenStack组件通信关系：
基于HTTP协议进行通信：通过各项目的API建立的通信关系，API都是RESTful Web API
基于SQL的通信：用于各个项目内部的通信
基于AMQP协议的通信：用于每个项目内部各个组件之间的通信
通过Native API实现通信：Openstack各组件和第三方软硬件之间的通信
附加：
超分：对这样的业务进行方案的规划，根据之前的超分的情况执行并发量，配置的增减，或者更改弹性伸缩的规则，最后定制应急预案。
整个OpenStack是由控制节点，计算节点，网络节点，存储节点，四大部分组成。（这四个节点也可以单机部署）
其中：
1.控制节点负责对其余几点的控制，包含虚拟机创建、迁移、网络分配、存储分配等等
控制节点架构：控制节点包括以下服务
管理支持服务
基础管理服务
扩展管理服务
1）管理支持服务包含数据库与消息代理服务
数据库作为基础/扩展服务产生的数据存放的地方
消息代理服务（也称消息中间件）为其他各种服务之间提供了统一的消息通信服务
2）基础管理服务包含Keystone、Glance、Nova、Neutron、Horizon五个服务
Keystone：认证管理服务、提供了其余所有组件的认证信息/令牌的管理、创建、修改等等、使用MySQL等数据库存储认证信息
Glance：镜像管理服务，提供了对虚拟机部署的时候所能提供镜像的管理、包含镜像的导入、格式以及制作相应的模板
Nova：计算管理服务，提供了对计算节点的Nova管理、使用Nova-API进行通信
Neutron：网络管理服务、提供了对网络节点的网络拓扑管理，同时提供Neutron在Horizon的管理界面
Horizon：控制台服务，提供了以Web形式对所有节点的所有服务的管理，通常把该服务成为Dashboard
3）扩展管理服务包含Cinder、Swift、Trove、Heat、Centimeter五个服务
Cinder：提供管理存储节点的Cinder相关、同时提供Cinder在Horizon中的管理面板
Swift：提供管理存储节点Swift相关、同时提供Swift在Horizon中的管理面板
Trove：提供管理数据库节点的Trove先关、同时提供Trove在Horizon中的管理面板
Heat：提供了基于模板来实现云环境中的资源的初始化，依赖关系处理，部署等基本操作，也可以解决自动收缩、负载均衡等高级特性
Centimeter：提供对物理资源以及虚拟资源的监控，并记录这些书库，读数据进行分析，在一定条件下出发现货供应动作
控制节点通常来说只需要一个网络端口来用于通信和管理各个节点
2.计算节点负责虚拟机运行
计算节点架构
计算节点包含Nova、Neutron、Telemter三个服务
1）基础服务
Nova：提供虚拟机的创建、运行、迁移、快照等围绕虚拟机的服务、并提供API与控制节点对接、由控制节点下发任务
Neutron：提供计算节点与网络节点之间的通信
2）扩展服务
Telmeter:提供计算节点监控代理、将虚拟机的情况反馈的控制节点，是Centimeter的代理服务
计算节点包含最少两个网络端口
端口1：与控制节点进行通信，受控制节点统一调配
端口2：与网络节点，存储节点进行通信
3.网络节点负责对外网络与内网之间的通信
网络节点架构
网络节点仅包含Neutron服务
Neutron：负责管理私有网络与公有网络的通信，以及管理虚拟机网络之间通信/拓扑、管理虚拟机之上的防火墙等等
网络节点包含三个网络端口
端口1：用于与控制节点进行通信
端口2：用于除了控制节点之外的计算/存储节点之间的通信
端口3：用于外部的虚拟机与相应的网络之间通信
4.存储节点负责对虚拟机的额外存储管理等等
存储节点架构
存储节点包含Cinder，Swift等服务
Cinder：块存储服务，提供相应的块才能出，简单来说，就是虚拟出一块存盘，可以挂载到相应的虚拟机之上，不收文件系统的影响，对虚拟机来说，这个操作像是加了一块硬盘，可以完成对磁盘的任何操作，包括挂载、卸载、格式化，转换文件系统等等操作，大多应用于虚拟机空间不足的情况下的空间扩容等。
Swift：对象存储服务，提供相应的独享存储、简单来说，就是虚拟出一块磁盘空间，可以在这个空间当中存放文件，也仅仅只能存放文件，不能进行格式化，转换文件系统，大多应用于云磁盘/文件
存储节点包含最少两个网络端口
端口1：与控制节点进行通信，接受控制节点任务，受控制节点统一调配
端口2：与计算/网络节点进行通信，完成控制节点下发的各类任务
网络节点(Network Node)
提供者网络(Provider networks)
自服务网络(Self-service networks)
网络节点通常需要3个网络端口，分别用于与控制节点进行通信、与除控制节点之外的计算和存储节点之间的通信、外部的虚拟机与相应网络之间的通信
Nova是OpenStack计算的弹性控制器。OpenStack云实例生命期所需要的各种动作都将由Nova进行处理和支撑，这就意味着Nova以管理平台的身份登场，负责管理整个云的计算资源，网络、授权及测读。虽然Nova本身并不提供任务虚拟能力，但是它将使用libvirt API与虚拟机的宿主机进行交互。Nova通过Web服务API来对外提供处理接口，而且这些接口与Amazon的Web服务接口是兼容的。
Nova它提供了一种配置计算实例（即虚拟服务器）的方法。Nova支持创建虚拟机、裸机服务器，并且对系统容器的支持有限。Nova在现有linux服务器之上作为一组守护进程运行，已提供该服务。
它需要以下额外的OpenStack服务来实现基本功能：
Keystone：这是为OpenStack服务提供身份和身份验证
Glance：这提供了计算镜像存储库。所有计算实例都是从Glance镜像启动的。
Neutron：他负责提供计算机实例在引导时连接到的虚拟或物理网络。
Nova主要功能包括：
实例生命周期管理
计算资源的管理
向外提供REST风格的API
这三个组件组件通过消息中间件传输通信
Nova包含以下主要部分：
API Server（nova-api）位于表示层。用于接受外部请求
消息队列服务（Rabbit MQ）
运算工作站（nova-comoute）负责虚拟机的创建和分配
网络控制器（nova-network）
卷管理（nova-volume）
调度器（nova-scheduler）调度如何选择哪个主机创建VM
详细说明：
1）API服务（nova-api）
API服务提供了云设施与外界交互的接口，它是外界用户对云实施管理的唯一通道。通过使用Web服务来调用各种EC2的API，接着API服务便通过消息队列把请求发送达至云内目标实施进行出路。作为对EC2-api的替代，用户也可以使用OpenStack的原生API，我们把它叫做"OpenStack API".
2)消息队列（Rabbit MQ ）
OpenStack内部在遵循AMQP（高级消息队列协议）的基础上采用消息队列进行通信，Nova对请求应答进行异步调用，当请求接受后立即出发一个回调。由于使用了异步通信，不会有用户的动作被长置于等待状态。例如，启动一个实例或上传一个镜像的过程较为耗时，API调用就将等待返回结果而不影响其他操作，在此异步通信起到了很大作用，使整个系统变得更加高效。
3）调度器（nova-scheduler）
调度器负责把nova-API调用送达给目标。调度器以名为"nova-schedule"的守护进程方式运行，并根据调度算法从可用资源池恰当的选择运算服务器。有很多因素都可以影响调度结果，比如负责、内存、、子节点的远近，CPU架构等等。强大的nova调度器采用的是可插入式架构。
目前nova调度器使用了几种基本的调度算法：
随机化：主机随机选择可用的节点；
可用化：与随机相似，只是随机选择的范围被制定；
简单化：应用这种方式，主机选择负载最小者来运行实例。负载均衡数据可以从别处获得，如负载均衡服务器。
4）运算工作站(nova-compute)
运算工作站的主要任务是管理实例的整个生命周期。他们通过消息队列接受请求并执行，从而对实例进行各种操作。在典型实际生产环境中，会架设许多运算工作站，根据调度算法，一个实例可以在可用的任意一台运算工作站上部署。
5）网络控制器（nova-network）
网络控制器处理主机的网络配置，例如IP地址分配，配置项目VLAN，设定安全群组以及为计算节点配置网络。
6）卷工作站（nova-volume）
卷工作站管理基于LVM的实例卷，它能够为一个实例创建、删除、附加卷、也可以从一个实例中分离卷。卷管理为何如此重要？因为它提供了一中保持实例持续存储的手段，比如当结束一个实力后，根分区如果是非持续化的，那么对其的任何改变都将丢失。可是。如果从一个实例中将卷分离出来，或者为这个实例附加上的卷的话，及时实例被关闭，数据仍保存其中。这些数据可以通过将卷附加到原实例或其他实例的方式而重新访问。
因此，为了日后访问，重要数据必要写入卷中。这种应用对于数据服务器实例的存储而言，尤为重要。
Keystone(OpenStack ldentity Service）是OpenStack中的一个独立的提供安全认证的模块，主要负责openstack用户的身份认证、令牌管理、提供访问资源的服务目录、以及基于用户角色的访问控制。
Keystone类似一个服务总线，或者说是整个Openstack框架的注册表，其他服务通过keystone来注册其服务的Endpoint(服务访问的URL)，任何服务之间相互的调用，需要经过Keystone的身份验证，来获得目标服务的Endpoint来找到目标服务。
附加：
URL和URI
简单的理解
URL：具体的路径
URI：类型标识
Keystone身份服务
身份认证：负责令牌的发放和校验
用户授权：授权用户有指定的可执行动作的范围
用户管理：管理用户的账户
服务目录：提供可用服务的API端点位置
Keystone的管理对象
Keystone服务贯穿整个架构，在进行身份认证服务的整个流程中，有几个重要的概念。
用户（user）：指的是使用openstack架构的用户。
证书（credentials）：用于确认用户身份的凭证，证明自己是自己，包括用户的用户名和密码，或是用户名和API密钥，或者身份管理服务提供的认证令牌。
认证（authentication）：确定用户身份的过程。
项目（project）：可以理解为一个人，或服务所拥有的资源的集合。
角色（role）：用于划分权限，通过给user指定role，使user获得role对应操作权限
服务（service）：openstack架构的组件服务，如nova、neutron、cinder、swift、glance等。
令牌（token）：由字符串表示，作为访问资源的凭证，是用户的身份/权限证明文件；
token决定了用户的权限范围，在指定的权限内进行操作；也包括令牌的有效期，在指定的时间范围内用户才有这些权限。
端点（endpoint）：一个可以通过网络来访问和定位某个openstack service的地址，即用户创建一个项目过程中需要的各个服务资源的位置
Keystone相关概念
Keystone (OpenStack Identity Service)是OpenStack中的一个独立的提供安全认证的模块，主要负责openstack用户的身份认证、令牌管理、提供访问资源的服务目录、以及基于用户角色的访问控制。
Keystone类似一个服务总线，或者说是整 个Openstack框架的注册表,其他服务通过keystone来注册其服务的Endpoint (服务访问的URL)，任何服务之间相互的调用，需要经过Keystone的身 份验证，来获得目标服务的Endpoint来找到目标服务。
Credentials:用于确认用户身份的凭证。用户的用户名和密码，或者是用户名和APl密钥，或者身份管理服务提供的认证令牌。
Service: Openstack service，即Openstack中运行的组件服务。如nova、swift、glance、neutron、cinder等。
Endpoint:一个可以通过网络来访问和定位某个Openstack service的地址，通常是一个URL。
Keystone采用两种授权方式，一种基于用户名/密码，另一种基于令牌（Token）。
除此之外，Keystone提供一下三种服务：
令牌服务：含有授权用户的授权信息
目录服务：含有用户合法操作的可用服务列表
策略服务：利用Keystone具体制定用户或群组某些访问权限
Keystion认证服务注意点：
服务入口：如Nova、Swift和Glance一样每个OpenStack服务都拥有一个制定的端口和专属的URL，我们称其为入口（endpoints）。
区位：在某个数据中心，一个区位具体制定了一处物理位置。在典型的云架构中，如果不是所有的服务都访问分布式数据中心或服务其的话，则也称其为区位。
用户：Keystone授权使用者
PS：代表一个个体，OpenStack以用户的形式来授权服务给它们。用户拥有证书（credentials），且可能分配个一个或多个租户。经过验证后，会为每个单独的租户提供一个特定的令牌。
服务：总体而言，任何通过Keystone进行连接或管理的组件都被称为服务。举个例子，我们可以称Glance为Keystone的服务
角色：为了维护安全限定，就云内特定用户可执行的操作而言，该用户关联的角色是非常重要的。
PS：一个角色是应用于某个租户的使用权限集合，以允许某个指定用户访问或使用特定操作。角色是使用权限的逻辑分组、它使得通过的权限可以简单的分组并绑定到与某个指定租户相关的用户。
租间：租间指的是具有全部服务入库并配有特定成员角色的一个项目。
PS：一个租间映射到一个Nova的"project-id",在对象存储中，一个租间可以有多个容器。根据不同的安装方式，一个租间可以代表一个客户、账号、组织或项目。
主要功能
Keystone简介
Keystone为所有的OpenStack组件提供认证和访问策略服务，它依赖资深REST（基于Identity API）系统进行工作主要对（单不限于）Swift、Glance、Nova等进行认证与授权。事实上，授权通过对动作消息来源者请求的合法性进行鉴定，下图显示了身份认证服务的流程：
Keystone工作流程（创建虚拟机的过程)
1.用户通过命令行或者horizon控制面板的方式登录openstack，凭借自己的证书（credentials）给keystone验证。
2.Keystone对用户的证书验证，验证通过则会发布一个令牌（token）和用户所需服务的位置点（endpoint）给用户。
3.用户得到了位置点（endpoint）之后，携带自己的令牌，向nova发起请求，请求创建虚拟机。
4.nova会拿着用户的token向keystone进行认证，看是否允许用户执行这样的操作。
5.keystone认证通过之后，返回给nova，nova即开始执行创建虚拟机的请求。首先需要镜像资源，nova带着令牌（token）和所需要的镜像名向glance提出镜像资源的请求。
6.glance会拿着token去向keystone进行认证，看是否允许提供镜像服务。keystone认证成功后，返回给glance。glance向nova提供镜像服务。
7.创建虚拟机还需要网络服务，nova携带token向neutron发送网络服务的请求
8.neutron拿着nova给的token向keystone进行认证，看是否允许向其提供网络服务。keystone认证成功后，返回给nuetron。nuetron则给nova提供网络规划服务。
9.nova获取了镜像和网络之后，开始创建虚拟机，通过hypervisior可调用底层硬件资源进行创建。创建完成返回给用户，成功执行了用户的请求。
概念
在早期的openstack版本中，glance只有管理镜像的功能，并不具备镜像存储功能，现在，glance已发至成为集镜像上传、检索、管理和存储等多功能的openstack核心服务。
镜像
镜像的英文名为Image，又译为映像，镜像通常指的是一系列文件或一个磁盘驱动的精确副本，将特定的一系列文件按照一定的格式制作成独立的文件，以方便用户的下载和使用。简单来说就是一系列资源/服务的集合，也可以作为模板创建多个同样的独立的副本。
镜像服务的功能
镜像服务主要是用来管理镜像，让用户能够发现、获取和保存镜像，主要功能如下：
查询和获取镜像的元数据和镜像本身（元数据：镜像的概要信息和描述信息）
注册和上传虚拟机镜像，包括镜像的创建、.上传、 下载和管理
维护镜像信息，包括元数据和镜像本身。
支持多种方式存储镜像，包括普通的文件系统、Swift、 Amazon S3等
对虚拟机实例执行创建快照命令来创建新的镜像，或者备份虚拟机的状态。
镜像的 API 版本
Glance提供的RESTful API有两个版本：V1,V2：
v1只提供基本的镜像和成员操作功能，包括镜像创建、删除、下载、列表、详细信息查询、 更新，以及镜像租户成员的创建、删除和列表。
v2除了支持v1的所有功能外，主要增加了镜像位置的添加、删除、修改，元数据和名称空间操作，以及镜像标记操作。
两个版本对镜像存储支持相同，v1从N版开始已经过时，迁移路径使用v2进行替代
镜像格式
虚拟机镜像文件磁盘格式
raw:无结构的磁盘格式（重要）： 特点：兼容性好，速度快
vhd:该格式通用于VMware、Xen、VirtualBox以及其他虚拟机管理程序
vhdx:vhd格式的增强版本，支持更大的磁盘尺寸
vmdk:一种比较通用的虚拟机磁盘格式
vdi:由VirtualBox虚拟机监控程序和QEMU仿真器支持的磁盘格式
iso:用于光盘(CD-ROM)数据内容的档案格式
ploop:由Virtuozzo支持，用于运行OS容器的磁盘格式
qcow2:由QEMU仿真支持，可动态扩展，支持写时复制(Copy on Write)的磁盘格式（重要）
aki:在Glance中存储的Amazon内核格式
ari:在Glance中存储的Amazon虚拟内存盘(Ramdisk)格式
ami:在Glance中存储的Amazon机器格式
Glance的常用管理命令
openstack image list：作用 查看已有镜像列表
openstack image show 镜像名 作用 查看镜像的详细信息
openstack image create --file 镜像文件名 --disk-format qcow2 --container-format bare --public centos7 生产一个qcow2格式的镜像，名字为centos7 作用 创建镜像
glance image-create --name “centos7” --file centos.img --disk-format raw --container-format bare --progress 作用 创建镜像并查看百分比进度
openstack image delete 镜像名 作用 删除镜像
openstack image create --file 镜像 --disk-format qcow2 --container-format bare --public 镜像名 作用 修改镜像格式（例如raw修改为qcow2）
qemu-img convert -f raw -O qcow2 centos7.img centos7.qcow2 作用 修改镜像格式（例如将裸格式镜像文件centos7.img转为qcow2格式）
镜像文件容器格式
bare:没有容器或元数据“信封”的镜像
ovf:开放虚拟化格式
ova:在Glance中存储的开放虚拟化设备格式
aki:在Glance中存储的Amazon内核格式
ari:在Glance中存储的Amazon虚拟内存盘（Ramdisk）格式
Docker:在Glance中存储的容器文件系统的Dockerd的tar档案
如果不能确定选择哪种容器格式，那么简单地容器格式指定为bare是安全
镜像状态
镜像从上传到识别的过程：
queued：初始化过程，镜像文件刚被创建，在Glance数据库只有其元数据，镜像数据还没有上传至数据库中
saving：导入数据库过程，是镜像地原始数据在上传到数据库中地一种过渡状态，表示正在上传镜像
uploading：提交给服务识别过程，指示已进行导入数据提交调用，此状态下不允许调用PUT/file（saving状态会执行PUT/file，这是另外一种上传的方法）
importing：准使用状态，指示已经完成导入调用，但是镜像还未准备好使用
镜像上载完成后的状态：
active：表示可使用
deactivated：表示只对管理员开放的权限
killed：表示镜像上传中发生错误
deleted：镜像将在不久后自动删除，镜像不可用（保留数据）
pending_delete：与deleted类似，但是删除后无法恢复
镜像访问权限
public公共的：可以被所有的项目使用
private私有的：只有被镜像所有者所在的项目使用
shared共享的：一个非共有的镜像，可以共享给其他项目，通过项目成员（member-*）操作来实现的
projected（受保护的）：这种镜像不能被删除
glance架构详解
glance服务的使用者即客户端，是 openstack 命令行工具，Horizon控制面板或者Nova服务。
架构图详解
客户端是Glance服务应用程序使用者，是OpenStack命令行工具、Horizon或Nova服务
glance-api 是 glance服务后台运行的服务进程，是进入glance的入口，对外提供REST API ，它对外提供REST API，负责接收外部客户端的服务请求，如响应镜像查询、获取和存储的调用。
glance-registry 是服务后台远程的镜像注册服务进程，负责处理与镜像的元数据相关的RESTful请求，元数据包括镜像大小、类型等信息。glance-api 接收请求如果是与镜像元数据相关的操作，glance-api会把请求转发给glance-registry，glance-registry会解析请求的内容，并与数据库交互，进行存储、处理、检索镜像的元数据。glance-api对外提供API，而glance-registry的API只由glance-api使用。
glance的DB模块存储的是镜像的元数据，可以选用MySQL、mariaDB、SQLite等数据库。镜像的元数据是通过glance-registry存放在数据库中。注意：镜像本身（chunk 块数据）是通过glance的存储驱动存储在后端的各种存储系统中。
存储后端（store backend）Glance自身并不存储镜像，它将镜像存放在后端存储系统中。镜像本身的数据通过glance_store存放在各种后端，并可从中获取。支持本地文件系统存储、对象存储、RBD块存储、Cinder块存储、分布式文件存储等。具体使用哪种backend，可以在glance的配置文件 /etc/glance/glance-api.conf 中配置 [glance-store] 模块。
glance的工作流程
流程解析
1、OpenStack的操作都需经Keystone进行身份认证(AuthN)并授权(AuthZ)，Glance也不例外。Glance是—一个C/S架构，提供—个RESTAPI，用户就通过RESTAPI来执行镜像的各种操作。Glance Domain Controller是—个主要的中间件，相当于调度器，作用是将Glance内部服务的操作分发到以下各个功能层
2、Auth(授权):用来控制镜像的访问权限，决定镜像自己或者它的属性是否可以被修改，只有管
理员或镜像的拥有者才可以执行修改操作。roperty Protection(属性保护):这是个可选层，要在Glance配置文件中设置了property_protection_file参数才会生效。它提供两种类型的镜像属性，—种是核心属性，在镜像参数中指定;另—种是元数据属性，可以被附加到一个镜像上的任—键值对。该层通过调用Glance的public API管理对meta属性的访问，也可以在配置文件中限制该访问。
Notifier(消息通知):将镜像变化的消息和使用镜像时发生的错误和警告添加到消息队列中。
3、Policy(规则定义):定义镜像操作的访问规则，这些规则在/etc/policy.json文件中定义，该层对
其进行监视并实施。
Quota(配额限制):如果管理员对某用户定义了镜像大小的镜像上传上限，则该用户上传了超
过该限额的镜像时会上传失败。
Location(定位):通过glance_store与后台存储进行交互，例如上传、下载镜像，管理镜像存
储位置。该层还能够在添加新位置时检查位置URI是否正确;镜像位置改变时删除存储后端保
存的镜像数据;防止镜像位置重复。
DB(数据库):实现与数据库进行交互的APl，—方面将镜像转换为相应的格式以存储在数据库
中，另—方面将从数据库读取的信息转换为可操作的镜像对象。
4、Registry Layer(主册层)是个可选层，通过使用单独的服务控制Glance Domain Controller与Glance DB之间的安全交互。
Glance DB:是Glance服务使用的核心库，该库对Glance内部所有依赖数据库的组件是共享的。(这
个库是存一些元数据信息的，不是真正存镜像的数据库)
Glance Store:用来组织处理Glance和各种存储后端的交互，提供了—个统—的接口来访问后端的存储。所有的镜像文件操作都是通过调用Glance Store库来执行的，它负责与外部存储端或本地文件存储系统的交互。
5、用户执行上传镜像命令。Glance-api服务收到请求，并通过它的中间件进行解析，获取版本号等信息。
Glance-registry服务APIl获取一个registry client，调用registryclient的add_image(添加镜像）函数。此时镜像的状态为"queued”，标识该镜像ID已经被保留，但是镜像还未上传。
Glance-registry服务执行client的add_image函数，向glance数据库插入—条记录。
Glance-api调用glance-registry的update_image_metadata函数，更新数据库中该镜像的状态为"saving”，标识镜像正在被上传
Glance-api端存储接口提供的add函数上传镜像文件。
Glance-api调用glance-registry的update_image_metadata函数，更新数据库中该镜像的状态为"active"”并发通知。"active"标识镜像在Glance中完全可用。
或
①红色方框是对客户端的请求进行认证和授权的服务流程：openstack的操作都需要经过keystone进行身份认证，并授权，glance也不例外，授权成功再去请求glance服务，glance服务接收到外部请求后，会去keystone进行认证，此请求是否已授权，认证通过后，才会将请求传到后端。
Auth(授权)：用来控制镜像的访问权限，决定镜像信息是否可以修改
②黄色方框的glance domain controller 是主用的中间件，相当于调度器，作用是将glance 内部服务的操作分发到下面的各个功能层
Policy（规则定义）：定义镜像操作的访问规则
Quota（配额限制）：管理员对用户定义了镜像大小的镜像上传上限
Location（定位）：通过glance_store与后台进行交互，在该层新位置添加进行时检查位置URI是否正确，防止镜像位置重复
③蓝色方框里镜像的元数据是通过glance-registry存放在数据库中。镜像本身（chunk 块数据）是通过glance的存储驱动存储在后端的各种存储系统中。
Registry Layer（注册层）：通过使用单独的服务控制Glance Controller与Glance DB之间的安全交互
Glance DB：存储镜像的元数据信息
Glance Store：用来处理Glance和各种存储后端的交互，提供了一个统一接口来访问后端的存储
④绿色方框是存储后端（store backend）将镜像本身的数据存放在后端存储系统
DB（数据库）：实现与数据库进行交互的API，将镜像转换为响应的格式存储在数据库中
注解：
A client
然后使用glance服务的应用程序，可以是命令行工具，horizon，nova等
REST API
glance是一个client-server架构，提供一个REST API，而使用者就是通过REST API来执行关于镜像的各种操作。
Glance Domain Controller
是glance内主要的中间件实现，就相当于一调度员，作用是将glance内部服务的操作分发到各层（Auth认证，Notifier，Policy策略，Quota，Location,DB数据库连接）具体任务由每个层实现。
第一层：Auth
验证镜像自己或者它的属性是否可以被修改，只有管理员和该镜像的拥有者才可以执行该修改操作，否则报错。
第二层：Property protection
由glance domain controller控制的七层组件
是可选的层，只有在glance的配置文件中设置了property_protection_file参数才会生效，它提供了两种类型的镜像属性：
1.核心属性，是在镜像参数中指定的；2元数据属性，是任意可以被附加到一个镜像上的key/value
该层的功能就是通过调用glance的public API来管理对meta属性的访问，你也可以在它的配置文件中限定这个访问
第三层：Notifier
把下列信息添加到queue队列中
1.关于所有镜像修改的通知
2.在使用过程中发生的所有的异常和警告
第四层：Policy
负责：
1.定义操作镜像的访问规则rules，这些规则都定义在/etc/policy.json文件中
2.监控rules的执行
第五层：Quota
如果针对一个用户，管理员为其规定好他能够上传的所有镜像的大小配额，此处的Quota层就是用来检测用户上传是否超出配额限制：
1.如果没有超出配额限制，那么添加镜像的操作成功
2.如果超出了配额，那么添加镜像的操作失败并且报错。
第六层：Location
与Glance Store交互，如上传下载等。由于可以有多个存储后端，不同的镜像存放的位置都被该组件管理
负责：
1.当一个新的镜像位置被添加时，检测该URI是否正确。
2.当一个镜像位置被改变时，负责从存储中删除该镜像。
3.阻止镜像位置的重复
第七层：DB
1.实现了与数据库API的交互
2.将镜像转换为相应的格式以记录在数据库中。并且从数据库接收的信息转换为可操作的镜像对象。
Registry Layer
属于可选的层，用来组织安全。
通过使用这个单独的服务，来控制Glance Domain Controller与Glance DB之间的通信。
Glance DB
glance服务使用统一一个核心库Glance DB,该库对glance内部所有依赖数据库的组件来说是共享的。
Glance Store
用来组织处理Glance和各种存储后端的交互。
所有的镜像文件操作都是通过调用Glance Store库执行的，它负责与外部存储端和（或）本地文件系统的交互。Glance Store提供了一个统一的接口来访问后端的存储。
基于命令界面进行管理镜像
1.查看镜像
[root@control ~(keystone_admin)]# openstack image list
+--------------------------------------+--------+--------+
| ID | Name | Status |
+--------------------------------------+--------+--------+
| d51ba14f-ef4f-4872-b1a6-38e2bd47a061 | 12306 | active |
| 45d80ad7-5354-459b-9e20-3873fdd11bb5 | cirros | active |
+--------------------------------------+--------+--------+
[root@control ~(keystone_admin)]# openstack image show 12306
+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| checksum | 567bc1a1b9aa8a72147675596d11145b |
| container_format | bare |
| created_at | 2020-06-02T09:29:56Z |
| disk_format | qcow2 |
| file | /v2/images/d51ba14f-ef4f-4872-b1a6-38e2bd47a061/file |
| id | d51ba14f-ef4f-4872-b1a6-38e2bd47a061 |
| min_disk | 20 |
| min_ram | 0 |
| name | 12306 |
| owner | 872b3fa35a9f4e7aa6d77303b7a3c53c |
| properties | base_image_ref='45d80ad7-5354-459b-9e20-3873fdd11bb5', boot_roles='_member_', image_location='snapshot', image_state='available', image_type='snapshot', instance_uuid='f40ae825-d72a-4547-a4be-c5cbe0bcfdb4', os_hash_algo='sha512', os_hash_value='5f072f1242c3fc9998da5bead4ee7b7ce38471ef4ec4b9f47294af7f3142288d3718b3077bf4aef3d3b55497f057afa6f7e36abfd8a7ab7eb11183c8226c76d1', os_hidden='False', owner_id='872b3fa35a9f4e7aa6d77303b7a3c53c', owner_project_name='12306', owner_user_name='12306', user_id='e68232dbd188459abeb0159a2631c6f9' |
| protected | False |
| schema | /v2/schemas/image |
| size | 21823488 |
| status | active |
| tags | |
| updated_at | 2020-06-02T09:29:59Z |
| virtual_size | None |
| visibility | private |
+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
2.创建镜像
[root@control ~(keystone_admin)]# openstack image create --disk-format qcow2 --container-format bare --public --file=./cirros-0.3.5-x86_64-disk.img cirros-new
+------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| checksum | f8ab98ff5e73ebab884d80c9dc9c7290 |
| container_format | bare |
| created_at | 2020-06-02T22:30:46Z |
| disk_format | qcow2 |
| file | /v2/images/69efa87f-f54d-4147-bfd4-ef5f649a6b60/file |
| id | 69efa87f-f54d-4147-bfd4-ef5f649a6b60 |
| min_disk | 0 |
| min_ram | 0 |
| name | cirros-new |
| owner | 9951801795e84f82a52defb5736b857b |
| properties | os_hash_algo='sha512', os_hash_value='f0fd1b50420dce4ca382ccfbb528eef3a38bbeff00b54e95e3876b9bafe7ed2d6f919ca35d9046d437c6d2d8698b1174a335fbd66035bb3edc525d2cdb187232', os_hidden='False' |
| protected | False |
| schema | /v2/schemas/image |
| size | 13267968 |
| status | active |
| tags | |
| updated_at | 2020-06-02T22:30:46Z |
| virtual_size | None |
| visibility | public |
+------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
[root@control ~(keystone_admin)]# openstack image list
+--------------------------------------+------------+--------+
| ID | Name | Status |
+--------------------------------------+------------+--------+
| d51ba14f-ef4f-4872-b1a6-38e2bd47a061 | 12306 | active |
| 45d80ad7-5354-459b-9e20-3873fdd11bb5 | cirros | active |
| 69efa87f-f54d-4147-bfd4-ef5f649a6b60 | cirros-new | active |
+--------------------------------------+------------+--------+
3.更改镜像
[root@control ~(keystone_admin)]# openstack image set --name cirros-n cirros-new
[root@control ~(keystone_admin)]# openstack image list
+--------------------------------------+----------+--------+
| ID | Name | Status |
+--------------------------------------+----------+--------+
| d51ba14f-ef4f-4872-b1a6-38e2bd47a061 | 12306 | active |
| 45d80ad7-5354-459b-9e20-3873fdd11bb5 | cirros | active |
| 69efa87f-f54d-4147-bfd4-ef5f649a6b60 | cirros-n | active |
+--------------------------------------+----------+--------+
4.删除镜像
[root@control ~(keystone_admin)]# openstack image delete cirros-n
[root@control ~(keystone_admin)]# openstack image list
+--------------------------------------+--------+--------+
| ID | Name | Status |
+--------------------------------------+--------+--------+
| d51ba14f-ef4f-4872-b1a6-38e2bd47a061 | 12306 | active |
| 45d80ad7-5354-459b-9e20-3873fdd11bb5 | cirros | active |
+--------------------------------------+--------+--------+
5.镜像与项目关联
1）创建关联（镜像文件必须是shared时才可关联）
[root@control ~(keystone_admin)]# openstack image create --disk-format qcow2 --container-format bare --file=./cirros-0.3.5-x86_64-disk.img cirros-new
+------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| checksum | f8ab98ff5e73ebab884d80c9dc9c7290 |
| container_format | bare |
| created_at | 2020-06-02T22:37:07Z |
| disk_format | qcow2 |
| file | /v2/images/0a5ca160-9217-4594-ba10-bb0449dc2af4/file |
| id | 0a5ca160-9217-4594-ba10-bb0449dc2af4 |
| min_disk | 0 |
| min_ram | 0 |
| name | cirros-new |
| owner | 9951801795e84f82a52defb5736b857b |
| properties | os_hash_algo='sha512', os_hash_value='f0fd1b50420dce4ca382ccfbb528eef3a38bbeff00b54e95e3876b9bafe7ed2d6f919ca35d9046d437c6d2d8698b1174a335fbd66035bb3edc525d2cdb187232', os_hidden='False' |
| protected | False |
| schema | /v2/schemas/image |
| size | 13267968 |
| status | active |
| tags | |
| updated_at | 2020-06-02T22:37:07Z |
| virtual_size | None |
| visibility | shared |
+------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
[root@control ~(keystone_admin)]# openstack image add project cirros-new 12306
+------------+--------------------------------------+
| Field | Value |
+------------+--------------------------------------+
| created_at | 2020-06-02T22:37:47Z |
| image_id | 0a5ca160-9217-4594-ba10-bb0449dc2af4 |
| member_id | 872b3fa35a9f4e7aa6d77303b7a3c53c |
| schema | /v2/schemas/member |
| status | pending |
| updated_at | 2020-06-02T22:37:47Z |
+------------+--------------------------------------+
2）解除关联
[root@control ~(keystone_admin)]# openstack image remove project cirros-new 12306
总结：
1.glance-api是系统后台运行的服务进程。对外提供REST API，响应image查询、获取和存储的调用。glance-api不会真正处理请求。
2．如果是与image metadata(元数据）相关的操作，glance-api会把请求转发给glance-registry;
3.如果是与image自身存取相关的操作，glance-api会把请求转发给该image的store backend。
查看glance-api进程##
ps -ef | grep glance-api
glance-registry是系统后台运行的服务进程。负责处理和存取image的metadata，例如image的大小和类型。
查看glance-registry进程##
ps -ef | grep glance-registry
Databaselmage的metadata会保持到database中，默认是MySQL。在控制节点上可以查看glance的database信息
在任一能够与VIP网络互通的节点，上传任一测试镜像，如cirros，查询镜像状态为active,然后删除镜像成功。
# glance image-create --name "test" --disk-format qcow2 --container-
format bare --progress < cirros.img
# glance image-show f439af15-74ec-4cdd-94f2-b817b7a8faa4
#glance image-delete f439af15-74ec-4cdd-94f2-b817b7a8faa4
Nova 简介
计算服务是openstack最核心的服务之一 ， 负责维护和管理云环境的计算资源，它在openstack项目中代号是nova。
Nova自身并没有提供任何虚拟化能力，它提供计算服务，使用不同的虚拟化驱动来与底层支持的Hypervisor (虚拟机管理器)进行交互。所有的计算实例(虚拟服务器)由Nova进行生命周期的调度管理(启动、挂起、停止、删除等)，全局来看，nova为整个架构提供虚拟化资源、技术，服务层面来看，nova本身并不具备虚拟化能力，而是通过compute组件与虚拟化管理工具交互实现虚拟资源调度。
Nova需要keystone、glance、 neutron、 cinder和swift等其他服务的支持， 能与这些服务集成，实现如加密磁盘、裸金属计算实例等。会和其他外部组件集成，共同完成请求。
Nova工作流程图：
Nova由多个服务器进程构成，每个进程执行不同的功能，下面介绍各个组件的功能
外部服务包括keystone，neutron，glance，cinder这些nova服务需要与之交互的服务。
内部组件：
DB：用于数据存储的sql数据库，存放各组件的工作过程信息，后盾裸金属实际的使用资源信息
API：用于接收HTTP请求、转换命令、通过消息队列或HTTP与其他组件通信
Scheduler：用于决定哪台计算节点承载计算实例，相当于nova的调度器
Network：管理IP转发，网桥或虚拟局域网，是一个网络组件
Compute：管理虚拟机管理器（VMM）与虚拟机之间通信，与hypervisor交互实现虚拟化调用底层硬件资源，计算组件
Conductor：处理需要协调的的请求（构建虚拟机或调整虚拟机大小的请求），或者处理对象转换
API是访问nova的接口，nova-api服务接收和处理来自用户的所有计算api请求，它是openstack对外服务最主要的接口并且提供了可以查询所有api的端点，也是外部访问并使用nova提供的各种服务的唯一途径，nova-api对接收到的api请求有以下几个步骤，首先检查客户端传过来的参数是否合法，如果合法则调用其他服务来处理客户端的HTTP请求，最后格式化nova其他子服务返回结果并返回给客户端
API提供REST标准调用服务，便于与第三方系统集成，只要与虚拟机生命周期相关的操作，nova-api都会响应
用户不会直接发送RESTful API请求，而是通过命令行、控制台和其他需要跟nova交换的组件来使用这些API
Scheduler：用于决定那台计算节点承载计算实例的nova调度器
组件介绍
API：
它是客户端访问nova的http接口，它由nova-api服务实现，nova-api服务接收和响应来自最终用户的计算api请求（包括跟虚拟机声明周期相关的操作），作为openstack对外服务的最主要接口，nova提供了一个集中的可以查询所有api的端点，以便自己平台内部和其他云平台的调用。
所有对nova的请求都首先由nova-api处理，API提供REST标准调用服务，便于与第三方系统集成（其他云平台）。它是外部访问并使用nova提供的各种服务的唯一途径，也是客户端和nova之间的中间件。
最终用户不会直接改送RESTful API 请求，而是通过openstack命令行，horison控制面板和其他需要跟nova交换 的组件来使用这些API。
Nova-api对接收到的HTTP API请求做以下处理：
1、检查客户端传入的参数是否合法有效（而不止是进行认证）
2、调用nova其他服务来处理客户端HTTP请求
3、格式化nova其他子服务返回的结果，并返回给客户端
Scheduler：
简介
调度器，由nova-scheduler服务实现，主要解决的是选择在哪个计算节点上启动实例。它可以应用多种规则，考虑内存使用率、cpu负载率、CPU架构等多种因素，根据一定的算法，确定虚拟机实例能够运行在哪一台计算机服务器上。
nova-scheduler服务会从消息队列中接收一个虚拟机实例的请求，通过读取数据库的内容，从可用资源池中选择最合适的计算节点，创建新的虚拟机实例。
创建虚拟机实例时，用户会提出实例的资源需求，如CPU、内存、磁盘。openstack将这些需求定义在实例类型中，有多个实例模板存储在nova的数据库中，用户可以指定使用哪个实例类型，再创建实例。
调度器的类型：
随机调度器：从所有正常运行nova-compute服务的节点中随机选择
缓存调度器：是随机调度器的一种特殊类型，在随机调度器的基础上，将主机资源信息缓存在本地内存中，然后通过后台的定时任务，定时从数据库中获取最新的主机资源信息，周期性同步而不是实时获取主机资源信息。
过滤器调度器：根据指定的过滤条件以及权重选择最佳的计算节点，又称为筛选器。
过滤器调度器调度过程：
主要分为两个阶段：
通过指定的过滤器选择满足条件的计算节点，比如内存使用率，可以使用多个过滤器依次进行过滤。（预选）
对过滤之后的主机列表进行权重计算并排序，选择最优的计算节点来创建虚拟机实例。（优选）
调度器与DB的交互过程：
scheduler组件决定的是虚拟机实例部署在哪台计算节点上并调度，在调度之前，会先向数据库获取宿主机资源信息作为依据；
之后可通过过滤器和权重选择最合适的节点调度，或者指定节点直接调度；
计算节点的 libvirt 工具负责收集宿主机的虚拟化资源，根据已创建的实例再次统计资源，将资源信息更新到数据库中，整个更新资源信息的过程是周期性执行的，而不是实时的；
所以存在一个问题，当刚创建完一个实例，随即又需要创建时，数据库还未来得及更新宿主机的最新状态，那么调度器依据的信息就不正确，有可能所选的节点资源并不够用，而导致调度失败。
这同时也是缓存调度器的缺陷，无法实时获取租主机资源信息。我们可在调度完成时，直接将资源信息返回给数据库，更新数据库状态，解决这个问题。
过滤器
当过滤调度器需要执行调度操作时，会让过滤器对计算节点进行判断，返回ture或false，按照主机列表中的顺序依次过滤。
scheduler_available_filters 选项用于配置可用过滤器，默认是所有nova自带的过滤器都可以使用。
scheduler_default_filters 选项用于指定nova-schedule 服务真正使用的过滤器。
过滤器类型：
RetryFilter（再审过滤器）
主要作用是过滤掉之前已经调度过的节点（类比污点）。如A、B、C都通过了过滤，A权重最大被选中执行操作，由于某种原因，操作在A上失败了。Nova-filter 将重新执行过滤操作，再审过滤器直接过滤掉A，以免再次失败。
AvailabilityZoneFilter（可用区域过滤器）
主要作用是提供容灾性，并提供隔离服务，可以将计算节点划分到不同的可用区域中。Openstack默认有一个命名为nova的可用区域，所有计算节点一开始都在其中。用户可以根据需要创建自己的一个可用区域。创建实例时，需要指定将实例部署在那个可用区域中。通过可用区过滤器，将不属于指定可用区的计算节点过滤掉。
RamFilter（内存过滤器）
根据可用内存来调度虚拟机创建，将不能满足实例类型内存需求的计算节点过滤掉，但为了提高系统资源利用率, Openstack在计算节点的可用内存允许超过实际内存大小，可临时突破上限，超过的程度是通过nova.conf配置文件中ram_ allocation_ ratio参数来控制的， 默认值是1.5。（但这只是临时的）
Vi /etc/nova/nova . conf
Ram_ allocation_ ratio=1 .5
DiskFilter（硬盘过滤器）
根据磁盘空间来调度虚拟机创建，将不能满足类型磁盘需求的计算节点过滤掉。磁盘同样允许超量，超量值可修改nova.conf中disk_ allocation_ ratio参数控制，默认值是1.0，（也是临时的）
Vi /etc/nova/nova.conf
disk_ allocation_ ratio=1.0
CoreFilter（核心过滤器）
根据可用CPU核心来调度虚拟机创建，将不能满足实例类型vCPU需求的计算节点过滤掉。vCPU也允许超量，超量值是通过修改nova.conf中cpu_ allocation_ratio参数控制，默认值是16。
Vi /etc/nova/nova. conf
cpu_allocation_ ratio=16.0
ComputeFilter（计算过滤器）
保证只有nova-compute服务正常工作的计算节点才能被nova-scheduler调度，它是必选的过滤器。
ComputeCapabilitiesFilter（计算能力过滤器）
根据计算节点的特性来过了，如不同的架构。
ImagePropertiesFilter（镜像属性过滤器）
根据所选镜像的属性来筛选匹配的计算节点，通过元数据来指定其属性。如希望镜像只运行在KVM的Hypervisor上，可以通过Hypervisor Type属性来指定。
服务器组反亲和性过滤器
要求尽量将实例分散部署到不同的节点上，设置一个服务器组，组内的实例会通过此过滤器部署到不同的计算节点。适用于需要分开部署的实例。
服务器组亲和性过滤器
此服务器组内的实例，会通过此过滤器，被部署在同一计算节点上，适用于需要位于相同节点的实例服务。
权重：
在对计算节点进行过滤时，多个过滤器依次进行过滤，而不是并行，相当于一个个预选，避免重复对同一个节点进行所有过滤项检验。过滤之后的节点再通过计算权重选出最终的计算节点。
所有权重位于nova/scheduler/weights 目录下，目前默认是RAMweighter，根据计算节点空闲的内存计算权重，内存空闲越多权重越大，实例将被部署到内存空闲最大的计算节点。
Network：管理IP转发、网桥或虚拟局域网的nova网络组件
Compute：管理Hypervisor与虚拟机之间通信的nova计算组件
Conductor：处理需要协调的虚拟处理对象转换
Nova组件介绍-Compute
Nova-compute在计算节点上运行，负责管理节点上的实例。通常一个主机运行一个Nova-compute服务，一个实例部署在哪个可用的主机上取决于调度算法。OpenStack对实例的操作，最后都是提交给Nova-compute来完成。
Nova-compute可分为两类，一类是定向openstack报告计算节点的状态
另一类是实现实例生命周期的管理
通过Driver（驱动）架构支持多种Hypervisor虚拟机管理器
面对多种Hypervisor，nova-compute为这些Hypervisor定义统一的接口
Hypervisor只需要实现这些接口，就可以Driver的形式即插即用到OpenStack系统中
定期向OpenStack报告计算节点的状态
每隔一段时间，nova-compute就会报告当前节点的资源使用情况和nova-compute服务状态
nova-compute是通过Hypervisor的驱动获取这些信息的
实现虚拟机实例生命周期的管理
OpenStack对虚拟机实例最主要的操作都是通过nova-compute实现的。
创建、关闭、重启、挂起、恢复、中止、调整大小、迁移、快照
以实例创建为例来说明nova-compute的实现过程
（1）为实例准备资源
（2）创建实例的镜像文件
（3）创建实例的XML定义文件
（4）创建虚拟网络并启动虚拟机
nova组件介绍-Conductor
由nova-conductor模块实现，旨在为数据库的访问提供一层安全保障。Nova-conductor作为nova-compute服务由nova-compute服务与数据库之间交互的中介，避免了直接访问由nova-compute服务创建对接数据库
Nova-compute访问数据库的全部操作都改到nova-conductor中，nova-conductor作为对数据库操作的一个代理，而且nova-conductor是部署在控制节点上的
Nova-conductor有助于提高数据库的访问性能，nova-compute可以创建多个线程使用远程过程调用(RPC)访问nova-conductor
在一个大规模的openstack部署环境里，管理员可以通过增加nova-conductor的数量来应付日益增长的计算节点对数据库的访问量
nova组件介绍-PlacementAPI
以前对资源的管理全部由计算节点承担，在统计资源使用情况时，只是简单的将所有计算节点的资源情况累加起来，但是系统中还存在外部资源，这些资源由外部系统提供。如ceph、nfs等提供的存储资源等。面对多种多样的资源提供者，管理员需要统一的、简单的管理接口来统计系统中资源使用情况，这个接口就是PlacementAPI
PlacementAPI由nova-placement-api服务来实现，旨在追踪记录资源提供者的目录和资源使用情况
被消费的资源类型是按类进行追踪的。如计算节点类、共享存储池类、IP地址类等
虚拟机实例化流程
用户可以通过多种方式访问虚拟机的控制台
Nova-novncproxy守护进程：通过vnc连接访问正在运行的实例提供一个代理，支持浏览器novnc客户端
Nova-spicehtml5proxy守护进程：通过spice连接访问正在运行的实例提供一个代理，支持基于html5浏览器的客户端
Nova-xvpvncproxy守护进程：通过vnc连接访问正在运行的实例提供一个代理，支持openstack专用的java客户端
Nova-consoleauth守护进程：负责对访问虚拟机控制台提供用户令牌认证。这个服务必须与控制台代理程序共同使用
控制台接口
首先用户（可以是OpenStack最终用户，也可以是其他程序）执行Nova Client提供的用于创建虚拟机的命令
nova-api服务监听到来自于Nova Client的HTTP请求，并将这些请求转换为AMQP消息之后加入消息队列
通过消息队列调用nova-conductor服务
nova-conductor服务从消息队列中接收到虚拟机实例化请求消息后，进行一些准备工作
nova-conductor服务通过消息队列告诉nova-scheduler服务去选择一个合适的计算节点来创建虚拟机，此时nova-scheduler会读取数据库的内容
nova-conductor服务从nova-scheduler服务得到了合适的将计算节点的信息后，在通过消息队列来通知nova-compute服务实现虚拟机的创建