Nova 組件詳解

本節開始，咱們將詳細講解 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 用術語 「Instance」 來表示虛擬機，後面咱們將統一使用這個術語。

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.