Nova 組件如何協同工做 - 天天5分鐘玩轉 OpenStack（24）

Nova 物理部署方案

前面你們已經看到 Nova 由不少子服務組成，同時咱們也知道 OpenStack 是一個分佈式系統，能夠部署到若干節點上，那麼接下來你們可能就會問： Nova 的這些服務在物理上應該如何部署呢？

對於 Nova，這些服務會部署在兩類節點上：計算節點和控制節點。 計算節點上安裝了 Hypervisor，上面運行虛擬機。 由此可知： 1. 只有 nova-compute 須要放在計算節點上。 2. 其餘子服務則是放在控制節點上的。

下面咱們能夠看看實驗環境的具體部署狀況。 經過在計算節點和控制節點上運行 ps -elf|grep nova 來查看運行的 nova 子服務

計算節點

計算節點 devstack-compute1 上只運行了 nova-compute 子服務

控制節點

控制節點 devstack-controller 上運行了若干 nova-* 子服務

RabbitMQ 和 MySQL 也是放在控制節點上的

可能細心的同窗已經發現咱們的控制節點上也運行了 nova-compute。 這實際上也就意味着 devstack-controller 既是一個控制節點，同時也是一個計算節點，也能夠在上面運行虛機。

這也向咱們展現了 OpenStack 這種分佈式架構部署上的靈活性： 能夠將全部服務都放在一臺物理機上，做爲一個 All-in-One 的測試環境； 也能夠將服務部署在多臺物理機上，得到更好的性能和高可用。

另外，也能夠用 nova service-list 查看 nova-* 子服務都分佈在哪些節點上

從虛機建立流程看 nova-* 子服務如何協同工做

從學習 Nova 的角度看，虛機建立是一個很是好的場景，涉及的 nova-* 子服務很全，下面是流程圖。

1. 客戶（能夠是 OpenStack 最終用戶，也能夠是其餘程序）向 API（nova-api）發送請求：「幫我建立一個虛機」

2. API 對請求作一些必要處理後，向 Messaging（RabbitMQ）發送了一條消息：「讓 Scheduler 建立一個虛機」

3. Scheduler（nova-scheduler）從 Messaging 獲取到 API 發給它的消息，而後執行調度算法，從若干計算節點中選出節點 A

4. Scheduler 向 Messaging 發送了一條消息：「在計算節點 A 上建立這個虛機」

5. 計算節點 A 的 Compute（nova-compute）從 Messaging 中獲取到 Scheduler 發給它的消息，而後在本節點的 Hypervisor 上啓動虛機。

6. 在虛機建立的過程當中，Compute 若是須要查詢或更新數據庫信息，會經過 Messaging 向 Conductor（nova-conductor）發送消息，Conductor 負責數據庫訪問。

上面是建立虛機最核心的幾個步驟，固然也省略了不少細節，咱們會在後面的章節詳細討論。 這幾個步驟向咱們展現了 nova-* 子服務之間的協做的方式，也體現了 OpenStack 整個系統的分佈式設計思想，掌握這種思想對咱們深刻理解 OpenStack 會很是有幫助。

下一節咱們將詳細介紹 OpenStack 組件的通用設計思路。