一. 云原生存儲的概念

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

圖1

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

• 敏捷化需求：可以靈活的將塊設備在不同節點進行快速的掛載切換；提供存儲服務的問題自動修復能力，減少人為干預；提供更加靈活的卷大小配置能力。
• 監控需求：提供更細粒度（目錄）的監控能力；提供更多維度的監控指標，如讀寫時延、讀寫頻率、IO分布等指標。
• 租戶隔離需求：讓共享文件系統的不同租戶之間實現文件系統級別的隔離效果；容器編排層實現基于名詞空間、PSP策略的編排隔離能力，保證不同租戶從應用部署側即無法訪問其他租戶的存儲卷服務。

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

• 公有云存儲：基于公有云的對象存儲、塊存儲、文件存儲、數據庫，在穩定性、性能、擴展性方面都能輕松滿足業務需求。
• 商業化私有云存儲：很多云存儲提供商都是在存儲技術上深耕多年，具有優異的技術能力和運維能力，目前都已提供了云原生的支持。
• 自建云存儲：基于一些開源的架構，在自己的物理機系統搭建私有的云存儲服務，如Ceph、GlusterFS等。
• 開源容器存儲：設計之初既充分考慮了存儲與云原生編排系統的融合，具有很好的容器數據卷接入能力，Longhorn^[1]、OpenEBS^[2]。

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

二. 開源容器存儲的技術路線

圖2

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

• 基于云原生社區重新造輪子--原生方案：基于容器化和k8s的應用場景，單獨開發一套比較輕量的分布式存儲系統。典型的開源項目有Longhorn、OpenEBS。
• 移植傳統的分布式存儲--移植方案：基于傳統的分布式存儲框架，進行容器化和k8s的編排，移植到k8s集群中部署。典型的開源項目有rook+ceph^[3]、heketi+glusterfs^[4]、minio^[5]。

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

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

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所示：

表1

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

四.Longhorn的安裝和使用

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

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

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

圖6

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

圖7

圖8

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

圖9

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

圖10

五.總結

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