Cinder 組件詳解 - 天天5分鐘玩轉 OpenStack（47）

本節咱們將詳細講解 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 請求會作以下處理：

1. 檢查客戶端傳人的參數是否合法有效

2. 調用 cinder 其餘子服務的處理客戶端請求

3. 將 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。