作者 | ***(壯懷) 阿里云智能事業群高級技術專家
導讀:新的企業負載/智能工作負載容器化、遷云、存儲方面遇到的性能、彈性、高可用、加密、隔離、可觀測性以及生命周期等方面的問題,不但需要存儲產品層次的改進,更需要在云原生的控制/數據平面的改進,推進云原生存儲和云存儲的演進。本文將介紹一下問題場景,探討可行的解決方案,最終得出云原生存儲以及云存儲目前可以做什么和未來還需要做什么。
引言
最近有幸參加了由 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的展望和規劃,我們會在后續文章進一步揭示這些新的場景,需求,方案以及發展方向。
原文鏈接
本文為云棲社區原創內容,未經允許不得轉載。
評論
查看更多