openstack理论

1：云计算的起源

在2006年3月，亚马逊公司首先提出弹性计算云服务
由埃里克·施密特在2006年8月9号在谷歌搜索引擎大会上首次提出“云计算”的概念

2：云计算的定义

云计算是一种按使用量付费的模式，这种模式提供可用的、便捷的、按需的网络访问，进入可配置的计算资源共享池（资源包括网络、服务器、存储和应用软件等），这些资源能够被快速提供，只需投入很少的管理工作或与服务供应商进行很少的交互。

3：云计算五大特征

① 按需自助服务：消费者可以单方面部署资源。例如服务器、网络存储，资源是按需自动部署的，不需要与服务供应商进行人工交互。
② 通过互联网获取：资源可以通过互联网获取，并可以通过标准方式访问。例如，通过瘦客户端或富客户端（移动电话、笔记本电脑和工作站等）。
③ 资源池化：供应商的资源被池化，以便以多用户租用模式被不同客户使用。例如，不同的物理和虚拟资源可根据客户需求动态分配和重新分配，通常与地域无关，这些资源包括存储、处理器、内存和网络带宽。
④ 快速伸缩：资源可以弹性地部署和释放，有时是自动化的，以便能够迅速地按需扩大和缩小规模。
⑤ 可计量：云计算系统通过使用一些与服务种类（存储、计算、带宽、激活的用户账号）对应的抽象信息提供计量能力（通常在此基础上实现按使用付费）。

4：云计算的服务模型

云计算的服务模型SPI由3大服务组成

1:IaaS		（基础设施即服务）
2：PaaS		（平台即服务）
3：SaaS		（软件即服务）

详细内容如下

① IaaS：消费者使用"基础计算资源”。资源服务包括处理能力、存储空间、网络组件或中间件服务。消费者能掌控操作系统、存储空间、已部署的应用程序及网络组件（如防火墙、负载均衡器等），但并不掌控云基础架构。如Amazon AWS、Rackspace等。
② PaaS：消费者使用主机操作应用程序。消费者掌控运作应用程序的环境（也拥有主机部分掌控权），但并不掌控操作系统、硬件或网络基础架构。平台通常是应用程序基础架构。如Google App Engine。
③ SaaS：消费者使用应用程序，但并不掌控操作系统、硬件或网络基础架构。它是一种服务观念的基础，软件服务供应商以租赁的概念提供客户服务，而非购买，比较常见的模式是提供一组账号密码。

5：云计算四大部署类型

① 私有云：云计算基础设施由一个单一的组织部署和独占使用，可由该组织、第三方或两者的组合来拥有和管理。
② 社区云：云计算基础设施由一些具有共有关注点的组织形成的社区中的用户部署和使用，可由一个或多个社区中的组织、第三方或两者的组合来拥有和管理、运营。
③ 公有云：云计算基础设施被部署给广泛的公众开放地使用。它可能被一个商业组织、研究机构、政府机构或者几者的混合所拥有、管理和运营，被一个销售云计算服务的组织所拥有，该组织将云计算服务销售于一般人或广泛的工业群体。
④ 混合云：云计算基础设施是由两种或两种以上的云（私有、社区或公共）组成，每种云仍然保持独立，但用标准的或专有的技术将它们组合起来，具有数据和应用程序的可移植性。

云计算平台分类
存储型云平台：数据存储为主
计算型云平台：数据处理为主
综合云计算平台：计算和数据存储处理兼顾

认证服务（Keystone）理论部分

认证服务的概念（Keystone）
在OpenStack框架中，Keystone（OpenStack Identity Service）的功能是负责验证身份、校验服务规则和发布服务令牌的，它实现了OpenStack的Identity API。Keystone可分解为两个功能，即权限管理和服务目录。权限管理主要用于用户的管理授权。服务目录，类似一个服务总线，或者说是整个OpenStack框架的注册表。认证模块提供API服务、 token 令牌机制、服务目录、规则和认证发布等功能。

认证（Authentication）
认证是确认允许一个用户访问的进程。为了确认请求，OpenStack Identity会为访问用户提供证书，起初这些证书是用户名和密码，或用户名和API key。当OpenStack Identity认证体系接受了用户的请求之后，它会发布一个认证令牌（Token），用户在随后的请求中使用这个令牌去访问资源中其他的应用。

证书（Credentials）
用于确认用户身份的数据。例如，用户名、密码或者API key，或认证服务提供的认证令牌。

令牌（Token）
通常指的是一串比特值或者字符串，用来作为访问资源的记号。Token（令牌统一用词）中含有可访问资源的范围和有效时间，一个令牌是一个任意比特的文本，用于与其他OpenStack服务来共享信息，Keystone以此来提供一个central location，以验证访问OpenStack服务的用户。令牌的有效期是有限的，可以随时被撤回。

项目（project）
project即项目，早期版本又称为project，它是各个服务中的一些可以访问的资源集合。例如，通过nova创建虚拟机时要指定到某个项目中，在cinder创建卷也要指定到某个项目中，用户访问项目的资源前，必须与该项目关联，并且指定该用户在该项目下的角色。
平台构建完毕会产生admin、service和demo三个项目。在这些项目中，admin项目代表管理组，拥有平台的最高权限，可以更新、删除和修改系统的任何数据。service代表平台内所有服务的总集合，平台安装的所有服务默认会被加入到此项目中，为后期的统一管理提供帮助，此项目可以修改当前项目下所有服务的配置信息，提交项目的内容以及修改。demo则是一个演示测试项目，没有什么实际的用处。

用户（User）
使用服务的用户，可以是人、服务或系统使用OpenStack相关服务的一个组织。例如，一个项目映射到一个Nova的“project-id”，在对象存储中，一个项目可以有多个容器。根据不同的安装方式，一个项目可以代表一个客户、账号、组织或项目。用户通过Keystone Identity认证登录系统并调用资源。用户可以被分配到特定项目并执行项目相关操作。需要特别指出的是，OpenStack通过注册相关服务用户来管理服务，例如Nova服务注册nova用户来管理相应的服务。对于管理员来说，需要通过Keystone来注册管理用户。

角色（Role）
Role即角色，Role代表一组用户可以访问的资源权限，例如Nova中的虚拟机、Glance中的镜像。Users可以被添加到任意一个全局的role或项目内的role中。在全局的role中，用户的role权限作用于所有的项目，即可以对所有的项目执行role规定的权限。在项目内的role中，用户仅能在当前项目内执行role规定的权限。

理论合并，这里举例酒店行程
张三（用户）他拿着身份证（证书）去酒店前台开一间房间，前台登记完身份（认证），前台给张三一个房卡（令牌），给他开的房间门的权限（角色）

基础控制服务

1．概述
Glance镜像服务实现发现、注册、获取虚拟机镜像和镜像元数据，镜像数据支持存储多种的存储系统，可以是简单文件系统、对象存储系统等。

2．Glance服务架构
Glance镜像服务是典型的C/S架构，Glance架构包括glance-CLIent、Glance和Glance Store。Glance主要包括REST API、数据库抽象层（DAL）、域控制器（glance domain controller）和注册层（registry layer），Glance 使用集中数据库（Glance DB）在Glance各组件间直接共享数据。
所有的镜像文件操作都通过glance_store库完成，glance_store库提供了通用接口，对接后端外部不同存储，如图所示。

（1）客户端（CLient）：外部用于同Glance服务的交互和操作。

（2）glance-api：Glance对外的REST接口。

（3）数据库抽闲层（DAL）：Glance和数据库直接交互的编程接口。

（4）Glance域控制器：中间件实现Glance的认证、通知、策略和数据链接等主要功能。

（5）注册层：可选层，用于管理域控制和数据库DAL层之间的安全通信。

（6）Glance DB：存储镜像的元数据，根据需要可以选择不同类型的数据库，目前采用Mysql。

（7）Glance Store：Glance对接不同数据存储的抽象层。

（8）后端存储：实际接入的存储系统。可以接入简单文件系统、Swift、Ceph和S3云存储等。当前框架选择存储在本地，目录在控制节点：/var/lib/glance/images/。

Glance服务自带两个配置文件，在使用Glance镜像服务时需要配置glance-api.conf和glance-registry.conf两个服务模块。在添加镜像到Glance时，需要指定虚拟镜像的磁盘格式（disk format）和容器格式（container format）。
镜像服务运行两个后台服务进程Demon，如下。

（1）glance-api：对外接受并发布镜像、获取和存储的请求调用。

（2）glance-registry：存储、处理和获取镜像元数据，内部服务只有Glance内部使用，不暴露给用户。

（3）glance-all：是对前两个进程的通用封装，操作方式和结果一直。

3．镜像文件格式
虚拟机镜像需要指定磁盘格式和容器格式。虚拟设备供应商将不同的格式布局的信息存在一个虚拟机磁盘映像，虚拟机的磁盘镜像的格式基本有如下几种。

（1）raw：非结构化磁盘镜像格式。

（2）qcow2：QEMU模拟器支持的可动态扩展、写时复制的磁盘格式，是kvm虚拟机默认使用的磁盘文件格式。

（3）AMI/AKI/ARI：Amazon EC2最初支持的镜像格式。

（4）UEC tarball：ubuntu enterprise cloud tarball 是一个gzip压缩后的tar文件，包含有AMI、AKI和ARI 三种类型的文件。

（5）VHD ：microsoft virtual hard disk format（微软虚拟磁盘文件）的简称。

（6）VDI：VirtualBox使用VDI（virtual disk image）的镜像格式，OpenStack没有提供直接的支持，需要进行格式转换。

（7）VMDK：VMWare virtual machine disk format是虚拟机VMware创建的虚拟机格式。

（8）OVF：open virtualization format，开放虚拟化格式，OVF文件是一种开源的文件规范，可用于虚拟机文件的打包。

容器格式是可以理解成虚拟机镜像添加元数据后重新打包的格式，目前有以下几种容器格式。

（1）Bare：指定没有容器和元数据封装在镜像中，如果Glance和OpenStack的其他服务没有使用容器格式的字符串，为了安全，建议设置bare。

（2）ovf: ovf的容器模式This is the OVF container format。

（3）aki：存储在Glance中的是Amazon的内核镜像。

（4）ari：存储在Glance中的是Amazon的ramdisk镜像。

（5）ami：存储在Glance中的是Amazon的machine镜像。

（6）ova：存储在Glance中的是OVA的tar归档文件。

4．镜像状态
由于镜像文件都比较大，镜像从创建到成功上传到Glance文件系统中，是通过异步任务的方式一步步完成的，状态包括Queued（排队）、Saving（保存中）、Acive（有效）、deactivated（无效）、Killed（错误）、Deleted（被删除）和Pending_delete（等待删除），如图所示。

（1）Queued排队：镜像ID已经创建和注册，但是镜像数据还没有上传。

（2）Saving保存中：镜像数据在上传中。

（3）Active有效：镜像成功创建，状态有效可用。

（4）Deactivated不活的：镜像成功创建，镜像对非管理员用户不可用。

（5）Killed错误：上传镜像数据出错，目前不可读取。

（6）Deleted被删除：镜像不可用，将被自动删除。

（7）Pending_delete等待删除：镜像不可用，等待将被自动删除

架构解析

nova整体解析

概述

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

架构

解析

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

部署架构特点：

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

组件解析

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之间的中间层。

Scheduler··

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

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

1、过滤（filter）：过滤出可以创建虚拟机的主机

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

Nova-compute

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

Rabbitmq

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

Nova-conductor

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

运行流程

虚拟机启动流程

#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的信息调用配置的虚拟化驱动来创建虚拟机。

设计思想

API前端服务

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

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

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

Scheduler 调度服务

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

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

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

Worker 工作服务

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

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

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

Driver 框架

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

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

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

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

Messaging 服务

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

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

Database

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

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

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