上一節介紹了 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 的設計思想
Cinder 延續了 Nova 的以及其他組件的設計思想。
API 前端服務
cinder-api 作為 Cinder 組件對外的唯一窗口，向客戶暴露 Cinder 能夠提供的功能，當客戶需要執行 volume 相關的操作，能且只能向 cinder-api 發送 REST 請求。這里的客戶包括終端用戶、命令行和 OpenStack 其他組件。
設計 API 前端服務的好處在於：
-
對外提供統一接口，隱藏實現細節
-
API 提供 REST 標准調用服務，便於與第三方系統集成
-
可以通過運行多個 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 的每一個組件。
