Nova 組件詳解 - 每天5分鐘玩轉 OpenStack（26）

本節開始，我們將詳細講解 Nova 的各個子服務。

前面架構概覽一節知道 Nova 有若干 nova-* 的子服務，下面我們將依次學習最重要的幾個。
今天先討論 nova-api 和 nova-conductor。

nova-api

Nova-api 是整個 Nova 組件的門戶，所有對 Nova 的請求都首先由 nova-api 處理。 Nova-api 向外界暴露若干 HTTP REST API 接口。 在 keystone 中我們可以查詢 nova-api 的 endponits。

客戶端就可以將請求發送到 endponits 指定的地址，向 nova-api 請求操作。 當然，作為最終用戶的我們不會直接發送 Rest AP I請求。 OpenStack CLI，Dashboard 和其他需要跟 Nova 交換的組件會使用這些 API。

Nova-api 對接收到的 HTTP API 請求會做如下處理： 1. 檢查客戶端傳人的參數是否合法有效 2. 調用 Nova 其他子服務的處理客戶端 HTTP 請求 3. 格式化 Nova 其他子服務返回的結果并返回給客戶端

nova-api 接收哪些請求？ 簡單的說，只要是跟虛擬機生命周期相關的操作，nova-api 都可以響應。 大部分操作都可以在 Dashboard 上找到。

打開Instance管理界面

點擊下拉箭頭，列表中就是 nova-api 可執行的操作。

OpenStack 用術語 “Instacne” 來表示虛擬機，后面我們將統一使用這個術語。

nova-conductor

nova-compute 需要獲取和更新數據庫中 instance 的信息。 但 nova-compute 并不會直接訪問數據庫，而是通過 nova-conductor 實現數據的訪問。

這樣做有兩個顯著好處：

1. 更高的系統安全性

2. 更好的系統伸縮性

更高的安全性

在 OpenStack 的早期版本中，nova-compute 可以直接訪問數據庫，但這樣存在非常大的安全隱患。 因為 nova-compute 這個服務是部署在計算節點上的，為了能夠訪問控制節點上的數據庫，就必須在計算節點的 /etc/nova/nova.conf 中配置訪問數據庫的連接信息，比如

[database] connection = mysql+pymysql://root:secret@controller/nova?charset=utf8

試想任意一個計算節點被******，都會導致部署在控制節點上的數據庫面臨極大風險。

為了解決這個問題，從 G 版本開始，Nova 引入了一個新服務 nova-conductor，將 nova-compute 訪問數據庫的全部操作都放到 nova-conductor 中，而且 nova-conductor 是部署在控制節點上的。 這樣就避免了 nova-compute 直接訪問數據庫，增加了系統的安全性。

更好的伸縮性

nova-conductor 將 nova-compute 與數據庫解耦之后還帶來另一個好處：提高了 nova 的伸縮性。

nova-compute 與 conductor 是通過消息中間件交互的。 這種松散的架構允許配置多個 nova-conductor 實例。 在一個大規模的 OpenStack 部署環境里，管理員可以通過增加 nova-conductor 的數量來應對日益增長的計算節點對數據庫的訪問。

下一節我們討論計算節點調度服務 nova-scheduler.