Nova 元件如何協同工作 - 每天5分鐘玩轉 OpenStack（24）Nova 實體部署方案從虛機建立流程看 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-* 子服務很全，下面是流程圖。

客戶（可以是 OpenStack 最終使用者，也可以是其他程式）向 API（nova-api）發送請求：“幫我建立一個虛機”

API 對請求做一些必要處理後，向 Messaging（RabbitMQ）發送了一條消息：“讓 Scheduler 建立一個虛機”

Scheduler（nova-scheduler）從 Messaging 擷取到 API 發給它的消息，然後執行排程算法，從若幹計算節點中選出節點 A

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

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

在虛機建立的過程中，Compute 如果需要查詢或更新資料庫資訊，會通過 Messaging 向 Conductor（nova-conductor）發送消息，Conductor 負責資料庫通路。

上面是建立虛機最核心的幾個步驟，當然也省略了很多細節，我們會在後面的章節詳細讨論。 這幾個步驟向我們展示了 nova-* 子服務之間的協作的方式，也展現了 OpenStack 整個系統的分布式設計思想，掌握這種思想對我們深入了解 OpenStack 會非常有幫助。

下一節我們将詳細介紹 OpenStack 元件的通用設計思路。

本文轉自CloudMan6 51CTO部落格，原文連結:http://blog.51cto.com/cloudman/1766515