O02五、OpenStack 通用設計思路

參考 http://www.javashuo.com/article/p-ydivjnaa-bx.html

 

API 前端服務

 

每一個OpenStack組件可能包含若干子服務，其中一定有一個API服務負責接收客戶請求。

 

以Nova爲例，nova-api 做爲Nova 組件對外的惟一窗口，向客戶暴露Nova 可以提供的功能。當客戶須要執行虛機相關的操做，能且只能向 nova-api 發送REST 請求。這裏的客戶包括終端用戶、命令行、和OpenStack其餘組件。

 

設計API前端服務的好處在於：

 

    一、對外提供統一接口，隱藏實現細節

    二、API提供 REST 標準調用服務，便於與第三方系統集成

    三、能夠經過運行多個API服務實例輕鬆實現API的高可用，好比運行多個 nova-api 進程

 

Scheduler 調度服務

 

對於某項操做，若是有多個實體都可以完成任務，那麼一般會有一個 Scheduler 負責從這些實體中挑選出一個最合適的來執行操做。

 

在前面的例子中，Nova有多個計算節點。當須要建立虛機的時候，nova-scheduler 會根據計算節點當時的資源使用狀況選擇一個最合適的計算節點來運行虛機。

 

調度服務比如是開發團隊中的項目經理，當接到新的開發任務後，項目經理會評估任務的難度，考察團隊成員目前的工做負荷和技能水平，而後將任務分配給最合適的開發人員。除了Nova，塊存儲組件Cinder 也有Scheduler 子服務，後面咱們會詳細討論。

 

Worker 工做服務

 

調度服務只管分配任務，真正執行任務的是 Worker 工做服務。在Nova中，這個Worker 就是 nova-compute了。將Scheduler 和 Worker 從職能上進行劃分使得OpenStack很是容易擴展：

 

    一、當計算資源不夠了沒法建立虛機時，能夠增長計算節點（增長Worker）

    二、當客戶的請求量太大調度不過來時，能夠增長Scheduler

 

Driver 服務

 

OpenStack 做爲開放的 infrastructure as a Service 雲操做系統，支持業界各類優秀的技術。這些技術多是開源免費的。也多是商業收費的。這種開放的架構使得OpenStack 可以在技術上保持先進性，具備很強的競爭力，同時又不會形成廠商鎖定（Lock-in）

 

那OpenStack的這種開放性體如今哪裏呢？

 

一個重要的方面就是採用基於Driver的框架。已Nova 爲例，OpenStack 的計算節點支持多種Hypervisor。包括 KVM、Hyper-V、VMware 、Xen、Docker 、LXC 等。Nova-compute 爲這些Hypervisor 定義了統一的接口，Hypervisor 只須要實現這些接口，就能夠以driver的形式即插即用到 OpenStack中。下面是 nova  driver 的架構示意圖。

 

 

在nova-Compute 的配置文件中，由 compute_driver 配置想指定該計算節點使用哪一種 Hypervisor 的driver

 

stack@DevStack-Controller:~$ cat /etc/nova/nova.conf  | grep compute_driver

compute_driver = libvirt.LibvirtDriver

 

在咱們的環境中由於是KVM，因此配置的是 Libvirt 的 driver

 

不知你們是否記得咱們在學習 Glance 的時候，OpenStack 支持多種backend 來存放image。能夠是本地文件系統、Cinder、Ceph、Swift等。其實這也是一個driver架構。只要符合 Glance 定義的規範，新的存儲方式能夠很方便的加入到backend支持列表中。在後面 Cinder 和 Neutron 中咱們還會看到 driver 框架的應用。

 

Messaging 服務

 

在前面建立虛機的流程示意圖中，咱們看到 nova-*  子服務之間的調用嚴重依賴 Messaging 。Messaging 是nova-* 子服務交互的中樞。

 

 

之前沒接觸過度布式系統的同窗可能會不太理解爲何不讓API 直接調用Scheduler，或是讓Scheduler 直接調用Compute，而是非要經過 Messaging 進行中轉。這裏作一些解釋。程序之間的調用一般分兩種：同步調用和異步調用。

 

同步調用：

 

API直接調用 Scheduler 的接口是同步調用。其特色是API發出請求後須要一直等待，直到Scheduler完成對Compute的調度，將結果返回給API後API才能繼續作後面的工做。

 

異步調用：

 

API經過Messaging 間接調用 Scheduler 就是異步調用。其特色是API 發出請求後不須要等待，直接返回，繼續作後面的工做。Scheduler 從 Messaging接收到請求後執行調度操做，完成後將結果也經過Messaging 發送給API  。在OpenStack這類分佈式系統中，一般採用異步調用的方式，其好處是：

 

    一、解耦各子服務。子服務不須要知道其餘服務在哪裏運行，只須要發送消息給Messaging 就能完成調用

    二、提升性能異步調用使得調用者無需等待結果返回。這樣能夠繼續執行更多工做，提升系統總的吞吐量

    三、提升伸縮性，子服務能夠根據須要進行擴展，啓動更多的實例處理更多的請求，在提升可用性的同時也提升了整個系統的伸縮性。並且這種變化不會影響到其餘子服務，也就是說變化對別人是無感的。