OpenStack计算管理-nova

OpenStack计算管理-nova

nova负责：

•虚拟机生命周期管理

•其他计算资源生命周期管理
nova不负责：

•承载虚拟机的物理主机自身的管理

•全面的系统状态监控

NOVA系统架构

•DB ：用于数据存储的SQL数据库。
•API ：接收 HTTP 请求、转换命令并通过oslo.messaging队列或 HTTP与其他组件通信的组件。
•Scheduler ：为虚拟机选择合适的物理主机。
•Compute ：虚拟机生命周期和复杂流程控制。
•Conductor ：处理需要协调（构建/调整大小）的请求，充当数据库代理或处理对象转换。

•Placement：跟踪资源提供者的库存和使用情况。

•RPC：Remote Procedure Call，远程过程调用，是一个计算机通信协议。该协议允许运行于一台计算机

的程序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。

•API服务器处理REST请求，通常涉及数据库读写，将RPC消息发送到其他Nova服务（可选），并生成对

REST调用的响应。

•RPC消息传递是通过oslo.messaging库完成的，它是消息队列之上的抽象。

•Nova使用基于消息传递的"无共享"架构，大多数主要的nova组件可以在多个服务器上运行，并且有一个

监听RPC消息的管理器

查看计算节点的nova服务

nova物理部署

检查RabbitMQ服务是否正常

[root@controller ~(keystone_admin)]# systemctl status rabbitmq-server.service

nova服务运行架构

nova-api

nova-conductor

nova-scheduler

Nova 允许使用第三方 scheduler，配置 scheduler_driver 即可。 这又一次体现了OpenStack的开放

性。Scheduler 可以使用多个 filter 依次进行过滤，过滤之后的节点再通过计算权重选出最适合的节点。

nova-compute

RabbitMQ性能查看

默认安装中，我们只能用命令 rabbitmqctl 监控 RabbitMQ，比如：rabbitmqctl list_queues，

rabbitmqctl list_exchanges 等子命令。这种方式不太直观，效率不高。

好在 RabbitMQ 有一个管理 plugin，提供了图形管理界面，可以在运行 RabbitMQ 的节点（一般是控制

节点）执行下面的命令启用。

[root@controller ~]# rabbitmq-plugins enable rabbitmq_management
Enabling plugins on node rabbit@controller:
rabbitmq_management
The following plugins have been configured:
rabbitmq_management
rabbitmq_management_agent
rabbitmq_web_dispatch
Applying plugin configuration to rabbit@controller...
The following plugins have been enabled:
rabbitmq_management
rabbitmq_management_agent
rabbitmq_web_dispatch
started 3 plugins.

#然后还需要创建一个 用户，用来登录管理控制台了。
[root@controller ~]# iptables -F
[root@controller ~]# rabbitmqctl add_user user_admin passwd_admin   #创建用户名密码
Adding user "user_admin" ...
[root@controller ~]# rabbitmqctl set_user_tags user_admin administrator 
rabbitmqctl set_permissions -p / user_admin ".*" ".*" ".*"    
#授权
Setting tags for user "user_admin" to [administrator, rabbitmqctl, 
set_permissions, user_admin, .*, .*, .*] ...

观察Unacked

Unacked Message 指的是还没有被处理的消息。正常情况下，这个值应该为 0。如不是 0，并且持续增

长，那你就得注意了，这意味着RabbitMQ 出现了问题，队列开始积压，消息开始堆积，是一个严重的

信号。

接下来怎么办呢？

这个时候就可以点开 Overview 后面的标签，查看到底消息是在哪个或者哪些 Connection，Channel，

Exchange，Queues 中堆积，进而分析问题的根源并解决。

创建虚拟机过程（简单版）

1. 客户（可以是 OpenStack 最终用户，也可以是其他程序）向 API（nova-api）发送请求："帮我创
   建一个 Instance"
2. API对请求做一些必要处理后，向 Messaging（RabbitMQ）发送了一条消息："让 Scheduler 创建
   一个 Instance"
3. Scheduler（nova-scheduler）从 Messaging 获取到 API 发给它的消息，然后执行调度算法，从若
   干计算节点中选出节点 A。
   请参考 看 nova-scheduler 如何选择计算节点
4. Scheduler 向 Messaging 发送了一条消息："在计算节点 A 上创建这个 Instance"
5. 计算节点 A 的 Compute（nova-compute）从 Messaging 中获取到 Scheduler 发给它的消息，然
   后通过本节点的 Hypervisor Driver 创建 Instance。请参考 nova-compute 部署 instance详解
6. 在 Instance 创建的过程中，Compute 如果需要查询或更新数据库信息，会通过 Messaging 向
   节点的 Hypervisor Driver 创建 Instance。请参考 nova-compute 部署 instance详解
7. 在 Instance 创建的过程中，Compute 如果需要查询或更新数据库信息，会通过 Messaging 向
   Conductor（nova-conductor）发送消息，Conductor 负责数据库访问。