本系列文章同步發布於筆者網站

上一篇文章我們介紹了 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 的介紹