OpenStack学习笔记

OpenStack是一个开源的IaaS解决方案，使用它，你可以通过仪表盘或者利用OpenStack API控制/Provision大规模的计算、存储、网络资源池。

通过“驱动”，OpenStack支持大量商业、开源的计算、存储、网络相关技术框架，从而能够管理各种各样的基础设施。不管是裸金属机器、虚拟机、还是容器，都可以基于OpenStack进行管理，并共享网络、存储等底层资源：

Kubernetes、CloudFoundry等PaaS平台可以构建在OpenStack之上。

OpenStack由若干子项目组成，它们围绕着计算、存储、网络这三个核心概念组织：

1. 计算：提供并管理网络中大量的虚拟机，主要由Nova子项目负责
2. 存储：供服务器、应用程序使用的对象存储、块存储，分别由Swift、Cinder子项目负责
3. 网络：可拔插、可扩容、API驱动的网络和IP管理

这三类子项目还具有一些共享的服务：identity、镜像管理（image management）、一个基于Web的UI接口。

OpenStack项目的总览图如下，其中粗体标出了它的核心子项目，包括Horizon、Heat、Nova、Neutron、Swift、Cinder等：

以Bigdata as Service场景为例，各子项目的交互关系如下图：

简单的说明一下：

1. Keystone提供身份验证服务
2. Ceilometer提供监控服务
3. Horizon提供一个管理UI
4. Nova负责分配虚拟机
5. Glance提供镜像服务，镜像文件存放在Swift中
6. Cinder为虚拟机提供块存储卷
7. Cinder将卷备份到Swift中
8. Neuron为虚拟机提供网络连接

每个子项目，或者叫OpenStack服务，都通过公共的Identity Service进行身份验证，服务之间通过公共API进行交互。每个服务至少包含一个API进程，此进程监听API请求，进行预处理然后转交给服务的其它部分进行处理。

每个服务可以有多个进程，这些进程之间的通信方式通常是AMQP。服务的状态持久化在数据库中。多种消息代理、RDBMS被支持，例如RabbitMQ、MySQL、MariaDB。

用户访问OpenStack的方式有几种：

1. 通过Horizon提供的Web仪表盘
2. 提供CLI客户端
3. 提供SDK进行编程

不管是何种方式，在底层都会向不同的OpenStack服务发送REST请求。

Nova是OpenStack云中的计算组织控制器。支持OpenStack云中实例（instances）生命周期的所有活动都由Nova处理。这样使得Nova成为一个负责管理计算资源、网络、认证、所需可扩展性的平台。

Neutron是openstack核心项目之一，提供云计算环境下的虚拟网络功能。OpenStack网络（neutron）管理OpenStack环境中所有虚拟网络基础设施（VNI），物理网络基础设施（PNI）的接入层。

Cinder接口提供了一些标准功能，允许创建和附加块设备到虚拟机，如“创建卷”，“删除卷”和“附加卷”。还有更多高级的功能，支持扩展容量的能力，快照和创建虚拟机镜像克隆。

Octavia 是 openstack lbaas的支持的一种后台程序，提供为虚拟机流量的负载均衡。实质是类似于trove，调用 nova 以及neutron的api生成一台安装好haproxy和keepalived软件的虚拟机，并连接到目标网路。

Swift 不是文件系统或者实时的数据存储系统，而是对象存储，用于长期存储永久类型的静态数据。这些数据可以检索、调整和必要时进行更新。Swift最适合虚拟机镜像、图片、邮件和存档备份这类数据的存储。

Glance（OpenStack Image Service）是一个提供发现，注册，和下载镜像的服务。Glance提供了虚拟机镜像的集中存储。通过 Glance 的 RESTful API，可以查询镜像元数据、下载镜像。虚拟机的镜像可以很方便的存储在各种地方，从简单的文件系统到对象存储系统（比如 OpenStack Swift）。

Horizon 为 Openstack 提供一个 WEB 前端的管理界面 (UI 服务 )通过 Horizon 所提供的 DashBoard 服务 , 管理员可以使用通过 WEB UI 对 Openstack 整体云环境进行管理 , 并可直观看到各种操作结果与运行状态。

Ironic包含一个API和多个插件，用于安全性和容错性地提供物理服务器。它可以和nova结合被使用为hypervisor驱动，或者用bifrost使用为独立服务。默认情况下，它会使用PXE和IPMI去与裸金属机器去交互。Ironic也支持使用供应商的插件而实现额外的功能。

Cyborg（以前称为Nomad）旨在为加速资源（即FPGA,GPU,SoC, NVMe SSD,DPDK/SPDK,eBPF/XDP …）提供通用管理框架。

kolla 的使命是为 openstack 云平台提供生产级别的、开箱即用的交付能力。kolla 的基本思想是一切皆容器，将所有服务基于 Docker 运行，并且保证一个容器只跑一个服务（进程），做到最小粒度的运行 docker。

Kubernetes Kuryr是 OpenStack Neutron 的子项目，其主要目标是通过该项目来整合 OpenStack 与Kubernetes 的网络。该项目在 Kubernetes 中实现了原生 Neutron-based 的网络，因此使用 Kuryr-Kubernetes 可以让你的 OpenStack VM 与 Kubernetes Pods 能够选择在同一个子网上运作，并且能够使用 Neutron 的 L3 与 Security Group 来对网络进行路由，以及阻挡特定来源 Port。

Manila项目全称是File Share Service，文件共享即服务，用来提供云上的文件共享，支持CIFS协议和NFS协议。

Tacker是一个在OpenStack内部孵化的项目, 他的作用是NVF管理器，用于管理NVF的生命周期。Tacker的重点是配置VNF, 并监视他们。如果需要，还可重启和/或扩展（自动修复）NVF。整个进程贯穿ETSIMANO所描述的整个生命周期。

显示详细配置信息：

一个Domain，是用户、组、项目的集合。任何组、项目仅仅属于单个Domain。

管理项目

清除和指定项目关联的资源

用户的组。

用户管理

可以创建角色，将角色映射给用户或组。

角色和用户的映射关系。

指定角色之间的包含关系。

提供特定项目中，用户之间的角色代理，支持可选的替身机制（impersonation）。需要 OS-TRUST扩展。

在Identity服务的OS-OAUTH1扩展中使用，用于创建request token 、access token，仅仅支持Identity v3。

管理凭证：

使用应用凭证，用户可以给自己的应用程序授予对云资源的有限访问权限。

对应用程序凭证的权限进行细粒度控制。每个访问规则包含一下要素：

服务类型 + 请求路径 + 请求方法

创建或吊销一个令牌

Identity服务的OS-OAUTH1扩展使用访问令牌。consumer可以代表被授权用户来获得新的Identity API token。

Identity服务的OS-OAUTH1扩展使用请求令牌。consumer使用此令牌来请求access token

策略是一组规则，可以被远程服务消费。

基于RBAC的、针对网络资源的授权控制策略。让用户获得某个项目的网络资源的访问权限

很多API都支持资源配额

用于在项目级别进行资源配额。

用于定义OpenStack部署中的默认资源限制

显示计算、存储资源用量的限制

显示项目的资源用量

区域是OpenStack部署中的最大的分区。你可以配置多个sub-region，甚至形成树形结构。

可用区是云存储、计算、网络服务的逻辑分区。对等的AZ具有构成HA的效果，这和Region不同。

聚合是一组分组host的机制：

运行Hypervisor的物理机器。

OpenSSH公钥管理，用于访问创建的server（虚拟机）。

显示所有服务的版本、端点、是否弃用之类的信息

显示服务的类型、名称、端点列表：

很多OpenStack API包含API扩展，这些扩展提供额外的功能。

管理服务的API端点

一组端点，可以一起关联到项目。

表示一种虚拟机的规格。

管理镜像。

计算代理是和Hypervisor相关的，且仅仅被 XenAPI hypervisor driver支持。

Nova相关的服务。

显示虚拟机的控制台日志：

打印各种类型的控制台URL：

基于某种策略对服务器进行分组。

创建一个实例（虚拟机，也叫服务器server） 

为服务器添加固定IP地址：

为服务器添加浮动IP地址：

将服务器连接到某个网络 

将某个端口连接到服务器

将服务器添加到安全组

挂载（Attach）一个卷给服务器

服务器迁移，就是将一台宿主机上的实例，转移到另外一台上运行。

OpenStack支持四种迁移模式：热迁移、冷迁移、升降配（resize）、重建（evacuation）

扩/缩容服务器为新的flavor。实现方式是：

1. 创就一个新的服务器
2. 复制文件到新服务器

扩/缩容操作分为两步完成：第一步迁移，第二步确认

将服务器迁移到另外一个宿主机上。

迁移操作是基于resize操作实现的：

1. 创建一个新的实例，使用相同的flavor
2. 从原始磁盘上拷贝内容到新磁盘

和resize一样，迁移操作是分两步完成的：

1. 执行上述两步的迁移操作
2. 让用户确认，迁移是否成功并移除酒实例，还是执行revert操作 —— 删除新实例并重启老的

确认迁移

撤销迁移 

将服务器在另外一个宿主机上重建。这个命令的使用场景是：实例已经运行，但是后来它所在的宿主机宕掉了。 也就是说，仅当管理此实例的compute service宕机了，才可以使用此命令。

如果服务器实例使用临时的（ephemeral）root磁盘，此磁盘位于非共享存储上，则使用原始的glance镜像重建服务器。连接到原实例的port、挂载的卷被保留。

如果服务器实例从volume启动，或者跟磁盘位于共享存储上，则新建实例会重用此启动盘。

暂停服务器，状态保存在内存中

取消暂停服务器

暂停服务器，状态保存在磁盘中

从暂停中恢复

回退状态为软删除的服务器

重启服务器

启动服务器

停止服务器

重建服务器

让服务器进入rescue模式

从rescue模式恢复：

将服务器实例作为镜像，保存在glance中，然后在宿主机上删除此服务器 

将shelve的实例恢复

通过SSH连接到服务器

创建服务器的Dump文件。这会触发一个crash dump（例如Linux的kdump） 

（软）删除服务器

设置服务器属性

锁定实例，这样非admin用户就不能对它进行任何操作。

解锁服务器

备份一个运行中的服务器实例，将其磁盘保存为镜像，存放在Glance中。

从运行中的实例创建磁盘镜像，并存放到Glance中。

服务器事件，记录了针对服务器的各种操作。事件由操作类型（create, delete, reboot ...）+ 操作结果（success, error） + 开始/结束时间组成。

一个网络服务提供者，表示一个特定的、实现了网络服务的驱动：

所谓网络，是指一个独立的（isolated）的L2网段。OpenStack具有两种类型的网络：

1. project：完全隔离的、不和其它项目共享的网络。自服务网络
2. provider：映射到现有的、数据中心中的物理网络，为server或其它资源提供外部网络访问

仅仅管理员可以创建provider网络

子网是一段IP地址以及关联的配置状态。当新的Port接入到网络中时，子网用于向Port分配IP地址。

子网池中包含若干CIDR格式的子网前缀，这些前缀用于分配给子网。

表示IPv4或IPv6的地址范围，属于某个特定项目，可以被多个项目共享。

虚拟路由器是一个逻辑组件，能够在不同网络之间分发数据包。虚拟路由器也提供L3和NAT转发功能，让虚拟网络中的服务器能够访问外部流量。

端口是网络上的接入点，它可以将单个设备（例如server上的NIC）连接到网络。端口也描述了其关联的网络配置，例如MAC地址、IP地址

安全组是虚拟的网络防火墙，网络中的服务器、端口等资源可以受其影响。

安全组是安全组规则的容器。

安全组中的一条规则。

可以让管理员快速的设置某个项目的外部连接性。每个项目只能有一个此对象。

扩展network flavor允许用户在创建资源时，选择管理员配置的“网络风格”

用于管理员创建/删除/列出/显示网络服务的profile。

允许管理员来度量某个IP范围的流量。需要L3 metering extension

为某个meter设置度量网络流量的规则。需要L3 metering extension

将一组网络QoS规则组合到一起，可以应用到一个网络或端口。

上述policy中的一个规则

表示一个网络中的隔离的L2的段。一个（虚拟）网络可以包含多个段，同一个网络中的段的L2通信不被保证。

用于多租户下的网络段分配。可以让管理员全局的，或者基于用户的，来控制网络段范围。

所谓网络代理，负责（在节点上）处理各种任务，以实现虚拟网络。网络代理包括：

1. neutron-dhcp-agent，负责提供DHCP服务给虚拟机
2. neutron-l3-agent，负责在自服务网络中提供路由
3. neutron-metering-agent
4. neutron-lbaas-agent

显示网络可用的IP地址

管理浮动IP

浮动IP池管理

创建浮动IP端口转发规则

管理卷服务

管理卷

管理卷类型

将卷迁移到一个新的宿主机 

管理卷的快照

管理卷备份

从备份中恢复卷

管理卷关联的QoS规格，将QoS规格关联到卷类型

可以让一组卷同时进行快照，以保证数据一致性

定义Object Storage V1中的一个命名空间。

管理对象存储中的对象。

账户是container - objects树结构的最根部。

很多功能和openstack命令重复，建议使用openstack命令，仅仅在使用某些高级特性时，才需要底层的nova命令。

为虚拟机添加安全组

列出指定虚拟机的安全组

将虚拟机从安全组移除

创建agent build， 类似的agent-delete、agent-list、agent-modify命令完成相关CRUD操作

管理服务器聚合， 类似的aggregate-delete、aggregate-list、aggregate-update、aggregate-show命令完成相关CRUD操作

添加虚拟机到聚合中。类似的aggregate-remove-host用于移除虚拟机

缓存镜像到聚合的所有虚拟机中

更新和聚合关联的元数据

创建（基于策略的）虚拟机分组。 类似的server-group-delete、server-group-list、server-group-get命令完成相关CRUD操作

列出可用区

列出虚拟机

修改虚拟机的名字或描述

显示单个虚拟机的详细信息

SSH到虚拟机

启动虚拟机

停止虚拟机

通过创建backup类型的快照，来备份一个虚拟机

启动一个新的虚拟机

从元数据服务器上清除某个虚拟机的管理密码，不会改变实例的密码

获取虚拟机的管理密码，调用元数据服务器，而不是虚拟机自身

设置虚拟机密码

获取虚拟机控制台日志

重置虚拟机状态

锁定虚拟机，非管理员将无法对虚拟机进行操作

解锁虚拟机

在内存中暂停虚拟机

解除内存中暂停的虚拟机

暂停虚拟机到磁盘

恢复暂停到磁盘的虚拟机

重启虚拟机

重启虚拟机进入救援模式 —— 从虚拟机的初始镜像或另外一个特定镜像启动虚拟机，将当前book disk挂载为非boot disk

重启虚拟机，进入正常模式

触发虚拟机crash dump

立即关机，同时删除实例

恢复一个软删除的实例

强制删除一个虚拟机

重建（关机、re-image、启动）虚拟机

保存虚拟机为镜像

将镜像化的虚拟机恢复

将shelved的虚拟机从宿主机上删除

设置/删除虚拟机的元数据

获取虚拟机诊断信息

重建失败宿主机上的某个虚拟机

迁移虚拟机

修改虚拟机规格，即flavor

确认修改规格操作

撤销尚未确认的resize操作，虚拟机恢复原状

对指定的虚拟机进行在线迁移

中止正在进行的在线迁移。需要Nova API版本2.24+

强制结束正在进行的在线迁移

显示某次虚拟机迁移的详细信息

列出指定虚拟机的迁移

列出所有迁移

添加一个或多个tag到虚拟机，类似的server-tag-delete、server-tag-delete-all、server-tag-list、server-tag-set完成相应CRUD操作

为某个租户增加某个flavor的权限。类似的flavor-access-remove移除某个租户访问某个flavor的权限

查看某个flavor的访问权限列表

创建一个flavor。类似的 flavor-delete、flavor-list、flavor-update、flavor-show命令完成相关CRUD操作。

为某个flavor设置或清除extra_spec。

达到虚拟机的RDP控制台

得到寻机的串口控制台

得到虚拟机的Spice控制台

得到虚拟机的VNC控制台

重建失败宿主机上的所有实例

对指定宿主机上所有虚拟机执行在线迁移操作

对指定宿主机上所有虚拟机执行迁移操作

设置/删除宿主机上所有的虚拟机的元数据

列出可用的Hypervisor

列出基于指定Hypervisor的虚拟机

查看Hypervisor的详细信息

显示所有Hypervisor的总和统计信息

显示指定Hypervisor的已启动时间

通过获取虚拟机快照，来创建新的镜像

列出针对指定虚拟机的操作历史

为虚拟机添加一个网络接口（Port）

列出连接到虚拟机的Port

刷新虚拟机的网络信息

重置虚拟机的网络

添加一个卷给虚拟机

将某个卷从虚拟机移除

列出所有添加到虚拟机的卷

将指定的、已经添加到虚拟机的卷的数据，拷贝到另外一个可用（没有被其它虚拟机使用）的卷上，然后将当前挂载的卷换成新的（接收数据拷贝的哪个）

添加访问虚拟机的密钥。类似的 keypair-delete、keypair-list、keypair-show命令完成相关CRUD操作。

显示一个quota class的配额信息

更新quota class的配额值

列出租户的默认配额

为一个用户/租户删除配额，配额值恢复为默认

显示指定用户/租户的配额

为指定用户/租户更新配额

显示单个租户的用量信息

列出所有租户的用量信息

列出所有API 版本

删除服务

禁用服务

启用服务

强制停止服务

列出运行中的服务

用于bash自动补全。脚本文件位于：/etc/bash_completion.d/nova，可以直接拷贝到其它机器使用

列出针对某个用户的，存储（总计、备份、快照、卷等）用量的硬限制

创建一个卷的备份

删除一个卷备份

导出备份元数据

导入备份元数据

列出所有备份

显式的更新备份状态

从一个备份恢复

显示备份详细信息

更新一个备份

创建一个卷

删除一个或多个卷

尝试扩展一个卷的尺寸

进行故障转移，要求卷是replicated

强制删除卷，不管其状态如何

冻结并且禁用指定的卷主机

显示卷的后端的统计信息、属性

显示卷的池信息：

 每个主机上的lvm后端，独立作为一个池。但是在各主机上都配置了的、指向同一NFS export的，只显示了一个池

列出所有卷

将卷迁移到一个新的主机上

为指定的卷类型设置QoS规格

创建一个QoS规格

删除一个QoS规格

解除一个QoS规格和一个卷类型的关联

解除一个QoS规格的所有关联

列出QoS规格的关联

设置/删除QoS规格的某个属性

列出所有的QoS规格

列出一个配额类（quota class）的所有配额属性

更新配额类的属性

列出租户的默认配额

为一个租户删除配额

显示某个租户的当前配额

更新一个租户的配额

列出一个租户的配额使用情况

列出一个租户的速率限制

重命名卷

在Cinder数据库中显式的重置卷的状态

修改卷的类型

将某个卷回退到某个快照

禁用一个卷服务：

要删除卷服务，需要：

创建卷快照

删除卷快照

列出卷快照

管理卷快照

设置或删除快照元数据

查看快照元数据

重命名快照

显式的重置快照状态

显示卷快照的信息

停止管理卷快照

接受一个卷转移（volume transfer）

创建一个卷转移

撤销一个卷转移

列出所有卷转移

显示卷转移的信息

授予指定项目（租户）访问某个卷类型的权限

列出卷类型的访问权限

移除卷类型的访问权限

配置好一个卷后端后，需要使用该命令，创建对应的卷类型，并且将类型关联到后端：

显示默认使用的卷类型：

通过type-update修改默认卷类型的名字，会导致出错。你必须同步修改控制节点的cinder.conf：

删除卷类型

设置/删除卷类型的额外规格（extra_spec）

列出所有卷类型

显示一个卷类型的详细信息

根据ID来更新一个卷类型的名字、描述、是否公开：

停止管理卷

将卷上传到镜像服务，作为镜像使用

本章按照官网的样例架构，搭建最小化的OpenStack集群。此集群和生产环境架构的不同之处是：

1. 网络代理（networking agents）部署在控制器节点上，而非专用的网络节点
2. 自服务网络（self-service networks）的隧道（Overlay）流量，通过管理网络（management network）而非专用网络传递

此集群包含如下角色的节点：

1. Controller：要求2张NIC
   1. 部署Identity Service、Image Service、计算服务的管理部分、网络服务的管理部分、Web仪表盘，以及多种网络代理
   2. 部署支持性服务，包括SQL数据库、消息代理、NTP
   3. 可选的，部署块存储服务、对象存储服务、编排服务、遥测服务的部分组件
2. Compute：要求2张NIC
   1. 部署计算服务的Hypervisor部分，能够操控Instance。默认Hypervisor是KVM
   2. 部署一个网络代理，用于将Instance连接到虚拟网络，并通过安全组为Instance提供防火墙服务
3. Block Storage：可选的，为Instance提供块存储、共享文件系统服务。在本示例环境中，计算节点和块存储节点之间的流量通过管理网络传输，生产环境下应该有独立的存储网络
4. Object Storage：可选的，用于对象存储的服务

推荐使用两套物理网络：

1. 管理网络（management network，10.1.0.0/16）：通过NAT连接到互联网。绝大部分情况下，节点需要连接到外网（例如安装软件包）时，都应该通过管理网
2. 提供者网络（provider network，10.0.0.0/16）：这是虚拟机的工作负载流量所使用的网络，在：
   1. 网络选项一（提供者网络）下，虚拟机直接连接到此网络
   2. 网络选项二（自服务网络）下，虚拟机连接到自服务网络，然后NAT到此网络以获得外部连接

此集群可以选用两种虚拟网络之一。

Provider networks，也就是外部网络。以最简单的方式部署OpenStack网络服务，通常基于L2（桥接/交换）服务和网络VLAN分段实现。这种选项将虚拟网络桥接到物理网络，依赖于物理网络基础设施完成L3服务。

此外，一个DHCP服务用于为Instance提供IP地址。

这种选项不支持一些高级特性，例如LBaaS、FWaaS。

所谓自服务，是指非特权账户在不需要管理员介入的情况下，管理虚拟化基础设施 —— 例如网络的能力。

这种选项通过提供L3（路由）服务来增强提供者网络，使用的是类似VXLAN之类的overlay segmentation技术。虚拟网络到物理网络的路由通过NAT实现。

OpenStack用户可以在不了解数据网络（data network）底层基础设施的情况下，创建虚拟网络。包括VLAN网络（如果L2插件被相应的配置）。 

安装软件：

配置Shell自动完成： 

OpenStack由一系列独立安装的、相互协作的组件构成。

略，参考Ubuntu的时钟同步

Keystone为OpenStack提供身份（Identity）服务。Keystone可以提供四种Token（代表请求者身份），样例环境使用Fernet Token，同时基于Apache HTTP Server来处理请求。

首先，你需要安装一个数据库： 

创建并修改配置文件：

启用服务：

启用安全配置：

安装RabbitMQ：

创建一个RabbitMQ用户：

为用户openstack授予配置、读写权限：

Identity Service使用Memcached来缓存Tokens。

安装软件：

 修改配置：

启动服务：

OpenStack组件可能需要使用Etcd来实现分布式键锁定、配置存储、跟踪服务是否存活。

安装软件：

修改配置文件：

启动服务：

为Keystone创建数据库和用户：

然后，安装以下包： 

编辑Keystone配置文件：

初始化数据库：

初始化Fernet密钥存储库：

启动Identity服务：

编辑Apache配置文件： 

将Keystone的配置文件链接到Apache配置目录：

启动Apache服务：

为了后续使用OpenStack工具时进行身份验证，你需要设置环境变量（密码来自上面的 keystone-manage bootstrap 步骤）：

现在，我们需要需要创建一些OpenStack对象：

Glance为OpenStack提供（虚拟机）镜像服务，Glance支持多种后端存储，本样例环境下我们直接存放在文件系统中。

首先，需要为Glance创建数据库：

使用OpenStack命令行来创建Glance的凭证信息，注意需要进行上述环境变量设置： 

为service项目中的glance用户添加admin角色：

创建Glance服务： 

为Glance服务添加一个端点：

下面，需要安装和配置Glance组件。安装软件包：

修改配置文件：

初始化Glance数据库：

启动服务：

为了测试OpenStack，建议使用CirrOS镜像。

在Stein版本之前，placement 的代码在Nova中，服务在compute REST API（nova-api）中。

Placement提供了WSGI脚本placement-api，可以在Apache/Nginx之类的WSGI-capable服务器中使用。取决于你的安装方式，该脚本可能位于/usr/bin或/usr/local/bin下面。

为Placement创建数据库：

创建用户和端点：

安装和配置Placement组件：

修改配置文件：

初始化数据库：

修改Apache配置文件（否则可能计算节点nova报 You don't have permission to access this resource）：

重启Apache服务：

创建数据库：

创建用户和端点：

安装组件：

修改配置文件： 

初始化数据库：

校验一下，确保cell0和cell1正确的注册了： 

启动服务：

安装软件：

修改配置文件：

启动服务：

如果nova-compute启动失败，检查日志： /var/log/nova/nova-compute.log。

最后，将该节点加入到cell数据库中：

创建数据库：

创建用户和端点：

如果使用提供者网络，也就是直接将VM添加到外部网络，不提供自服务网络（以及路由器、浮动IP等），则需要使用admin或其它特权账户。步骤如下：

1. 安装软件：
   
   Shell

   1	dnf -y install openstack-neutron openstack-neutron-ml2 openstack-neutron-linuxbridge ebtables

2. 配置Neutron：
   
   /etc/neutron/neutron.conf

   INI

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

   [database] connection = mysql+pymysql://neutron:neutron@os.gmem.cc/neutron   [DEFAULT] core_plugin = ml2 service_plugins =   transport_url = rabbit://openstack:openstack@os.gmem.cc   auth_strategy = keystone   notify_nova_on_port_status_changes = true notify_nova_on_port_data_changes = true   [keystone_authtoken] www_authenticate_uri = http://os.gmem.cc:5000 auth_url = http://os.gmem.cc:5000 memcached_servers = os.gmem.cc:11211 auth_type = password project_domain_name = default user_domain_name = default project_name = service username = neutron password = neutron   [nova] auth_url = http://os.gmem.cc:5000 auth_type = password project_domain_name = default user_domain_name = default region_name = china project_name = service username = nova password = nova   [oslo_concurrency] lock_path = /var/lib/neutron/tmp

3. 配置Modular Layer2（ML2）插件。此插件使用Linux bridge来为虚拟机构建L2 VNI：

   /etc/neutron/plugins/ml2/ml2_conf.ini

   INI

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

   [ml2] ; 启用Flat/VLAN网络 type_drivers = flat,vlan ; 禁用自服务网络 tenant_network_types = ; 启用 Linux bridge mechanism mechanism_drivers = linuxbridge ; 启用端口安全扩展驱动 extension_drivers = port_security   [ml2_type_flat] ; 配置提供者虚拟网络为Flat网络 flat_networks = provider   [securitygroup] ; 增强安全组规则的性能 enable_ipset = true

4.  配置Linux Bridge agent，此Agent为VM构建L2 VNI，并处理安全组：

   /etc/neutron/plugins/ml2/linuxbridge_agent.ini

   INI

   1 2 3 4 5 6 7 8 9 10 11 12

   [linux_bridge] ; 这里填写底层的提供者网络的设备名 physical_interface_mappings = provider:eth0   [vxlan] ; 禁用VXLAN enable_vxlan = false   [securitygroup] ; 启用安全组，配置基于iptables的防火墙驱动 enable_security_group = true firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver

5. 确保宿主机内核支持Network bridge filters：

   Shell

   1 2 3

   # 二层的网桥在转发包时也会被iptables的FORWARD规则所过滤 net.bridge.bridge-nf-call-iptables  1 net.bridge.bridge-nf-call-ip6tables 1

   此外，为了支持网桥，需要加载内核模块 br_netfilter

6.  配置DHCP代理，此代理为虚拟网络提供DHCP服务：

   /etc/neutron/dhcp_agent.ini

   INI

   1 2 3 4

   [DEFAULT] interface_driver = linuxbridge dhcp_driver = neutron.agent.linux.dhcp.Dnsmasq enable_isolated_metadata = true

如果使用自服务网络，不需要特权用户就可以管理网络（包括路由）并在自服务网络和提供者网络之间创建连接，也可以为VM提供浮动IP，以便从外部访问VM。步骤如下：

1. 安装软件，同上
2. 配置Neutron，基本同上：
   
   /etc/neutron/neutron.conf

   INI

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

   [database] connection = mysql+pymysql://neutron:neutron@os.gmem.cc/neutron   [DEFAULT] ; 同样使用ML2插件 core_plugin = ml2 ; 启用路由服务，允许IP重叠 service_plugins = router allow_overlapping_ips = true   transport_url = rabbit://openstack:openstack@os.gmem.cc   auth_strategy = keystone   notify_nova_on_port_status_changes = true notify_nova_on_port_data_changes = true   [keystone_authtoken] www_authenticate_uri = http://os.gmem.cc:5000 auth_url = http://os.gmem.cc:5000 memcached_servers = os.gmem.cc:11211 auth_type = password project_domain_name = default user_domain_name = default project_name = service username = neutron password = neutron   [nova] auth_url = http://os.gmem.cc:5000 auth_type = password project_domain_name = default user_domain_name = default region_name = china project_name = service username = nova password = nova   [oslo_concurrency] lock_path = /var/lib/neutron/tmp

3.  配置Modular Layer2（ML2）插件：

   /etc/neutron/plugins/ml2/ml2_conf.ini

   INI

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

   [ml2] ; 启用Flat/VLAN/VXLAN type_drivers = flat,vlan,vxlan ; 启用自服务网络，基于VXLAN tenant_network_types = vxlan ; 启用Linux网桥，以及Layer-2 Population mechanism_drivers = linuxbridge,l2population ; 启用端口安全扩展驱动 extension_drivers = port_security   [ml2_type_flat] ; 配置提供者虚拟网络为Flat网络 flat_networks = provider   [ml2_type_vxlan] ; 设置VXLAN网络标识符的范围 vni_ranges = 1:1000   [securitygroup] ; 增强安全组规则的性能 enable_ipset = true

4. 配置Linux Bridge agent：
   
   /etc/neutron/plugins/ml2/linuxbridge_agent.ini

   INI

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

   [linux_bridge] ; 这里填写底层的提供者网络的设备名 physical_interface_mappings = provider:eth0   [vxlan] ; 启用VXLAN enable_vxlan = true ; 用于处理Overlay网络的底层网络的本机IP地址 local_ip = 10.1.0.10 l2_population = true   [securitygroup] ; 启用安全组，配置基于iptables的防火墙驱动 enable_security_group = true firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver

5. 确保宿主机内核支持Network bridge filters，同上

6.  配置DHCP，同上

7. 配置L3代理，此代理为自服务VNI提供路由、NAT：
   
   /etc/neutron/l3_agent.ini

   INI

   1 2	[DEFAULT] interface_driver = linuxbridge

自服务网络是overlay网络，使用VXLAN之类的协议，这些协议具有额外的头，导致实际可能负载减小，如果VM不知道此VNI的特征，会自动设置过大的MTU 1500。Neutron提供的DHCP能自动给VM提供正确的MTU。但是，某些云镜像不使用DHCP，或者忽略DHCP的MTU选项，需要注意。

执行完上述两种网络选项之一后，继续配置元数据代理（metadata agent） ，元数据代理代替虚拟机（附加Instance ID、Tenant ID等请求头）访问Nova metadata API，获取虚拟机镜像的配置信息：

 配置计算服务（Nova）来使用网络服务：

将ML2配置链接为Neutron插件主配置文件：

初始化数据库： 

重启Nova： 

启动Neutron：  

如果使用自服务网络选项，还需要启用L3服务： 

安装软件： 

配置身份验证、消息队列： 

配置网络选项。如果使用提供者网络：

1.  配置Linux bridge Agent：
   
   /etc/neutron/plugins/ml2/linuxbridge_agent.ini

   INI

   1 2 3 4 5 6 7 8 9

   [linux_bridge] physical_interface_mappings = provider:eth0   [vxlan] enable_vxlan = false   [securitygroup] enable_security_group = true firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver

2. 确保内核参数（通常需要保证内核模块br_netfilter已加载 ）：

   Shell

   1 2	net.bridge.bridge-nf-call-iptables 1 net.bridge.bridge-nf-call-ip6tables 1

如果使用自服务网络：

1.  配置Linux bridge Agent：
   
   /etc/neutron/plugins/ml2/linuxbridge_agent.ini

   INI

   1 2 3 4 5 6 7 8 9 10 11

   [linux_bridge] physical_interface_mappings = provider:eth0   [vxlan] enable_vxlan = true local_ip = 10.1.0.11 l2_population = true   [securitygroup] enable_security_group = true firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver

2. 同上 

配置计算服务，让它使用网络服务：

重启Nova： systemctl restart openstack-nova-compute.service

启动Linux bridge Agent：

列出已加载的扩展列表，确保Neutron相关进程启动：

校验Neutron代理都已经启动： 

应该启动的代理包括：

1. 控制节点的元数据代理、DHCP代理、Linux bridge代理
2. 计算节点的Linux bridge代理
3. 如果使用自服务网络，控制节点还有L3代理

样例环境中，使用存储节点上的空白磁盘/dev/sdb ，基于LVM划分初逻辑卷，然后通过iSCSI协议暴露给虚拟机。

创建用户和端点：

安装组件：

修改配置文件：

初始化数据库：

配置Nova来使用存储服务： 

重新启动Nova：

启动Cinder服务： 

在本样例环境下，需要LVM支持：

在/dev/sdb上创建LVM物理卷，并创建名为cinder-volumes的卷组：

只有虚拟机实例能够访问块设备卷。但是，存储节点的底层OS负责管理卷关联的块设备。默认情况下，LVM卷扫描工具会扫描/dev/目录来寻找包含卷的块设备。如果某个OpenStack项目使用基于LVM的卷，扫描工具会扫描卷并缓存结果，这可能导致很多问题。因此，你必须重新配置LVM，让它仅仅扫描包含cinder-volumes卷组的设备：

安装组件： 

修改配置文件： 

启动服务：

OpenStack Dashboard组件，即Horizon，此组件仅仅依赖于Identity。

安装软件：

修改配置文件：

修改配置文件：

重启服务：

此后你应该可以通过：http://os.gmem.cc访问仪表盘。

修改horizon主配置文件：

修改Dashboard的httpd配置：

安装必要的httpd模块：

在启动实例之前，你需要创建必要的VNI。如果使用网络选项一，则虚拟机通过Provider（External）网络连接到PNI（基于bridging/switching）。

网络架构如下图：

 

使用下面的命令在OpenStack中创建一个名为provider的网络：

为上述网络创建一个子网：

前面我们提到过两个网络选项，如果使用选项1，则参考上一小节的内容创建虚拟网络。如果使用选项2，则在创建上述provider网络之后，还需要参考本节内容。

网络架构如下：

 

使用选项2时，需要创建一个自服务（私有）的虚拟网络，并通过NAT连接到物理网络。此虚拟网络提供DHCP服务器，并且分配IP地址给实例。在这种私有网络中的实例可以直接访问外部网络（NAT），但是外部网络不能直接访问这些实例，除非给实例分配浮动IP。

修改环境变量，使用用户gmem来操作。

创建名为gmem的自服务网络：

非特权用户通常无法为上述命令指定额外的参数。OpenStack会依据下面的配置文件来自动选择参数：

创建子网： 

自服务网络通过一个虚拟路由器，连接到提供者网络：

将上述子网添加为此虚拟路由器的一个接口（interface）： 

将在提供者网络上的生成一个“网关“，连接到路由器：

到控制节点上进行校验，确保虚拟网络正常工作：

所谓Flavor就是虚拟机的规格，例如内存多大，CPU几个，磁盘几个，等等。最小的默认Flavor消耗512MB内存，这里我们创建一个仅消耗64MB内存的Flavor：

大部分的云镜像支持基于PKI的身份验证，而不是密码。在启动实例之前，我们需要为计算服务创建密钥： 

默认的安全组应用到所有的实例， 此安全组禁止对实例的所有远程访问。对于Linux镜像例如CirrOS，我们至少应该允许ICMP（ping）以及SSH：

列出可用的基础资源：

当虚拟机构建完毕后，其状态会从BUILD变为ACTIVE：

CirrOS的默认用户密码是cirros / gocubsgo，确认可以登陆。

在虚拟机的宿主机上，可以看到OpenStack创建了一个网桥，连接了提供者物理网络和虚拟机（的tap设备）：

Keystone是OpenStack的Identity服务，它负责身份验证、授权，以及一系列其它服务。Keystone可以集成到外部的用户管理系统，例如LDAP。

Keystone通常是用户首先与之交互的服务，随后用户使用他的Identity来访问其它OpenStack服务。OpenStack组件也需要访问Keystone来验证用户声明的Identity是否合法。

用户或者服务，可以利用服务目录来得到其它服务（Openstack组件）的位置，服务目录（Service catalog）也是Keystone提供的服务之一。

每个服务可以提供1-N个端点，每个端点可以是admin/internal（可能仅限于OpenStack所在主机访问）/public（可能允许Internet访问）三种类型之一。在生产环境中，这些不同类型的端点可能出于安全方面的考虑，存放在不同的网络中，供不同类型的用户访问。

代表单个API消费者：

1. 用户就是一个有身份验证信息的API消费实体
2. 用户可以属于多个项目/角色

代表一组User的集合。

代表OpenStack中基本的所有权单元 —— OpenStack中各种计算资源都是归属于某个特定项目的。而Project则是归属于某个Domain的。

租户（Tenant）在OpenStack中，就是项目，其目的就是隔离计算资源。

是Project、User、Role、Group的高层次容器，后面三者仅仅属于唯一一个domain。Keystone默认提供一个名为Defulat的domain。

Keystone由三类组件构成。

中心化的HTTP服务器，对外提供鉴权的RESTful接口

集成在Server里面，用于访问存放在OpenStack外部（例如LDAP或MySQL数据库）的身份信息。

运行在使用Identity service的那些OpenStack组件中，负责拦截针对这些组件的请求，抽取用户凭证信息，发送到上述Server执行鉴权。

这些Modules基于Python Web Server Gateway Interface和OpenStack组件集成。

Token类型	UUID	PKI	PKIZ	Fernet
大小	32 Byte	KB 级别	KB 级别	约 255 Byte
支持本地认证	不支持	支持	支持	不支持
Keystone 负载	大	小	小	大
存储于数据库	是	是	是	否
携带信息	无	user, catalog 等	user, catalog 等	user 等
涉及加密方式	无	非对称加密	非对称加密	对称加密(AES)
是否压缩	否	否	是	否
版本支持	D	G	J	K

K版本之后，通常选择Fernet Token。

Nova，即OpenStack Compute组件，负责host和管理云主机，是IaaS系统的核心组成部分。可以管理的云主机类型包括虚拟机、物理机（依赖ironic），并对容器提供有限的支持。

Nova和Keystone交互进行身份验证。Placement负责计算资源的跟踪和选择（作为实例的宿主），Glance提供虚拟机镜像，这些组件配合就能让实例运行起来。

OpenStack自身不提供虚拟化软件，而是通过“驱动”和底层的Hypervisor进行交互。交互工作主要由Nova完成。

Nova由一系列分布式的组件构成，每种组件具有自己的职责。面向用户的是一个REST API。内部组件主要通过RPC消息传递机制通信。

API组件监听到请求后，通常会进行数据库读写操作，可选的，会将RPC消息发送给其它Nova组件，然后将REST响应发给客户端。RPC消息是通过 oslo.messaging 库完成的，这个库是基于消息队列的抽象。

大部分组件可以运行在多台宿主机上，并且其中具有一个manager负责监听RPC消息、执行一些周期性工作。一个主要的例外是nova-compute，此组件和它管理的Hypervisor（除了VMware或Ironic驱动）对应，每个Hypervisor对应一个nova-compute。

Nova具有一个逻辑的、中心化的、被所有组件共享的数据库。为了辅助OpenStack升级，对数据库的访问基于一个对象层，此对象层确保一个升级后的控制平面，仍然能和低版本的nova-compute进行交互。具体实现上，nova-compute通过中心化的nova-conductor间接的访问数据库，后者提供基于RPC的接口。

安装在控制节点上。提供OpenStack Compute API，负责确保一些策略，发起大部分编排活动（例如运行实例）。

安装在控制节点上。处理处理获取实例元数据的请求。

安装在计算节点上。Worker守护进程，负责调用Hypervisor API，在计算节点上创建、终结虚拟机实例。支持的Hypervisor API包括：

1. XenAPI for XenServer/XCP
2. libvirt for KVM or QEMU
3. VMwareAPI for VMware

该组件的大概工作流程是：

1. 从消息队列里接受Action
2. 调用一系列的系统命令，启动虚拟机
3. 在数据库中更新实例状态

从队列中取出虚拟机实例的请求，然后决定将其调度在哪台计算节点上。

协调nova-compute s服务和数据库之间的交互。避免nova-compute直接访问数据库。该模块支持水平扩容，避免将其部署在nova-compute运行的节点。

提供一个代理，用于通过VNC协议连接到运行中的实例。

提供一个代理，用于通过SPICE协议连接到运行中的实例，支持HTML5客户端。

这个服务目前已经独立出去，它负责跟踪资源库存、使用情况。

这是一个中心化的Hub，用于在不同组件之间传递消息。通常使用RabbitMQ。

存储云基础设施的构建时、运行时状态，包括：

1. 可用的实例类型
2. 使用着哦个的实例
3. 可用的网络
4. 项目
5. ……

任何SQLAlchemy支持的RDBMS都可以。

为了支持Nova部署的水平扩展，Nova引入了分片机制，每个分片叫Cell。利用Cell：

1. 可以在单个Region中将计算节点的数量扩容到成千上万。每个Cell具有自己的数据库、消息队列，这是可扩容的关键
2. 实现故障隔离的特性（一个Cell故障，其它Cell还可以正常工作）
3. 作为一种分组机制，可以将类似的硬件放在同一Cell中

Cell V1的特性：

1. 捕获并中继消息给Cell
2. 处理竞态条件
3. 两级调度架构

Cell V1的缺点：

1. 不支持安全组、主机聚合、可用区等特性
2. 顶级调度功能很弱

当Nova API接收到针对实例的前请求后，实例的信息将从数据库读取，其中包含实例的宿主机名字。如果需要针对实例进行其它操作（通常都需要），那么宿主机名字将用来计算出消息队列的名字，RPC消息随后被写入消息队列，可以到达正确的计算节点。

引入Cell后，上述逻辑将变成：

1. 查找实例的三元组：宿主机名称、数据库连接信息、消息队列连接信息
2. 连接到数据库，获取实例记录
3. 连接到消息队列，并根据宿主机名称，选额消息队列，发送RPC消息

引入Cell V2后，不存在没有Cell的部署架构。Cell V2的优势包括：

1. 数据库、消息队列的分片，成为Nova的一等特性
2. 不需要在顶级复制Cell数据库，Nova API需要自己的数据库，存放例如实例索引的信息
3. 在gloabl和local数据元素之间划分好了界限。Flavor、Keypair之类的全局性质对象，仅仅需要存储在顶级。这样计算节点更加无状态化，不会被全局数据的修改所干扰

所有Nova部署中，都需要一个名为API的数据库，一个特殊的Cell数据库cell0，1-N个cell的数据库。高层次的跟踪信息存放在API数据库中，哪些从未调度成功的实例，存放在cell0。所有成功调度的/运行的实例，都放在其它cell数据库中。

你需要将API数据库的信息配置在nova.conf：

由于cell数据库数量不定，此外任何部署都至少有cell0和cell1（唯一的Cell使用），因此这些Cell的连接信息，是写在API数据库中（而不是静态编写在文件）的。

由于cell0中不会存在任何宿主机，不需要对它进行进一步配置。

现在，你需要创建第一个常规cell： 

如果为cell1准备的数据库是空白的，你需要同步数据库schema：

现在，cell1中没有任何宿主机，因此nova-scheduler不会把实例调度到此cell中。

使用下面的命令，可以扫描数据库中计算节点的记录，并将其添加到刚刚创建的cell中。执行命令之前，至少需要安装一个计算节点并添加到cell。

上述命令会连接到所有cell数据库，扫描将自己注册到cell的宿主机，然后在API数据库中映射这些宿主机，这样nova-scheduler就可以进行调度了。

任何时候，你加入新的宿主机到cell，都需要调用此命令（或者启用自动发现）。

我们知道计算节点通过消息队列和控制平面通信，也不会直接访问数据库。实际上，计算节点属于哪个cell，就看它通过哪个消息队列连接。你只需要配置计算节点的nova.conf：

然后再启动nova-compute服务，最后验证、确保节点在下面命令的输出中： 

就将计算节点添加到cell中了。 

要实现自动发现添加到cell的计算节点，并通过到API数据库，可以配置所有nova-scheduler节点的nova.conf：

到目前为止（V版），还不支持跨Cell迁移实例。影响的操作包括resize/evacuate/migrate等。

如果Cell不可达，那么针对租户的用量统计信息可能不准确。

从T版开始，可以配置在Placement服务+API数据库上进行Quota统计，这样宕掉/性能很差的Cell不会导致用量统计不准确。

多Cell环境下，列出实例的结果可能没有排序、分页可能不正确。

从S版开始，元数据服务可以运行为两种模式之一：全局/PerCell。使用api.local_metadata_per_cell配置项

Nova将它启动的实例的配置信息呈现为元数据。cloud-init之类的助手会在虚拟机初始化时，利用元数据进行配置工作，例如设置虚拟机root密码。

通过元数据服务、或者config drive，元数据变的可（被实例使）用。你还可以通过nova api的user data特性来定制实例的元数据。

类别	说明
用户提供	创建实例的用户可以通过多种方式，将元数据传递给实例： 实例nova api的keypairs功能，可以设置宿主机的登陆密钥 使用nova api的user data特性，可以传递一小块opaque blob
Nova提供	Nova自身会添加一些元数据，例如实例所在宿主机名称、实例所在AZ。 Nova提供OpenStack metadata API，以及EC2-compatible API。两者都是以日期来版本化的
部署者提供	对于创建实例的用户来说未知，由OpenStack的部署者提供。通过vendordata特性可以实现。用于实现在实例创建后，自动加入AD这样的网络管理类功能

控制节点上的Neutron元数据代理服务，负责代替虚拟机Nova metadata API。并自动设置正确的Instance ID、Tenant ID等请求头。

元数据服务为实例提供了一种获取自身元数据的REST API。实例可以通过169.254.169.254或者fe80::a9fe:a9fe访问此REST API，如此奇怪的地址是兼容Amazon EC2的考虑。在Openstack里面，这两个IP通过iptables映射到控制节点。

所有上述三类元数据，都可以通过此REST API访问：

Config drive是一种特殊的drive，在实例boot时添加。实例可以挂载此drive，读取其中的文件，从而获取（通常应该从metadata service获取的）信息。

下面的命令示意了如何使用在创建实例时使用config drive：

如果客户机操作系统支持udev，则可以这样挂载config drive： 

否则，这样识别config drive对应的块设备：

config drive中的文件目录结构，和metadata service的URL结构对应：

OpenStack元数据基于JSON格式分发： 

1. meta_data.json：提供Nova相关的信息
2.  network_data.json：提供从Neutron获取的，网络相关信息

示例：

兼容Amazon EC2 metadata service 2009-04-04版本。这意味着，为EC2设计的虚拟机镜像，可以和OpenStack一起工作。

EC2 API为每个元数据暴露了独立的URL：

就是一小段blob，OpenStack不知道它内容的意义。传递user data： 

在客户机里面访问user data： 

支持cloud-init的镜像，可以利用user data，定制实例的初始化过程。

这类数据可以通过metadata service或config drive读取。对于前者： 

cloud-init是一个在主要Linux发行版中都支持的包，用于在云环境（例如OpenStack）中初始化虚拟机实例。cloud-init在虚拟机第一次运行时执行。

cloud-init集成到系统启动的五个Stage，以发挥作用：

Stage	说明
Generator	基于Systemd启动时，此阶段中有一个Generator用于确认cloud-init.target十分需要包含在Boot Goals中。默认情况下此Generator会启用cloud-init，以下情形之一，则不启用： 文件 /etc/cloud/cloud-init.disabled存在 内核命令行参数 /proc/cmdline包含 cloud-init=disabled
Local	此Stage运行一个Systemd服务cloud-init-local.service。该服务在 / 挂载为读写后立即执行，block尽可能多的Systemd启动单元，必须block网络 该Stage的意图包括： 定位到“local”数据源 应用网络配置到系统（包含Fallback）。网络配置的来源可能包括： datasource，云环境通过元数据（Metadata）提供的网络配置信息 fallback，cloud-init的备用网络配置，等价于dhcp on eth0 none，如果/etc/cloud/cloud.cfg包含配置 network: {config: disabled}
Network	此Stage运行一个Systemd服务cloud-init.service。该服务在Local Stage之后，所有网络启动后运行。包含的模块定义在/etc/cloud/cloud.cfg中 此Stage会处理所有user-data，所谓处理指： 递归的读取 #include或 #include-once 展开所有压缩内容 运行发现的所有 part-handler 此Stage会运行disk_setup、mounts模块，从而进行分区、格式化、配置挂载点（/etc/fstab）。这些模块不能运行的更早，韵味可能依赖于需要从网络才能得到的配置输入，例如用户提供的位于网络资源中的user-data
Config	此Stage运行一个Systemd服务cloud-config.service。包含的模块定义在/etc/cloud/cloud.cfg中 对于其他Boot Stage不产生影响的模块运行在此Stage
Final	此Stage运行一个Systemd服务cloud-final.service。它的运行时机相当于rc.local，也就是在启动的最后阶段。可以做的事情包括： 安装软件包 执行用户定义的、通过user-data传递的脚本

cloud-init需要判断实例是否第一次启动。在第一次启动时，会运行 per-instance的配置；在后续启动时，仅运行 per-boot的配置。

在运行的时候，cloud-init会将内部状态缓存起来，共后续boot读取。缓存存在，意味着两种情况之一：

1. 实例不是第一次启动
2. 文件系统被挂载给一个新实例，该实例是第一次启动。将一个OpenStack卷上传为镜像，然后从此镜像启动新实例，就会导致这种情况

默认情况下，cloud-init检查缓存中的实例ID，和运行时获取的实例ID，来判断是上述两种情况的哪一种。

使用命令 cloud-init clean可以清空缓存。

cloud-init的主配置文件位于 /etc/cloud/cloud.cfg， /etc/cloud/cloud.cfg.d目录中的所有其它文件都会被合并。CentOS 8云镜像的配置文件如下：

用户数据支持多种形式：

格式	说明
Gzip压缩内容	任何user-data都可以压缩为gzip格式，cloud-init会解压它，然后再处理
MIME Multi Part Archive	使用此格式，用户可以指定多种类型的数据，例如同时指定一个user-data script和cloud-config。支持的类型包括： Shell 1 2 3 4 5 6 7 8 9 10 11 # cloud-init devel make-mime --list-types cloud-boothook cloud-config cloud-config-archive cloud-config-jsonp jinja2 part-handler upstart-job x-include-once-url x-include-url x-shellscript 使用make-mime子命令可以生成MIME multi-part文件： Shell 1 2 cloud-init devel make-mime -a config.yaml:cloud-config \                            -a script.sh:x-shellscript > user-data
User-Data Script	就是一段脚本，需要以 #!开头，包含在MIME Multi Part Archive中时使用Content-Type：text/x-shellscript
Include File	文件包含一系列URL，每个URL一行，这些URL会被读取，从中获取Gzip压缩内容、MIME Multi Part Archive，或者普通文本 需要以 #include开头，包含在MIME Multi Part Archive中时使用Content-Type： text/x-include-url
Cloud Config Data	这是最简单的通过user-data来实现实例定制的方式。就是提供一个YAML配置文件 需要以 #cloud-config开头，包含在MIME Multi Part Archive中时使用Content-Type：text/cloud-config 定制用户、组的例子： YAML 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 #cloud-config # Add groups to the system # The following example adds the ubuntu group with members 'root' and 'sys' # and the empty group cloud-users. groups:   - ubuntu: [root,sys]   - cloud-users   # Add users to the system. Users are added after groups are added. # Note: Most of these configuration options will not be honored if the user #       already exists. Following options are the exceptions and they are #       applicable on already-existing users: #       - 'plain_text_passwd', 'hashed_passwd', 'lock_passwd', 'sudo', #         'ssh_authorized_keys', 'ssh_redirect_user'. users:   - default   - name: foobar     gecos: Foo B. Bar     primary_group: foobar     groups: users     selinux_user: staff_u     expiredate: '2012-09-01'     ssh_import_id: foobar     lock_passwd: false     passwd: $6$j212wezy$7H/1LT4f9/N3wpgNunhsIqtMj62OKiS3nyNwuizouQc3u7MbYCarYeAHWYPYb2FT.lbioDm2RrkJPb9BZMN1O/   - name: barfoo     gecos: Bar B. Foo     sudo: ALL=(ALL) NOPASSWD:ALL     groups: users, admin     ssh_import_id: None     lock_passwd: true     ssh_authorized_keys:       - <ssh pub key 1>       - <ssh pub key 2>   - name: cloudy     gecos: Magic Cloud App Daemon User     inactive: '5'     system: true   - name: fizzbuzz     sudo: False     ssh_authorized_keys:       - <ssh pub key 1>       - <ssh pub key 2>   - snapuser: joe@joeuser.io   - name: nosshlogins     ssh_redirect_user: true   # Valid Values: #   name: The user's login name #   expiredate: Date on which the user's account will be disabled. #   gecos: The user name's real name, i.e. "Bob B. Smith" #   homedir: Optional. Set to the local path you want to use. Defaults to #           /home/<username> #   primary_group: define the primary group. Defaults to a new group created #           named after the user. #   groups:  Optional. Additional groups to add the user to. Defaults to none #   selinux_user:  Optional. The SELinux user for the user's login, such as #           "staff_u". When this is omitted the system will select the default #           SELinux user. #   lock_passwd: Defaults to true. Lock the password to disable password login #   inactive: Number of days after password expires until account is disabled #   passwd: The hash -- not the password itself -- of the password you want #           to use for this user. You can generate a safe hash via: #               mkpasswd --method=SHA-512 --rounds=4096 #           (the above command would create from stdin an SHA-512 password hash #           with 4096 salt rounds) # #           Please note: while the use of a hashed password is better than #               plain text, the use of this feature is not ideal. Also, #               using a high number of salting rounds will help, but it should #               not be relied upon. # #               To highlight this risk, running John the Ripper against the #               example hash above, with a readily available wordlist, revealed #               the true password in 12 seconds on a i7-2620QM. # #               In other words, this feature is a potential security risk and is #               provided for your convenience only. If you do not fully trust the #               medium over which your cloud-config will be transmitted, then you #               should use SSH authentication only. # #               You have thus been warned. #   no_create_home: When set to true, do not create home directory. #   no_user_group: When set to true, do not create a group named after the user. #   no_log_init: When set to true, do not initialize lastlog and faillog database. #   ssh_import_id: Optional. Import SSH ids #   ssh_authorized_keys: Optional. [list] Add keys to user's authorized keys file #   ssh_redirect_user: Optional. [bool] Set true to block ssh logins for cloud #       ssh public keys and emit a message redirecting logins to #       use <default_username> instead. This option only disables cloud #       provided public-keys. An error will be raised if ssh_authorized_keys #       or ssh_import_id is provided for the same user. # #       ssh_authorized_keys. #   sudo: Defaults to none. Accepts a sudo rule string, a list of sudo rule #         strings or False to explicitly deny sudo usage. Examples: # #         Allow a user unrestricted sudo access. #             sudo:  ALL=(ALL) NOPASSWD:ALL # #         Adding multiple sudo rule strings. #             sudo: #               - ALL=(ALL) NOPASSWD:/bin/mysql #               - ALL=(ALL) ALL # #         Prevent sudo access for a user. #             sudo: False # #         Note: Please double check your syntax and make sure it is valid. #               cloud-init does not parse/check the syntax of the sudo #               directive. #   system: Create the user as a system user. This means no home directory. #   snapuser: Create a Snappy (Ubuntu-Core) user via the snap create-user #             command available on Ubuntu systems.  If the user has an account #             on the Ubuntu SSO, specifying the email will allow snap to #             request a username and any public ssh keys and will import #             these into the system with username specifed by SSO account. #             If 'username' is not set in SSO, then username will be the #             shortname before the email domain. #   # Default user creation: # # Unless you define users, you will get a 'ubuntu' user on ubuntu systems with the # legacy permission (no password sudo, locked user, etc). If however, you want # to have the 'ubuntu' user in addition to other users, you need to instruct # cloud-init that you also want the default user. To do this use the following # syntax: #   users: #     - default #     - bob #     - .... #  foobar: ... # # users[0] (the first user in users) overrides the user directive. # # The 'default' user above references the distro's config: # system_info: #   default_user: #     name: Ubuntu #     plain_text_passwd: 'ubuntu' #     home: /home/ubuntu #     shell: /bin/bash #     lock_passwd: True #     gecos: Ubuntu #     groups: [adm, audio, cdrom, dialout, floppy, video, plugdev, dip, netdev] 写入到文件系统的例子： YAML 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 #cloud-config # vim: syntax=yaml # # This is the configuration syntax that the write_files module # will know how to understand. encoding can be given b64 or gzip or (gz+b64). # The content will be decoded accordingly and then written to the path that is # provided. # # Note: Content strings here are truncated for example purposes. write_files: - encoding: b64   content: CiMgVGhpcyBmaWxlIGNvbnRyb2xzIHRoZSBzdGF0ZSBvZiBTRUxpbnV4...   owner: root:root   path: /etc/sysconfig/selinux   permissions: '0644' - content: |     # My new /etc/sysconfig/samba file       SMBDOPTIONS="-D"   path: /etc/sysconfig/samba - content: !!binary |     f0VMRgIBAQAAAAAAAAAAAAIAPgABAAAAwARAAAAAAABAAAAAAAAAAJAVAAAAAAAAAAAAAEAAOAAI     AEAAHgAdAAYAAAAFAAAAQAAAAAAAAABAAEAAAAAAAEAAQAAAAAAAwAEAAAAAAADAAQAAAAAAAAgA     AAAAAAAAAwAAAAQAAAAAAgAAAAAAAAACQAAAAAAAAAJAAAAAAAAcAAAAAAAAABwAAAAAAAAAAQAA     ....   path: /bin/arch   permissions: '0555' - encoding: gzip   content: !!binary |     H4sIAIDb/U8C/1NW1E/KzNMvzuBKTc7IV8hIzcnJVyjPL8pJ4QIA6N+MVxsAAAA=   path: /usr/bin/hello   permissions: '0755' 添加YUM源： YAML 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 #cloud-config # vim: syntax=yaml # # Add yum repository configuration to the system # # The following example adds the file /etc/yum.repos.d/epel_testing.repo # which can then subsequently be used by yum for later operations. yum_repos:   # The name of the repository   epel-testing:     # Any repository configuration options     # See: man yum.conf     #     # This one is required!     baseurl: http://download.fedoraproject.org/pub/epel/testing/5/$basearch     enabled: false     failovermethod: priority     gpgcheck: true     gpgkey: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL     name: Extra Packages for Enterprise Linux 5 - Testing 添加APT源： YAML 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 #cloud-config   # Add primary apt repositories # # To add 3rd party repositories, see cloud-config-apt.txt or the # Additional apt configuration and repositories section. # # # Default: auto select based on cloud metadata #  in ec2, the default is <region>.archive.ubuntu.com # apt: #   primary: #     - arches [default] #       uri: #     use the provided mirror #       search: #     search the list for the first mirror. #     this is currently very limited, only verifying that #     the mirror is dns resolvable or an IP address # # if neither mirror is set (the default) # then use the mirror provided by the DataSource found. # In EC2, that means using <region>.ec2.archive.ubuntu.com # # if no mirror is provided by the DataSource, but 'search_dns' is # true, then search for dns names '<distro>-mirror' in each of # - fqdn of this host per cloud metadata # - localdomain # - no domain (which would search domains listed in /etc/resolv.conf) # If there is a dns entry for <distro>-mirror, then it is assumed that there # is a distro mirror at http://<distro>-mirror.<domain>/<distro> # # That gives the cloud provider the opportunity to set mirrors of a distro # up and expose them only by creating dns entries. # # if none of that is found, then the default distro mirror is used apt:   primary:     - arches: [default]       uri: http://us.archive.ubuntu.com/ubuntu/ # or apt:   primary:     - arches: [default]       search:         - http://local-mirror.mydomain         - http://archive.ubuntu.com # or apt:   primary:     - arches: [default]       search_dns: True 在首次启动时更新APT数据库： YAML 1 2 3 4 5 6 7 8 #cloud-config # Update apt database on first boot (run 'apt-get update'). # Note, if packages are given, or package_upgrade is true, then # update will be done independent of this setting. # # Default: false # Aliases: apt_update package_update: true 执行YUM/APT Upgrade： YAML 1 2 3 4 5 6 7 8 #cloud-config   # Upgrade the instance on first boot # (ie run apt-get upgrade) # # Default: false # Aliases: apt_upgrade package_upgrade: true 配置实例的受信任CA： YAML 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 #cloud-config # # This is an example file to configure an instance's trusted CA certificates # system-wide for SSL/TLS trust establishment when the instance boots for the # first time. # # Make sure that this file is valid yaml before starting instances. # It should be passed as user-data when starting the instance.   ca-certs:   # If present and set to True, the 'remove-defaults' parameter will remove   # all the default trusted CA certificates that are normally shipped with   # Ubuntu.   # This is mainly for paranoid admins - most users will not need this   # functionality.   remove-defaults: true     # If present, the 'trusted' parameter should contain a certificate (or list   # of certificates) to add to the system as trusted CA certificates.   # Pay close attention to the YAML multiline list syntax.  The example shown   # here is for a list of multiline certificates.   trusted:   - |    -----BEGIN CERTIFICATE-----    YOUR-ORGS-TRUSTED-CA-CERT-HERE    -----END CERTIFICATE-----   - |    -----BEGIN CERTIFICATE-----    YOUR-ORGS-TRUSTED-CA-CERT-HERE    -----END CERTIFICATE----- 配置DNS： YAML 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 #cloud-config # # This is an example file to automatically configure resolv.conf when the # instance boots for the first time. # # Ensure that your yaml is valid and pass this as user-data when starting # the instance. Also be sure that your cloud.cfg file includes this # configuration module in the appropriate section. # manage_resolv_conf: true   resolv_conf:   nameservers: ['8.8.4.4', '8.8.8.8']   searchdomains:     - foo.example.com     - bar.example.com   domain: example.com   options:     rotate: true     timeout: 1 在第一次启动时执行命令： YAML 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 #cloud-config   # boot commands # default: none # this is very similar to runcmd, but commands run very early # in the boot process, only slightly after a 'boothook' would run. # bootcmd should really only be used for things that could not be # done later in the boot process.  bootcmd is very much like # boothook, but possibly with more friendly. # - bootcmd will run on every boot # - the INSTANCE_ID variable will be set to the current instance id. # - you can use 'cloud-init-per' command to help only run once bootcmd:   - echo 192.168.1.130 us.archive.ubuntu.com >> /etc/hosts   - [ cloud-init-per, once, mymkfs, mkfs, /dev/vdb ] YAML 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 #cloud-config   # run commands # default: none # runcmd contains a list of either lists or a string # each item will be executed in order at rc.local like level with # output to the console # - runcmd only runs during the first boot # - if the item is a list, the items will be properly executed as if #   passed to execve(3) (with the first arg as the command). # - if the item is a string, it will be simply written to the file and #   will be interpreted by 'sh' # # Note, that the list has to be proper yaml, so you have to quote # any characters yaml would eat (':' can be problematic) runcmd: - [ ls, -l, / ] - [ sh, -xc, "echo $(date) ': hello world!'" ] - [ sh, -c, echo "=========hello world'=========" ] - ls -l /root # Note: Don't write files to /tmp from cloud-init use /run/somedir instead. # Early boot environments can race systemd-tmpfiles-clean LP: #1707222. - mkdir /run/mydir - [ wget, "http://slashdot.org", -O, /run/mydir/index.html ] 安装软件包： YAML 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 #cloud-config   # Install additional packages on first boot # # Default: none # # if packages are specified, this apt_update will be set to true # # packages may be supplied as a single package name or as a list # with the format [<package>, <version>] wherein the specifc # package version will be installed. packages: - pwgen - pastebinit - [libpython2.7, 2.7.3-0ubuntu3.1] 调整挂载点： YAML 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 #cloud-config   # set up mount points # 'mounts' contains a list of lists #  the inner list are entries for an /etc/fstab line #  ie : [ fs_spec, fs_file, fs_vfstype, fs_mntops, fs-freq, fs_passno ] # # default: # mounts: #  - [ ephemeral0, /mnt ] #  - [ swap, none, swap, sw, 0, 0 ] # # in order to remove a previously listed mount (ie, one from defaults) # list only the fs_spec.  For example, to override the default, of # mounting swap: # - [ swap ] # or # - [ swap, null ] # # - if a device does not exist at the time, an entry will still be #   written to /etc/fstab. # - '/dev' can be ommitted for device names that begin with: xvd, sd, hd, vd # - if an entry does not have all 6 fields, they will be filled in #   with values from 'mount_default_fields' below. # # Note, that you should set 'nofail' (see man fstab) for volumes that may not # be attached at instance boot (or reboot). # mounts: - [ ephemeral0, /mnt, auto, "defaults,noexec" ] - [ sdc, /opt/data ] - [ xvdh, /opt/data, "auto", "defaults,nofail", "0", "0" ] - [ dd, /dev/zero ]   # mount_default_fields # These values are used to fill in any entries in 'mounts' that are not # complete.  This must be an array, and must have 6 fields. mount_default_fields: [ None, None, "auto", "defaults,nofail", "0", "2" ]     # swap can also be set up by the 'mounts' module # default is to not create any swap files, because 'size' is set to 0 swap:   filename: /swap.img   size: "auto" # or size in bytes   maxsize: size in bytes cloud-init完毕后重启/关机： YAML 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 #cloud-config   ## poweroff or reboot system after finished # default: none # # power_state can be used to make the system shutdown, reboot or # halt after boot is finished.  This same thing can be acheived by # user-data scripts or by runcmd by simply invoking 'shutdown'. # # Doing it this way ensures that cloud-init is entirely finished with # modules that would be executed, and avoids any error/log messages # that may go to the console as a result of system services like # syslog being taken down while cloud-init is running. # # If you delay '+5' (5 minutes) and have a timeout of # 120 (2 minutes), then the max time until shutdown will be 7 minutes. # cloud-init will invoke 'shutdown +5' after the process finishes, or # when 'timeout' seconds have elapsed. # # delay: form accepted by shutdown.  default is 'now'. other format #        accepted is '+m' (m in minutes) # mode: required. must be one of 'poweroff', 'halt', 'reboot' # message: provided as the message argument to 'shutdown'. default is none. # timeout: the amount of time to give the cloud-init process to finish #          before executing shutdown. # condition: apply state change only if condition is met. #            May be boolean True (always met), or False (never met), #            or a command string or list to be executed. #            command's exit code indicates: #               0: condition met #               1: condition not met #            other exit codes will result in 'not met', but are reserved #            for future use. # power_state:   delay: "+30"   mode: poweroff   message: Bye Bye   timeout: 30   condition: True 配置实例的SSH Keys： YAML 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 #cloud-config   # add each entry to ~/.ssh/authorized_keys for the configured user or the # first user defined in the user definition directive. ssh_authorized_keys:   - ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAGEA3FSyQwBI6Z+nCSjUUk8EEAnnkhXlukKoUPND/RRClWz2s5TCzIkd3Ou5+Cyz71X0XmazM3l5WgeErvtIwQMyT1KjNoMhoJMrJnWqQPOt5Q8zWd9qG7PBl9+eiH5qV7NZ mykey@host   - ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA3I7VUf2l5gSn5uavROsc5HRDpZdQueUq5ozemNSj8T7enqKHOEaFoU2VoPgGEWC9RyzSQVeyD6s7APMcE82EtmW4skVEgEGSbDc1pvxzxtchBj78hJP6Cf5TCMFSXw+Fz5rF1dR23QDbN1mkHs7adr8GW4kSWqU7Q7NDwfIrJJtO7Hi42GyXtvEONHbiRPOe8stqUly7MvUoN+5kfjBM8Qqpfl2+FNhTYWpMfYdPUnE7u536WqzFmsaqJctz3gBxH9Ex7dFtrxR4qiqEr9Qtlu3xGn7Bw07/+i1D+ey3ONkZLN+LQ714cgj8fRS4Hj29SCmXp5Kt5/82cD/VN3NtHw== smoser@brickies   # Send pre-generated SSH private keys to the server # If these are present, they will be written to /etc/ssh and # new random keys will not be generated #  in addition to 'rsa' and 'dsa' as shown below, 'ecdsa' is also supported ssh_keys:   rsa_private: |     -----BEGIN RSA PRIVATE KEY-----     MIIBxwIBAAJhAKD0YSHy73nUgysO13XsJmd4fHiFyQ+00R7VVu2iV9Qcon2LZS/x     1cydPZ4pQpfjEha6WxZ6o8ci/Ea/w0n+0HGPwaxlEG2Z9inNtj3pgFrYcRztfECb     1j6HCibZbAzYtwIBIwJgO8h72WjcmvcpZ8OvHSvTwAguO2TkR6mPgHsgSaKy6GJo     PUJnaZRWuba/HX0KGyhz19nPzLpzG5f0fYahlMJAyc13FV7K6kMBPXTRR6FxgHEg     L0MPC7cdqAwOVNcPY6A7AjEA1bNaIjOzFN2sfZX0j7OMhQuc4zP7r80zaGc5oy6W     p58hRAncFKEvnEq2CeL3vtuZAjEAwNBHpbNsBYTRPCHM7rZuG/iBtwp8Rxhc9I5w     ixvzMgi+HpGLWzUIBS+P/XhekIjPAjA285rVmEP+DR255Ls65QbgYhJmTzIXQ2T9     luLvcmFBC6l35Uc4gTgg4ALsmXLn71MCMGMpSWspEvuGInayTCL+vEjmNBT+FAdO     W7D4zCpI43jRS9U06JVOeSc9CDk2lwiA3wIwCTB/6uc8Cq85D9YqpM10FuHjKpnP     REPPOyrAspdeOAV+6VKRavstea7+2DZmSUgE     -----END RSA PRIVATE KEY-----     rsa_public: ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAGEAoPRhIfLvedSDKw7XdewmZ3h8eIXJD7TRHtVW7aJX1ByifYtlL/HVzJ09nilCl+MSFrpbFnqjxyL8Rr/DSf7QcY/BrGUQbZn2Kc22PemAWthxHO18QJvWPocKJtlsDNi3 smoser@localhost     dsa_private: |     -----BEGIN DSA PRIVATE KEY-----     MIIBuwIBAAKBgQDP2HLu7pTExL89USyM0264RCyWX/CMLmukxX0Jdbm29ax8FBJT     pLrO8TIXVY5rPAJm1dTHnpuyJhOvU9G7M8tPUABtzSJh4GVSHlwaCfycwcpLv9TX     DgWIpSj+6EiHCyaRlB1/CBp9RiaB+10QcFbm+lapuET+/Au6vSDp9IRtlQIVAIMR     8KucvUYbOEI+yv+5LW9u3z/BAoGBAI0q6JP+JvJmwZFaeCMMVxXUbqiSko/P1lsa     LNNBHZ5/8MOUIm8rB2FC6ziidfueJpqTMqeQmSAlEBCwnwreUnGfRrKoJpyPNENY     d15MG6N5J+z81sEcHFeprryZ+D3Ge9VjPq3Tf3NhKKwCDQ0240aPezbnjPeFm4mH     bYxxcZ9GAoGAXmLIFSQgiAPu459rCKxT46tHJtM0QfnNiEnQLbFluefZ/yiI4DI3     8UzTCOXLhUA7ybmZha+D/csj15Y9/BNFuO7unzVhikCQV9DTeXX46pG4s1o23JKC     /QaYWNMZ7kTRv+wWow9MhGiVdML4ZN4XnifuO5krqAybngIy66PMEoQCFEIsKKWv     99iziAH0KBMVbxy03Trz     -----END DSA PRIVATE KEY-----     dsa_public: ssh-dss AAAAB3NzaC1kc3MAAACBAM/Ycu7ulMTEvz1RLIzTbrhELJZf8Iwua6TFfQl1ubb1rHwUElOkus7xMhdVjms8AmbV1Meem7ImE69T0bszy09QAG3NImHgZVIeXBoJ/JzByku/1NcOBYilKP7oSIcLJpGUHX8IGn1GJoH7XRBwVub6Vqm4RP78C7q9IOn0hG2VAAAAFQCDEfCrnL1GGzhCPsr/uS1vbt8/wQAAAIEAjSrok/4m8mbBkVp4IwxXFdRuqJKSj8/WWxos00Ednn/ww5QibysHYULrOKJ1+54mmpMyp5CZICUQELCfCt5ScZ9GsqgmnI80Q1h3Xkwbo3kn7PzWwRwcV6muvJn4PcZ71WM+rdN/c2EorAINDTbjRo97NueM94WbiYdtjHFxn0YAAACAXmLIFSQgiAPu459rCKxT46tHJtM0QfnNiEnQLbFluefZ/yiI4DI38UzTCOXLhUA7ybmZha+D/csj15Y9/BNFuO7unzVhikCQV9DTeXX46pG4s1o23JKC/QaYWNMZ7kTRv+wWow9MhGiVdML4ZN4XnifuO5krqAybngIy66PMEoQ= smoser@localhost   # By default, the fingerprints of the authorized keys for the users # cloud-init adds are printed to the console. Setting # no_ssh_fingerprints to true suppresses this output. no_ssh_fingerprints: false   # By default, (most) ssh host keys are printed to the console. Setting # emit_keys_to_console to false suppresses this output. ssh:   emit_keys_to_console: false 初始化磁盘： YAML 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 #cloud-config # Cloud-init supports the creation of simple partition tables and file systems # on devices.   # Default disk definitions for AWS # -------------------------------- # (Not implemented yet, but provided for future documentation)   disk_setup:   ephmeral0:     table_type: 'mbr'     layout: True     overwrite: False   fs_setup:   - label: None,     filesystem: ext3     device: ephemeral0     partition: auto   # Default disk definitions for Microsoft Azure # ------------------------------------------   device_aliases: {'ephemeral0': '/dev/sdb'} disk_setup:   ephemeral0:     table_type: mbr     layout: True     overwrite: False   fs_setup:   - label: ephemeral0     filesystem: ext4     device: ephemeral0.1     replace_fs: ntfs     # Data disks definitions for Microsoft Azure # ------------------------------------------   disk_setup:   /dev/disk/azure/scsi1/lun0:     table_type: gpt     layout: True     overwrite: True   fs_setup:   - device: /dev/disk/azure/scsi1/lun0     partition: 1     filesystem: ext4     # Default disk definitions for SmartOS # ------------------------------------   device_aliases: {'ephemeral0': '/dev/vdb'} disk_setup:   ephemeral0:     table_type: mbr     layout: False     overwrite: False   fs_setup:   - label: ephemeral0     filesystem: ext4     device: ephemeral0.0   # Caveat for SmartOS: if ephemeral disk is not defined, then the disk will #    not be automatically added to the mounts.     # The default definition is used to make sure that the ephemeral storage is # setup properly.   # "disk_setup": disk partitioning # --------------------------------   # The disk_setup directive instructs Cloud-init to partition a disk. The format is:   disk_setup:   ephmeral0:     table_type: 'mbr'     layout: 'auto'   /dev/xvdh:     table_type: 'mbr'     layout:       - 33       - [33, 82]       - 33     overwrite: True   # The format is a list of dicts of dicts. The first value is the name of the # device and the subsequent values define how to create and layout the # partition. # The general format is: #   disk_setup: #     <DEVICE>: #       table_type: 'mbr' #       layout: <LAYOUT|BOOL> #       overwrite: <BOOL> # # Where: #   <DEVICE>: The name of the device. 'ephemeralX' and 'swap' are special #               values which are specific to the cloud. For these devices #               Cloud-init will look up what the real devices is and then #               use it. # #               For other devices, the kernel device name is used. At this #               time only simply kernel devices are supported, meaning #               that device mapper and other targets may not work. # #               Note: At this time, there is no handling or setup of #               device mapper targets. # #   table_type=<TYPE>: Currently the following are supported: #                   'mbr': default and setups a MS-DOS partition table #                   'gpt': setups a GPT partition table # #               Note: At this time only 'mbr' and 'gpt' partition tables #                   are allowed. It is anticipated in the future that #                   we'll also have "RAID" to create a mdadm RAID. # #   layout={...}: The device layout. This is a list of values, with the #               percentage of disk that partition will take. #               Valid options are: #                   [<SIZE>, [<SIZE>, <PART_TYPE]] # #               Where <SIZE> is the _percentage_ of the disk to use, while #               <PART_TYPE> is the numerical value of the partition type. # #               The following setups two partitions, with the first #               partition having a swap label, taking 1/3 of the disk space #               and the remainder being used as the second partition. #                 /dev/xvdh': #                   table_type: 'mbr' #                   layout: #                     - [33,82] #                     - 66 #                   overwrite: True # #               When layout is "true" it means single partition the entire #               device. # #               When layout is "false" it means don't partition or ignore #               existing partitioning. # #               If layout is set to "true" and overwrite is set to "false", #               it will skip partitioning the device without a failure. # #   overwrite=<BOOL>: This describes whether to ride with saftey's on and #               everything holstered. # #               'false' is the default, which means that: #                   1. The device will be checked for a partition table #                   2. The device will be checked for a file system #                   3. If either a partition of file system is found, then #                       the operation will be _skipped_. # #               'true' is cowboy mode. There are no checks and things are #                   done blindly. USE with caution, you can do things you #                   really, really don't want to do. # # # fs_setup: Setup the file system # ------------------------------- # # fs_setup describes the how the file systems are supposed to look.   fs_setup:   - label: ephemeral0     filesystem: 'ext3'     device: 'ephemeral0'     partition: 'auto'   - label: mylabl2     filesystem: 'ext4'     device: '/dev/xvda1'   - cmd: mkfs -t %(filesystem)s -L %(label)s %(device)s     label: mylabl3     filesystem: 'btrfs'     device: '/dev/xvdh'   # The general format is: #   fs_setup: #     - label: <LABEL> #       filesystem: <FS_TYPE> #       device: <DEVICE> #       partition: <PART_VALUE> #       overwrite: <OVERWRITE> #       replace_fs: <FS_TYPE> # # Where: #   <LABEL>: The file system label to be used. If set to None, no label is #     used. # #   <FS_TYPE>: The file system type. It is assumed that the there #     will be a "mkfs.<FS_TYPE>" that behaves likes "mkfs". On a standard #     Ubuntu Cloud Image, this means that you have the option of ext{2,3,4}, #     and vfat by default. # #   <DEVICE>: The device name. Special names of 'ephemeralX' or 'swap' #     are allowed and the actual device is acquired from the cloud datasource. #     When using 'ephemeralX' (i.e. ephemeral0), make sure to leave the #     label as 'ephemeralX' otherwise there may be issues with the mounting #     of the ephemeral storage layer. # #     If you define the device as 'ephemeralX.Y' then Y will be interpetted #     as a partition value. However, ephermalX.0 is the _same_ as ephemeralX. # #   <PART_VALUE>: #     Partition definitions are overwriten if you use the '<DEVICE>.Y' notation. # #     The valid options are: #     "auto|any": tell cloud-init not to care whether there is a partition #       or not. Auto will use the first partition that does not contain a #       file system already. In the absence of a partition table, it will #       put it directly on the disk. # #       "auto": If a file system that matches the specification in terms of #       label, type and device, then cloud-init will skip the creation of #       the file system. # #       "any": If a file system that matches the file system type and device, #       then cloud-init will skip the creation of the file system. # #       Devices are selected based on first-detected, starting with partitions #       and then the raw disk. Consider the following: #           NAME     FSTYPE LABEL #           xvdb #           |-xvdb1  ext4 #           |-xvdb2 #           |-xvdb3  btrfs  test #           \-xvdb4  ext4   test # #         If you ask for 'auto', label of 'test, and file system of 'ext4' #         then cloud-init will select the 2nd partition, even though there #         is a partition match at the 4th partition. # #         If you ask for 'any' and a label of 'test', then cloud-init will #         select the 1st partition. # #         If you ask for 'auto' and don't define label, then cloud-init will #         select the 1st partition. # #         In general, if you have a specific partition configuration in mind, #         you should define either the device or the partition number. 'auto' #         and 'any' are specifically intended for formating ephemeral storage or #         for simple schemes. # #       "none": Put the file system directly on the device. # #       <NUM>: where NUM is the actual partition number. # #   <OVERWRITE>: Defines whether or not to overwrite any existing #     filesystem. # #     "true": Indiscriminately destroy any pre-existing file system. Use at #         your own peril. # #     "false": If an existing file system exists, skip the creation. # #   <REPLACE_FS>: This is a special directive, used for Microsoft Azure that #     instructs cloud-init to replace a file system of <FS_TYPE>. NOTE: #     unless you define a label, this requires the use of the 'any' partition #     directive. # # Behavior Caveat: The default behavior is to _check_ if the file system exists. #   If a file system matches the specification, then the operation is a no-op. 自动增长分区大小： YAML 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 #cloud-config # # growpart entry is a dict, if it is not present at all # in config, then the default is used ({'mode': 'auto', 'devices': ['/']}) # #  mode: #    values: #     * auto: use any option possible (any available) #             if none are available, do not warn, but debug. #     * growpart: use growpart to grow partitions #             if growpart is not available, this is an error. #     * off, false # # devices: #   a list of things to resize. #   items can be filesystem paths or devices (in /dev) #   examples: #     devices: [/, /dev/vdb1] # # ignore_growroot_disabled: #   a boolean, default is false. #   if the file /etc/growroot-disabled exists, then cloud-init will not grow #   the root partition.  This is to allow a single file to disable both #   cloud-initramfs-growroot and cloud-init's growroot support. # #   true indicates that /etc/growroot-disabled should be ignored # growpart:   mode: auto   devices: ['/']   ignore_growroot_disabled: false
Upstart Job	内容存放为/etc/init/下的一个文件，从而被Upstart调用 需要以 #upstart-job开头，包含在MIME Multi Part Archive中时使用Content-Type：text/upstart-job
Cloud Boothook	存放在/var/lib/cloud并立即执行，没有任何机制保证钩子仅仅执行一次 需要以 #cloud-boothook开头，包含在MIME Multi Part Archive中时使用Content-Type：text/cloud-boothook
Part Handler	一段代码，用于处理新的MIME类型，或者覆盖既有的MIME类型的处理器。以Python编写，包含函数： list_types：本Handler支持的MIME类型列表 handle_part：执行处理 示例： Python 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 #part-handler   def list_types():     # return a list of mime-types that are handled by this module     return(["text/plain", "text/go-cubs-go"])   def handle_part(data,ctype,filename,payload):     # data: the cloudinit object     # ctype: '__begin__', '__end__', or the specific mime-type of the part     # filename: the filename for the part, or dynamically generated part if     #           no filename is given attribute is present     # payload: the content of the part (empty for begin or end)     if ctype == "__begin__":        print "my handler is beginning"        return     if ctype == "__end__":        print "my handler is ending"        return       print "==== received ctype=%s filename=%s ====" % (ctype,filename)     print payload     print "==== end ctype=%s filename=%s" % (ctype, filename) 需要以 #part-handler开头，包含在MIME Multi Part Archive中时使用Content-Type：text/part-handler

所谓实例数据，是指cloud-init用来配置实例的所有数据的集合。数据来源包括：

1. 云环境的元数据服务（metadata）
2. 用户定制的，提供给实例的config-drive
3. 镜像中的cloud-config seed files
4. 提供文件/元数据服务提供的vendor-data
5. 创建实例时提供的user-data

也就是说，上节的user-data是instance-data的一部分。

在OpenStack中，Flavor定义了实例的规格 —— 计算、内存、存储资源的硬件规格。Flavor也可以用来定义实例可以在哪些宿主机上启动。

命令行标记	说明
--vcpus	虚拟CPU数量，必须
--ram	内存/MB，必须
--disk	根磁盘大小/GB，必须 从镜像创建虚拟机时，根磁盘是一个临时（ephemeral）磁盘，虚拟机的镜像会拷贝到该磁盘上。如果从持久化的卷来启动虚拟机，则不会使用这种磁盘 设置为0，其含义是，使用虚拟机镜像的大小作为临时磁盘大小。但是这种情况下会导致filter scheduler不能基于镜像尺寸来选择适当的宿主机。因此，你应该仅仅在从卷启动虚拟机、或者出于测试目的的时候，才将此参数设置为0 要强制必须从0根磁盘大小的Flavor来创建基于卷的虚拟机，设置策略规则：os_compute_api:servers:create:zero_disk_flavor
--ephemeral	额外的临时磁盘/GB，默认0 该参数为虚拟机提供额外的临时分去，虚拟机销毁后，此磁盘消失
--swap	交换分区/MB，默认0
--public --private	公共标记，默认True 指示该Flavor是不是可以被除了Flavor所在项目（租户）的其它租户使用
--property	额外规格说明，可以指定多次，键值对。高级配置下，用作scheduler的提示信息   以quota:开头的属性，用于对Flavor进行配额限制，示例： Shell 1 2 3 4 5 6 7 8 # 确保虚拟机只能消耗50%的物理CPU能力 openstack flavor set FLAVOR-NAME \     --property quota:cpu_quota=10000 \     --property quota:cpu_period=20000   # 限制每秒最多写入10MB到磁盘 openstack flavor set FLAVOR-NAME \     --property quota:disk_write_bytes_sec=10485760 所有quota属性列表（前缀省略）： cpu_shares，相对于domain下其它虚拟机的、使用CPU时间片的权重值 cpu_shares_level，仅仅用于VMware，custom, high, normal, low cpu_period，设置QEMU/LXC的enforcement interval，在周期内，不得消耗大于cpu_quota的带宽 cpu_limit，设置VMware的CPU频率，单位MHZ cpu_reservation，设置VMware可以确保给虚拟机的CPU频率，MHZ cpu_quota，设置最大允许带宽，单位微秒。负数表示无限制 memory_limit，内存上限，单位MB memory_reservation，设置VMware最小保证内存，指定数量的内存一定会分配给虚拟机 disk_io_limit，设置VMware下每秒磁盘IO的上限 disk_io_reservation，设置VMware下保证的IOPS disk_read_bytes_sec，限制读流量 disk_read_iops_sec，限制读IOPS disk_write_bytes_sec，限制写流量 disk_write_iops_sec，限制写IOPS disk_total_bytes_sec，限制流量 disk_total_iops_sec，限制IOPS vif_inbound_average，入站流量平均速度，单位kb vif_inbound_burst，入站流量以peak速度最多连续接收多少kb vif_inbound_peak，入站流量的的最大速度，单位kb vif_outbound_average，出站流量平均速度，单位kb vif_outbound_burst，出站流量以peak速度最多连续接收多少kb vif_outbound_peak，出站流量的的最大速度，单位kb

允许使用的资源的配额可以针对项目（租户）或者用户进行设置。

配额	说明
cores	每个项目总计允许分配的核心数
instances	每个项目总计允许启动的实例数
key_pairs	每个用户允许的密钥对数量
metadata_items	每个实例允许的元数据数量
ram	每个项目总计允许分配的内存MB
server_groups	每个项目允许的服务器组数量
server_group_members	每个服务器组中成员的数量

使用下面的命令查看默认配额值：

要查看某个用户的配额，执行：

主机聚合是一种对宿主机进行分区的机制，聚合中的主机常常具有类似的硬件/性能特征。一个主机可以属于多个聚合。

引入主机聚合最初是为了使用Xen资源池，但是现在作为一种机制，允许管理员将一系列键值对（属性）同时分配到多台主机。

主机聚合不直接对用户暴露，管理员可以将Flavor映射到主机聚合 —— 只需要为聚合设置匹配Flavor的额外规格说明的元数据，即可完成映射。

管理员也可以将一组主机划分为AZ，与主机聚合不同，AZ是面向用户的概念，而且主机仅能属于一个AZ。

要让Nova调度器支持主机聚合，需要配置：

在Placement中，Aggregate表示相关的资源提供者（resource provider）的分组。在Placement中，Nova的计算节点就是资源提供者。因此，节点在Placement中也可以被加入到聚合。

使用下面的命令，可以查询计算节点的UUID，并将其加入到Placement聚合中：

从Nova 18.0.0开始，添加主机到Host Aggregate中后，会自动修改对应的Placement聚合。不需要手工操作。删除时类似。

为了使用Placement来进行租户隔离，必须存在和Host Aggregate在UUID+成员关系上匹配的Placement Aggregate。调度过滤器AggregateMultiTenancyIsolation会使用聚合元数据。

需要设置 scheduler.limit_tenants_to_placement_aggregate  = True才能启用此特性。

配置示例：

Nova组件nova-scheduler负责决定在哪台计算节点上创建虚拟机。 在调度的场景下，术语host表示运行了nova-compute服务的哪些节点。

调度器的基本配置项是：

默认的调度器驱动是 filter_scheduler，在默认配置下，该调度器选择满足以下所有条件的宿主机：

1. AvailabilityZoneFilter：位于请求的AZ中
2. ComputeFilter：能够服务请求
3. ComputeCapabilitiesFilter：满足实例类型的extra_specs（来自Flavor）
4. ImagePropertiesFilter：满足实例镜像属性中的架构、Hypervisor类型、虚拟机模式属性
5. ServerGroupAntiAffinityFilter：满足服务器组的反亲和设置——和组中的其它虚拟机不再同一宿主机上
6. ServerGroupAffinityFilter：满足服务器组亲和设置

当执行nova evacuate命令重建虚拟机时，调度器服务遵循管理员给出的目标宿主机，如果管理员没有指定目标宿主机，则由调度器来选择适当的宿主机。

从R版开始，调度器包含一个前置的过滤步骤，其目的时提升效率，减少候选的主机。

下面是一些常用的预过滤器：

镜像类型支持过滤器： [scheduler]/query_placement_for_image_type_support=True 过滤掉那些不支持用于启动虚拟机的镜像的格式的计算节点。例如，对于libvrit驱动，当使用Ceph作为临时存储后端时，不支持qcow2镜像格式。在混合使用基于Ceph、不使用Ceph作为存储后端的计算节点时，可以启用此过滤器

禁用状态节点过滤器：强制启用 从T版本开始，此过滤器会排除禁用状态的节点（类似于ComputeFilter）。具有trait COMPUTE_STATUS_DISABLED的（计算节点）资源提供者，将被排除，不作为调度候选 Trait由nova-compute服务管理，应该mirror位于os-services中的计算服务记录的disabled状态。例如，如果计算服务的状态是disabled，那么它关联的计算节点资源提供者对象应当具有COMPUTE_STATUS_DISABLED这一trait；当计算服务状态为enabled，对应资源提供者的此trait应该被移除 如果状态改变时计算服务宕了，那么trait将在它重启后同步。如果尝试给对应资源提供者添加/删除trait时出错，则update_available_resource这一定时任务负责重新同步。[DEFAULT]/update_resources_interval负责此同步操作的间隔

前面我们提到过，nova.scheduler.filter_scheduler.FilterScheduler是默认的调度器（驱动）。它使用过滤器、权重来选择宿主机。

 

配置项 [filter_scheduler]/available_filters 列出调度器可以使用的过滤器集合，此配置项可以指定多次：

配置项 [filter_scheduler]/filter_scheduler.enabled_filters 列出当前nova-scheduler启用的过滤器。

过滤器	说明
AggregateImagePropertiesIsolation	从L版开始，Nova仅会传递标准元数据给此过滤器。如果需要使用所有元数据，考虑过滤器AggregateInstanceExtraSpecsFilter 该过滤器对 镜像元数据 和 聚合元数据 进行匹配： 如果主机属于聚合，且聚合定义了1-N个元数据，这些元数据匹配镜像的属性，则主机作为从镜像启动的虚拟机的候选宿主 如果宿主机不属于任何聚合，通过此过滤器（即不会被过滤掉）
AggregateInstanceExtraSpecsFilter	该过滤器对 实例类型（Flavor）的、Scope为aggregate_instance_extra_specs的extra_specs 和 聚合属性进行匹配 为了向后兼容，没有Scope的Specs也可以用来匹配，但是不推荐 —— 当同时使用ComputeCapabilitiesFilter时会出现冲突 使用此过滤器，可以实现将Flavor调度到特定的主机集合中
AggregateMultiTenancyIsolation	确保租户隔离（tenant-isolated）的主机聚合（即设置了filter_tenant_id的主机聚合）仅仅能被相关的租户（项目）所使用 filter_tenant_id可以用逗号分隔多个租户 如果某个主机属于设置了filter_tenant_id的聚合，那么某个不属于相应租户的用户发起创建虚拟机的请求时，虚拟机不会在此聚合的某个宿主机上创建 主机可以不属于任何设置了filter_tenant_id的聚合，通过此过滤器
AggregateNumInstancesFilter	用于限制宿主机上实例的最大数量 对于一个聚合，如果设置了max_instances_per_host，那么其中的宿主机上的实例不会超过特定数量 如果主机属于多个设置了max_instances_per_host的聚合，验证此主机实例数量是否到达上限时，使用最小的max_instances_per_host值
AggregateTypeAffinityFilter	用于实现实例类型（Flavor）亲和性 此过滤器pass（通过）没有设置instance_type的主机，或者所在聚合的元数据instance_type（逗号分隔）包含正在请求创建的虚拟机的instance_type的主机
AllHostsFilter	通过所有主机
AvailabilityZoneFilter	满足调度请求中关于可用区的需求
ComputeCapabilitiesFilter	对Flavor的extra_specs中的属性 和 compute capabilities进行匹配 如果Extra Spec中包含冒号，则：之前的看作命名空间，之后的看作需要匹配的key。如果命名空间不是capabilities，则忽略此Spec 为了向后兼容，没有Namespace的Specs也可以用来匹配，但是不推荐 —— 当同时使用AggregateInstanceExtraSpecsFilter时会出现冲突 某些虚拟化驱动支持报告CPU的trait给placement服务，这种情况下，应该在Flavor中使用trait，而不是使用此过滤器。因为trait提供了CPU特性的一致性命名，而且查询trait的效率更高
ComputeFilter	此过滤器pass（通过）所有启用的、可以工作的计算服务（节点）
DifferentHostFilter	调度到其它宿主机，排除的宿主机由请求时给出的different_host来确定，该字段是一个实例的列表，排除的是这些实例所在的宿主机： JSON 1 2 3 4 5 6 7 8 9 10 11 12 13 {     "server": {         "name": "server-1",         "imageRef": "cedef40a-ed67-4d10-800e-17455edce175",         "flavorRef": "1"     },     "os:scheduler_hints": {         "different_host": [             "a0cf03a5-d921-4877-bb5c-86d26cf818e1",             "8c19174f-4220-44f0-824a-cd1eeef10287"         ]     } }  使用命令： Shell 1 2 3 4 openstack server create --image cedef40a-ed67-4d10-800e-17455edce175 \   --flavor 1 --hint different_host=a0cf03a5-d921-4877-bb5c-86d26cf818e1 \   # 调度提示   --hint different_host=8c19174f-4220-44f0-824a-cd1eeef10287 server-1
ImagePropertiesFilter	根据实例的镜像的属性来过滤宿主机，仅仅通过那些支持镜像属性的宿主机 属性包括：架构、Hypervisor类型/版本、虚拟机模式： hw_architecture，架构：i686, x86_64, arm, ppc64 ... img_hv_type，Hypervisor类型：qemu,hyperv ... img_hv_requested_version，Hypervisor版本 对于QEMU、KVM，Hypervisor类型都是qemu Shell 1 openstack image set --architecture arm --property img_hv_type=qemu img-uuid
IsolatedHostsFilter	允许定义一个隔离镜像集、隔离宿主机集，两者必须在一起 restrict_isolated_hosts_to_isolated_images 用于限制隔离主机仅仅运行隔离镜像。取值True意味着卷后备的虚拟机不能调度到隔离主机集；取值False则没有任何限制（对比镜像后备的虚拟机） 镜像集、宿主机集合必须配置在nova.conf： INI 1 2 3 [filter_scheduler] isolated_hosts = server1, server2 isolated_images = 342b492c-128f-4a42-8d3a-c5088cf27d13, ebd267a6-ca86-4d6c-9a0e-bd132d6b7d09
IoOpsFilter	过滤掉具有太多并发IO实例的宿主机 max_io_ops_per_host指定 单个宿主机上IO敏感的实例的最大数量
JsonFilter	此过滤器默认没有启用，且没有广泛测试 允许用户为调度器提供一个JSON格式的提示。在提示中： 支持操作符 = < > in <= >= not or and 支持判断属性   $free_ram_mb  $free_disk_mb  $hypervisor_hostname  $total_usable_ram_mb  $vcpus_total $vcpus_used 等任何HostState 示例： Shell 1 2 openstack server create --image 827d564a-e636-4fc4-a376-d36f7ebe1747 \   --flavor 1 --hint query='[">=","$free_ram_mb",1024]' server1
PciPassthroughFilter	仅仅通过匹配Flavor的extra_specs中设备请求的宿主机
SameHostFilter	调度到和指定实例（集）相同的宿主机（之一） 实例（集）由提示给出： Shell 1 2 3 openstack server create --image cedef40a-ed67-4d10-800e-17455edce175 \   --flavor 1 --hint same_host=a0cf03a5-d921-4877-bb5c-86d26cf818e1 \   --hint same_host=8c19174f-4220-44f0-824a-cd1eeef10287 server-1
ServerGroupAffinityFilter	确保调度到指定的服务器组中，服务器组由提示给出 Shell 1 2 3 openstack server group create --policy affinity group-1 openstack server create --image IMAGE_ID --flavor 1 \   --hint group=SERVER_GROUP_UUID server-1
ServerGroupAntiAffinityFilter	确保不调度到指定的服务器组中，服务器组由提示给出
SimpleCIDRAffinityFilter	根据宿主机的IP地址CIDR进行过滤，指定两个提示： build_near_host_ip  CIDR的第一个IP  cidr  CIDR的掩码部分 Shell 1 2 openstack server create --image cedef40a-ed67-4d10-800e-17455edce175 \   --flavor 1 --hint build_near_host_ip=192.168.1.1 --hint cidr=/24 server-1

经过过滤后，可能仍然有多个宿主机满足需求。那么，到底选择哪一个？这时需要基于权重来确定。

一个宿主机的最初权重由它拥有的硬件资源来确定，每当调度新的实例到它上面，宿主机的权重值就变小。 

权重计算算法的参数，配置在nova.conf中：

从S版开始，nova-compute会基于计算驱动的capabilities报告为COMPUTE_开头的（资源提供者的）Trait（特性）。

通过配置Flavor，可以指定实例要求、禁止哪些Trait。例如，某个主机聚合支持multi-attach卷，你可以限制某个Flavor仅仅调度到这个主机聚合：

1. 为Flavor设置extra_specs： trait:COMPUTE_VOLUME_MULTI_ATTACH=required
2. 按照常规方式限制Flavor到主机聚合

关于基于计算驱动capabilities定义的Trait，需要注意：

1. 计算服务拥有这些COMPUTE_开头的Trait的控制权，nova-compute服务启动后，或者update_available_resource定时任务执行后，会自动添加/擅长Traits
2. 用户自定义的Trait，不会被删除。除非定义的Trait以COMPUTE_开头
3. 如果用户通过命令： openstack resource provider trait delete 删除某个资源提供者的COMPUTE_*，计算服务会在重启时再次添加

在OpenStack中，可用区是一个用户可见的逻辑的云分区。在创建主机时，用户可以指定，创建到哪个可用区。

可用区没有在数据库中建模，而是定义为主机聚合的元数据。为主机聚合添加特定的元数据，即可将其中的主机加入到某个可用区。

需要注意主机聚合和AZ的不同：

1. 宿主机可以属于多个主机聚合，但是只能属于一个AZ
2. 默认情况下，主机是默认AZ的成员，即使它不属于任何主机聚合

其它OpenStack服务，例如网络、块存储服务，也有可用区的概念，但是实现方式各不相同。

默认AZ的名字，可以在nova.conf中配置：

该配置项指定计算服务（nova-compute组件）的默认可用区的名字。 

可用区是在主机聚合上设置的：

将主机聚合关联到可用区的操作，需要提前规划。聚合中任何主机上已经实例，则无法设置可用区。

导致实例所在宿主机改变的操作包括 evacuate, resize, cold migrate, live migrate 以及 unshelve。其中只有evacuate和live migrate可以绕过调度器，强制指定目标主机。

如果满足以下条件之一，迁移后的实例限定在特定的AZ中：

1. 创建实例时，指定了availability_zone参数，即指明在特地AZ中创建实例
2. 虽然没有指定availability_zone，但是API service配置了 default_schedule_zone
3. 2.77版本之后，Unshelve实例时，指定了availability_zone
4. cinder.cross_az_attach设置为False，default_schedule_zone也没有设置，但是实例使用了卷，这样会调度到卷所在的AZ

如果实例没有在特定AZ内创建，则它可以被自由的移动到其它AZ， AvailabilityZoneFilter不做任何事情。

需要注意，如果实例在某个AZ内创建的情况下，通过evacuate或者live migrate将其移动到另外一个AZ的主机上，是个危险的操作。因为假设后续你又resize实例，调度器会将其转移到原先的AZ。

Noava的配置项cinder.cross_az_attach，用于限制实例和它使用的卷在相同的AZ中。如果设置为False，则计算和存储资源会位于相同AZ，如果无法满足，则请求会失败：

1. 创建实例时，将一个已存在的卷挂载给它，那么实例将创建到卷所在的AZ
2. 创建实例时，需要创建一个新卷挂载给它，那么Nova将会在实例所在的AZ中创建卷

关于在Nova中使用、创建、管理卷，参考openstack server create。

Nova从Q版开始支持Cinder的多重挂载。前提条件：

1. Compute API最小版本是2.6
2. 底层的Hypervisor驱动必须支持将卷挂载到多个客户机。使用libvirt驱动时，libvirt必须大于3.10，qemu必须大于2.10
3. 不支持swap一个正在使用的multiattach卷

OpenStack支持多种控制台来连接到客户机，包括VNC、SPICE、Serial、RDP、MKS（VMware vSphere）。推荐仅仅部署一种类型的控制台支持，此外需要注意某些Hypervisor不支持某些控制台类型。

为了连接到虚拟机控制台，计算节点的5900-5999端口必须开启。

不管使用哪种控制台，都需要部署console proxy服务。该服务负责：

1. 提供用户所在的公共网络和虚拟机所在的私有网络之间的桥梁
2. 中介Token验证
3. 屏蔽Hypervisor相关的连接细节，给用户一致的体验

对于某些Hypervisor + Console驱动的组合，控制台代理是Hypervisor/其它外部服务提供的。其它的则由Nova提供控制台代理服务。Nova控制台代理的工作方式如下（以基于noVNC的VNC控制台为例）：

1. 用户访问OpenStack API，获取控制台访问URL，例如：http://ip:port/?path=%3Ftoken%3Dxyz
2. 用户在浏览器打开控制台
3. 浏览器连接到代理
4. 代理校验用户的Token，映射Token到私有网络中的、实例的VNC服务器的地址:端口
5. 计算节点在vnc.server_proxyclient_address中指定代理应该如何连接到本机的VNC服务器，代理通过此地址连接到VNC服务器

要启用基于noVNC的VNC控制台，OpenStack需要部署以下额外组件：

1. 一个或多个 nova-novncproxy服务，以支持基于浏览器的noVNC客户端。在简单部署场景中，此服务运行在nova-api所在机器上，因为它是公共、私有网络之间的桥梁

VNC是很多Hypervisor和客户端支持的图形化控制台。noVNC支持通过浏览器访问VNC。

配置nova-novncproxy服务：

配置nova-compute服务： 

使用串口控制台（serial console）可以检查虚拟机的内核输出，查看其它虚拟消息。串口控制台在虚拟机的网络连接不可用时特别有效。

从J版开始，OpenStack支持可读写的串口控制台。你需要在计算节点上配置：

使用下面的命令后的串口控制台的WS地址：

Nova支持注入密码到虚拟机的管理员用户，密码会打印在openstack server create命令的输出中。

默认情况下，仪表盘会显示管理员密码并允许修改。如果希望禁用此特性：

对于使用libvirt后端的Hypervisor（KVM/QEMU/LXC），管理员密码注入默认禁用，要启用需要修改：

默认情况下，很多placement相关的OpenStackt命令不可用，需要安装osc-placement插件。

默认情况下，使用的Placement API版本是1.0。要使用其它版本，需要指定 --os-placement-api-version命令行标记，或者设置环境变量：

OpenStack Networking组件，即Neutron，允许你创建网络接口设备、将网络接口设备Attach到虚拟网络。Neutron基于插件化机制设计，用以支持不同的网络设备以及软件。

Neutron负责管理虚拟网络基础设施（Virtual Networking Infrastructure，VNI）的方方面面、以及物理网络基础设施（Physical Networking Infrastructure，PNI）的访问/接入层面。

Neutron支持防火墙、VPN等高级网络特性。

Neutron提供网络、子网、路由器的抽象，这些抽象模拟相应物理实体的特性。例如，网络包含子网，路由器负责再不同子网/网络之间进行封包路由。

任何给定的网络方案（set up），至少包含一个外部网络（External network）。与其它网络不同，外部网络不仅仅是虚拟网络，他是真实物理网络（可以访问OpenStack外部）的一种视图。外部网络上的IP地址，可以从OpenStack外部直接访问到。

除了外部网络之外，任何网络方案至少包含一个内部网络（Internal network），内部网络是虚拟（软件定义的）网络，直接将VM连接在一起。

为了从外部访问VM（或者反之），需要添加虚拟路由器。每个路由器包含一个网关，通向外部网络；包含1-N个接口，通往内部网络。和物理路由器类似，连接到同一个路由器的子网之间可以相互访问。VM可以通过路由器的网关访问外部网络。

当有什么连接到一个子网时，那个连接点（connection）就称为端口（port）。你将外部网络的IP地址分配到内部网络的（由于VM连接到子网而产生的）端口上，这样，外部实体就能直接访问VM。

Neutron支持安全组（security groups），安全组让管理员可以按组来定义防火墙规则。一个VM可以归属1-N个安全组，Neutron根据安全组中的规则，来阻止VM访问端口、端口范围。

一个典型的Netron部署，包含了多个服务（service）和代理（agent），这些组件可能运行在一个或多个节点上。

接受API请求，并路由给适当的OpenStack Networking plug-in进行处理。作为访问数据库的中心点。

Neutron使用插件化的架构，各种可拔插功能依赖于plugin和agent实现。

使用通用/厂商特定的技术，来提供网络分段（segmentation）和隔离（isolation），也就是划分出子网（network number相同的主机位于同一个子网，子网是个以太网）。

L2代理应当运行在任何需要网络连接、提供虚拟接口安全性的节点上，包括计算、网络节点。

OpenStack自带了Cisco 虚拟/物理交换机、NEC OpenFlow产品、Open vSwitch、Linux Bridging、VMware NSX产品的代理。

运行在网络节点上，提供东西向、南北向的路由能力，并提供FWaaS、VPNaaS之类的高级特性。

用于再Neutron服务器和各种代理之间进行消息交换，也用作某些特定插件存储网络状态的数据库。

主配置文件neutron.conf，neutron-server和各种Agent都会读取。该文件包含用于Neutron内部RPC的oslo.messaging配置，并且会包含一些和主机相关的信息。此配置文件还包括database、nova、keystone的凭证信息。

此外neutron-server可能会加载plugin特定的配置文件。而Agent则不会加载。原因是插件配置主要是全局范围的选项。

每个不同的Agent可能有自己的配置文件，他们应当在主配置之后加载。因此其中的配置项优先级更高。代理配置文件中，可能包含主机特定的配置，例如local_ip。

模块化L2（Modular Layer 2 ，ML2）插件是Neutron的L2框架，它允许你在一个部署中使用多种L2网络技术。ML2的扩展点是两种不同类型的驱动

网络类型驱动，定义了OpenStack网络的技术分类，例如VxLAN、flat。

每种实现技术都对应了一个ML2 Type驱动。这些驱动会维护任何需要的、和网络类型相关的状态。它会验证Provider网络上和网络类型有关的信息，并且负责在项目的网络中分配一个空闲的段。

网络机制驱动，定义了OpenStack网络的实现技术，例如flat网络可以利用Linux bridge或者OVS来实现。

Mechanism驱动会利用Type驱动所产生的信息，并且确保这些信息并应用。

Mechanism驱动能通过RPC利用L2代理，也能够直接和外部控制器/设备进行交互。

Mechanism驱动和Type驱动的搭配，不是任意的：

Mech\Type	Flat	VLAN	VxLAN	GRE
Open vSwitch	Y	Y	Y	Y
Linx Bridge	Y	Y	Y	N
SRIOV	Y	Y	N	N
MacVTap	Y	N	N	N
L2 population	N	N	Y	Y

在ML2的主配置文件/etc/neutron/plugins/ml2/ml2_conf.ini中配置：

在ML2的主配置文件/etc/neutron/plugins/ml2/ml2_conf.ini中配置：

更多的配置查看相关Agent的配置文件。

该代理通过配置Linux Bridge来为OpenStack资源实现L2网络。配置文件路径 /etc/neutron/plugins/ml2/linuxbridge_agent.ini

参考配额和限速 - Neutron QoS

OpenStack支持对以下资源配置DNS：

资源	DNS名	DNS域
端口/Ports	是	否
网络/Networks	否	是
浮动IP	是	是

要更改默认的域名后缀openstacklocal，需要修改neutron-server节点的：

重启服务：

你可以为一个Port配置DNS名：

当Port分配给实例时，实例的主机名+域名后缀，会自动成为Port的FQDN，例如centos8-amd64.os.gmem.cc

OpenStack DNS Service，即Designate，是一个支持多租户的OpenStack的DNSaaS服务。它提供集成了keystone身份验证的REST API，能够基于Nova/Neutron动作自动生成DNS记录。Designate支持多种DNS服务器，包括Bind9和PowerDNS 4

提供REST API接口。

编排Zones和RecordSet的创建、删除和更新。

编排周期性任务。

运行任务，例如Zone的创建/删除/更新，以及来自designate-producer的周期性任务。

一个小的DNS服务器，负责推送DNS Zone信息到面向客户的DNS服务器，也能够拉取Designate基础设施之外的DNS Zone信息。

某些DNS服务要求在本地执行命令，此代理负责对接到这些DNS服务。

为客户提供DNS服务，由designate-worker管理其记录。Bind9、Power DNS 4被支持的很好。

安装openstack-designate以及相关依赖：

创建一个RNDC key：

改完重启服务：

执行下面的命令创建池：

查看DNS服务列表：

创建一个DNS Zone：

确认其状态到达ACTIVE：

创建一个记录集（RecordSet）：

Neutron支持将域名通过designate暴露给外部。

用例说明：用户创建在一个可被外部访问的网络上创建实例，并且希望从集群外部通过域名来访问实例。

参考步骤：

1. 前提条件：
   1. 不支持使用 --external 创建的网络
   2. 支持FLAT, VLAN, GRE, VXLAN, GENEVE类型的网络
   3. 对于FLAT, VLAN, GRE, VXLAN, GENEVE，其segmentation ID必须位于分配给project networks的范围之外
2. 给网络的dns_domain属性分配一个合法的值：
   
   Shell

   1 2	# neutron net-update 5fdf474c-533a-403d-b7dd-cc7d7e1dfa23 --dns_domain os.gmem.cc. openstack network set --dns-domain os.gmem.cc. provider

3. 查看此Zone中的记录：

   Shell

   1 2 3 4 5 6 7

   openstack recordset list os.gmem.cc. +--------------------------------------+-------------+------+---------------------------------------------------------------------+--------+--------+ | id                                   | name        | type | records                                                             | status | action | +--------------------------------------+-------------+------+---------------------------------------------------------------------+--------+--------+ | 22422e08-0c17-4106-a222-35c3e535d37a | os.gmem.cc. | NS   | ns.openstack.gmem.cc.                                               | ACTIVE | NONE   | | e4683c9e-70c0-4d3b-83e1-bb5530059311 | os.gmem.cc. | SOA  | ns.openstack.gmem.cc. admin.gmem.cc. 1618997152 3586 600 86400 3600 | ACTIVE | NONE   | +--------------------------------------+-------------+------+---------------------------------------------------------------------+--------+--------+

4.  创建一个端口，配置DNS名：

   Shell

   1 2 3 4

   openstack port create --dns-name t3m1 --network provider \     --fixed-ip subnet=provider,ip-address=10.2.0.111 --disable-port-security tcnp3-master-1 # | dns_assignment          | fqdn='t3m1.os.gmem.cc.', hostname='t3m1', ip_address='10.2.0.111'         |

5. 再次查看Zone，应该发现名为t3m1.os.gmem.cc.的新A记录：
   
   Shell

   1 2	openstack recordset list os.gmem.cc. # | f81bc3c2-2272-4f21-93d3-2c4fc9e6435d | t3m1.os.gmem.cc. | A    | 10.2.0.111   | ACTIVE | NONE   |

当把端口授予实例后，原先的A记录被替换，前缀改为实例的主机名。

OpenStack Block Storage service，即Cinder为VM提供块设备。块设备如何产生、如何被消费，取决于块设备驱动。如果使用多后端配置，则取决于多个驱动。Cinder具有多种驱动，包括NAS/SAN, NFS, iSCSI, Ceph，等等。

Block Storage API组件和Scheduler服务通常运行在控制节点上。取决于使用的驱动，Volume服务可能运行在控制节点、计算节点，或者独立的存储节点上。

Cinder和Nova交互，从而将卷提供给虚拟机实例。

接受API请求，路由给cinder-volume处理。

直接（或者通过消息队列）和后端存储服务交互、cinder-scheduler这样的组件交互。

cinder-volume会响应针对后端存储服务的读写请求，从而维持状态。它是通过驱动架构与后端交互的。

这是一个守护程序，负责选取一个最优化的、能够提供卷的节点，并由节点创建卷。

这是一个守护程序，负责备份任意类型的卷到某个Backup storage provider。它是通过驱动架构与后端交互的。

在上述进程之间交换信息。

参考上文的样例环境。

需要注意的是，LVM后端可以映射为远程宿主机的磁盘。当卷从位于LVM后端上的快照上创建时，它必须和快照在一个存储节点上，这种情况下，远程映射可能是必须的，需要注意性能问题。不能假设LVM后端是本地磁盘。

添加到已启用后端列表：

配置NFS服务地址，以及使用的NFS导出目录的绝对路径：

并修改该配置文件的访问权限：

重新启动cinder-volume服务：

查看cinder服务列表：

创建对应的volume type：

参考集成Ceph。

参考如下配置：

重启服务：

查看后端列表：

首先创建一个镜像记录：

然后向此镜像记录上传镜像：

通过Ceph命令可以看到，存储池中出现一个以镜像ID为名字的RBD镜像：

通过libvirt（底层是配置QEMU使用librbd），你可以将Ceph的RBD镜像挂载（Attach）给Openstack实例。

OpenStack有三部分可以用到Ceph存储：

1. 镜像：Glance管理的虚拟机镜像（不可变的）可以存放在Ceph中。Openstack将其作为blob并下载使用
2. 卷：虚拟机启动使用的卷，或者后续挂载的额外卷
3. 客户机磁盘：虚拟机启动时使用的系统盘，默认情况下，此系统盘表现为Hypervisor的文件系统中的一个文件，通常位于/var/lib/nova/instances/<uuid>/。在Havana版本之前，唯一启动系统盘位于Ceph中的VM方法是，使用boot-from-volume特性。现在，则可以直接启动存储在Ceph中的虚拟机，而不需要使用Cinder。这样，在虚拟机热迁移过程中，可以方便的执行维护操作。另外一个好处是，如果Hypervisor宕机，你可以通过 nova evacuate几乎无缝的重新实例化VM，OpenStack会在系统盘对应的RBD镜像上加独占锁以防多个计算节点并发访问之

Glance 能够将镜像存储为一个 Ceph 块设备。通过 Cinder使用COW克隆镜像来启动虚拟机。Ceph不支持 QCOW2 格式的镜像，必须使用RAW格式的镜像。

需要在nova-compute, cinder-backup 和 cinder-volume节点上安装Ceph客户端软件：

glance-api节点只需要安装 python-rbd。

运行glance-api, cinder-volume, nova-compute, cinder-backup的节点，是Ceph客户端，因此首先把/etc/ceph/ceph.conf复制到这些节点。

然后，创建以下Ceph账户：

并且把Keyring分发到相应节点：

准备一个UUID，推荐所有节点使用同一UUID：

在每个节点上执行：

编辑配置文件：

注意，glance支持多个存储后端，上面的配置增加了一个rbd后端。

要启用copy-on-write的镜像克隆，增加配置：

为了防止glance在/var/lib/glance/image-cache/下缓存镜像，配置：

修改备份节点的Cinder配置文件：

配置cinder.conf：

创建卷类型并关联到新建的后端：

到这一步，可以创建Ceph卷了，但是还不能挂载给虚拟机。

libvirt进程需要利用client.cinder的keyring来挂载Ceph卷（不管是作为普通块设备还是启动盘）：

为了支持直接从Ceph卷启动虚拟机，需要为Nova配置ephemeral后端。

建议在ceph.conf中启用RBD缓存（从Giant版本默认开启）。此外，可以开启client admin socket，以收集指标和辅助故障诊断：

使用下面的命令可以将镜像转换为raw格式：

从raw格式的、存放在Ceph后端的镜像创建卷：

当Glance和Cinder同时使用Ceph后端时，镜像使用copy-on-write方式克隆，因此新卷的很快。

如果通过OpenStack Dashboard操作，参考步骤：

1. 新建一个实例
2. 选择一个关联到copy-on-write克隆的镜像的卷。也就是存放在Ceph中的，创建自位于Ceph中的镜像的卷
3. 选择从卷启动，并使用上一步的卷

所谓配额，是指限制某个项目（租户）或者类（class）能够使用的各种云资源的量。例如CPU核心个数、固定IP个数、实例个数、密钥对个数、内存量、存储量、备份存储量、备份个数、每个卷最大存储量、网络数、子网数，等等。

默认的admin项目的配额比较小，可以用 openstack quota set修改配额。要查看配额，可以：

每个Flavor都可以被分配额外的属性（Extra Specs），来限制它的CPU、IO、网络的速度。

CPU限速基于cgroups实现。

IO限流由QEMU处理（通过libvirt的blkdeviotune），尽管libvirt提供了基于cgroups的blkiotune特性，但是Nova并没有使用它。

流量塑形（Traffic shaping）也就是出入站带宽限制，基于tc实现。Libvirt以网络接口为级别进行流量塑形，如果它基于cgroups进行塑形，则客户机的所有网络接口被一起限制，因为cgroups运行在进程级别。

可以使用以下Extra Specs键：

键	说明
disk_write_bytes_sec	限制字节数/秒，写
disk_read_bytes_sec	限制字节数/秒，读
disk_read_iops_sec	限制IOPS，读
disk_write_iops_sec	限制IOPS，写
disk_total_bytes_sec	限制字节数/秒，读写
disk_total_iops_sec	限制IOPS，读写

配置示例：

可以使用以下Extra Specs键：

键	说明
cpu_shares	占用CPU时间的权重，不是绝对值。一个设置了2048的VM，会比1024的多用一倍的CPU时间
cpu_period	单位微秒，限制在指定周期（period）内占用CPU带宽（时间）最大值（quota）
cpu_quota

可以使用以下Extra Specs键：

键	说明
vif_inbound_average	inbound表示入站流量限制，outbound表示出站流量限制 average: 期望的平均带宽KB/s peak：最大的峰值带宽KB/s burst：以峰值带宽最多连续发送多少KB
vif_outbound_average
vif_inbound_peak
vif_outbound_peak
vif_inbound_burst
vif_outbound_burst

所谓QoS，是指能够确保一定的网络需求的能力，这些网络需求包括带宽、延迟、抖动、可靠性。

交换机、路由器之类的网络设备，能够给流量打标记，并以更高的优先级来处理这些流量，以满足应用提供者和终端用户之间的SLA（Service Level Agreement ）。

在Neutron中，qos是一个高级的插件，它将QoS从OpenStaack网络代码的其他部分解耦出来，它从多个网络级别进行QoS控制，可以通过ml2扩展驱动的方式来使用。目前qos仅仅支持ml2（的SR-IOV, Open vSwitch, linuxbridge驱动）

在控制节点，配置Neutron：

修改你所使用的网络代理的配置，配置文件位于 /etc/neutron/plugins/ml2/<agent_name>_agent.ini。例如：

在计算/网络节点，修改网络代理配置：

如果希望给浮动IP配置QoS，需要配置L3代理：

Differentiated Services（DS，DiffServ）是一种在IP网络中分类、管理网络流量并提供QoS的机制。DS在保障关键流量（例如VoIP、视频流）低延迟的同时，为非关键服务（例如Web流量）提供best-effort服务。

DS在8bit的IP头字段differentiated services（DS）字段（用于替换过时的IPv4 TOS字段）中，写入6bit的DSCP（Differentiated Services Code Point）。RFC 4594对各个DSCP值由规定，例如广播食品CS3的DSCP为24。

当使用VxLAN之类的Overlay网络时，DHCP标记仅仅应用在内层IP头上。在封装期间，DSCP标记不会自动拷贝到外层包头。为了自动在外层包头设置DSCP，需要配置网络代理：

OpenStack会将QoS规则映射为底层代理的配置。如果使用Linux Bridge作为网络代理：

使用默认的policy.json时，仅仅管理员能够创建QoS策略。 下面是个例子：

注意：对于OVS和Linux Bridge来说，QoS实现需要burst值才能确保正确的带宽限制行为。设置合理的burst值非常重要，如果仅设置bandwidth-limit，即使它的值是合理的，带宽也会被throttled。对于TCP流量来说，推荐burst为bandwidth-limit的80%，如果burst设置的过低，则实际获得的带宽可能小于预期。

为某个网络端口配置/解除QoS策略：

你也可以将浮动IP、网络关联到QoS策略：

关联到浮动IP的QoS策略，将在浮动IP挂载到某个端口的时候生效。

每个项目可以配置一个默认QoS策略：

你可以在运行时动态修改QoS策略的规则，这些修改会传播到每个Attach到策略的端口：

要调整Nova日志级别，修改配置：

在/etc/nova/logging.conf中配置日志级别： 

此功能使用户能够将单个块存储卷挂载到多个服务器，以及从多个服务器访问单个块存储卷。此功能的用例包括 active-active 和 hot-standby 场景——有多台服务器需要访问卷上的数据，以在出现故障时快速恢复或能够处理系统中增加的负载。在 Queens 发行版中，有三个驱动程序支持 multi-attach ：LVM、NetApp / SolidFire 和 Oracle ZFSSA

在 Nova 中，对 vGPU 的支持让云管理员能够定义 flavor 以请求 vGPU 的特定资源和分辨率。最终用户可以启动具有 vGPU 的虚拟机，这对于图像密集型工作负载以及人工智能和机器学习工作负载来说是一项重要的功能

Cyborg是用于管理硬件和软件加速资源（如 GPU，FPGA，CryptoCards 和 DPDK/SPDK）的架构，对NFV工作负载的电信公司而言，加速是一项必备的功能。通过Cyborg，运维人员可以列出、识别和发现加速器，将加速器连接到实例并将其分离、安装和卸载驱动器。它可以单独使用，或与 Nova 或 Ironic 结合使用

之前在 Nova 中可以实现虚拟机实例修复，现在 Ironic 中可以实现裸机实例修复。运维人员可以对错误配置的裸机节点进行故障排除，或从诸如丢失的SSH密钥等问题中恢复

OpenStack是在私有云中部署容器的首选平台，Queens版本扩展了微服务功能。Kuryr 增加了一个 CNI 守护进程来增加 Kubernetes 操作的可扩展性。为了支持高可用（HA），CNI 守护进程能够监控 Pod 事件，不需要为每个事件等待 Kubernetes API。即便控制器宕机了，也可以创建 Pod。

Zun 是一个新 的OpenStack 项目，它允许用户无需管理服务器或集群即可快速启动和运行容器。它通过与 Neutron，Cinder，Keystone 和其他核心 OpenStack 服务集成，无缝地将先进的企业网络、存储和身份验证功能添加到容器中

提供了一系列 Helm 图表和工具，用于在 Kubernetes之 上管理 OpenStack的生命周期，并将 OpenStack 作为独立服务运行

OCI 生成兼容 Open Container Initiative 的 OpenStack 服务镜像，可以放入像 OpenStack-Helm 这样的重量级部署工具，或者单独使用来交付像 Cinder 块存储这样的独立服务。 LOCI 提供了现有 OpenStack Kolla 项目的一种替代方案（为每个容器镜像提供一个更完整的打包方法）。LOCI 采取的方法更符合 Kubernetes 运行镜像的方式，其中容器本身非常小，管理位于容器外部

提供运行容器所需的裸机和网络功能：

1. OpenStack Magnum，经过认证的Kubernetes安装程序，显著提升了Kubernetes集群的启动时间—无论节点数量多少，每个节点从10-12分钟降至5分钟
2. 通过OpenStack云供应商，您现在可以在Manila、Cinder和Keystone服务的支持下启动完全集成的Kubernetes集群，从而充分利用其底层的OpenStack云平台
3. Neutron，OpenStack网络服务，针对在组中创建端口的容器用例，更快速的创建批量端口
4. Ironic，裸机配置服务，持续改进部署模板，以便于独立用户请求分配裸机节点并提交配置数据，而不需要预先配置驱动器

1. Neutron，网段范围管理，云管理员可通过新的扩展API动态管理网段范围，而不是采用之前编辑配置文件的方法。StarlingX和边缘用例将得益于此，更易于管理

2. 对于网络密集型应用程序，拥有最小可用网络带宽至关重要。在Rocky周期中开始工作，提供基于最小带宽需求的调度，该功能已在Stein中交付。作为强化功能的一部分，Neutron将带宽视为一种资源，并与OpenStack Nova计算服务协作，将实例调度到满足其带宽需求的主机上

3. 对API的改进增加了OpenStack体系结构和部署的灵活性，增加了对服务质量（QoS）策略规则aliases的支持，使调用者能够更高效地执行删除、显示和更新QoS规则等请求

1. Blazar，资源预留服务，引进了新的资源分配API，运营商可查询其云计算资源的保留状态

2. Placement是引入Stein版本的一个新项目，是从Nova项目中分离出来的。可定位候选资源供应商，简化了为工作负载迁移指定主机的任务。对于常见的调度操作，API性能提升了50%。Train版本中将删除Nova中的Placement服务，其后安装Nova需要使用单独的Placement服务

1. 支持软件RAID：具有Ironic 裸机服务可保护服务免受磁盘故障的影响。欧洲核研究组织欧洲核子研究组织（CERN）领导了此功能的上游开发，并且已经将该功能在超过1000个节点上投入生产
2. 基于硬件的加密：Nova 是OpenStack的计算功能， 其新框架支持对guest存储器进行基于硬件的加密，以保护用户免遭攻击者或流氓管理员在使用libvirt计算驱动程序时窥探其工作负载。此功能对于多租户环境和具有可公开访问的硬件的环境很有用
3. 数据保护流程：Karbor 为检查，还原，计划和触发操作添加了事件通知。此功能允许用户使用位于根磁盘上的新添加的数据备份映像引导服务器

要求CentOS 8

完成了Nova Cyborg Interaction功能，使两者在某些方面进行紧密的联系，用于启动和管理具有GPU等加速器的实例

1. Nova API策略引入了具有scope_type功能的新默认角色

2. Ironic及其远程代理之间的交互身份验证得到了补充

3. Kolla 添加了对后端API服务的TLS加密的初始支持

1. Glance 优化了对Multiple Strores的操作，单次操作，后台同步

2. Keystone对创建应用程序凭据和信任关系的用户体验进行了极大改善

1. 为volume-type设置最大和最小的Size

2. 使用时间比较运算符过滤卷列表的能力

3. 将卷上载到Image Service时，支持Glance multistore和镜像数据托管

4. 添加了一些新的后端驱动程序，并且许多当前的驱动程序都增加了对更多功能的支持

1. 随着Nova-Cyborg集成的完成，用户现在可以使用由Cyborg管理的加速器启动实例

2. 实现了新的API，用以列出由Cyborg管理的设备，可以查看和管理加速器的列表

3. Cyborg通过在v2 API中采用microversions的模式，旨在将来版本中提供向后兼容的办法

4. Cyborg客户端现在基于OpenStack SDK，并支持大多数Version 2 API

5. 通过增加更多的单元/功能测试并减少技术负担来提高总体质量

1. 增强了Multiple Stores功能，用户现在可以向多个Stores导入单个镜像，在多个Stores中复制现有的imgae，并从单个Store中删除镜像

2. 新导入了插件以解压镜像

3. 再次为glance-store引入了S3 driver

1. 支持范围内省的规则，该规则允许每个节点子集具有（并保留）规则，例如不同的硬件交付

2. 支持硬件退役工作流程，以实现托管云中硬件退役的自动化

3. 非管理员使用Ironic可以使用多租户概念和其他策略选项

4. Ironic及其远程代理之间的交互身份验证得到了补充，从而可以在不受信任的网络上进行部署

5. UEFI和设备选择现在可用于软件RAID

1. 使用联合身份验证方法时，用于创建应用程序凭据和信任关系的用户体验已得到极大改善。角色分配来自映射的组成员身份的联盟用户将在令牌过期后将这些组成员身份保留为可配置的TTL，在此期间其应用程序凭证将保持有效

2. 现在，可以通过在Keystone中直接创建联盟用户并将其链接到其身份提供者，而无需依赖于映射API，就可以为联盟用户指定具体的角色分配

3. 当引导新的Keystone部署时，管理员角色现在默认设置为“ immutable”选项，这可以防止意外删除或修改它，除非有意删除了“ immutable”选项

4. Keystonemiddleware不再支持Identity v2.0 API，该身份在先前的发行周期中已从keystone中删除

5. 恢复资源驱动程序的可配置性，因此，如果内置sql驱动程序不满足业务要求，现在可以创建自定义资源驱动程序

1. 所有镜像，脚本和Ansible剧本都使用Python 3，并且对Python 2的支持也已删除

2. 添加了对CentOS 8主机和镜像的支持

3. 添加了对后端API服务的TLS加密的初始支持，从而提供了API流量的端到端加密。目前支持Keystone

4. 增加了对开放虚拟网络（OVN）部署以及与Neutron集成的支持

5. 增加了对部署Zun CNI（容器网络接口）组件的支持，从而使带有容器的Docker可以支持Zun capsules(pods)

6. 添加了对Elasticsearch Curator的支持，以帮助管理集群日志数据

7. 添加了将Mellanox网络设备与Neutron一起使用所必需的组件

8. 简化了外部Ceph集成的配置，可以轻松地从Ceph-Ansible部署的Ceph集群过渡到在OpenStack中启用它

1. 支持IPv6

2. DPDK支持嵌套设置以及其他各种与DPDK和SR-IOV相关功能的改进

3. 与NetworkPolicy支持相关的多个修复程序

1. 共享组已从试验性功能逐渐发展成熟。从API版本2.55开始，不再需要X-OpenStack-Manila-API-Experimental标头来创建/更新/删除共享组类型，组规范，组配额和共享组本身

2. 兼容时，可以从跨存储池的快照创建共享。这项新功能可以通过分散先前局限于托管快照的后端的工作负载来更好地利用后端资源

3. 引入了新的配额控制机制，以限制项目及其用户可创建的共享副本的数量和大小

4. 现在可以按时间间隔查询异步用户消息

1. OVN驱动程序现在已合并到Neutron存储库中，并且是核心 Neutron ML2 drivers之一，例如linuxbridge或openvswitch。与openvswitch驱动程序相比，OVN驱动程序的优点包括具有分布式SNAT流量的DVR，分布式DHCP以及无需网络节点即可运行的可能性。当然其他ML2驱动程序仍然受到完全支持。当前默认代理还是openvswitch，但计划是使用OVN驱动程序成为将来的默认选择

2. 添加了对无状态安全组的支持。用户现在可以将安全组集创建为无状态，这意味着conntrack将不会用于该组中的任何规则。一个端口只能使用无状态或有状态安全组。在某些用例中，无状态安全组将允许操作员选择优化的数据路径性能，而有状态安全组会在系统上施加额外的处理

3. 已添加用于地址范围和子网池的基于角色的访问控制（RBAC）。地址范围和子通常由运营商定义并向用户公开。此更改使操作员可以在地址范围和子网池上使用更精细的访问控制

4. Neutron API中添加了对创建过程中标记资源的支持。用户现在可以设置资源标签，例如直接在POST请求中移植端口。这将大大提高kubernetes网络操作的性能。API调用的数量，例如Kuryr已发送给Neutron的邮件大大减少

1. Nova不再支持Python 2，Python 3.6和3.7则受支持

2. 支持在Nova cells间进行冷迁移和重新调整虚拟机大小

3. 支持precaching glance image到计算节点

4. 支持在创建虚拟机时通过Cyborg来附加加速设备

5. 进一步支持QOS最小的带宽功能(拓展了以下操作evacuate、live migrate、unshelve)

6. 支持nova-manage placement auditCLI，以查找和清理孤立的资源分配

7. Nova API策略引入了具有scope_type功能的新默认角色。这些新更改提高了安全级别和可管理性。在处理具有“读取”和“写入”角色的系统和项目级别令牌的访问权限方面，新策略更加丰富

8. 从卷启动的虚拟机能够使用Rescue操作，允许将稳定的磁盘设备连接到救援实例

9. 计算节点支持多种虚拟GPU类型

10. 移除os-consoles和os-networksREST APIs

11. 移除nova-dhcpbridge、nova-console、nova-xvpvncproxy服务

Octavia提供负载均衡服务

1. Octavia现在支持在特定可用性区域中部署负载平衡器。这允许将负载平衡功能部署到边缘环境

2. Octavia amphora驱动程序已添加了一项技术预览功能，可以改善控制平面的弹性。如果控制平面主机在负载均衡器配置操作期间发生故障，备用控制器可以恢复进行中的配置并完成请求

3. 用户现在可以指定侦听器和池可接受的TLS密码。这允许负载平衡器强制执行安全合规性要求

Placement 放置服务，通过使分配重试计数可配置，提高了常见的并发分配写入次数（例如繁忙的群集管理程序）情况下的鲁棒性

1. 为Swift容器和对象添加了新的系统命名空间

2. 使用新的名称空间添加了新的Swift对象版本API

3. 添加了对使用新API的S3版本控制的支持

4. 添加了使用SIGUSR1执行“无缝”重载的功能，其中WSGI服务器套接字从不停止接受连接

1. 改进了对配置的默认卷类型的处理，并使用microversion 3.62添加了新的块存储API调用，可以为单个项目设置项目级别的默认卷类型
2. 添加了一些新的后端驱动程序，同时当前的大部分驱动程序都添加了对更多功能的支持。例如，NFS驱动程序现在支持卷加密
3. 使用流行的Zstandard压缩算法，增加了对cinder备份的支持

1. 自Ussuri发行以来，用户可以使用由Cyborg管理的加速器启动实例，该发行版还支持两项操作Rebuild and Evacuate
2. Cyborg支持新的加速器驱动程序（Intel QAT和Inspur FPGA），并达成协议，希望实施新驱动程序的供应商至少应提供完整的驱动程序报告结果
3. 支持Program API，现在，用户可以在给定预加载的bitstream的情况下对FPGA进行编程
4. 在此版本中，部分实施了针对cyborg的策略刷新（带有作用域的RBAC）（设备配置文件API），我们在基本策略和device_profile策略中实现了新的默认规则，并为所有策略添加了基本测试框架。对于向后兼容性，将旧规则保留为不推荐使用的规则，并使用与当前相同的默认值，以便现有部署将保持原样运行。实施所有功能后，我们将为用户提供两个周期的过渡期

1. 增强了多个商店功能，管理员现在可以设置策略以允许用户复制其他租户拥有的镜像
2. 概览允许配置多cinder存储
3. 一目了然的RBD和Filesystem驱动程序现在支持稀疏镜像上传
4. 增强了RBD驱动程序块上传镜像

1. 部署步骤工作将基本部署操作分解为多个步骤，现在还可以包括部署时支持的RAID和BIOS接口的步骤
2. 一个agent电源接口支持在没有基板管理控制器的情况下进行资源调配操作
3. 现在可以将Ironic配置为进行HTTP Basic身份验证，而无需其他服务
4. 添加了对Redfish虚拟介质的基于DHCP的部署的初始支持

1. 添加了对Ubuntu Focal 20.04的支持
2. 添加了对后端API服务的TLS加密的附加支持，从而提供了API流量的端到端加密
3. 增加了对核心OpenStack服务的容器健康检查的支持
4. 添加了对etcd的TLS加密的支持
5. 改善了Ansible Playbook的性能和可伸缩性
6. 增加了对将Neutron与Mellanox InfiniBand集成的支持
7. 为Kayobe添加了对在neutron上部署自定义容器的支持

1. Kuryr将不再使用注释在k8s api中存储关于OpenStack对象的数据。而是创建了一个相应的CRD，即KuryrPort、KuryrLoadBalancer和KuryrNetworkPolicy
2. 增加了在嵌套设置中自动检测虚拟机桥接接口的支持

1. 租户驱动的共享复制，数据保护，灾难恢复和高可用性的自助服务现已普遍可用并得到完全支持
2. 共享服务器迁移现在作为一个实验性功能提供。共享服务器通过隔离网络路径中的共享文件系统来提供多租户保证。在这个版本中，云管理员能够将共享服务器移动到不同的后端或共享网络

1. 现在可以通过IPv6使用元数据服务。用户现在可以在仅IPv6的网络中使用不带配置驱动器的元数据服务。
2. flat已为分布式虚拟路由器（DVR）添加了对网络的支持。
3. OVN后端增加了对浮动IP端口转发的支持。现在，在Neutron中使用OVN后端时，用户可以为浮动IP创建端口转发。
4. 在OVN中增加了对路由器可用区域的支持。OVN驱动程序现在可以从路由器的Availability_zone_hints字段中读取，并使用给定的可用区域相应地调度路由器端口

1. Nova支持在同一nova服务器中混合使用绑定和浮动CPU
2. Nova支持通过提供程序配置文件来自定义计算节点的放置资源清单
3. 即使使用Glance多存储 配置，Nova也支持 从Ceph RBD群集快速克隆Glance镜像 
4. Nova支持使用虚拟TPM设备创建服务器

1. 用户现在可以指定侦听器和池接受的TLS版本。用户现在还可以设置其部署可接受的最低TLS版本
2. Octavia现在使用新的侦听器应用程序层协议协商（ALPN）配置选项来支持TLS上的HTTP/2
3. 现在可以将负载均衡器统计信息同时报告给多个统计信息驱动程序，并支持增量指标。这样可以更轻松地集成到外部度量系统中，例如时间序列数据库
4. 用于amphora驱动程序的Octavia flavors现在支持将glance image标记指定为flavor的一部分。这允许用户定义Octavia flavor来引导备用的amphora镜像
5. 负载平衡器池现在支持PROXY协议的版本2。使用TCP协议时，这允许将客户端信息传递到成员服务器。PROXYV2提高了使用PROXY协议与成员服务器建立新连接的性能，尤其是在侦听器使用IPv6的情况下

1. 改进了读取纠错码数据时的第一字节延迟
2. 当使用单独的复制网络运行时，后台守护程序和代理服务器之间的隔离度增加
3. 我们开始看到生产集群从python2下运行Swift过渡到python3 

Neutron元数据代理日志（/var/log/neutron/metadata-agent.log）报错：The remote metadata server responded with Forbidden. This response usually occurs when shared secrets do not match.

可能原因：元数据代理配置文件metadata_agent.ini中的metadata_proxy_shared_secret和nova.conf中配置的不一样。

报错示例：compressor.exceptions.OfflineGenerationError: You have offline compression enabled but key "xxx" is missing from offline manifest. You may need to run "python manage.py compress". Here is the original content

解决办法：

然后重启httpd

禁用IPv6可以消除此错误：

linux-bridge从设计上禁用了IPv6，如果物理网卡上配置了IPv6地址，则neutron/root没有权限将IPv6地址从物理网卡移动到linux-bridge上。

尽管如此，linux-bridge仍然会将IPv6的L2帧转发，你仍然可以在客户机上使用IPv6。

使用provider网络时，底层网络中存在DHCP服务器时出现此情况。实例向底层网络中的DHCP请求了IP地址，而非DHCP Agent。

建议：使用底层网络，但是分配独立的网段。

需要修改镜像虚拟尺寸，首先检查一下镜像信息：

可以看到这是一个128G的XFS分区，由于XFS分区不支持Shrink，我们可以考虑将其备份，然后还原到一个较小的卷上。

把这个2G的卷保存为镜像即可。

镜像被外部程序修改，建议重新上传镜像。

上传卷为镜像时报此错误：Invalid volume: Volume 8d2747cf-b50e-4d36-a90a-33dd7b56cad4 status must be available

解决方案，配置Cinder：

重启控制节点服务：

从镜像创建卷失败，报如上错误。移除镜像的signature_verified属性即可解决：

openstack volume service list报告某些节点的cinder-volume处于down状态：

查看对应节点的/var/log/cinder/volume.log，出现上述报错。

原因：LVM卷组cinder-volumes没有初始化。 

首先重置状态：

然后登陆数据库删除记录：

报错内容：libvirt.libvirtError: internal error: Child process (tc filter add dev tapaf7dae14-ef parent ffff: protocol all u32 match u32 0 0 police rate 10485760kbps burst 10485760kb mtu 64kb drop flowid :1) unexpected exit status 1: Illegal "rate"

可能原因：限速的值太大了。

如果遇到报错：

Ignoring domain related config project_domain_name because identity API version is 2.0

Expecting to find domain in project. The server could not comply with the request since it is either malformed or otherwise incorrect. The client is assumed to be in error. (HTTP 400) (Request-ID: req-047e4968-2c06-4501-8635-0dd27093d5d8)

需要增加环境变量：