本節我們將詳細講解 Cinder 的各個子服務。
cinder-api
cinder-api 是整個 Cinder 組件的門戶，所有 cinder 的請求都首先由 nova-api 處理。cinder-api 向外界暴露若干 HTTP REST API 接口。在 keystone 中我們可以查詢 cinder-api 的 endponits。
客戶端可以將請求發送到 endponits 指定的地址，向 cinder-api 請求操作。 當然，作為最終用戶的我們不會直接發送 Rest API 請求。OpenStack CLI，Dashboard 和其他需要跟 Cinder 交換的組件會使用這些 API。
cinder-api 對接收到的 HTTP API 請求會做如下處理：
-
檢查客戶端傳人的參數是否合法有效
-
調用 cinder 其他子服務的處理客戶端請求
-
將 cinder 其他子服務返回的結果序列號並返回給客戶端
cinder-api 接受哪些請求呢？簡單的說，只要是 Volume 生命周期相關的操作，cinder-api 都可以響應。大部分操作都可以在 Dashboard 上看到。
打開 Volume 管理界面
點擊下拉箭頭，列表中就是 cinder-api 可執行的操作。
cinder-scheduler
創建 Volume 時，cinder-scheduler 會基於容量、Volume Type 等條件選擇出最合適的存儲節點，然后讓其創建 Volume。
這個部分比較多，我們下一次單獨討論。
cinder-volume
cinder-volume 在存儲節點上運行，OpenStack 對 Volume 的操作，最后都是交給 cinder-volume 來完成的。 cinder-volume 自身並不管理真正的存儲設備，存儲設備是由 volume provider 管理的。cinder-volume 與 volume provider 一起實現 volume 生命周期的管理。
通過 Driver 架構支持多種 Volume Provider
接着的問題是：現在市面上有這么多塊存儲產品和方案（volume provider），cinder-volume 如何與它們配合呢？
這就是我們之前討論過的 Driver 架構。 cinder-volume 為這些 volume provider 定義了統一的接口，volume provider 只需要實現這些接口，就可以 Driver 的形式即插即用到 OpenStack 系統中。下面是 Cinder Driver 的架構示意圖：
我們可以在 /opt/stack/cinder/cinder/volume/drivers/ 目錄下查看到 OpenStack 源代碼中已經自帶了很多 volume provider 的 Driver：
存儲節點在配置文件 /etc/cinder/cinder.conf 中用 volume_driver 選項配置使用的driver：
這里 LVM 是我們使用的 volume provider。
定期向 OpenStack 報告計算節點的狀態
在前面 cinder-scheduler 會用到 CapacityFilter 和 CapacityWeigher，它們都是通過存儲節點的空閑容量來做篩選。那這里有個問題：Cinder 是如何得知每個存儲節點的空閑容量信息的呢？
答案就是：cinder-volume 會定期向 Cinder 報告。
從 cinder-volume 的日志 /opt/stack/logs/c-vol.log 可以發現每隔一段時間，cinder-volume 就會報告當前存儲節點的資源使用情況。
因為在我們的實驗環境中存儲節點使用的是 LVM，所以在上面的日志看到存儲節點通過“vgs”和”lvs”這兩個命令獲取 LVM 的容量使用信息。
實現 volume 生命周期管理
Cinder 對 volume 的生命周期的管理最終都是通過 cinder-volume 完成的，包括 volume 的 create、extend、attach、snapshot、delete 等，后面我們會詳細討論。
下一節我們將詳細討論 cinder-scheduler 如何篩選 cinder-volume。