雲原生儲存和雲端儲存有什麼區別？
作者 | 李鵬（壯懷） 阿里雲智慧事業群高階技術專家
導讀：新的企業負載／智慧工作負載容器化、遷雲、儲存方面遇到的效能、彈性、高可用、加密、隔離、可觀測性以及生命週期等方面的問題，不但需要儲存產品層次的改進，更需要在雲原生的控制／資料平面的改進，推進雲原生儲存和雲端儲存的演進。本文將介紹一下問題場景，探討可行的解決方案，最終得出雲原生儲存以及雲端儲存目前可以做什麼和未來還需要做什麼。
引言
最近有幸參加了由 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，對不同的雲上塊儲存的效能在時延和吞吐，以及穩定性提出了不同的要求，比如：
- 毫秒級 NvME SSD 級別的穩定時延，來滿足高效能 KVstore 和資料庫需求；
- 隨著應用單機部署密度的提升，對塊儲存單機密度的挑戰；
- 本地塊儲存共享，對塊儲存的彈性和隔離性也提出了更高需求。
在雲原生環境下，如何以宣告方式來滿足不同的業務場景，成為了雲原生儲存在實現控制面和資料面上的挑戰。
在智慧應用 AI 場景下，高效能運算、流式計算也嘗試通過 Kubernetes 雲原生平臺來部署，使用雲端儲存方式來完成訓練、計算、推理等方面的工作，這對雲端儲存在 Kubernetes 環境的選擇及使用方面提出了挑戰。比如，有證據表明 Spark 生態正在逐步從 Hadoop YARN 向 Kubernetes 原生的排程器以及擴充套件排程器 e.g. Gang Scheuler 遷移。
在雲端計算環境中：由於成本和儲存計算分離的模型，HDFS 仍然會以儲存協議的方式存在，但儲存方式會逐步從 HDFS 的 3 副本向物件儲存（OSS，S3）遷移；GPU 多機多卡 MPI 計算、Flink 流式計算的 Kubernetes 化已經逐步成為主流，儲存訪問方式也多以物件儲存方式呈現。
但是在使用物件儲存過程中，大資料／AI 應用的計算效率仍面臨著嚴峻的挑戰：
- 減少同一節點對同一 Block 的反覆拉起產生的網路 IO；
- 減少資料的 Shuffle 產生的寫 IO；
- 實現計算對資料感知，計算向資料遷移的就近計算。
目前的 Kubernetes 排程器以及雲端儲存特性並未給出好的解決方案，所以這也給雲原生儲存在加速大資料計算、彌補 IO 吞吐不足方面提供了發揮的舞臺。
大資料離線計算比如基因計算，已經通過 Kubernetes 雲原生平臺來大規模的執行計算任務：對檔案儲存峰值吞吐 10GBps - 30GBps 的峰值剛性兌付，需要獨立的高吞吐的檔案儲存形態和交付方式在雲原生環境下的演進和變革。
容器服務成為雲原生時代基礎設施
隨著企業應用上雲越來越多地選擇使用容器化方式，容器服務在不同的雲廠商中都有大幅度的業務增長，容器服務已經逐步成為雲原生時代新的基礎設施和最佳使用雲資源的入口。雲原生儲存對雲端計算／雲端儲存來說也有了新的內涵，有必要重新思考雲端儲存和雲原生儲存的本質區別和聯絡。
雲原生儲存和雲端儲存的思考
Cloud Native Storage vs Cloud Storage：
- 對立還是統一？
- 兩者之間的聯絡？
- 差異和側重點？
1. 雲原生儲存 = 雲端儲存 UI，面向應用的申明式應用層儲存 + 效率等能力組合
雲原生儲存宣告的六要素：
- 容量 Size；
- 效能 IOPS,、吞吐、時延；
- 可訪問性，共享／獨享；
- IO 可觀測性；
- QoS；
- 多租戶隔離。
2. 分層儲存，重用基礎設施紅利，不重新發明輪子，針對新的負載型別部分儲存形態上移
3. 在控制平面實現效率、自治方面能力，最大化儲存穩定和安全
市場上的雲原生儲存
為了更好的理解在雲環境中如何構建雲原生儲存，先看幾個在 Kubernetes 企業環境中部署主流的雲原生儲存，以及對比雲端儲存的形態：
- Ceph on Kubernetes with Rook
- Portworx
- 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
公有云中的雲原生儲存
- 儲存分層，重用基礎設施紅利，不重新發明輪子。
- 雲原生儲存
- 提升資料平面的一致性（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等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術公眾號。”