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

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

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

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

客戶（可以是 OpenStack 最終使用者，也可以是其他程式）向 API（cinder-api）發送請求：“幫我建立一個 volume”

API 對請求做一些必要處理後，向 Messaging（RabbitMQ）發送了一條消息：“讓 Scheduler 建立一個 volume”

Scheduler（cinder-scheduler）從 Messaging 擷取到 API 發給它的消息，然後執行排程算法，從若幹計存儲點中選出節點 A

Scheduler 向 Messaging 發送了一條消息：“讓存儲節點 A 建立這個 volume”

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

上面是建立虛機最核心的幾個步驟，當然省略了很多細節，我們會在後面的章節詳細讨論。

Cinder 延續了 Nova 的以及其他元件的設計思想。

cinder-api 作為 Cinder 元件對外的唯一視窗，向客戶暴露 Cinder 能夠提供的功能，當客戶需要執行 volume 相關的操作，能且隻能向 cinder-api 發送 REST 請求。這裡的客戶包括終端使用者、指令行和 OpenStack 其他元件。

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

對外提供統一接口，隐藏實作細節

API 提供 REST 标準調用服務，便于與第三方系統內建

可以通過運作多個 API 服務執行個體輕松實作 API 的高可用，比如運作多個 cinder-api 程序

Cinder 可以有多個存儲節點，當需要建立 volume 時，cinder-scheduler 會根據存儲節點的屬性和資源使用情況選擇一個最合适的節點來建立 volume。

排程服務就好比是一個開發團隊中的項目經理，當接到新的開發任務時，項目經理會根據任務的難度，每個團隊成員目前的工作負荷和技能水準，将任務配置設定給最合适的開發人員。

排程服務隻管配置設定任務，真正執行任務的是 Worker 工作服務。

在 Cinder 中，這個 Worker 就是 cinder-volume 了。這種 Scheduler 和 Worker 之間職能上的劃分使得 OpenStack 非常容易擴充：

當存儲資源不夠時可以增加存儲節點（增加 Worker）。

當客戶的請求量太大排程不過來時，可以增加 Scheduler。

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 的每一個元件。

本文轉自CloudMan6 51CTO部落格，原文連結:http://blog.51cto.com/cloudman/1788506