基礎不牢,地動山搖。無論是何種體系架構,底層儲存的選擇都是一個值得探討的話題。儲存承載著業務的資料,其效能直接影響到業務應用的實際表現。也正因為儲存和業務的資料關聯緊密,其可靠性也必須得到關注,儲存的失效一旦導致業務資料丟失,那將會是一場災難級別的事故。
最近幾年,我的工作內容始終圍繞著客戶 Kubernetes 叢集的建設。如何為客戶的 Kubernetes 叢集選擇一款穩定可靠、效能表現優異的儲存解決方案,這樣的問題一直困擾著我。
儲存卷可以在 Pod 漂移到其他節點後重新掛載這一最基礎的功能性要求,讓我一開始就把目光放在了共用檔案系統這一儲存型別上。最開始選擇了 Nfs,到後來又投入了 Glusterfs 的懷抱,直到最近開始努力探索其他更好的雲原生儲存解決方案,這一路走來也讓我對各種儲存有了一定的瞭解。它們各自有著自己的特點:
Nfs:Nfs 是一種老牌的基於網路共用檔案的儲存解決方案。它的優點是簡單高效。它的缺點也比較明顯,伺服器端單點故障,資料沒有複製機制。在某些對可靠性要求不高的場景下,Nfs依然是不二之選。
Glusterfs:這是一種開源的分散式共用儲存解決方案。相對於 Nfs 而言,Gfs 通過多副本複製集提升了資料的可靠性,新增 Brick 的機制也讓儲存叢集的擴充套件不再受限於一臺伺服器。Gfs 一度是我部在生產環境下的首選,通過將複製因子設定為 3 ,保障了資料的可靠性的同時,又能夠避免分散式系統下的資料腦裂的問題。伴隨 Gfs 一起前進了很久之後,我們也發現了它在密集小檔案讀寫場景下的效能短板。而且單一的共用檔案系統型別的儲存,也漸漸不再滿足我們的使用場景需要。
我們在尋找更合適的儲存這一道路上一直沒有停止探索。這兩年雲原生概念炙手可熱,社群中不斷湧現出來各種雲原生領域專案,其中也不乏儲存相關的專案。最開始,我們將目光放在 Ceph 身上,它最吸引我們的是可以提供高效能的塊裝置型別儲存。然而被其複雜的部署方式、較高的運維門檻一度勸退。而 CNCF 畢業專案 Rook 的出現,終於剷平了接觸 Ceph 的最後一道門檻。
Rook 專案提供了一種雲原生儲存編排工具,為各種型別的儲存提供平臺級、框架級的支援,統管了儲存軟體的安裝、運維。Rook 在 2018 年釋出的 0.9 版本中,正式將 Ceph Operator 作為穩定支援的特性,迄今已經數年。使用 Rook 部署和管理生產級別的 Ceph 叢集還是非常穩健的。
相對於 Gfs ,Rook-Ceph 提供了效能極高的塊裝置型別儲存,這相當於為 Pod 掛載了一塊硬碟,應對密集小檔案讀寫場景並非難事。Rook-Ceph 除了能夠提供塊裝置型別儲存之外,也可以基於 Cephfs 提供分散式共用儲存,以及基於 S3 協定的物件儲存。多種儲存型別統一管理,並提供了視覺化管理介面,對於運維人員非常友好。
作為 CNCF 畢業專案,Rook-Ceph 對雲原生場景的支援毋庸置疑。部署完成的 Rook-Ceph 叢集提供了 CSI 外掛,以 StorageClass 的形式面向 Kubernetes 供應資料卷,對於相容 CSI 規範的各類雲原生 PaaS 平臺也非常友好。
在 Rainbond V5.7.0-release 版本中,新增了對 Kubernetes CSI 容器儲存介面的支援。
Rainbond 在安裝部署階段,就會參照 Cephfs 來部署預設為所有服務元件提供的共用儲存。而對於有狀態的服務元件而言,新增持久化儲存時,可以選擇當前叢集中所有可用的 StorageClass,通過選擇 rook-ceph-block
即可申請塊裝置進行掛載,全程圖形化介面操作,十分方便。
如何部署 Rook-Ceph 並對接到 Rainbond 之中,請參考檔案 Rook-Ceph 對接方案 。
這個章節,我會以直觀的方式,描述在 Rainbond 對接了 Rook-Ceph 儲存之後的各種使用體驗。
Rainbond 在安裝階段通過指定引數來對接 Cephfs 作為叢集共用儲存。在使用 Helm 安裝 Rainbond 的過程中,關鍵的對接引數如下:
--set Cluster.RWX.enable=true \
--set Cluster.RWX.config.storageClassName=rook-cephfs \
--set Cluster.RWO.enable=true \
--set Cluster.RWO.storageClassName=rook-ceph-block
對於任意一個部署在 Rainbond 平臺上的服務元件而言,僅需要在掛載持久化儲存時,選擇預設的共用儲存,即相當於將資料持久化的儲存進了 Cephfs 檔案系統中。
叢集中使用元件英文名可以過濾查詢所生成的 PV 資源:
$ kubectl get pv | grep mysqlcephfs
pvc-faa3e796-44cd-4aa0-b9c9-62fa0fbc8417 500Gi RWX Retain Bound guox-system/manual7-volume-mysqlcephfs-0 rainbondsssc 2m7s
除了預設的共用儲存之外,其他所有叢集中的 StorageClass 都面向有狀態服務開放。手動選擇 rook-ceph-block
即可建立塊裝置型別儲存,並掛載給 Pod 使用。當服務元件擁有多個範例時,每個 Pod 都會生成一個塊裝置掛載使用。
查詢所生成的 PV 資源:
$ kubectl get pv | grep mysql6-0
pvc-5172cb7a-cf5b-4770-afff-153c981ab09b 50Gi RWO Delete Bound guox-system/manual6-app-a710316d-mysql6-0 rook-ceph-block 5h15m
Rook-Ceph 預設部署時安裝了視覺化操作介面 Ceph-dashboard。在這裡可以監控整個儲存叢集,也可以基於圖形化介面操作更改各種儲存型別的設定。
修改 Ceph 叢集設定,禁用 dashboard 內建 ssl:
$ kubectl -n rook-ceph edit cephcluster -n rook-ceph rook-ceph
# 修改 ssl 為 false
spec:
dashboard:
enabled: true
ssl: false
# 重啟 operator 使設定生效
$ kubectl delete po -l app=rook-ceph-operator -n rook-ceph
$ kubectl -n rook-ceph get service rook-ceph-mgr-dashboard
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
rook-ceph-mgr-dashboard ClusterIP 10.43.210.36 <none> 7000/TCP 118m
獲取svc,在平臺上使用第三方元件的形式代理,開啟對外服務地址後,即可經過閘道器存取 dashboard。
存取到儀表板後,預設使用者為admin
,在伺服器執行以下命令獲取密碼:
kubectl -n rook-ceph get secret rook-ceph-dashboard-password -o jsonpath="{['data']['password']}" | base64 --decode && echo
請參考檔案 Rook-Ceph 部署對接 ,可以在 Rook-Ceph 中部署物件儲存。只需要將物件儲存的 service ClusterIP 通過第三方服務代理,我們就可以得到一個可以被同個控制檯納管的多個叢集同時存取的物件儲存地址。Rainbond 可以基於這一特性,實現雲端備份遷移功能。
獲取物件儲存的 svc 地址:
$ kubectl -n rook-ceph get service rook-ceph-rgw-my-store
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
rook-ceph-rgw-my-store ClusterIP 10.43.12.100 <none> 80/TCP 3h40m
通過在企業設定中填寫好事先在 Ceph-dashboard 中建立的物件儲存 bucket、access-key、secret-key,即可對接好物件儲存。
我們利用 sysbench 工具,對使用了不同型別儲存的 Mysql 進行了效能測試,除資料目錄掛載了不同型別的儲存,其他實驗條件均一致。參與測試的儲存型別包括 Glusterfs、Cephfs、Ceph-RBD 三種。
採集的資料為 sysbench 測試返回的每秒事務數(TPS)以及每秒請求數(QPS):
儲存型別 | Mysql 記憶體 | QPS | TPS |
---|---|---|---|
Glusterfs | 1G | 4600.22 | 230.01 |
Cephfs | 1G | 18095.08 | 904.74 |
Ceph-RBD | 1G | 24852.58 | 1242.62 |
測試結果顯而易見,Ceph 塊裝置效能最高,Cephfs 相對 Glusterfs 也有較明顯的效能優勢。
適配 Kubernetes CSI 容器儲存介面是 Rainbond v5.7.0-release 版本的一大特性,這個特性讓我們可以輕鬆對接 Rook-Ceph 這一優秀的儲存解決方案。通過對 Rook-Ceph 的使用體驗的描述以及最後的效能測試對比,不得不說,Rook-Ceph 即將成為我們在雲原生儲存領域探索的一個主攻方向。