OpenStack资源管理层次模型

转载自：https://www.talkwithtrend.com/Article/240419

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

1 用户视图

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

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

1. ~/int32bit # cinder quota-usage 240e267f0c4043b3aac9123b4e7e85a0
2. +----------------------+--------+----------+-------+
3. | Type | In_use | Reserved | Limit |
4. +----------------------+--------+----------+-------+
5. | backup_gigabytes | 9 | 0 | 5120 |
6. | backups | 3 | 0 | 100 |
7. | gigabytes | 8 | 0 | 1000 |
8. | per_volume_gigabytes | 100 | 0 | -1 |
9. | snapshots | 10 | 0 | 10 |
10. | volumes | 4 | 0 | 10 |
11. +----------------------+--------+----------+-------+

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

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

以上三个数值关系满足：

1. 当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查看整个集群的资源使用情况:

1. ~/int32bit # nova hypervisor-stats
2. +----------------------+---------+
3. | Property | Value |
4. +----------------------+---------+
5. | count | 18 |
6. | current_workload | 0 |
7. | disk_available_least | 3617 |
8. | free_disk_gb | 1562 |
9. | free_ram_mb | 1018842 |
10. | local_gb | 4452 |
11. | local_gb_used | 2890 |
12. | memory_mb | 4322820 |
13. | memory_mb_used | 3303978 |
14. | running_vms | 291 |
15. | vcpus | 561 |
16. | vcpus_used | 1148 |
17. +----------------------+---------+

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

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

1. ~/int32bit # nova hypervisor-show 1
2. +---------------------------+-----------------+
3. | Property | Value |
4. +---------------------------+-----------------+
5. | free_disk_gb | 561 |
6. | free_ram_mb | 58978 |
7. | local_gb | 1181 |
8. | local_gb_used | 620 |
9. | memory_mb | 262002 |
10. | memory_mb_used | 203024 |
11. | vcpus | 32 |
12. | vcpus_used | 86 |
13. |... | ... |
14. +---------------------------+-----------------+

3 系统视图

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

1. $ ceilometer meters-list
2. host.cpu.util
3. host.disk.read.speed
4. host.disk.util
5. host.disk.write.speed
6. host.memory.util
7. ...

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

4 三者的联系

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

注意：

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

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

场景	用户视图	OpenStack视图	系统视图
创建一台2C4GB虚拟机	CPU-2, RAM-2	CPU-2,RAM-2	虚拟机所在计算节点可用资源减少
关机一台虚拟机	不变	不变	虚拟机所在计算节点可用资源增加
增加一个计算节点(16C16G)	不变	CPU+16,RAM+16	不变
删除一台2C4GB虚拟机	CPU+2,RAM+4	CPU+2,RAM+4	虚拟机所在计算节点可用资源增加
挂起(suspend)一台2C4GB虚拟机	不变	不变	虚拟机所在计算节点可用资源增加
搁置(shelve)一台2C4GB虚拟机	CPU+2,RAM+4	CPU+2,RAM+4	虚拟机所在计算节点可用资源增加