雲原生存儲的思考 （一）什麼是雲原生存儲
Abstract
最近有幸參加了有PingCap和CNCF組織的面向雲原生面相持久化應用的Meetup，結合最近對雲存儲，開源存儲，雲原生存儲的思考，對雲原生存儲到底是什麼，需要做些什麼，雲原生存儲未來挑戰是什麼，做了更多的反思和梳理，一家之言，分享了幾個初步觀點。
- 雲原生存儲是雲存儲UI，面向應用的申明式應用層存儲
公有雲 Cloud Native Storage = Declarative API + Cloud Storage
專有雲 Cloud Native Storage = Declarative API + Native Storage
- 雲原生存儲是重用雲存儲基礎設施紅利，是建構在核心存儲，應用存儲之上的分層存儲，不需要重新發明輪子。
- 雲原生控制平面實作效率，自治方面能力，最大化減小存儲穩定和安全隐患。
結合企業生産落地場景中，針對目前雲原生應用需求，對存儲性能，彈性，高可用，加密，隔離，可觀測性，生命周期面臨着各種挑戰，整理出了部分雲原生存儲v2的解決方案和演進路徑。其中就TiDB在雲原生架構中的擴容能力，存儲選擇可行性和演進，以及不同雲原生存儲的QoS的保障能力和遇到的挑戰與會者做了互動溝通。
容器和雲原生計算被企業快速接納
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雲原生平台來部署，使用雲存儲方式來完成訓練，計算，推理等方面的工作，這對雲存儲在Kubernets環境的選擇，使用也提出了挑戰。比如，有證據表明Spark生态正在逐漸從Hadoop YARN向Kubernets原生的排程器以及擴充排程器 e.g. Gang Scheuler遷移。在雲計算環境中，由于成本和存儲計算分離的模型，HDFS仍然會以存儲協定的方式存在，但存儲方式會逐漸從HDFS的3副本向對象存儲（OSS，S3)遷移。雲計算環境中，GPU多機多卡MPI計算，Flink流式計算的Kuberntes化已經逐漸成為主流了，存儲通路方式也多以對象存儲方式。但是使用對象存儲過程中，大資料／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是聖克魯茲加利福尼亞大學的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也提供獨立的叢集安裝能力。
控制面MON/RBD/RADOSGW/CEPHFS
資料面：OSDs(RADOS)
快照，備份，支援IO監控等存儲性能監控，支援RBD QoS的服務端限速能力
Portworx以容器服務的方式部署，每個節點稱為PX，向下對接各種公有雲的塊存儲或者裸金屬伺服器，向上提供塊或檔案服務
不綁定硬體形态和廠商，可接入任何一家公有雲或者自建伺服器叢集(隻需支援iSCSI或FC協定)，目前Portworx主打能力雲災備DR，多雲複制，具備完備的快照(ROW)，多雲管理，同步複制（RTO，秒級）異步複制（RPO<=15min), 可以通過Kubernetes CRD申明方式來優雅實作持久化雲下應用帶資料自動遷移雲上能力。PX可以獨立部署，并不強依賴Kubernetes的容器網絡。
彈性擴充， 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基于Kubernetes建構的開源版EBS，軟體定義PV：将各種媒體，包括本地磁盤，雲等各種存儲統一池化和管理。使用iSCSI作為存儲協定。沒有綁定某一個廠商的存儲，可以靈活的接入各種存儲的一個原因。從某種意義上也是更加靈活，輕量。但是強依賴容器網絡，增加了抽象層OpenEBS layer, 寫入操作要通過抽象層，并且每個卷PV都有獨立的controller增加了額外的開銷，雖然可以做到更靈活，但相比于Portworx，Ceph在性能上有比較大的劣勢。
控制面：擴充容器編排系統，支援超融合。相比塊，卷的數量多，卷的大小任意配置，更靈活。
高可用：每個卷可以有多副本，資料實時同步，資料同步是在不同的存儲池間進行同步。
快照，備份，監控存儲性能功能。
和Cloud-Native Tools有很好的內建：可以使用雲原生工具（如Prometheus，Grafana，Fluentd，Weavescope，Jaeger等）來配置，監控和管理存儲資源
性能對比
測試環境：3台“2 vCPU 以及 16GB 的記憶體”虛拟機建立的Azure AKS叢集，每台虛機挂載1個1TB的Premium SSD存儲，測試工具FIO
在這個測試中，以hostPath為雲盤的性能基準
- Portworx性能最好，PX優化了讀性能超過了hostPath模式，但寫性能應該是在多副本，PX和裸存儲之間的互動損失。
- Ceph操作管理複雜，Rook簡化了運維複雜性，讀性能優化很好，寫性能猜測因為寫請求進入多個OSDs的通過RPC走以太網造成了數量級的降低。
- OpenEBS微服務架構，猜測因為增加了額外的虛拟層，使用了容器overlay網絡，以及額外的controller的記憶體換出的代價，性能優化空間很大
盤古 vs RADOS
對比以上三種開源／企業存儲，為了更容易的了解雲存儲的架構，我們把盤古的分層架構和Ceph存儲的分層做一個對比。
可以把CS（Chunk Server）類比Ceph OSDs服務程序，把盤古的Master程序類比于Ceph MDSs程序。
把雲産品塊存儲類比于Ceph RBD， 檔案存儲類别于CephFS, 對象存儲類比于RADOSGW，本地塊存儲／高性能檔案存儲CPFS産品暫沒有對應。
随着盤古架構的演進，和盤古2.0的全面推廣，使用者态TCP網絡協定棧的推廣，全面的RDMA存儲網絡，全面優化的RPC性能，上層産品存儲也享受到了底層存儲變革的巨大紅利，進入了亞毫秒級别時延，和百萬IOPS的時代，雲原生存儲也必然是要在産品存儲層次之上能夠繼承這些能力。
雲原生存儲
通過分析了市場上雲原生存儲，我們可以發現這些存儲都有共同的特征就是支援聲明化的API，可以實作對性能，容量，功能等方面實作度量和聲明，或多或少對品質／穩定／安全都有不同支援。
進一步來說，雲原生負載可以直接通過資料平面無損耗的使用産品存儲在1, 2，3的能力，在控制平面繼續提升面向使用者應用的IO可觀測性，應用級的QoS，多租戶的隔離能力，通過控制平面接口實作CSI／Flexvolume等可聲明的存儲接口，并提供對部分存儲生命周期的Operator，容器編排把業務應用和存儲粘合成為實際的負載聲明，可能是更加正确的使用雲存儲的姿勢。
由于公有雲的基礎設施産品存儲的完備，可以使用更加輕量化的資料平面（virio, 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 – 功能性
今天的雲原生存儲已經實作了在控制平面／控制平面接口對阿裡雲産品存儲的全品類支援，在資料平面也完成了大部分系統級和用戶端層的優化。但随着大量的持久化企業應用和智能化應用的容器化遷移，我們依然面臨着更多的問題和挑戰，将會在下一篇文章探讨。