一. 云原生存儲的概念

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

圖1

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

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

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

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

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

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

圖2

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

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

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

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

3.1 Longhorn云原生存儲

Longhorn最早由Rancher社區(qū)創(chuàng)建和開發(fā)，完全使用容器和微服務實現(xiàn)分布式塊存儲。Longhorn為每個塊設備卷創(chuàng)建一個專用的存儲控制器，并在跨多個節(jié)點上存儲的多個副本同步復制該卷。存儲控制器和副本本身使用Kubernetes進行編排。?

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

• 控制引擎：負責在Kubernetes集群中創(chuàng)建和管理卷，并處理來自UI或Kubernetes卷插件的API調(diào)用。當Longhorn Manager被要求創(chuàng)建一個卷時，它會在該卷所連接的節(jié)點上創(chuàng)建一個Longhorn Engine實例。
• 數(shù)據(jù)引擎：始終在與使用Longhorn volume的Pod相同的節(jié)點中運行。它跨存儲在多個節(jié)點上的多個副本同步復制卷。引擎(Engine)和副本(replicas)使用Kubernetes進行編排。

3.2 OpenEBS云原生存儲

OpenEBS是kubernetes下與容器原生和容器附加存儲類型相關的開源項目之一，由CloudByte最早研發(fā)，并開源到CNCF?；贕O語言進行開發(fā)，通過為每個工作負載指定專用的存儲控制器，OpenEBS遵循容器附加存儲或CAS的原則，允許操作員和管理員根據(jù)工作量動態(tài)調(diào)整卷的大小。?

OpenEbs分為了控制面板和數(shù)據(jù)面板，其中：

• 控制面板：包含了節(jié)點組件和集群組件兩類pod，其中NDM(Node Disk Manager)負責識別和管理每個節(jié)點上的磁盤；m-apiserver暴露了存儲REST API，并承擔了大部分的卷策略處理和管理。Provisioner實現(xiàn)了K8s中PVC同m-apiserver的交互。NDM Operator用戶控制NDM的初始化和生命周期管理。
• 數(shù)據(jù)面板：分為cStor、Jiva、LocalPV三種不同的pod與業(yè)務pod伴生存在。其中Jiva實際上就是使用的Longhorn引擎；而LocalPV就是K8S的本地PV模式，副本無法復制，故障無法轉移。

3.3 Rook+Ceph容器化存儲

Rook本身并不是一個分布式存儲系統(tǒng)，而是利用Kubernetes平臺的強大功能，通過Kubernetes Operator為每個存儲提供商提供服務。它將分布式存儲系統(tǒng)轉變?yōu)樽晕夜芾怼⒆晕覕U展、自我修復的存儲服務。

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

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

• 監(jiān)視器：用于保存并更新集群的結構、狀態(tài)信息，負責控制塊存儲和文件存儲的元數(shù)據(jù)信息。默認為三個副本的選舉集群。
• 存儲器：用于存儲數(shù)據(jù)、數(shù)據(jù)自動校驗、數(shù)據(jù)容量自平衡；定時向監(jiān)視器上報心跳，并對外提供數(shù)據(jù)的寫入和讀取API。

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

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

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

表1

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

四.Longhorn的安裝和使用

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

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

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

圖6

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

圖7

圖8

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

圖9

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

圖10

五.總結

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