openstack 命令

CLI 创建 image
1、将 image 上传到控制节点的文件系统中，例如 /tmp/cirros-0.3.4-x86_64-disk.img
2、设置环境变量
source devstack/openrc admin admin
Devstack 的安装目录下有个 openrc 文件。source 该文件就可以配置 CLI 的环境变量。这里我们传入了两个参数，第一个参数是 OpenStack 用户名 admin；第二个参数是 Project 名 admin
3、执行 image 创建命令
glance image-create --name cirros --file /tmp/cirros-0.3.4-x86_64-disk.img --disk-format qcow2 --container-format bare --progress
在 /opt/stack/data/glance/images/ 下查看新的 Image

CLI 删除 image
1、查询现有image
glance image-list
2、删除image
glance image-delete 1651654s-d15dsf-adsf1-354-adf5-3a1465

如何使用 OpenStack CLI
OpenStack 服务都有自己的 CLI。
命令很好记，就是服务的名字，比如 Glance 就是 glance，Nova 就是 nova。
但 Keystone 比较特殊，现在是用 openstack 来代替老版的 keystone 命令。

不同服务用的命令虽然不同，但这些命令使用方式却非常类似，可以举一反三。
1. 执行命令之前，需要设置环境变量。
这些变量包含用户名、Project、密码等；
如果不设置，每次执行命令都必须设置相关的命令行参数

2. 各个服务的命令都有增、删、改、查的操作
其格式是
CMD <obj>-create [parm1] [parm2]…
CMD <obj>-delete [parm]
CMD <obj>-update [parm1] [parm2]…
CMD <obj>-list
CMD <obj>-show [parm]
例如 glance 管理的是 image，那么:
CMD 就是 glance；obj 就是 image
对应的命令就有

glance image-create
glance image-delete
glance image-update
glance image-list
glance image-show
再比如 neutron 管理的是网络和子网等，那么：
CMD 就是 neutron；obj 就是 net 和 subnet
对应的命令就有

网络相关操作
neutron net-create
neutron net -delete
neutron net -update
neutron net -list
neutron net –show
子网相关操作
neutron subnet-create
neutron subnet -delete
neutron subnet -update
neutron subnet -list
neutron subnet–show
有的命令 <obj> 可以省略，比如 nova
下面的操作都是针对 instance
nova boot
nova delete
nova list
nova show

3. 每个对象都有 ID
delete，show 等操作都以 ID 为参数，例如


如何 Troubleshooting
OpenStack 排查问题的方法主要是通过日志，Service 都有自己单独的日志。
Glance 主要有两个日志，glance_api.log 和 glance_registry.log，保存在 /var/log/glance/ 目录里。
devstack 的 screen 窗口已经帮我们打开了这两个日志，可以直接查看
g-api 窗口显示 glance-api 日志，记录 REST API 调用情况
g-reg 窗口显示 glance-registry 日志，记录 Glance 服务处理请求的过程以及数据库操作

如果需要得到最详细的日志信息，可以在 /etc/glance/*.conf 中打开 debug 选项。
devstack 默认已经打开了 debug。

Nova
Nova 处于 Openstak 架构的中心，其他组件都为 Nova 提供支持：
Glance 为 VM 提供 image
Cinder 和 Swift 分别为 VM 提供块存储和对象存储
Neutron 为 VM 提供网络连接

nova-api
接收和响应客户的 API 调用。
除了提供 OpenStack 自己的API，nova-api 还支持 Amazon EC2 API。
也就是说，如果客户以前使用 Amazon EC2，并且用 EC2 的 API 开发了些工具来管理虚机，那么如果现在要换成 OpenStack，这些工具可以无缝迁移到 OpenStack，因为 nova-api 兼容 EC2 API，无需做任何修改。

Compute Core
nova-scheduler
虚机调度服务，负责决定在哪个计算节点上运行虚机
nova-compute
管理虚机的核心服务，通过调用 Hypervisor API 实现虚机生命周期管理
Hypervisor
计算节点上跑的虚拟化管理程序，虚机管理最底层的程序。
不同虚拟化技术提供自己的 Hypervisor。
常用的 Hypervisor 有 KVM，Xen， VMWare 等
nova-conductor
nova-compute 经常需要更新数据库，比如更新虚机的状态。
出于安全性和伸缩性的考虑，nova-compute 并不会直接访问数据库，而是将这个任务委托给 nova-conductor，这个我们在后面会详细讨论。
Console Interface
nova-console
用户可以通过多种方式访问虚机的控制台：
nova-novncproxy，基于 Web 浏览器的 VNC 访问
nova-spicehtml5proxy，基于 HTML5 浏览器的 SPICE 访问
nova-xvpnvncproxy，基于 Java 客户端的 VNC 访问
nova-consoleauth
负责对访问虚机控制台请亲提供 Token 认证
nova-cert
提供 x509 证书支持


从虚机创建流程看 nova-* 子服务如何协同工作
1、客户（可以是 OpenStack 最终用户，也可以是其他程序）向 API（nova-api）发送请求：“帮我创建一个虚机”

2、API 对请求做一些必要处理后，向 Messaging（RabbitMQ）发送了一条消息：“让 Scheduler 创建一个虚机”

3、Scheduler（nova-scheduler）从 Messaging 获取到 API 发给它的消息，然后执行调度算法，从若干计算节点中选出节点 A

4、Scheduler 向 Messaging 发送了一条消息：“在计算节点 A 上创建这个虚机”

5、计算节点 A 的 Compute（nova-compute）从 Messaging 中获取到 Scheduler 发给它的消息，然后在本节点的 Hypervisor 上启动虚机。

6、在虚机创建的过程中，Compute 如果需要查询或更新数据库信息，会通过 Messaging 向 Conductor（nova-conductor）发送消息，Conductor 负责数据库访问。

上面是创建虚机最核心的几个步骤，当然也省略了很多细节，我们会在后面的章节详细讨论。 这几个步骤向我们展示了 nova-* 子服务之间的协作的方式，也体现了 OpenStack 整个系统的分布式设计思想，







nova-scheduler 的调度机制和实现方法
创建 Instance 时，用户会提出资源需求，例如 CPU、内存、磁盘各需要多少。
OpenStack 将这些需求定义在 flavor 中，用户只需要指定用哪个 flavor 就可以了。

lavor 主要定义了 VCPU，RAM，DISK 和 Metadata 这四类。 nova-scheduler 会按照 flavor 去选择合适的计算节点。 VCPU，RAM，DISK 比较好理解，而 Metatdata 比较有意思，我们后面会具体讨论。
下面介绍 nova-scheduler 是如何实现调度的。
在 /etc/nova/nova.conf 中，nova 通过 scheduler_driver，scheduler_available_filters 和 scheduler_default_filters 这三个参数来配置 nova-scheduler。

Filter scheduler
Filter scheduler 是 nova-scheduler 默认的调度器，调度过程分为两步：
通过过滤器（filter）选择满足条件的计算节点（运行 nova-compute）
通过权重计算（weighting）选择在最优（权重值最大）的计算节点上创建 Instance。
scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler
Nova 允许使用第三方 scheduler，配置 scheduler_driver 即可。 这又一次体现了OpenStack的开放性。
Scheduler 可以使用多个 filter 依次进行过滤，过滤之后的节点再通过计算权重选出最适合的节点。


Filter
当 Filter scheduler 需要执行调度操作时，会让 filter 对计算节点进行判断，filter 返回 True 或 False。
Nova.conf 中的 scheduler_available_filters 选项用于配置 scheduler 可用的 filter，默认是所有 nova 自带的 filter 都可以用于滤操作。
scheduler_available_filters = nova.scheduler.filters.all_filters
另外还有一个选项 scheduler_default_filters，用于指定 scheduler 真正使用的 filter，默认值如下
scheduler_default_filters = RetryFilter, AvailabilityZoneFilter, RamFilter, DiskFilter, ComputeFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter, ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter
Filter scheduler 将按照列表中的顺序依次过滤。 下面依次介绍每个 filter。
RetryFilter
RetryFilter 的作用是刷掉之前已经调度过的节点。
举个例子方便大家理解： 假设 A,B,C 三个节点都通过了过滤，最终 A 因为权重值最大被选中执行操作。 但由于某个原因，操作在 A 上失败了。 默认情况下，nova-scheduler 会重新执行过滤操作（重复次数由 scheduler_max_attempts 选项指定，默认是 3）。 那么这时候 RetryFilter 就会将 A 直接刷掉，避免操作再次失败。 RetryFilter 通常作为第一个 filter。
AvailabilityZoneFilter
为提高容灾性和提供隔离服务，可以将计算节点划分到不同的Availability Zone中。
例如把一个机架上的机器划分在一个 Availability Zone 中。 OpenStack 默认有一个命名为 “Nova” 的 Availability Zone，所有的计算节点初始都是放在 “Nova” 中。 用户可以根据需要创建自己的 Availability Zone。

创建 Instance 时，需要指定将 Instance 部署到在哪个 Availability Zone中。


nova-scheduler 在做 filtering 时，会使用 AvailabilityZoneFilter 将不属于指定 Availability Zone 的计算节点过滤掉。

RamFilter
RamFilter 将不能满足 flavor 内存需求的计算节点过滤掉。
对于内存有一点需要注意： 为了提高系统的资源使用率，OpenStack 在计算节点可用内存时允许 overcommit，也就是可以超过实际内存大小。 超过的程度是通过 nova.conf 中 ram_allocation_ratio 这个参数来控制的，默认值为 1.5
ram_allocation_ratio = 1.5
其含义是：如果计算节点的内存有 10GB，OpenStack 则会认为它有 15GB（10*1.5）的内存。

DiskFilter
DiskFilter 将不能满足 flavor 磁盘需求的计算节点过滤掉。
Disk 同样允许 overcommit，通过 nova.conf 中 disk_allocation_ratio 控制，默认值为 1
disk_allocation_ratio = 1.0

CoreFilter
CoreFilter 将不能满足 flavor vCPU 需求的计算节点过滤掉。
vCPU 同样允许 overcommit，通过 nova.conf 中 cpu_allocation_ratio 控制，默认值为 16
cpu_allocation_ratio = 16.0
这意味着一个 8 vCPU 的计算节点，nova-scheduler 在调度时认为它有 128 个 vCPU。 需要提醒的是： nova-scheduler 默认使用的 filter 并没有包含 CoreFilter。 如果要用，可以将 CoreFilter 添加到 nova.conf 的 scheduler_default_filters 配置选项中。

ComputeFilter
ComputeFilter 保证只有 nova-compute 服务正常工作的计算节点才能够被 nova-scheduler调度。
ComputeFilter 显然是必选的 filter。

ComputeCapabilitiesFilter
ComputeCapabilitiesFilter 根据计算节点的特性来筛选。
这个比较高级，我们举例说明。
例如我们的节点有 x86_64 和 ARM 架构的，如果想将 Instance 指定部署到 x86_64 架构的节点上，就可以利用到 ComputeCapabilitiesFilter。
还记得 flavor 中有个 Metadata 吗，Compute 的 Capabilitie s就在 Metadata中 指定。

ImagePropertiesFilter
ImagePropertiesFilter 根据所选 image 的属性来筛选匹配的计算节点。
跟 flavor 类似，image 也有 metadata，用于指定其属性。
配置好后，ImagePropertiesFilter 在调度时只会筛选出 kvm 的节点。
如果没有设置 Image 的Metadata，ImagePropertiesFilter 不会起作用，所有节点都会通过筛选。

ServerGroupAntiAffinityFilter
ServerGroupAntiAffinityFilter 可以尽量将 Instance 分散部署到不同的节点上。
例如有 inst1，inst2 和 inst3 三个 instance，计算节点有 A,B 和 C。
为保证分散部署，进行如下操作：
创建一个 anti-affinity 策略的 server group “group-1”
nova server-group-create --policy anti-affinity group-1
请注意，这里的 server group 其实是 instance group，并不是计算节点的 group。
依次创建 Instance，将inst1, inst2和inst3放到group-1中
nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst1
nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst2
nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst3
因为 group-1 的策略是 AntiAffinity，调度时 ServerGroupAntiAffinityFilter 会将 inst1, inst2 和 inst3 部署到不同计算节点 A, B 和 C。
目前只能在 CLI 中指定 server group 来创建 instance。
创建 instance 时如果没有指定 server group，ServerGroupAntiAffinityFilter 会直接通过，不做任何过滤。

ServerGroupAffinityFilter
与 ServerGroupAntiAffinityFilter 的作用相反，ServerGroupAffinityFilter 会尽量将 instance 部署到同一个计算节点上。
方法类似
创建一个 affinity 策略的 server group “group-2”
nova server-group-create --policy affinity group-2
依次创建 instance，将 inst1, inst2 和 inst3 放到 group-2 中
nova boot --image IMAGE_ID --flavor 1 --hint group=group-2 inst1
nova boot --image IMAGE_ID --flavor 1 --hint group=group-2 inst2
nova boot --image IMAGE_ID --flavor 1 --hint group=group-2 inst3
因为 group-2 的策略是 Affinity，调度时 ServerGroupAffinityFilter 会将 inst1, inst2 和 inst3 部署到同一个计算节点。
创建 instance 时如果没有指定 server group，ServerGroupAffinityFilter 会直接通过，不做任何过滤。

Weight
经过前面一堆 filter 的过滤，nova-scheduler 选出了能够部署 instance 的计算节点。
如果有多个计算节点通过了过滤，那么最终选择哪个节点呢？
Scheduler 会对每个计算节点打分，得分最高的获胜。
打分的过程就是 weight，翻译过来就是计算权重值，那么 scheduler 是根据什么来计算权重值呢？
目前 nova-scheduler 的默认实现是根据计算节点空闲的内存量计算权重值：
空闲内存越多，权重越大，instance 将被部署到当前空闲内存最多的计算节点上

日志
是时候完整的回顾一下 nova-scheduler 的工作过程了。
整个过程都被记录到 nova-scheduler 的日志中。
比如当我们部署一个 instance 时
打开 nova-scheduler 的日志 /opt/stack/logs/n-sch.log（非 devstack 安装其日志在 /var/log/nova/scheduler.log）






nova-compute
nova-compute 在计算节点上运行，负责管理节点上的 instance。
OpenStack 对 instance 的操作，最后都是交给 nova-compute 来完成的。
nova-compute 与 Hypervisor 一起实现 OpenStack 对 instance 生命周期的管理。

通过 Driver 架构支持多种 Hypervisor
接着的问题是：现在市面上有这么多 Hypervisor，nova-compute 如何与它们配合呢？
这就是我们之前讨论过的 Driver 架构。
nova-compute 为这些 Hypervisor 定义了统一的接口，Hypervisor 只需要实现这些接口，就可以 Driver 的形式即插即用到 OpenStack 系统中。
下面是Nova Driver的架构示意图

我们可以在 /opt/stack/nova/nova/virt/ 目录下查看到 OpenStack 源代码中已经自带了上面这几个 Hypervisor 的 Driver
某个特定的计算节点上只会运行一种 Hypervisor，只需在该节点 nova-compute 的配置文件 /etc/nova/nova.conf 中配置所对应的 compute_driver 就可以了。
compute_driver=libvirt.LibvirtDriver

nova-compute 的功能可以分为两类：
1、定时向 OpenStack 报告计算节点的状态
2、实现 instance 生命周期的管理