雲原生存儲工具的選型和應用探討

隨着雲原生概念在業界的推廣，傳統應用部署的方式被容器化部署所取代。基於雲原生的容器化部署和運維，給開發和運維人員帶來 DevOps 快速部署和自動化運維等諸多便利的同時，對於基礎架構服務也提出了更高的要求，其中存算分離就是保障雲原生應用故障快速轉移、算力負載均衡的基石。因此雲原生存儲的概念也在雲原生的基礎上應運而生，接下來本文將會逐步梳理雲原生存儲的概念、工具的選型，最後會選擇一個代表性的雲原生存儲工具來演示如何使用。

作者：郭楊勇

單位：中國移動智慧家庭運營中心

1 雲原生存儲的概念

雲原生存儲的概念來源於雲原生應用，顧名思義：一個應用爲了滿足雲原生特性的要求，其對存儲所要求的特性是雲原生存儲的特性，而滿足這些特性的存儲方案，可以稱其爲傾向雲原生的存儲。

如上圖 1 所示，雲原生應用對於存儲的要求，可以概括爲三方面：

• 敏捷化需求： 可以靈活的將塊設備在不同節點進行快速的掛載切換；提供存儲服務的問題自動修復能力，減少人爲干預；提供更加靈活的卷大小配置能力。

• 監控需求： 提供更細粒度（目錄）的監控能力；提供更多維度的監控指標，如讀寫時延、讀寫頻率、IO 分佈等指標。

• 租戶隔離需求： 讓共享文件系統的不同租戶之間實現文件系統級別的隔離效果；容器編排層實現基於名詞空間、PSP 策略的編排隔離能力，保證不同租戶從應用部署側即無法訪問其他租戶的存儲卷服務。

滿足以上需求的存儲工具，又可以分爲以下幾類：

• 公有云存儲： 基於公有云的對象存儲、塊存儲、文件存儲、數據庫，在穩定性、性能、擴展性方面都能輕鬆滿足業務需求。

• 商業化私有云存儲： 很多雲存儲提供商都是在存儲技術上深耕多年，具有優異的技術能力和運維能力，目前都已提供了雲原生的支持。

• 自建雲存儲： 基於一些開源的架構，在自己的物理機系統搭建私有的雲存儲服務，如 Ceph、GlusterFS 等。

• 開源容器存儲： 設計之初既充分考慮了存儲與雲原生編排系統的融合，具有很好的容器數據卷接入能力，Longhorn[1]、OpenEBS[2]。

以上滿足雲原生基本要求的存儲方案中，公有云存儲、商業化的私有云存儲的部署位置和成本的限制，無法完全應用在私有云環境，而基於開源架構自建的雲存儲，可靠性不高，且維護成本高，還無法完全與雲原生集羣實現一體化運營。所以下文將重點介紹開源的容器化存儲方案。

2 開源容器存儲的技術路線

圖 2

如上圖 2 所示，目前比較主流的開源容器存儲解決方案，主要包括：

• 基於雲原生社區重新造輪子 -- 原生方案： 基於容器化和 k8s 的應用場景，單獨開發一套比較輕量的分佈式存儲系統。典型的開源項目有 Longhorn、OpenEBS。

• 移植傳統的分佈式存儲 -- 移植方案： 基於傳統的分佈式存儲框架，進行容器化和 k8s 的編排，移植到 k8s 集羣中部署。典型的開源項目有 rook+ceph[3]、heketi+glusterfs[4]、minio[5]。

筆者所在的項目對開源容器存儲方案進行初步調研後認爲 minio 僅可以提供對象存儲服務，無法進行磁盤掛載，而 heketi+gluster 的開源項目已停止維護，所以首先將 minio 和 heketi+gluster 的方案排除。

3 開源容器存儲的主要工具介紹

3.1 Longhorn 雲原生存儲

Longhorn 最早由 Rancher 社區創建和開發，完全使用容器和微服務實現分佈式塊存儲。Longhorn 爲每個塊設備卷創建一個專用的存儲控制器，並在跨多個節點上存儲的多個副本同步複製該卷。存儲控制器和副本本身使用 Kubernetes 進行編排。

Longhorn 設計有兩層：數據平面 (data plane) 和控制平面(control plane)。Longhorn Engine 是存儲控制器對應數據平面，Longhorn Manager 對應控制平面。

• 控制引擎： 負責在 Kubernetes 集羣中創建和管理卷，並處理來自 UI 或 Kubernetes 卷插件的 API 調用。當 Longhorn Manager 被要求創建一個卷時，它會在該卷所連接的節點上創建一個 Longhorn Engine 實例。

• 數據引擎： 始終在與使用 Longhorn volume 的 Pod 相同的節點中運行。它跨存儲在多個節點上的多個副本同步複製卷。引擎 (Engine) 和副本 (replicas) 使用 Kubernetes 進行編排。

3.2 OpenEBS 雲原生存儲

OpenEBS 是 kubernetes 下與容器原生和容器附加存儲類型相關的開源項目之一，由 CloudByte 最早研發，並開源到 CNCF。基於 GO 語言進行開發，通過爲每個工作負載指定專用的存儲控制器，OpenEBS 遵循容器附加存儲或 CAS 的原則，允許操作員和管理員根據工作量動態調整卷的大小。

OpenEbs 分爲了控制面板和數據面板，其中：

• 控制面板： 包含了節點組件和集羣組件兩類 pod，其中 NDM(Node Disk Manager) 負責識別和管理每個節點上的磁盤；m-apiserver 暴露了存儲 REST API，並承擔了大部分的卷策略處理和管理。Provisioner 實現了 K8s 中 PVC 同 m-apiserver 的交互。NDM Operator 用戶控制 NDM 的初始化和生命週期管理。

• 數據面板： 分爲 cStor、Jiva、LocalPV 三種不同的 pod 與業務 pod 伴生存在。其中 Jiva 實際上就是使用的 Longhorn 引擎；而 LocalPV 就是 K8S 的本地 PV 模式，副本無法複製，故障無法轉移。

3.3 Rook+Ceph 容器化存儲

Rook 本身並不是一個分佈式存儲系統，而是利用 Kubernetes 平臺的強大功能，通過 Kubernetes Operator 爲每個存儲提供商提供服務。它將分佈式存儲系統轉變爲自我管理、自我擴展、自我修復的存儲服務。

Ceph 是聖克魯茲加利福尼亞大學的 sage weil 在 2003 年開發的，也是他的博士項目的一部分。初始原型是大約 4 萬行 c++ 代碼的 ceph 文件系統，2006 年遵循 LGPL 協議進行開源。

Ceph 架構主要有兩個核心模塊：監視器 (MON)、存儲器 (OSD)。此外還包括了一個基於 aws s3 的對象存儲網關 RadosGW；塊存儲、文件存儲相關的系統插件。其中：

• 監視器： 用於保存並更新集羣的結構、狀態信息，負責控制塊存儲和文件存儲的元數據信息。默認爲三個副本的選舉集羣。

• 存儲器： 用於存儲數據、數據自動校驗、數據容量自平衡；定時向監視器上報心跳，並對外提供數據的寫入和讀取 API。

Rook+Ceph 的組合解決方案是目前比較成熟的一套 Ceph 容器化部署移植方案，Rook 在其中主要完成 Ceph 集羣的初始化和狀態掛你、Kubernetes 對接的工作，真正的存儲業務邏輯都還是由容器化運行的 Ceph 集羣來實現。

3.4 開源容器化存儲項目特性的橫向比較

在筆者的測試環境依次對以上三個開源容器化存儲工具的功能和性能測試情況來看，三者的比較情況如下表 1 所示：

筆者所在項目綜合考慮了三者的優缺點、磁盤性能損耗和維護複雜度後，認爲 Longhorn 不支持條帶化的缺點可以通過掛載 Linux 卷組的方式予以規避，所以最終選擇使用 Longhorn。

4 Longhorn 的安裝和使用

爲每個節點安裝 ISCSI（小型計算機網絡接口）守護進程，如果集羣節點都已安裝，則無需此操作。

yum install -y iscsi-initiator-utils && systemctl enable --now iscsid.

如下圖 6，將 Longhorn 倉庫添加到 rancher 應用商店當中，這樣就可以在 rancher 的應用商店列表中看到 Longhorn 應用了。

如下圖 7 和 8，在 rancher 的應用商店列表中選擇 Longhorn 並安裝，就可以在這裏預設 longhorn 的域名、默認路徑、默認副本數等。

所有組件安裝完成後，通過上一步設定的 Longhorn 域名，就可以打開主頁的 UI，進行存儲路徑、自動備份、劵分配和掛載等操作了。

用戶除了通過上圖 9 的頁面去創建 PVC 之外，也可以直接在 rancher 頁面的 PVC 創建頁面中選擇使用 Longhorn 作爲 StorageClass，如下圖 10 所示。

5 總結

到這裏，就完成了雲原生存儲工具選型和應用的初步探討，雖然筆者的項目出於易維護性和成本的考慮最終選擇了 Longhorn，但 Rook+Ceph 和 OpenEBS 兩套方案，在特定條件下，還是具備其使用價值的。而有條件的項目，使用共有云或購買商業的私有云存儲也都是不錯的選項。

參考文獻

[1]Longhorn 官方文檔  https://longhorn.io/docs

[2]OpenEBS 官方文檔  https://openebs.io/docs

[3]Rook 官方文檔  https://rook.io/docs/rook/latest/Getting-Started/quickstart/

[4]Heketi 使用文檔  https://github.com/heketi/heketi/blob/master/docs/admin/readme.md

[5]Minio 官網  http://www.minio.org.cn/

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/QoVlOe01hGWSYEKS8wfsKw