本節(jié)開始，我們將詳細講解 Nova 的各個子服務(wù)。

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

nova-api

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

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

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

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

打開Instance管理界面

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

OpenStack 用術(shù)語 “Instance” 來表示虛擬機，后面我們將統(tǒng)一使用這個術(shù)語。

nova-conductor

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

這樣做有兩個顯著好處：

更高的系統(tǒng)安全性

更好的系統(tǒng)伸縮性

更高的安全性

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

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

試想任意一個計算節(jié)點被黑客入侵，都會導致部署在控制節(jié)點上的數(shù)據(jù)庫面臨極大風險。

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

更好的伸縮性

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

nova-compute 與 conductor 是通過消息中間件交互的。 這種松散的架構(gòu)允許配置多個 nova-conductor 實例。 在一個大規(guī)模的 OpenStack 部署環(huán)境里，管理員可以通過增加 nova-conductor 的數(shù)量來應(yīng)對日益增長的計算節(jié)點對數(shù)據(jù)庫的訪問。

下一節(jié)我們討論計算節(jié)點調(diào)度服務(wù) nova-scheduler.

轉(zhuǎn)載于:https://www.cnblogs.com/CloudMan6/p/5436855.html

總結(jié)

以上是生活随笔為你收集整理的Nova 组件详解 - 每天5分钟玩转 OpenStack（26）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。