openstack基础理论进阶

之前的基本概述在这篇博客必备基础理论

1.Keyston身份服务

1.1 主要功能

身份认证：对用户进行身份认证，并对应权限范围
用户授权(令牌管理权限)：以token令牌的方式标识用户对应拥有的权限范围
用户管理(寻址功能)：提供用户访问资源的寻址功能(URL)
服务目录：所有服务的交互/调用，均需要keyston进行认证

1.2 管理对象

User：指使用Openstack service的用户，nova glance(跑在OpenStack里面，是需要一个用户进行管理的)
Project(Tenant)：可以理解为一个人或服务所拥有的资源集合
Role：用于划分权限，通过给User指定Role, 使User获得Role对应操作权限
Authentication：确定用户身份的过程
Token：是一个字符串表示，作为访问资源的令牌。Token包含了在指定范围和有效时间内可以被访问的资源
Credentials：用于确认用户身份的凭证，用户的用户名和密码，或者是用户名和API密钥,或者身份管理服务提供的认证令牌。
Service Openstack service, 即Openstack中运行的组件服务。如nova、swift、glance、 neutron、 cinder等
Endpoint：一个可以通过网络来访问和定位某个Openstack service的地址,通常是一个URL(即apache的api (位置点))

1.3 keystone认证过程

user 登陆（keystone 认证）
user 进入控制台/命令行界面（位置点）
user 发起创建虚拟的请求（向keystone认证指引位置点）
请求到达nova组件（向keystone认证 ）
nova会开始执行请求，并且调用创建实例所需要的glance、neutron等资源（向keystone
认证，指引对应服务的位置点）
glance和neutron 服务收到请求后（向keystone认证）才会给与nova对应的资源
nova 拿到资源后，调用对应资源，创建实例，最后将创建结果返回给用户

2.Glance 镜像服务

2.1 镜像

镜像通常指的是一系列文件或一个磁盘驱动的精确副本，将特定的一系列文件按照一定的格式制作成独立的文件，以方便用户的下载和使用。简单来说就是一系列资源/服务的集合，也可以作为模板创建多个同样的独立的副本

2.2 镜像服务的功能

镜像服务主要是用来灌流镜像，让用户能够发现、获取和保存镜像，主要功能如下：

查询和获取镜像的元数据和镜像本身（元数据：镜像的概要信息和描述信息）
注册和上传虚拟机镜像，包括镜像的创建、.上传、 下载和管理
维护镜像信息，包括元数据和镜像本身。
支持多种方式存储镜像，包括普通的文件系统、Swift、 Amazon S3等
对虚拟机实例执行创建快照命令来创建新的镜像，或者备份虚拟机的状态

2.3 镜像的 API 版本

Glance提供的RESTful API有两个版本：V1,V2：

v1只提供基本的镜像和成员操作功能，包括镜像创建、删除、下载、列表、详细信息查询、 更新，以及镜像租户成员的创建、删除和列表。
v2除了支持v1的所有功能外，主要增加了镜像位置的添加、删除、修改，元数据和名称空间操作，以及镜像标记操作

2.4 镜像格式

2.4.1虚拟机镜像文件磁盘格式

2.4.2 镜像文件容器格式

2.5 镜像状态

2.5.1 镜像从上传到可识别的几个状态：

2.5.2 镜像在上载完成后的状态

2.6 镜像访问权限

2.7 工作流程

首先是对客户端的安全认证流程：openstack的操作都需要经过keystone进行身份认证，并授权，glance也不例外，授权成功再去请求glance服务，glance服务接收到外部请求后，会去keystone进行认证，此请求是否已授权，认证通过后，才会将请求传到后端处理。
glance domain controller 是API和后端功能模块的中间件，相当于调度器，作用是将外部服务分发到下面的各个功能层去处理。在调度时，遵循调度算法，首先有一个预选，排除不符合要求的节点，再进行优选，通过打分机制，对都能够处理此功能的节点进行打分，考虑它们当前的负荷，处理能力和速度，选出最优的一个。对于一些有污点的节点，调度器是直接跳过他们的，如果其余可用节点负担都太大，无法处理外部请求，会有一个容忍机制，由运维人员控制，让调度器接受污点，对污点再进行优选

3.Nova 计算服务

3.1 Nova 简介

计算服务是openstack最核心的服务之一 ， 负责维护和管理云环境的计算资源，它在openstack项目中代号是nova。
Nova自身并没有提供任何虚拟化能力，它提供计算服务，使用不同的虚拟化驱动来与底层支持的Hypervisor (虚拟机管理器)进行交互。所有的计算实例(虚拟服务器)由Nova进行生命周期的调度管理(启动、挂起、停止、删除等)，全局来看，nova为整个架构提供虚拟化资源、技术，服务层面来看，nova本身并不具备虚拟化能力，而是通过compute组件与虚拟化管理工具交互实现虚拟资源调度。
Nova需要keystone、glance、 neutron、 cinder和swift等其他服务的支持， 能与这些服务集成，实现如加密磁盘、裸金属计算实例等。会和其他外部组件集成，共同完成请求

3.2 Nova 系统架构

外部服务包括keystone，neutron，glance，cinder这些nova服务需要与之交互的服务。
内部组件：
DB：用于数据存储的sql数据库，存放各组件的工作过程信息，后端裸金属实际的使用资源信息
API：用于接收HTTP请求、转换命令、通过消息队列或HTTP与其他组件通信
Scheduler：用于决定哪台计算节点承载计算实例，相当于nova的调度器
Network：管理IP转发，网桥或虚拟局域网，是一个网络组件
Compute：管理虚拟机管理器（VMM）与虚拟机之间通信，与hypervisor交互实现虚拟化调用底层硬件资源，计算组件
Conductor：处理需要协调的的请求（构建虚拟机或调整虚拟机大小的请求），或者处理对象转换

3.3 组件介绍

3.3.1 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其他子服务返回的结果，并返回给客户端

3.3.2 Scheduler

调度器的类型：

随机调度器：从所有正常运行nova-compute服务的节点中随机选择
缓存调度器：是随机调度器的一种特殊类型，在随机调度器的基础上，将主机资源信息缓存在本地内存中，然后通过后台的定时任务，定时从数据库中获取最新的主机资源信息，周期性同步而不是实时获取主机资源信息。
过滤器调度器：根据指定的过滤条件以及权重选择最佳的计算节点，又称为筛选器。
过滤器调度器调度过程：

通过指定的过滤器选择满足条件的计算节点，比如内存使用率，可以使用多个过滤器依次进行过滤。（预选）
对过滤之后的主机列表进行权重计算并排序，选择最优的计算节点来创建虚拟机实例。（优选）
过滤器类型：

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，根据计算节点空闲的内存计算权重，内存空闲越多权重越大，计算节点按照内存空闲进行排序。

3.3.3 Nova-compute计算组件

Nova-compute在计算节点上运行，负责管理节点上的实例。通常一个主机运行一 个Nova-compute服务, 一个实例部署在哪个可用的主机上取决于调度算法。OpenStack对实例的操作最后都是提交给Nova-compute来完成。
Nova-compute可分为两类，一类是定向openstack报告计算节点的状态，另一类是实现实例生命周期的管理。

定期向OpenStack报告计算节点的状态，每隔一段时间，nova-compute就会报告当前计算节点的资源使用情况和nova-compute
服务状态。nova-compute是通过Hypervisor的驱动获取这些信息的，实现虚拟机实例生命周期的管理
OpenStack对虚拟机实例最主要的操作都是通过nova-compute实现的。创建、关闭、重启、挂起、恢复、中止、调整大小、迁移、快照
以实例创建为例来说明nova-compute的实现过程(compute执行的顺序)

1.为实例准备资源。
2.创建实例的镜像文件。
3.创建实例的XML定义文件。
4.创建虚拟网络并启动虚拟机。

3.3.4 Nova-conductor协调组件

由nova-condactor模块实现，旨在为数据库的访问提供一层安全保障。Nova-conductor作为nova-
compute服务与数据库之间交互的中介，避免了直接访问由nova-compute服务创建对接数据库。
Nova-compute访问数据库的全部操作都改到nova-conductor中,nova-conductor作为对数据库操作的一个代理，而且nova-conductor是部署在控制节点上的。
Nova-conductor有助于提高数据库的访问性能，nova-compute可以创建多个线程使用远程过程调用(RPC)访问nova-conductor。
在一个大规模的openstack部署环境里,管理员可以通过增加nova-conductor的数量来应付日益增长的计算节点对数据库的访问量。

3.3.4 Nova-placementAPI

以前对资源的管理全部由计算节点承担，在统计资源使用情况时，只是简单的将所有计算节点的资源情况累加起来，但是系统中还存在外部资源，这些资源由外部系统提供。如ceph, nfs等提供的存储资源等。面对多种多样的资源提供者，管理员需要统一的、简单的管理接口来统计系统中资源使用情况，这个接口就是PlacementAPl
PlacementAPI由nova-placement-api服务来实现，旨在追踪记录资源提供者的目录和资源使用情况
被消费的资源类型是按类进行跟踪的。如计算节点类、共享存储池类、IP地址类等

3.3.5 控制台接口

首先用户(可以是OpenStack最终用户，也可以是其他程序)执行Nova Client提供的用于创建虚拟机的命令。
nova-api服务监听到来自于Nova Client的HTTP请求，并将这些请求转换为AMQP消息之后加入消息队列。
通过消息队列调用nova-conductor服务。
nova-conductor服务从消息队列中接收到虚拟机实例化请求消息后，进行一些准备工作。
nova-conductor服务通过消息队列告诉nova-scheduler服务去选择-个合适的计算节点来创建虚拟机，此时nova-scheduler会读取数据库的内容。
nova-conductor服务从nova-scheduler服务得到了合适的将计算节点的信息后，在通过消息队列来通知nova-com ute服务实现虚拟机的创建。

3.3.6 Nova-Cell架构

当openstack-nova集群的规模变大时，数据库和消息队列服务就会出现瓶颈问题。Nova为提高水平扩展及分布式、大规模的部署能力，同时又不增加数据库和消息中间件的复杂度，引入了Cell概念。
Cell可译为单元。为支持更大规模的部署,openstack较大的nova集群分成小的单元,每个单元都有自己的消息队列和数据库，可以解决规模增大时引起的瓶颈问题。在Cell中，Keystone、Neutron、Cinder、Glance等资源是共享的。

NOVA架构的分层结构：
DB -> API数据库
conductor --> super conductor
rabbitmq --> api-rabbitmq

扩展后，加入了cell单元,单元是一个个独立存在的结构,形成cell_n的结构：
cell的数据库是cell_n数据库
cell的控制器: nova-conductor
cell的消息队列: cell-rabbitmq