Cinder 元件詳解 - 每天5分鐘玩轉 OpenStack（47）cinder-apicinder-schedulercinder-volume

本節我們将詳細講解 Cinder 的各個子服務。

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 可執行的操作。

建立 Volume 時，cinder-scheduler 會基于容量、Volume Type 等條件選擇出最合适的存儲節點，然後讓其建立 Volume。

這個部分比較多，我們下一次單獨讨論。

cinder-volume 在存儲節點上運作，OpenStack 對 Volume 的操作，最後都是交給 cinder-volume 來完成的。

cinder-volume 自身并不管理真正的儲存設備，儲存設備是由 volume provider 管理的。cinder-volume 與 volume provider 一起實作 volume 生命周期的管理。

接着的問題是：現在市面上有這麼多塊存儲産品和方案（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。

在前面 cinder-scheduler 會用到 CapacityFilter 和 CapacityWeigher，它們都是通過存儲節點的空閑容量來做篩選。那這裡有個問題：Cinder 是如何得知每個存儲節點的空閑容量資訊的呢？

答案就是：cinder-volume 會定期向 Cinder 報告。

從 cinder-volume 的日志 /opt/stack/logs/c-vol.log 可以發現每隔一段時間，cinder-volume 就會報告目前存儲節點的資源使用情況。

因為在我們的實驗環境中存儲節點使用的是 LVM，是以在上面的日志看到存儲節點通過“vgs”和”lvs”這兩個指令擷取 LVM 的容量使用資訊。

Cinder 對 volume 的生命周期的管理最終都是通過 cinder-volume 完成的，包括 volume 的 create、extend、attach、snapshot、delete 等，後面我們會詳細讨論。

下一節我們将詳細讨論 cinder-scheduler 如何篩選 cinder-volume。

本文轉自CloudMan6 51CTO部落格，原文連結:

http://blog.51cto.com/cloudman/1789380