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 上啟動虛機。
-
在虛機創建的過程中，Compute 如果需要查詢或更新數據庫信息，會通過 Messaging 向 Conductor（nova-conductor）發送消息，Conductor 負責數據庫訪問。
上面是創建虛機最核心的幾個步驟，當然也省略了很多細節，我們會在后面的章節詳細討論。 這幾個步驟向我們展示了 nova-* 子服務之間的協作的方式，也體現了 OpenStack 整個系統的分布式設計思想，掌握這種思想對我們深入理解 OpenStack 會非常有幫助。
下一節我們將詳細介紹 OpenStack 組件的通用設計思路。
