作者| 郡寶 阿里雲技術專家

參與文末留言互動，即有機會獲得贈書福利！

導讀：存儲服務支撐了應用的狀態、數據的持久化，是計算機系統中的重要組成部分，也是所有應用得以運行的基礎，其重要性不言而喻。在存儲服務演進過程中，每一種業務類型、新技術方向都會對存儲的架構、性能、可用性、穩定性等提出新的要求，而在當今技術浪潮走到雲原生技術普及的時代，存儲服務需要哪些特性來支持應用呢？

從本文開始，我們將用一個系列文章對雲原生存儲進行方方面面的探析，該系列文章將從雲原生存儲服務的概念、特點、需求、原理、使用、案例等方面，和大家一起探討雲原生存儲技術新的機遇與挑戰，歡迎大家討論：

"There is no such thing as a 'stateless' architecture" - Jonas Boner

雲原生存儲系列文章(一)：雲原生應用的基石
雲原生存儲系列文章(二)：容器存儲與K8S存儲卷
雲原生存儲系列文章(三)：Kubernetes存儲架構
雲原生存儲系列文章(四)：K8S存儲實踐-Flexvolume
雲原生存儲系列文章(五)：K8S存儲實踐-CSI
雲原生存儲系列文章(六)：存儲卷高可用方案
雲原生存儲系列文章(七)：存儲調度與容量感知
雲原生存儲系列文章(八)：數據卷擴縮容能力
雲原生存儲系列文章(九)：雲原生存儲安全
雲原生存儲系列文章(十)：高性能計算場景的存儲優化

本節會介紹雲原生存儲的基本概念和常用的存儲方案。

雲原生存儲

1.概念

要理解雲原生存儲，我們首先要了解雲原生技術的概念，CNCF 對雲原生定義如下：

雲原生技術有利於各組織在公有云、私有云和混合雲等新型動態環境中，構建和運行可彈性擴展的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式 API。
這些技術能夠構建容錯性好、易於管理和便於觀察的鬆耦合系統。結合可靠的自動化手段，雲原生技術使工程師能夠輕鬆地對系統作出頻繁和可預測的重大變更。

簡言之：雲原生應用和傳統應用並沒有一個標準的劃分界限，其描述的是一種技術傾向，即越符合以下特徵的應用越雲原生：

• 應用容器化
• 服務網格化
• 聲明式 API
• 運行可彈性擴展
• 自動化的 DevOps
• 故障容忍和自愈
• 平臺無關，可移植的

雲原生應用是一簇應用特徵能力的集合，而實現了這些能力的應用在可用性、穩定性、擴展性、性能等核心能力都會有大幅的優化。優異的能力代表了技術的方向，雲原生應用正在引領各個應用領域實現雲原生化，同時也在深刻改變著應用服務的方方面面。存儲作為應用運行的基石，也在服務雲原生化過程中提出了更多的需求。

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

2.雲原生存儲特徵

1）可用性

存儲系統的可用性定義了在系統故障情況下訪問數據的能力，故障可以是由存儲介質、傳輸、控制器或系統中的其他組件造成的。可用性定義系統故障時如何繼續訪問數據，以及在部分節點不可用時如何將對數據的訪問重新路由到其他的可訪問節點。

可用性定義了故障的恢復時間目標（RTO），即故障發生與服務恢復之間的時長。可用性通常計算為應用運行時間中的可用時間的百分比（例如 99.9%），以及以時間單位度量的 MTTF（平均故障時間）或 MTTR（平均修復時間）來度量。

2）可擴展性

存儲的可擴展性主要衡量以下參數指標：

• 擴展可以訪問存儲系統的客戶端數量的能力，例如：一個 NAS 存儲卷同時支持多少客戶端掛載使用；
• 擴展單個接口的吞吐量和 IO 性能；
• 擴展存儲服務單實例的容量能力，例如：雲盤的擴容能力。

3）性能

衡量存儲的性能通常有兩個標準：

• 每秒支持的最大存儲操作數 - IOPS；
• 每秒支持的最大存儲讀寫量 - 吞吐量；

雲原生應用在大數據分析、AI 等場景得到廣泛應用，在這些重吞吐 / IO 場景中對存儲的需求也非常高，同時雲原生應用的快速擴容、極致伸縮等特性也會考驗存儲服務在短時間內迎接峰值流量的能力。

4）一致性

存儲服務的一致性是指在提交新數據或更新數據後，訪問這些新數據的能力；根據數據一致性的延遲效果，可以將存儲分為：“最終一致”和“強一致”存儲。

不同的服務對存儲一致性的敏感度是不一樣的，像數據庫這類對底層數據準確性和時效性要求非常高的應用，對存儲的要求是具有強一致性的能力。

5）持久性

多個因素應用數據的持久性：

• 系統冗餘等級；
• 存儲介質的耐久性（如：SSD 或 HDD）；
• 檢測數據損壞的能力，以及使用數據保護功能重建或恢復損壞數據的能力。

3.數據訪問接口

在雲原生應用系統中，應用訪問存儲服務有多種方式。從訪問接口類型上可以分為：數據卷方式、API 方式。

數據卷：將存儲服務映射為塊或文件系統方式共應用直接訪問，使用方式類似於應用在操作系統中直接讀寫本地目錄文件。例如：可以將塊存儲、文件存儲掛載到本地，應用可以像訪問本地文件一樣對數據捲進行訪問；
API：有些存儲類型並不能使用掛載數據卷的方式進行訪問，而需要通過調用 API 的方式進行。例如：數據庫存儲、KV 存儲、對象存儲，都是通過 API 的方式進行數據的讀寫。

需要說明的是對象存儲類型，其標準使用方式是通過 Restful API 對外提供了文件的讀寫能力，但也可以使用用戶態文件系統的方式進行存儲掛載，使用方式模擬了塊、文件存儲數據卷掛載的方式。

下面表格列舉了各種存儲接口的優缺點：

4.雲原生存儲分層

1）編排和操作系統層

這一層定義了存儲數據的對外訪問接口，即應用訪問數據時存儲所表現的形式。同上節所述，可以分為數據卷方式和 API 訪問方式。這一層是容器服務存儲編排團隊關注的重點，雲原生存儲對敏捷性、可操作性、擴展性等方面的需求都在這一層集成、實現。

2）存儲拓撲層

這一層定義了存儲系統的拓撲結構和架構設計，定義了系統不同部分是如何相互關聯和連接的（如存儲設備、計算節點和數據）。拓撲結構在構建時影響存儲系統的許多屬性，因此必須加以考慮。

存儲拓撲可以是集中式的、分佈式的、或超融合的。

3）數據保護層

定義如何通過冗餘的方式對數據進行保護。在存儲系統出現故障時，如何通過數據冗餘對數據進行保護、恢復非常重要。通常有以下幾種數據保護方案：

• RAID（獨立磁盤冗餘陣列）：用於在多個磁盤之間的分發數據技術，同時考慮到冗餘；
• 擦除編碼：數據被分成多個片段，這些片段被編碼，並與多個冗餘集合一起存儲，保證數據可恢復；
• 副本：將數據分佈在多個服務器上，實現數據集的多個完整副本。

4）數據服務

數據服務補充了核心存儲功能以外的存儲能力，例如可以提供存儲快照、數據恢復、數據加密等服務。
數據服務所提供的補充能力也正是雲原生存儲所需要的，雲原生存儲正是通過集成豐富數據服務來實現其敏捷、穩定、可擴展等能力。

5）物理層

這一層定義了存儲數據的實際物理硬件。物理硬件的選擇影響系統的整體性能和存儲數據的持續性。

5.存儲編排

雲原生意味著容器化，而容器服務場景中通常需要某種管理系統或者應用編排系統。這些編排系統與存儲系統的交互可以實現工作負載與存儲數據的關聯。

如上圖所示：

• 負載：表示應用實例，會消費底層存儲資源；
• 編排系統：類似於 K8s 一樣的容器編排系統，負責應用的管理和調度；
• 控制平面接口：指編排系統調度、運維底層存儲資源的標準接口，例如 K8s 裡面的 Flexvolume，已經容器存儲通用的 CSI 接口；
• 工具集：指控制平面接口運維存儲資源時所依賴的三方工具、框架；
• 存儲系統：分為控制平臺數據數據平面。控制檯平面對外暴露接口，提供存儲資源的接入、接出能力。數據平面提供數據存儲服務。

當應用負載定義了存儲資源需求時，編排系統會為應用負載去準備這些存儲資源。編排系統通過調用控制平面接口，進而實現對存儲系統控制平面的調用，這樣就實現了應用負載對存儲服務的接入、接出操作。當實現了存儲系統接入後，應用負載可以直接訪問存儲系統的數據平面，即可以直接訪問數據。

常見的雲原生存儲方案

1.公有云存儲

每個公有云服務提供商都會提供各種雲資源，其中也包含了各種雲存儲服務。以阿里云為例，其幾乎提供了能夠滿足所有業務需要的存儲類型，包括：對象存儲、塊存儲、文件存儲、數據庫等等。公有云存儲的優勢是規模效應，足夠大的體量實現了巨大研發、運維投入的同時，提供低廉的價格優勢。而且公有云存儲在穩定性、性能、擴展性方面都能輕鬆滿足您的業務需求。

隨著雲原生技術的發展，各個公有云廠商都開始對其雲服務進行雲原生化改造或適配，提供更加敏捷、高效的服務來適應雲原生應用的需求。阿里雲存儲服務也在雲原生應用適配做了很多優化，阿里雲容器服務團隊實現的 CSI 存儲驅動無縫的銜接了雲原生應用和存儲服務之間的數據接口。實現了用戶使用存儲資源時對底層存儲無感知，而專注於自己的業務開發。

優點如下所示：

• 高可靠性：多數雲廠商都可以提供服務穩定性、數據可考慮下都非常優異的服務，例如：阿里雲ebs提供了9個9的可靠性服務，為您的數據安全提供了強有力的基礎保障能力；
• 高性能：公有云對不同的服務提供了不同等級的存儲性能適配，幾乎可以滿足所有應用類型對存儲性能的需求。阿里雲 EBS 可以提供百萬級別的 IOPS 能力，接近本地盤的訪問性能。NAS 服務最大提供每秒數十 G 的吞吐能力，在數據共享的應用場景滿足您的高性能需求。而 CPFS 高性能併發文件系統最高可以提供近 TB 級別的吞吐能力，更是可以滿足一些極端高性能計算對存儲的需求；
• 擴展性好：公有云存儲服務一般都提供了容量擴容能力，讓您在應用對存儲的需求增加的時候可以動態的實現容量伸縮，且實現應用的無感知；
• 安全性高：不同的雲存儲服務都提供了數據安全的保護機制，通過 KMS、AES 等加密技術實現數據的加密存儲，同時也實現了客戶端到服務的鏈路加密方案，讓數據傳輸過程中也得到加密保護；
• 成熟的雲原生存儲接口：提供了兼容所有存儲類型的雲原生存儲接口，讓您的應用無縫的接入不同存儲服務。阿里雲容器服務提供的 CSI 接口驅動已經支持了：雲盤、OSS、NAS、本地盤、內存、LVM等多種存儲類型，可以讓應用無感知的訪問任何的存儲服務類型；
• 免運維：相對於自建存儲服務來說，公有云存儲方案省去了運維的難度

缺點如下所示：

• 定製化能力差：由於公有云存儲方案需要服務所有用戶場景，其能力主要集中在一些通用需求，而對某些用戶個性化需求很難滿足。

2.商業化雲存儲

在很多私有云環境中，業務方為了實現數據的高可靠性通常會購買商業化的存儲服務。這種方案為用戶提供了高可用、高效、便捷的存儲服務，且運維服務、後期保障等也都有保證。私有云存儲提供商也意識到雲原生應用的普及，也會為用戶提供完善的、成熟的雲原生存儲接口實現方案。

優點如下所示：

• 安全性好：私有云部署，可以從物理上實現數據的安全隔離；
• 高可靠、高性能：很多雲存儲提供商都是在存儲技術上深耕多年，具有優異的技術能力和運維能力，其商業化存儲服務可以滿足多數應用的性能、可靠性的需求；
• 雲原生存儲接口：從多家存儲服務提供商開源的項目可以看出，其對雲原生應用的支持已經實現或者展開。

缺點如下所示：

• 貴：商業化的存儲服務加個多數都很昂貴；
• 雲原生存儲接口兼容性：商業化的雲原生存儲接口都是針對其一家的存儲類型。多數用戶會使用不同的存儲類型，而使用了不同家的存儲服務，很難實現統一的存儲接入能力。

3.自建存儲服務

對於一些 SLA 要是不是很高的業務數據，很多公司都會選擇使用自建的方式提供存儲服務。業務方需要通過當前的開源的存儲方案，並結合自建的業務需求進行方案選擇。

• 文件存儲：考慮 CephFS、GlusterFS、NFS 等方案。其中 CephFS，GlusterFS 在技術的成熟度上還需要進一步驗證，且在高可靠、高性能場景上也存在不足。而 NFS 雖然已經成熟，但是自建集群在性能上很難達到高性能應用的需求。
• 塊存儲：例如 RBD、SAN 等是常見的塊存儲方案，技術也相對比較成熟，已經有較多的公司將其應用在自己的業務上。但其複雜度也相對很高，需要有專業的團隊來運維支持。

優點如下所示：

• 業務匹配度高、靈活性好：可以在眾多開源方案中選擇最適合自己業務的方案，且可以在原生代碼的基礎上進行二次開發來優化業務場景；
• 安全性好：如果搭建在公司內部使用，則具有物理隔離的安全性；
• 雲原生存儲接口：常用的開源存儲方案都可以在社區找到雲原生存儲接口的實現，且可以在其基礎上進行開發、優化。

缺點如下所示：

• 性能欠佳：多數開源的存儲方案其原生的性能表現並不是很好。當然您可以通過架構設計、物理硬件升級、二次開發等方案進行優化；
• 可靠性差：開源存儲方案在可靠性方面無法和商業化的存儲比較，所以更多場景是應用在 SLA 低的數據存儲場景；
• 雲原生存儲插件魚龍混雜：目前網上開源的雲原生存儲驅動版本眾多，且質量參差不齊，有些項目存在 bug，且長期無人維護，所以使用時需要更多的甄別和調測工作；
• 專業的團隊支撐：自己搭建的服務需要自己負責，面對並不是十分成熟的開源方案，需要組建一個具有較強技術能力的專業團隊來運維、開發存儲系統。

4.本地存儲

一些業務類型不需要高可用分佈式存儲服務，而會選擇使用性能表現更優的本地存儲方案。

數據庫類服務：對存儲的 IO 性能、訪問時延有很多的要求，一般的塊存儲服務並不能很好的滿足這方面的需求。且其應用本身已經實現了數據的高可用設計，不再需要底層實現多副本的能力，即分佈式存儲的多副本設計對這類應用是一種浪費。

存儲作為緩存：部分應用期望保存一些不重要的數據，數據在程序執行完成即可以丟掉，且對存儲的性能要求較高，其本質是將存儲作為緩存使用。雲盤的高可用能力對這樣的業務並沒有太大的意義，且雲盤在 IO 性能、價格方面的表現（相對本地盤）也沒有優勢。

所以本地盤存儲在很多關鍵能力上要比分佈式塊存儲弱很多，但在特定場景下仍然有其使用的優勢。阿里雲存儲服務提供了基於 NVMe 的本地盤存儲方案，以更好的性能表現和更低的價格優勢，在特定的應用場景得到了用戶的青睞。

阿里雲 CSI 驅動供了雲原生應用使用本地存儲的接入實現，支持：lvm 卷、本地盤裸設備、本地目錄映射等多種接入形式，實現數據的高性能訪問、quota、iops 配置等眾多適配能力。

優點如下所示：

• 性能高：提供相對分佈式存儲更優的 IOPS、吞吐能力；
• 低價：通過物理裸設備直接提供本地盤，在價格上相對於多副本的分佈式存儲具有優勢。

缺點如下所示：

• 數據可靠性差：本地盤保存的數據丟失後不能找回，需要從應用層實現數據的高可用設計；
• 靈活性差：不能像雲盤一樣實現數據遷移到其他節點使用。

5.開源容器存儲

隨著雲原生技術的發展，社區提供了一些開源的雲原生存儲方案。

1）Rook

Rook 作為第一個 CNCF 存儲項目，是一個集成了 Ceph、Minio 等分佈式存儲系統的雲原生存儲方案，意圖實現一鍵式部署、管理方案，且和容器服務生態深度融合，提供適配雲原生應用的各種能力。從實現上，可以認為 Rook 是一個提供了 Ceph 集群管理能力的 Operator。其使用 CRD 方式來對 Ceph、Minio 等存儲資源進行部署和管理。

Rook 組件：

• Operator：實現自動啟動存儲集群，並監控存儲守護進程，並確保存儲集群的健康；
• Agent：在每個存儲節點上運行，並部署一個 CSI / FlexVolume 插件，和 Kubernetes 的存儲卷控制框架進行集成。Agent 處理所有的存儲操作，例如掛載存儲設備、加載存儲卷以及格式化文件系統等；
• Discovers：檢測掛接到存儲節點上的存儲設備。

Rook 將 Ceph 存儲服務作為 Kubernetes 的一個服務進行部署，MON、OSD、MGR 守護進程會以 pod 的形式在 Kubernetes 進行部署，而 rook 核心組件對 ceph 集群進行運維管理操作。

Rook 通過 ceph 可以對外提供完備的存儲能力，支持對象、塊、文件存儲服務，讓你通過一套系統實現對多種存儲服務的需求。同時 rook 默認部署雲原生存儲接口的實現，通過 CSI / Flexvolume 驅動將應用服務與底層存儲進行銜接，其設計之初即為 Kubernetes 生態所服務，對容器化應用的適配非常友好。

Rook 官方文檔參考：https://rook.io/

2）OpenEBS

OpenEBS 是一種模擬了 AWS 的 EBS、阿里雲的雲盤等塊存儲實現的開源版本。OpenEBS 是一種基於 CAS 理念的容器解決方案，其核心理念是存儲和應用一樣採用微服務架構，並通過 Kubernetes 來做資源編排。其架構實現上，每個卷的 Controller 都是一個單獨的 Pod，且與應用 Pod 在同一個 Node，卷的數據使用多個 Pod 進行管理。

架構上可以分為數據平面（Data Plane）和控制平面（Control Plane）兩部分：

• 數據平面：為應用程序提供數據存儲；
• 控制平面：管理 OpenEBS 卷容器，通常會用到容器編排軟件的功能；

數據平面：

OpenEBS 持久化存儲卷通過 Kubernetes 的 PV 來創建，使用 iSCSI 來實現，數據保存在 node 節點上或者雲存儲中。OpenEBS 的卷完全獨立於用戶的應用的生命週期來管理，和 Kuberentes 中 PV 的思路一致。
OpenEBS 卷為容器提供持久化存儲，具有針對系統故障的彈性，更快地訪問存儲，快照和備份功能。同時還提供了監控使用情況和執行 QoS 策略的機制。

控制平面：

OpenEBS 控制平面 maya 實現了創建超融合的 OpenEBS，並將其掛載到如 Kubernetes 調度引擎上，用來擴展特定的容器編排系統提供的存儲功能；
OpenEBS 的控制平面也是基於微服務的，通過不同的組件實現存儲管理功能、監控、容器編排插件等功能。

更多關於 OpenEBS 的介紹可以參考：https://openebs.io/

3）Heketi

類似於 Rook 是 Ceph 開源存儲系統在雲原生編排平臺（Kubernetes）的一個落地方案，Glusterfs 同樣也有一個雲原生實踐方案。Heketi 提供了一個 Restful 管理接口，可用於管理 Gluster 存儲卷的生命週期。使用 Heketi，Kubernetes 可以動態地為 Gluster 存儲卷提供任何支持的持久性類型。Heketi 將自動確定集群中 brick 的位置，確保在不同的故障域中放置 brick 及其副本。Heketi 還支持任意數量的 Gluster 存儲集群，為雲服務提供網絡文件存儲。

使用 Heketi，管理員不再管理或配置塊、磁盤或存儲池。Heketi 服務將為系統管理所有硬件，使其能夠按需分配存儲。任何在 Heketi 註冊的物理存儲必須以裸設備方式提供，然後 Heketi 在提供的磁盤上使用 LVM 進行管理。

更多詳解參考：https://github.com/heketi/heketi)

6. 優勢

• 上述幾種雲原生存儲方案其設計之初既充分考慮了存儲與雲原生編排系統的融合，具有很好的容器數據卷接入能力；
• 在 Quota 配置、QoS 限速、ACL 控制、快照、備份等方面有較好的雲原生集成實現，雲原生應用使用存儲資源時更加靈活、便利；
• 開源方案，社區較為活躍，網絡資源、使用方案豐富，讓您更容易入手。

7. 劣勢

• 成熟度較低，目前上述方案多在公司內部測試環境或者 SLA 較低的應用中使用，很少存儲關鍵應用數據；
• 性能差：和公有云存儲、商業化存儲相比，上述雲原生存儲方案在 IO 性能、吞吐、時延等方面都表現欠佳，很難應用在高性能服務場景；
• 後期維護成本高：雖然上面方案部署、入門都很簡單，但一旦運行中出現問題解決起來非常棘手。上述項目屬於初期階段，並不具備生產級別的服務能力，如果使用此方案需要有強有力的技術團結加以保障。

現狀和挑戰

1.敏捷化需求

雲原生應用場景對服務的敏捷度、靈活性要求非常高，很多場景期望容器的快速啟動、靈活的調度，這樣即需要存儲卷也能敏捷的根據 Pod 的變化而調整。

需求表現在：

• 雲盤掛載、卸載效率提高：可以靈活的將塊設備在不同節點進行快速的掛載切換；
• 存儲設備問題自愈能力增強：提供存儲服務的問題自動修復能力，減少人為干預；
• 提供更加靈活的卷大小配置能力。

2.監控能力需求

多數存儲服務在底層文件系統級別已經提供了監控能力，然後從雲原生數據卷角度的監控能力仍需要加強，目前提供的PV監控數據維度較少、監控力度較低；

具體需求：

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

3.性能要求

在大數據計算場景同時大量應用訪問存儲的需求很高，這樣對存儲服務帶來的性能需求成為應用運行效率的關鍵瓶頸。

具體需求：

• 底層存儲服務提供更加優異的存儲性能服務，優化 CPFS、GPFS 等高性能存儲服務滿足業務需求；
• 容器編排層面：優化存儲調度能力，實現存儲就近訪問、數據分散存儲等方式降低單個存儲卷的訪問壓力。

4.共享存儲的隔離性

共享存儲提供了多個 Pod 共享數據的能力，方便了不同應用對數據的統一管理、訪問，但在多租的場景中，不同租戶對存儲的隔離性需求成為一個需要解決的問題。

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

- 贈書福利 -

6 月 12 日 17：00 前在“阿里巴巴雲原生”公眾號留言區歡迎大家討論交流雲原生存儲新的機遇與挑戰，精選留言點贊第 1 名即可免費獲得此書！

課程推薦

為了更多開發者能夠享受到 Serverless 帶來的紅利，這一次，我們集結了 10+ 位阿里巴巴 Serverless 領域技術專家，打造出最適合開發者入門的 Serverless 公開課，讓你即學即用，輕鬆擁抱雲計算的新範式——Serverless。

點擊即可免費觀看課程：https://developer.aliyun.com/learning/roadmap/serverless

“阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”