雲原生存儲和雲存儲有什麼區別？

做者 | 李鵬（壯懷） 阿里雲智能事業羣高級技術專家

導讀：新的企業負載／智能工做負載容器化、遷雲、存儲方面遇到的性能、彈性、高可用、加密、隔離、可觀測性以及生命週期等方面的問題，不但須要存儲產品層次的改進，更須要在雲原生的控制／數據平面的改進，推動雲原生存儲和雲存儲的演進。本文將介紹一下問題場景，探討可行的解決方案，最終得出雲原生存儲以及雲存儲目前能夠作什麼和將來還須要作什麼。

引言

最近有幸參加了由 Infra Meetup 聯合 Kubernetes & Cloud Native Meetup 共同組織的面向雲原生持久化應用的 Meetup，結合最近對雲存儲、開源存儲、雲原生存儲的思考，對雲原生存儲究竟是什麼，須要作些什麼，雲原生存儲將來挑戰是什麼，作了更多的反思和梳理，一家之言，分享了幾個初步觀點。

隨着雲原生應用對可遷移性、擴展性和動態特性的需求，相應的，對雲原生存儲也帶來了密度、速度、混合度的要求，因此對雲存儲基本能力又提出了在效率、彈性、自治、穩定、應用低耦合、GuestOS 優化、安全等方面的訴求。

雲原生現狀

容器和雲原生計算被企業快速接納

Forrester 預測：到 2022 年， 全球組織／公司在生成環境運行容器化應用，從今天不足 30% 的比例將大幅度提高到超過 75%，企業應用容器化的趨勢勢不可擋。

另外一方面，根據 IDC 對將來企業級存儲市場的增加趨勢預測：雲存儲的需求相比於 2015 年，到 2020 將會有 3 倍以上的增加，企業存儲市場中，數據管理類企業核心數據消耗的存儲所佔的比例將從 15% 提高到 23%，結構化數據和 DBMS 數據在企業存儲市場中將進一步增強。

對雲原生來講，核心企業應用／智能應用，使用雲原生存儲來部署生產可用的有狀態應用，呈現加速上升趨勢。海外存儲巨頭 EMC、NetApp 擁抱雲原生，積極佈局 REX-Ray flexrex、Trident 等雲原生存儲編排方案。

Kubernetes 逐漸成爲雲原生時代的基礎設施

過去的一年（2018-2019）中，Kubernetes 逐漸成爲雲原生時代的基礎設施，愈來愈多的互聯網、數據庫、消息隊列等有狀態企業核心應用，逐步遷移到雲原平生臺 Kubernetes，對不一樣的雲上塊存儲的性能在時延和吞吐，以及穩定性提出了不一樣的要求，好比：

1. 毫秒級 NvME SSD 級別的穩定時延，來知足高性能 KVstore 和數據庫需求；
2. 隨着應用單機部署密度的提高，對塊存儲單機密度的挑戰；
3. 本地塊存儲共享，對塊存儲的彈性和隔離性也提出了更高需求。

在雲原生環境下，如何以聲明方式來知足不一樣的業務場景，成爲了雲原生存儲在實現控制面和數據面上的挑戰。

在智能應用 AI 場景下，高性能計算、流式計算也嘗試經過 Kubernetes 雲原平生臺來部署，使用雲存儲方式來完成訓練、計算、推理等方面的工做，這對雲存儲在 Kubernetes 環境的選擇及使用方面提出了挑戰。好比，有證據代表 Spark 生態正在逐步從 Hadoop YARN 向 Kubernetes 原生的調度器以及擴展調度器 e.g. Gang Scheuler 遷移。

在雲計算環境中：因爲成本和存儲計算分離的模型，HDFS 仍然會以存儲協議的方式存在，但存儲方式會逐步從 HDFS 的 3 副本向對象存儲（OSS，S3）遷移；GPU 多機多卡 MPI 計算、Flink 流式計算的 Kubernetes 化已經逐步成爲主流，存儲訪問方式也多以對象存儲方式呈現。

可是在使用對象存儲過程當中，大數據／AI 應用的計算效率仍面臨着嚴峻的挑戰：

1. 減小同一節點對同一 Block 的反覆拉起產生的網絡 IO；
2. 減小數據的 Shuffle 產生的寫 IO；
3. 實現計算對數據感知，計算向數據遷移的就近計算。

目前的 Kubernetes 調度器以及雲存儲特性並未給出好的解決方案，因此這也給雲原生存儲在加速大數據計算、彌補 IO 吞吐不足方面提供了發揮的舞臺。

大數據離線計算好比基因計算，已經經過 Kubernetes 雲原平生臺來大規模的運行計算任務：對文件存儲峯值吞吐 10GBps - 30GBps 的峯值剛性兌付，須要獨立的高吞吐的文件存儲形態和交付方式在雲原生環境下的演進和變革。

容器服務成爲雲原生時代基礎設施

隨着企業應用上雲愈來愈多地選擇使用容器化方式，容器服務在不一樣的雲廠商中都有大幅度的業務增加，容器服務已經逐步成爲雲原生時代新的基礎設施和最佳使用雲資源的入口。雲原生存儲對雲計算／雲存儲來講也有了新的內涵，有必要從新思考雲存儲和雲原生存儲的本質區別和聯繫。

雲原生存儲和雲存儲的思考

Cloud Native Storage vs Cloud Storage：

• 對立仍是統一？
• 二者之間的聯繫？
• 差別和側重點？

1. 雲原生存儲 = 雲存儲 UI，面向應用的申明式應用層存儲 + 效率等能力組合

雲原生存儲聲明的六要素：

1. 容量 Size；
2. 性能 IOPS,、吞吐、時延；
3. 可訪問性，共享／獨享；
4. IO 可觀測性；
5. QoS；
6. 多租戶隔離。

2. 分層存儲，重用基礎設施紅利，不從新發明輪子，針對新的負載類型部分存儲形態上移

3. 在控制平面實現效率、自治方面能力，最大化存儲穩定和安全

市場上的雲原生存儲

爲了更好的理解在雲環境中如何構建雲原生存儲，先看幾個在 Kubernetes 企業環境中部署主流的雲原生存儲，以及對比雲存儲的形態：

1. Ceph on Kubernetes with Rook
2. Portworx
3. OpenEBS

Ceph on Kubernetes with Rook

Ceph 是聖克魯茲加利福尼亞大學的 Sage Weil 在 2003 年開發的，也是他博士學位項目中的一部分。Ceph LTS 成熟穩定、高可用、生態強大，在雲原生時代和 Kubernets 緊密集成。Ceph 基於 RADOS（Reliable Autonomic Distributed Object Store ）的高可用存儲，在雲原生時代以前 2003 年發行起，已經普遍生產部署的高可用存儲，支持最普遍的塊存儲 RBD、文件 POSIX Cephfs，以及對象存儲訪問協議。

RedHat／SUSE 目前是 Ceph 最主要的商業化支持者，在多個容器平臺落地案例中，RBD、CephFS 都被採用做爲容器平臺實施的主要存儲，用來彌補基礎雲存儲的缺失。

Rook 目前是在 Kubernetes 產品級可用的部署和運維 Ceph 編排工具。

Ceph 的基本架構由數據面 OSDs(RADOS) 和控制面 MON/RBD/RADOSGW/CEPHFS 組成，以 CRUSH Algorithm 做爲核心算法處理數據冗餘和高可用, 上層的應用存儲經過 librados 同數據面 OSDs 直接完成數據的讀寫，可以支持快照、備份、監控可觀測性等能力，能夠經過 Rook 直接經過 Kubernetes 輸出，RedHat／SUSE 也提供獨立的集羣安裝能力。

Ceph 的一些基本架構特徵和能力：

• 控制面：MON/RBD/RADOSGW/CEPHFS；
• 數據面：OSDs(RADOS)；
• 快照、備份、支持 IO 監控等存儲性能監控，支持 RBD QoS 的服務端限速能力。

Portworx

Portworx 以容器服務的方式部署，每一個節點稱爲 PX，向下對接各類公有云的塊存儲或者裸金屬服務器，向上提供塊或文件服務。

不綁定硬件形態和廠商，可接入任何一家公有云或者自建服務器集羣(只需支持 iSCSI 或 FC 協議)，目前 Portworx 主打能力雲災備 DR、多雲複製，具有完備的快照(ROW)、多雲管理、同步複製（RTO，秒級）異步複製（RPO<=15min)，能夠經過 Kubernetes CRD 申明方式，優雅實現持久化雲下應用帶數據自動遷移雲上能力。PX 能夠獨立部署，並不強依賴 Kubernetes 的容器網絡。

Portworx 的一些基本功能／性能特徵：

• 彈性擴展， PX 自動識別服務器節點的能力，可動態調度 IO

• 控制面

  • 支持主流容器編排工具：Kubernetes、Mesos、Swarm 等
  • 支持 IO 級別的性能監控

• IO面

  • 數據塊和元數據打散到不一樣的節點
  • 使用了緩存和高性能RPC
  • QOS隔離：不支持
  • 根據底層存儲的特性IOPS(4k) 768 - 65024
  • 時延（4k): 0.58ms - 23ms

• 增值特性

  • 加密（三方祕鑰託管，傳輸加密，落盤加密），支持雲廠商KMS集成和Vault
  • 快照(ROW)，多雲管理，同步複製（RTO，秒級），異步複製（RPO<=15min）
  • 可擴展性 >1000個節點，>10000個Volume
  • 支持拓撲感知計算

OpenEBS

OpenEBS 基於 Kubernetes 構建的開源版 EBS，軟件定義 PV：將各類介質，包括本地磁盤、雲等各類存儲統一池化和管理。使用 iSCSI 做爲存儲協議。沒有綁定某一個廠商的存儲，能夠靈活的接入各類存儲的一個緣由。從某種意義上也是更加靈活，輕量。可是強依賴容器網絡，增長了抽象層 OpenEBS layer, 寫入操做要經過抽象層，而且每一個卷 PV 都有獨立的 controller，增長了額外的開銷，雖然能夠作到更靈活，但相比於 Portworx、Ceph 來講，其在性能上有比較大的劣勢。

OpenEBS 的一些基本功能／性能特徵：

• 控制面：擴展容器編排系統，支持超融合。相比塊而言，卷的數量多且卷的大小任意配置，更加靈活；
• 高可用：每一個卷能夠有多副本，數據實時同步，數據同步是在不一樣的存儲池間進行同步；
• 快照、備份、監控存儲性能功能；
• 和 Cloud-Native Tools 有很好的集成：可使用雲原生工具（如 Prometheus，Grafana，Fluentd，Weavescope，Jaeger 等）來配置，監控和管理存儲資源。

理解雲存儲

盤古 vs RADOS

對比以上三種開源／企業存儲，爲了更容易的理解雲存儲架構，咱們把盤古的分層架構和 Ceph 存儲的分層作一個對比。

能夠把 CS（Chunk Server）類比 Ceph OSDs 服務進程，把盤古的 Master 進程類比於 Ceph MDSs 進程。

把雲產品塊存儲類比於 Ceph RBD， 文件存儲類別於 CephFS, 對象存儲類比於 RADOSGW，本地塊存儲／高性能文件存儲 CPFS 產品暫沒有對應。

隨着盤古架構的演進，和盤古 2.0 的全面推廣、用戶態 TCP 網絡協議棧的推廣、全面的 RDMA 存儲網絡、全面優化的 RPC 性能，上層產品存儲也享受到了底層存儲變革的巨大紅利，進入了亞毫秒級別時延，和百萬 IOPS 的時代，雲原生存儲也必然是要在產品存儲層次之上，可以繼承這些能力。

雲原生存儲在公有云和專(私)有云中的差別

經過分析了市場上雲原生存儲，咱們能夠發現這些存儲都有共同的特徵就是支持聲明化的 API，能夠實現對性能、容量、功能等方面的度量和聲明，或多或少對質量／穩定／安全都有不一樣支持。

進一步來講，雲原生負載能夠直接經過數據平面無損耗的使用產品存儲在容量、性能、可訪問性的能力，在控制平面繼續提高面向用戶應用的 IO 可觀測性、應用級的 QoS、多租戶的隔離能力，經過控制平面接口實現 CSI／Flexvolume 等可聲明的存儲接口，並提供對部分存儲生命週期的 Operator，容器編排把業務應用和存儲粘合成爲實際的負載聲明，多是更加正確使用雲存儲的姿式。

因爲公有云的基礎設施產品存儲的完備，可使用更加輕量化的數據平面（virtio, nfs-utils, cpfs-sdk, oss-sdk)來訪問產品存儲。

專有云環境差別較大，部分虛擬化或者無虛擬化環境，SAN 和裸盤是主要存儲方式，須要經過相似構建 ceph RADOS 或者盤古實現 SDS，而後經過數據平面（librados／px/pv-controller）實現存儲的訪問。

針對 vSphere，OpenStack，飛天所構建的專有云，有接近於公有云的存儲提供方式，但由於部署模塊的差別，也存在不一樣的控制／數據平面支持能力的差別。

簡單來講就是：

• 公有云 
 Cloud Native Storage = Declarative API + Cloud Storage
• 專有云 
 Cloud Native Storage = Declarative API + Native Storage

公有云中的雲原生存儲

1. 存儲分層，重用基礎設施紅利，不從新發明輪子。

2. 雲原生存儲

• 提高數據平面的一致性（kernel／OS／net／client／sdk 優化參數和版本控制）；
• 構建統一的控制平面 CSI/Flexvolume/Operator, 提供面向客戶聲明 API；
• 在調度編排層面實現拓撲感知，實現雲盤的 zone awareness, 本地盤的 node awareness。

塊存儲

在控制平面經過與 Aliyun Linux 2 OS 結合使用 Kernel Cgroup blkio 實現進程級別的 buffer IO 控制，提高了在應用層對本地盤、雲盤的 QoS 控制的粒度。經過對本地盤的 LVM 切分能夠實現對單機雲盤的密度提高。經過對掛載點／設備 IO 指標測採集能力，實現 IO 的可觀測性。

雲原生存儲- 塊存儲的主要特徵指標：

• 容量: 單盤 32TB
• 時延：0.2ms – 10ms
• IOPS: 5K – 1M
• 吞吐： 300Mbps - 4Gbps (本地 NvME ESSD: 2GBps)
• 可訪問性： 單可用區獨佔
• QoS：單盤隔離，進程隔離
• 多租戶： 單盤隔離

詳情見：雲盤性能

文件存儲

在控制平面能夠經過對 Pod Security Policy 和 SecuritContext 的控制，實現應用的強制 UID／GID 控制，實現應用對文件系統的 ACL 控制。控制平面實現對文件系統生命週期的控制，經過對掛載點 IO 指標測採集能力，實現 IO 的可觀測性。

雲原生存儲- 文件存儲的主要特徵指標：

• 容量：單文件系統 10PB
• 時延：100 微妙 – 10ms
• IOPS: 15K – 50K
• 吞吐： 150Mbps - 20GBps
• 可訪問性： 多集羣多可用區共享
• QoS：IO 爭搶
• 多租戶： PSP ACL （namespace）

CPFS 並行文件系統

在控制平面實現對文件系統 ACL 控制，對 QoS 提供客戶端限速的可配置性，文件系統提供生命週期的聲明式管理能力 Operator，再進一步，在雲原生環境內實現 CPFS 文件系統的聲明式部署。

雲原生存儲- 高性能文件存儲的主要特徵指標：

• 容量：單文件系統 100PB
• 時延：0.5ms – 10ms
• IOPS: 50K – 1M
• 吞吐： 10Gbps - 1000GBps
• 可訪問性： 多集羣多可用區共享
• QoS：支持客戶端限速
• 多租戶： PSP ACL （namespace)

總結：雲原生存儲 v1 – 功能性

今天的雲原生存儲已經實現了在控制平面／控制平面接口對阿里雲產品存儲的全品類支持，在數據平面也完成了大部分系統級和客戶端層的優化。但隨着大量的持久化企業應用和智能化應用的容器化遷移，咱們依然面臨着更多的問題和挑戰。

---

在整個雲原生存儲 v1 的開發過程當中，感謝阿里雲存儲團隊，在文件存儲、塊存儲和對象存儲的通力合做和幫助，共同打造的雲原生時代的存儲。

隨着雲原生應用對可遷移性，擴展性和動態特性的需求，對雲原生存儲也帶來了相應的密度，速度，混合度的要求，因此對雲存儲基本能力之上又提出了在效率，彈性，自治，穩定，應用低耦合，GuestOS優化，安全等方面的訴求。新的企業負載／智能工做負載容器化，遷雲，存儲方面遇到的性能，彈性，高可用，加密，隔離，可觀測性，生命週期等方面的問題，不可是須要存儲產品層次的改進，更須要在雲原生的控制／數據平面的改進，推動雲原生存儲和雲存儲的演進，這是對雲原生存儲v2的展望和規劃，咱們會在後續文章進一步揭示這些新的場景，需求，方案以及發展方向。

「 阿里巴巴雲原生微信公衆號（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術公衆號。」