OpenStack资源管理层次模型

OpenStack有三种资源视图，分别为用户视图、OpenStack视图以及系统视图，这几个资源视图经常容易混淆。我们将这三种视图做个对比。

1 用户视图

用户视图是站在用户的视角所看到的资源，位于资源抽象的最顶端。对于用户来说，底层是个无限量的巨大抽象资源池，所能使用的资源仅仅受管理员的配额限制。用户视图的资源也称为逻辑资源，它的资源量通常与底层物理资源没有关系，因为底层资源对用户是透明的。用户视图的资源在其所在的租户内是封闭的，与其他租户的资源完全隔离并且无感知。

用户视图资源使用量在OpenStack中通常称为quota usage，我们可以通过OpenStack的API获取资源的使用量，以块存储资源Cinder为例，查看其quota usage：

~/jingh # cinder quota-usage 240e267f0c4043b3aac9123b4e7e85a0
+----------------------+--------+----------+-------+
|         Type         | In_use | Reserved | Limit |
+----------------------+--------+----------+-------+
|   backup_gigabytes   |   9    |    0     |  5120 |
|       backups        |   3    |    0     |  100  |
|      gigabytes       |   8    |    0     |  1000 |
| per_volume_gigabytes |   100  |    0     |   -1  |
|      snapshots       |   10   |    0     |   10  |
|       volumes        |   4    |    0     |   10  |
+----------------------+--------+----------+-------+

其中Limit就是配额的上限，即允许用户申请的最大资源量，-1表示无限制。 quota usage包含三个阈值：

• limit：用户允许使用的最大资源上限，当用户超出limit资源时请求将直接被拒回。
• reserve：预留资源，即已分配资源给用户但资源尚未被使用，比如用户申请虚拟机，虚拟机已经完成调度但还未创建完成。
• usage：用户已经使用的资源量。

以上三个数值关系满足：当limit不等于-1时， usage + reserve <= limit。

limit由管理员设置，当管理员创建一个新的租户时，默认继承自称为default quota class的值，创建完成后管理员可以根据需要修改配额值。

2 OpenStack视图

前面的用户视图资源是以租户为单位划分的，而OpenStack视图是个全局资源的概念，统计了OpenStack所纳管资源的总量和使用量，因此OpenStack视图的资源通常又称为物理资源。OpenStack基于该资源使用以及分布情况进行调度。当资源不足时，将导致虚拟机调度失败，用户请求不会报错，但虚拟机状态为ERROR。 但是需要注意的是，OpenStack视图的资源是按分配量计算的，而不是按照实际使用量统计。比如用户申请了一台2C 4GB的云主机，但该云主机关机了，此时云主机实际上并不占用任何CPU和内存，但OpenStack在统计中还是需要减去2C 4GB资源。对于OpenStack来说，已经分配的资源，不管用户究竟有没有在使用，除非删除，否则不会被回收，也不能被其他虚拟机抢占。 OpenStack统计的资源总量在不超售的情况下等于所有物理资源总和，但如果设置了超售，OpenStack实际分配的资源可能大于资源总量。 OpenStack Nova通过hypervisor-stats查看整个集群的资源使用情况:

~/jingh # nova hypervisor-stats
+----------------------+---------+
| Property             | Value   |
+----------------------+---------+
| count                | 18      |
| current_workload     | 0       |
| disk_available_least | 3617    |
| free_disk_gb         | 1562    |
| free_ram_mb          | 1018842 |
| local_gb             | 4452    |
| local_gb_used        | 2890    |
| memory_mb            | 4322820 |
| memory_mb_used       | 3303978 |
| running_vms          | 291     |
| vcpus                | 561     |
| vcpus_used           | 1148    |
+----------------------+---------+

需要注意的是，以上统计的是整个集群的物理资源，而不是单个计算节点的资源，这意味着并不是总量满足请求资源就可以调度，可能存在资源碎片导致调度虚拟机失败。比如，假设有20台计算节点，每个计算节点剩余2GB内存，统计总量内存剩余量为2GB * 20 == 40GB，但用户若申请一台4GB内存的虚拟机调度仍然会失败，原因是没有任何一个计算节点满足内存资源。

要查看单个计算节点的资源可以使用hypervisor-show子命令:

~/jingh # nova hypervisor-show 1
+---------------------------+-----------------+
| Property                  | Value           |
+---------------------------+-----------------+
| free_disk_gb              | 561             |
| free_ram_mb               | 58978           |
| local_gb                  | 1181            |
| local_gb_used             | 620             |
| memory_mb                 | 262002          |
| memory_mb_used            | 203024          |
| vcpus                     | 32              |
| vcpus_used                | 86              |
|...                        | ...             |
+---------------------------+-----------------+

3 系统视图

系统视图是指资源供给者(provider)的资源统计，这是操作系统级别的统计，包括了宿主机的进程以及虚拟机所占用的资源，我们可以通过free命令查看内存使用情况。OpenStack通过ceilometer收集宿主机的资源使用情况，与之相关的meters如下:

$ ceilometer meters-list
host.cpu.util
host.disk.read.speed
host.disk.util
host.disk.write.speed
host.memory.util
...

需要注意的是，OpenStack调度时不会考虑计算节点的实时系统资源，而只考虑OpenStack视图下的分配资源。经常有一些人在创建虚拟机由于内存不足导致调度失败时，就跑去计算节点运行free命令，发现free命令结果中显示内存还够，于是很疑惑为什么会调度失败，这就是弄混了OpenStack视图下的资源和系统视图下的资源统计。

4 三者的联系

理论上其实这三者并无联系，层层抽象，层层透明。但管理员在设置用户的配额信息时肯定会参考OpenStack集群的资源情况，而OpenStack视图的资源总量是从计算节点的物理资源总量收集的，换句话说，只有资源总量存在一定的关联，资源使用量以及剩余量完全没有关系，各自统计各自的，互不干扰。

注意：

• 当用户资源配额不足(request + usage > limit时，用户申请新的资源请求将直接被驳回，提示资源配额不足。
• 当OpenStack资源不足时，用户申请新的资源的请求不会报错，但最终资源会调度失败，创建的虚拟机状态为Error.
• 当计算节点的系统资源不足时，这个后果比较严重，可能出现OOM导致该节点的大量虚拟机被系统杀掉，虚拟机直接宕机，业务终止。管理员应该避免出现这种情况，尽量不要设置过高的超售比。

以下列举几个常见的场景对三个视图资源的影响。

• Previous
  OpenStack高级特性简介
• Next
  从运行原理及使用场景看Apache和Nginx