OpenStack架构理论

一 ：Nova

1.1 Nova的概述

nova是负责提供计算资源的模块，也是OpenStack的核心模块，主要功能是负责虚拟机实例的生命周期管理、网络管理、存储卷管理、用户管理以及其他的相关云平台管理功能。

1.2 系统架构

DB:用于数据存储的sql数据库。
API:用于接收HTTP请求、转换命令、通过消息队列或HTTP与其他组件通信的nova组件。
Scheduler:用于决定哪台计算节点承载计算实例的nova调度器。
Network:管理IP转发、网桥或虚拟局域网的nova网络组件。
Compute:管理虚拟机管理器与虚拟机之间通信的nova计算组件。
Conductor:处理需要协调(构建虚拟机或调整虚拟机大小)的请求，或者处理对象转换。

没有network的时候是Nova-network 来提供网络
hypervisor 虚拟机管理器（kvm是一种落地实现的一种）

部署架构特点：

无中心结构
各组件无本地持久化状态
可水平扩展
通常将nova-api、nova-scheduler、nova-conductor组件合并部署在控制节点上
通过部署多个控制节点实现HA和负载均衡
通过增加控制节点和计算节点实现简单方便的系统扩容

1.3 内部组件介绍

1.3.1 nova-api

API是客户访问nova的http接口，它由nova-api服务实现，nova-api服务接受和响应来自最终用户计算api的请求。作为openstack对外服务的最主要接口，nova-api提供了一个集中的可以查询所有api的端点。
所有对nova的请求都首先由nova-api处理。API提供REST 标准调用服务，便于与第三方系统集成。
最终用户不会直接该送RESTful API请求而是通过openstack命令行、dashbord和其他需要跟nova的组件使用这些API。
NOva-api对接受到的HTTP API请求做以下处理：

（1）检查客户端传入的参数是否合法有效 
（2）调用nova其他服务来处理客户端HTTP请求 
（3）格式化nova其他子服务返回结果并返回给客户端

nova-api是外部访问并使用nova提供的各种服务的唯一途径，也是客户端和nova之间的中间层。
#每次执行都要经过API

~~~shell
 REST  #接口，一种规则，就相当于语言要统一才能交流
 CRUD 增删改查

** 1.3.2 Scheduler**

Scheduler可译为调度器，由nova-scheduler服务实现，主要解决的是如何选择在哪个计算节点上启动实例的问题。
选择最优和排序

它可以应用多种规则，如果考虑内存使用率、cpu负载率、cpu架构（Intel/amd）等多种因素，根据一定的算法，确定虚拟机实例能够运行在哪一台计算节点。Nova-scherduler服务会从队列中接受虚拟机实例的请求，通过读取数据库的内容，从可用资源池中选择最合适的计算节点来创建新的虚拟机实例
1、过滤（filter）：过滤出可以创建虚拟机的主机

2、计算权值（weight）：根据权重大小进行分配，默认根据资源可用空间进行权重排序。

1.3.3 Nova-compute
Nova-compute处理管理实例生命周期。他们通过Message Queue接收实例生命周期管理的请求，并承担操作工作。在一个典型生产环境的云部署中有一些compute workers。一个实例部署在哪个可用的compute worker上取决于调度算法。

1.3.4 Rabbitmq
OpenStack 节点之间通过消息队列使用AMQP（Advanced Message Queue Protocol）完成通信。Nova 通过异步调用请求响应，使用回调函数在收到响应时触发。因为使用了异步通信，不会有用户长时间卡在等待状态。这是有效的，因为许多API调用预期的行为都非常耗时，例如加载一个实例，或者上传一个镜像。

1.3.5 Nova-conductor
nova-conductor是nova-compute与数据库的中间件，nova-compute对数据库的CRUD操作都借由nova-conductor完成，nova-conductor通过rpc对外提供API服务。nova-conductor默认采用多进程运行，在不配置[conductor]worker的情况下，进程数会与服务器的逻辑CPU数一致。

1.4 运行流程

1.4.1 虚拟机启动流程

#1. 界面或命令行通过RESTful API向keystone获取认证信息。

#2. keystone通过用户请求认证信息，正确后生成token返回给对应的认证请求。

#3. 界面或命令行通过RESTful API向nova-api发送一个创建虚拟机的请求（携带token）。

#4. nova-api接受请求后向keystone发送认证请求，查看token是否为有效用户。

#5. keystone验证token是否有效，如有效则返回有效的认证和对应的角色（注：有些操作需要有角色权限才能操作）。

#6. 通过认证后nova-api检查创建虚拟机参数是否有效合法后和数据库通讯。

#7. 当所有的参数有效后初始化新建虚拟机的数据库记录。

#8. nova-api通过rpc.call向nova-scheduler请求是否有创建虚拟机的资源(Host ID)。

#9. nova-scheduler进程侦听消息队列，获取nova-api的请求。

#10. nova-scheduler通过查询nova数据库中计算资源的情况，并通过调度算法计算符合虚拟机创建需要的主机。

#11. 对于有符合虚拟机创建的主机，nova-scheduler更新数据库中虚拟机对应的物理主机信息。

# 12. nova-scheduler通过rpc.cast向nova-compute发送对应的创建虚拟机请求的消息。

#13. nova-compute会从对应的消息队列中获取创建虚拟机请求的消息。

#14. nova-compute通过rpc.call向nova-conductor请求获取虚拟机消息。

#15. nova-conductor从消息队队列中拿到nova-compute请求消息。

#16. nova-conductor根据消息查询虚拟机对应的信息。

#17. nova-conductor从数据库中获得虚拟机对应信息。

#18. nova-conductor把虚拟机信息通过消息的方式发送到消息队列中。

#19. nova-compute从对应的消息队列中获取虚拟机信息消息。

#20. nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求glance-api获取创建虚拟机所需要镜像。

#21. glance-api向keystone认证token是否有效，并返回验证结果。

#22. token验证通过，nova-compute获得虚拟机镜像信息(URL)。

#23. nova-compute通过keystone的RESTfull API拿到认证k的token，并通过HTTP请求neutron-server获取创建虚拟机所需要的网络信息。

#24. neutron-server向keystone认证token是否有效，并返回验证结果。

#25. token验证通过，nova-compute获得虚拟机网络信息。

#26. nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求cinder-api获取创建虚拟机所需要的持久化存储信息。

#27. cinder-api向keystone认证token是否有效，并返回验证结果。

#28. token验证通过，nova-compute获得虚拟机持久化存储信息。

#29. nova-compute根据instance的信息调用配置的虚拟化驱动来创建虚拟机。

1.5 设计思想

1.5.1 API前端服务

nova-api 作为 Nova 组件对外的唯一窗口，向客户暴露 Nova 能够提供的功能。当客户需要执行虚机相关的操作，能且只能向 nova-api 发送 REST 请求。

设计 API 前端服务的好处在于：

1：对外提供统一接口，隐藏实现细节
2：API 提供 REST 标准调用服务，便于与第三方系统集成:
3：可以通过运行多个 API 服务实例轻松实现 API 的高可用，比如运行多个 nova-api 进程

1.5.2 Scheduler 调度服务
对于某项操作，如果有多个实体都能够完成任务，那么通常会有一个 scheduler 负责从这些实体中挑选出一个最合适的来执行操作。

Nova 有多个计算节点， 当需要创建虚机时，nova-scheduler 会根据计算节点当时的资源使用情况选择一个最合适的计算节点来运行虚机。

除了 Nova，块服务组件 Cinder 也有 scheduler 子服务。

1.5.3 Worker 工作服务

调度服务只管分配任务，真正执行任务的是 Worker 工作服务。

在 Nova 中，这个 Worker 就是 nova-compute 了。 将 Scheduler 和 Worker 从职能上进行划分使得 OpenStack 非常容易扩展：

1：当计算资源不够了无法创建虚机时，可以增加计算节点（增加 Worker）
2：当客户的请求量太大调度不过来时，可以增加 Scheduler

1.5.4 Driver 框架
OpenStack 作为开放的云操作系统，支持业界各种优秀的技术。这种开放的架构使得 OpenStack 能够在技术上保持先进性，具有很强的竞争力，同时又不会造成厂商锁定（Lock-in）。OpenStack 的这种开放性一个重要的方面就是采用基于 Driver 的框架。

以 Nova 为例，OpenStack 的计算节点支持多种 Hypervisor。 包括 KVM, Hyper-V, VMWare, Xen, Docker, LXC 等。

nova-compute 为这些 Hypervisor 定义了统一的接口，hypervisor 只需要实现这些接口，就可以 driver 的形式即插即用到 OpenStack 中。

Glance、Cinder 和 Neutron 都有 driver 框架的应用

1.5.5 Messaging 服务
nova-* 子服务之间的调用严重依赖 Messaging。Messaging 是 nova-* 子服务交互的中枢。带来以下好处：

1：解耦各子服务。子服务不需要知道其他服务在哪里运行，只需要发送消息给 Messaging 就能完成调用。
2:提高性能。异步调用使得调用者无需等待结果返回。这样可以继续执行更多的工作，提高系统总的吞吐量。
3:提高伸缩性。子服务可以根据需要进行扩展，启动更多的实例处理更多的请求，在提高可用性的同时也提高了整个系统的伸缩性。而且这种变化不会影响到其他子服务，也就是说变化对别人是透明的。

1.5.6 Database
OpenStack 各组件都需要维护自己的状态信息。比如 Nova 中有虚机的规格、状态，这些信息都是在数据库中维护的。每个 OpenStack 组件都有自己的数据库。

总结 Nova 组件设计思想的特点：

1:分布式：由多个逻辑和物理上均可分离的组件组成，实现灵活部署
2:无中心：可以通过增加组件部署实例来实现水平扩展
3:无状态：所有组件无本地持久化状态数据
4:异步执行：大部分执行流通过消息机制实现异步执行
5:插件化、可配置：大量使用插件机制、配置参数实现灵活的扩展与变更
6:RESTful API：支持 RESTful 方式访问的 API，方便客户端访问，方便集成到其他应用系统

二：Glance

2.1 Glance概述

Glance是一个提供发现、注册和下载镜像的服务。Glance是虚拟机镜像的集中存储的地方。通过 Glance 的 RESTful API，可以查询镜像元数据、下载镜像。虚拟机的镜像可以很方便的存储在各种地方，从简单的文件系统到对象存储系统。提供了对虚拟机部署的时候所能提供的镜像的管理，包含镜像的导入，格式，以及制作相应的模板。

2.2 为什么要有Glance

基于openstack是构建基本的Iaas平台对外提供虚机，而虚机在创建的时候必须为其选择操作系统，glance服务器就是为该选择提供不同的系统镜像。

2.3 内部架构

在 Newton 之前的版本中，Glance 支持两种 RESTful API V1和V2，两者区别为：

v1：

1：镜像创建:
2：镜像删除
3：镜像下载
4：镜像列表
5:镜像详细信息
6:镜像更新
7:镜像租户成员的创建
8:镜像租户成员的删除
9:镜像租户成员的列表

v2：

1:支持v1的所有的功能
2:镜像 location 的添加、删除和修改等操作。
3:metadata namespace 操作。
4:镜像 tag 操作。

V2版本的实现就是将 glance-registry 集成到了 glance-api 内部，这么做的好处是减少了一个中间的处理环节。

2.3.1 glance-api

接收镜像API的调用，诸如镜像发现、恢复、存储。

2.3.2 glance-registry

存储、处理和恢复镜像的元数据，元数据包括项诸如大小和类型

2.3.3 Database

可以选择自己喜欢的数据库存储镜像元数据，大多数使用 MySQL 或则 SQLite.

2.3.4 Storage repository for image files

指的是存储镜像文件的仓库或者称为backend，可以是：

1：本地文件系统（或者任何挂载到glance-api控制节点的文件系统）
2：对象存储Object Storage(swift)
3：块存储RADOS(ceph)
4：VMware数据存储
5:HTTP

2.3.5 Metadata definition service

为厂商、管理员、openstack其他服务提供一个公用的API，并且用户可以自定义自己的元数据(有意义的)。这个元数据功能非常强大,可以被用在不同类型的资源：

1:image
2:volumes
3：flavors 套餐

2.4 镜像的数据存放

镜像的数据包括：

​	1.镜像元数据；

​	2.镜像本身即chunk

其中镜像的元数据是通过glance-registry保存到数据库中，而镜像的chunk数据是通过Glance store Drivers存放到各种bakcend store中。

Glance 自己并不存储镜像。 真正的镜像是存放在后端存储中的。Glance 支持多种后端存储，包括：

A directory on a local file system：这是默认配置，在本地的文件系统里进行保存镜像。
GridFS：使用MongoDB存储镜像。
Ceph RBD：使用Ceph的RBD接口存储到Ceph集群中。
Amazon S3：亚马逊的S3。
Sheepdog：专为QEMU/KVM提供的一个分布式存储系统。
OpenStack Block Storage (Cinder)
OpenStack Object Storage (Swift)
HTTP：可以使用英特网上的http服务获取镜像。这种方式只能只读。
VMware ESX/ESXi or vCenter。

2.5 镜像状态

2.5.1 queued

在 Glance registry 里已经通过验证可以开始存储。暂时没有镜像数据被上传到 Glance，镜像大小在上传时设置为0。

2.5.2 saving

表示正在上传镜像到 Glance。通过POST /images 接口注册镜像，如果有 x-image-meta-location http 头，这个镜像将不会处于 saving 状态（因为镜像数据在其他位置已经可用）。

2.5.3 active

表示在 Glance 里是一个完全可用的镜像。当镜像上传成功后，会切换到这个状态。.

2.5.4 killed

表示在 Glance 里是一个完全可用的镜像。当镜像上传成功后，会切换到这个状态。.

2.5.5 deleted

Glance 仍然保留了镜像的相关信息，但不能在被使用。这个状态下的镜像将会被自动删除。

2.5.6 pending_delete

与deleted相似，glance还没有清除镜像数据，只是处于该状态的镜像不可恢复。

2.6 磁盘格式

2.6.1 RAW

RAW即常说的裸格式，它其实就是没有格式，最大的特点就是简单，数据写入什么就是什么，不做任何修饰，所以再性能方面很不错，甚至不需要启动这个镜像的虚拟机，只需要文件挂载即可直接读写内部数据。并且由于RAW格式简单，因此RAW和其他格式之间的转换也更容易。在KVM的虚拟化环境下，有很多使用RAW格式的虚拟机。

2.6.2 QCOW2

它是QEMU的CopyOn Write特性的磁盘格式，主要特性是磁盘文件大小可以随着数据的增长而增长。譬如创建一个10GB的虚拟机，实际虚拟机内部只用了5GB，那么初始的qcow2磁盘文件大小就是5GB。与RAW相比，使用这种格式可以节省一部分空间资源。

2.6.3 VHD

VHD也是一种通用的磁盘格式。微软公司的Virtual PC和Hyper-V使用的就是VHD格式。VirtualBox也提供了对VHD的支持。如果要在OpenStack上使用Hyper-V的虚拟化，就应该上传VHD格式的镜像文件。

2.6.4 VMDK

VMware创建的一个虚拟机磁盘格式，目前也是一个开放的通用格式，除了VMware自家的产品外，QEMU和VirtualBox也提供了对VMDK格式的支持。

2.6.5 VDI

Oracle公司的VirtualBox虚拟软件所使用的格式。

2.6.6 ISO

ISO是指一种存档数据文件在光盘上的格式。

2.6.7 AKI、ARI、AMI

Amazon公司的AWS所使用的镜像格式。

2.7 容器格式

2.7.1 BARE

没有容器的一种镜像元数据格式。

2.7.2 OVF

开放虚拟化格式。

2.7.3 OVA

开放虚拟化设备格式。

2.7.4 AKI、ARI

Amazon公司的AWS所使用的镜像格式。

三：OpenStack逻辑架构