O02四、Nova組件如何協同工做

參考 http://www.javashuo.com/article/p-bhipyunz-gd.html

 

Nova 物理部署方案

 

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

 

對於Nova，這些服務會部署在兩類節點上：計算節點和控制節點

 

計算節點上安裝了Hypervisor，上面運行虛擬機，由此可知：

 

    一、只有nova-compute須要放在計算節點上

    二、其餘子服務則是放在控制節點上的

 

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

 

root@DevStack-Controller:~# ps -e | grep nova    #    控制節點

1818 pts/14   00:20:24 nova-conductor

2717 pts/14   00:09:12 nova-conductor

2718 pts/14   00:09:20 nova-conductor

2801 pts/15   00:03:29 nova-scheduler

3294 pts/16   00:00:57 nova-novncproxy

3955 pts/17   00:03:29 nova-consoleaut

4613 pts/18   00:10:13 nova-compute

28102 pts/8    00:20:41 nova-api

28282 pts/8    00:01:24 nova-api

28283 pts/8    00:01:03 nova-api

28285 pts/8    00:00:09 nova-api

28286 pts/8    00:00:09 nova-api

 

root@DevStack-Compute:~# ps -e | grep nova    #    計算節點

5368 pts/4    00:07:05 nova-compute

 

RabbitMQ 和 MySQL 也是放在控制節點上的。可能信息的同窗已經發現咱們的控制節點上運行了 nova-compute 。這實際上也就意味着DevStack-Controller既是一個計算節點，也是一個控制節點，也能夠在上面運行虛機。

 

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

 

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

 

stack@DevStack-Controller:~$ nova service-list

+----+------------------+---------------------+----------+---------+-------+----------------------------+-----------------+

| Id | Binary           | Host                | Zone     | Status  | State | Updated_at                 | Disabled Reason |

+----+------------------+---------------------+----------+---------+-------+----------------------------+-----------------+

| 3  | nova-conductor   | DevStack-Controller | internal | enabled | up    | 2019-05-23T02:01:25.000000 | -               |

| 4  | nova-scheduler   | DevStack-Controller | internal | enabled | up    | 2019-05-23T02:01:35.000000 | -               |

| 5  | nova-consoleauth | DevStack-Controller | internal | enabled | up    | 2019-05-23T02:01:26.000000 | -               |

| 6  | nova-compute     | DevStack-Controller | nova     | enabled | up    | 2019-05-23T02:01:29.000000 | -               |

| 7  | nova-compute     | DevStack-Compute    | nova     | enabled | up    | 2019-05-23T02:01:30.000000 | -               |

+----+------------------+---------------------+----------+---------+-------+----------------------------+-----------------+

 

從虛機建立流程看 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會很是有幫助。