掌握 Cinder 的設計思想 - 天天5分鐘玩轉 OpenStack（46）

上一節介紹了 Cinder 的架構，這節討論 Cinder 個組件如何協同工做及其設計思想。

從 volume 建立流程看 cinder-* 子服務如何協同工做

對於 Cinder 學習來講，Volume 建立是一個很是好的場景，涉及各個 cinder-* 子服務，下面是流程圖。

1. 客戶（能夠是 OpenStack 最終用戶，也能夠是其餘程序）向 API（cinder-api）發送請求：「幫我建立一個 volume」

2. API 對請求作一些必要處理後，向 Messaging（RabbitMQ）發送了一條消息：「讓 Scheduler 建立一個 volume」

3. Scheduler（cinder-scheduler）從 Messaging 獲取到 API 發給它的消息，而後執行調度算法，從若干計存儲點中選出節點 A

4. Scheduler 向 Messaging 發送了一條消息：「讓存儲節點 A 建立這個 volume」

5. 存儲節點 A 的 Volume（cinder-volume）從 Messaging 中獲取到 Scheduler 發給它的消息，而後經過 driver 在 volume provider 上建立 volume。

上面是建立虛機最核心的幾個步驟，固然省略了不少細節，咱們會在後面的章節詳細討論。

Cinder 的設計思想

Cinder 延續了 Nova 的以及其餘組件的設計思想。

API 前端服務

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

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

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

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

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

Scheduler 調度服務

Cinder 能夠有多個存儲節點，當須要建立 volume 時，cinder-scheduler 會根據存儲節點的屬性和資源使用狀況選擇一個最合適的節點來建立 volume。

調度服務就比如是一個開發團隊中的項目經理，當接到新的開發任務時，項目經理會根據任務的難度，每一個團隊成員目前的工做負荷和技能水平，將任務分配給最合適的開發人員。

Worker 工做服務

調度服務只管分配任務，真正執行任務的是 Worker 工做服務。 在 Cinder 中，這個 Worker 就是 cinder-volume 了。這種 Scheduler 和 Worker 之間職能上的劃分使得 OpenStack 很是容易擴展：

當存儲資源不夠時能夠增長存儲節點（增長 Worker）。 當客戶的請求量太大調度不過來時，能夠增長 Scheduler。

Driver 框架

OpenStack 做爲開放的 Infrastracture as a Service 雲操做系統，支持業界各類優秀的技術，這些技術多是開源免費的，也多是商業收費的。 這種開放的架構使得 OpenStack 保持技術上的先進性，具備很強的競爭力，同時又不會形成廠商鎖定（Lock-in）。 那 OpenStack 的這種開放性體如今哪裏呢？一個重要的方面就是採用基於 Driver 的框架。

以 Cinder 爲例，存儲節點支持多種 volume provider，包括 LVM, NFS, Ceph, GlusterFS，以及 EMC, IBM 等商業存儲系統。 cinder-volume 爲這些 volume provider 定義了統一的 driver 接口，volume provider 只須要實現這些接口，就能夠 driver 的形式即插即用到 OpenStack 中。下面是 cinder driver 的架構示意圖：

在 cinder-volume 的配置文件 /etc/cinder/cinder.conf 中 volume_driver 配置項設置該存儲節點使用哪一種 volume provider 的 driver，下面的示例表示使用的是 LVM。

下一節咱們將詳細討論 Cinder 的每個組件。