OpenStack Nova 介绍 2

本系列文章同步发布於笔者网站

上一篇文章我们介绍了 Nova 的功能与其使用方法，本篇文章将会继续介绍 Nova 的架构

OpenStack Nova 系统架构

Nova 包含多个服务器进程 (process)，每个进程执行不同的功能。 面向用户的界面是 REST API，而内部 Nova 的不同元件透过 RPC 来进行沟通运作。

API 服务器处理 REST 请求，这通常涉及资料库读/写、或是 RPC 消息发送到其他 Nova 服务，并生对应的 REST 回应 (response)。 RPC message 传递是通过 oslo.messaging 完成的，它是一个 OpenStack 元件共用的 RPC message 抽象层，让 OpenStack 元件可以不用在意底下 RPC 的实作。

大多数主要的 nova 元件都可以在多台服务器上运行，并且有一个 manager 来监听 RPC message，达到高可用性和附载平衡的目的。一个主要的例外是 nova-compute，它只在每一个其管理的 hypervisor 上运行单一个进程（使用 VMware 或 Ironic driver 时除外）。

Nova 的所有组件之间使用了一个逻辑上共享的中央资料库。然而，为了减轻升级时的负担，资料库是通过一个 object layer 进行沟通的，以确保升级後的控制平面 (control plane) 仍然可以与先前版本的 nova-compute 进行沟通。因此　nova-compute 通过 RPC 将所有 DB 请求代理到 nova-conductor 这个元件，关於其详细怎麽运作的可以参考这篇文章的 Objects 章节。

Nova 各个元件以及其所负责的功能

我们可以参考官方文件上的图示来了解 Nova 内部元件跟 OpenStack 其他元件的相互关系以及之间是如何沟通的：

我们可以整理出：

• Nova 与其他元件的沟通都是透过 REST API
• Nova 内部元件都是透过 oslo.messaging 提供的 RPC 沟通
• nova-compute 的 DB 请求都是透过 nova-conductor 去处理

再来笔者介绍一下各个元件主要负责的功能

• DB：用於存储资料的 SQL 资料库，通常使用 MariaDB。
• API：接收 HTTP 请求、转换命令并通过 oslo.messaging RPC 或 HTTP 与其他元件沟通。
• Scheduler：负责决定哪个主机 (hypervisor) 来生成每个实例 (instance)。
• Compute：管理 Nova 跟 hypervisor 和虚拟机的沟通。
• Conductor：处理需要协调多个元件的请求 (build/resize 等)，nova-compute 的资料库代理等工作。
• Placement：追踪资源提供者的库存和使用情况。

以上就是 Nova 整个架构面的技术介绍，如果有不懂的地方也可以在留言区询问。

小结

到本篇为止就介绍完了 Nova 的整个架构以及其功能，下一篇会为大家带来 Keystone 的介绍