同 Cinder 一样,Nova 本身不包括 Hypervisor,而是向下通过相应的驱动与 Hypervisor 交互,向上对外提供 API。

因此,Nova 负责虚拟机/计算资源生命周期管理,但不承载虚拟机的物理主机自身的管理,也不做系统状态监控。

Nova 架构相当复杂,内部组件众多,与外部组件交互也多,基本通信方案:

  1. 内部组件间使用 RPC 通信(通过 oslo.messaging
  2. 外部组件使用 HTTP 通信
  3. 数据库作为全局状态接受各内部组件的读写

组件:

  1. Controller Node 控制节点,一般同时部署 api、conductor、scheduler 组件
    1. nova-api API 层,已经相当重了
      1. 转化 REST API(HTTP 请求)内部组件 RPC 调用(消息队列消息),转化 RPC 调用结果为 HTTP 响应
    2. 中间层
      1. nova-scheduler 为虚拟机选择合适的物理主机
      2. nova-conductor 处理需要协调(构建/调整大小)的请求,总之,这层的存在主要为了解耦计算节点对数据库的操作
        1. 代理 nova-compute 对数据库的操作解耦和避免风险
        2. 参与复杂流程控制:创建、迁移、删除、重建、规格调整
        3. 其他组件的依赖,nova-conductor 作为桥梁核心,需要预先启动
    3. DB(MySQL)
    4. AMQP(Rabbit-MQ)
  2. Compute Node 计算节点(虚拟化层)
    1. nova-compute 虚拟机生命周期的真正执行者(调用 Hypervisor 的驱动),其他还有
      1. 虚拟机状态同步
      2. 资源统计
    2. Hypervisor 真正的虚拟化部分:Hyper-V/Xen/VMWare/Libvirt(KVM/QEMU/LXC)
  3. 其他

Nova 命令

细节问题

虚拟机状态

虚拟机状态在 Nova 中记录/表示的相当复杂,涉及多个字段:

  1. vm_state 数据库中记录的虚拟机状态
  2. task_state 当前虚拟机的任务状态,一般是中间态或者 null
  3. power_state hypervisor 获取的虚拟机的真实状态
  4. status 对外呈现的虚拟机状态,vm_statetask_state 联合生成

Nova 创建虚拟机流程

过于复杂

Nova 典型操作

  1. 虚拟机生命周期管理
  2. 虚拟机资源
    1. 卷:挂载、卸载、查询
    2. 网卡:挂载、卸载、查询
  3. 其他资源:Flavor 规格、Host Group 主机组、Quota 配额
  4. 其他组件的 API 封装
    1. Cinder:卷和快照
    2. Neutron:虚拟网络
    3. Glance:镜像