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-* 子服務很全，下面是流程圖。
- 客戶（可以是 OpenStack 最終使用者，也可以是其他程式）向 API（nova-api）發送請求：“幫我建立一個虛機”
- API 對請求做一些必要處理後，向 Messaging（RabbitMQ）發送了一條消息：“讓 Scheduler 建立一個虛機”
- Scheduler（nova-scheduler）從 Messaging 擷取到 API 發給它的消息，然後執行排程算法，從若幹計算節點中選出節點 A
- Scheduler 向 Messaging 發送了一條消息：“在計算節點 A 上建立這個虛機”
- 計算節點 A 的 Compute（nova-compute）從 Messaging 中擷取到 Scheduler 發給它的消息，然後在本節點的 Hypervisor 上啟動虛機。