歡迎光臨
每天分享高質量文章

如何評估Kubernetes持久化儲存方案

在2018年的Garnter技術成熟度曲線中,容器儲存出現在了技術觸發期,已經開始進入大眾的視野。我相信,在未來的兩年內,容器儲存會隨著Kubernetes的進一步成熟和商業化,其地位會越來越重要。如何在五花八門的儲存產品中,選擇適合自己的一款,將會是IT大佬們必須要面對的問題。本文將會從使用場景角度分析,如何評估容器儲存方案。
五花八門的儲存概念

 

從用戶角度看,儲存就是一塊盤或者一個目錄,用戶不關心盤或者目錄如何實現,用戶要求非常“簡單”,就是穩定,性能好。為了能夠提供穩定可靠的儲存產品,各個廠家推出了各種各樣的儲存技術和概念。為了能夠讓大家有一個整體認識,本文先介紹儲存中的這些概念。
從儲存介質角度,儲存介質分為機械硬碟和固態硬碟(SSD)。機械硬碟泛指採用磁頭尋址的磁盤設備,包括SATA硬碟和SAS硬碟。由於採用磁頭尋址,機械硬碟性能一般,隨機IOPS一般在200左右,順序帶寬在150MB/s左右。固態硬碟是指採用Flash/DRAM芯片+控制器組成的設備,根據協議的不同,又分為SATA SSD,SAS SSD,PCIe SSD和NVMe SSD。
從產品定義角度,儲存分為本地儲存(DAS),網絡儲存(NAS),儲存局域網(SAN)和軟體定義儲存(SDS)四大類。
  • DAS就是本地盤,直接插到服務器上

  • NAS是指提供NFS協議的NAS設備,通常採用磁盤陣列+協議網關的方式

  • SAN跟NAS類似,提供SCSI/iSCSI協議,後端是磁盤陣列

  • SDS是一種泛指,包括分佈式NAS(並行檔案系統),ServerSAN等

從應用場景角度,儲存分為檔案儲存(Posix/MPI),塊儲存(iSCSI/Qemu)和物件儲存(S3/Swift)三大類。
Kubernetes是如何給儲存定義和分類呢?Kubernetes中跟儲存相關的概念有PersistentVolume (PV)和PersistentVolumeClaim(PVC),PV又分為靜態PV和動態PV。靜態PV方式如下:
動態PV需要引入StorageClass的概念,使用方式如下:
社區列舉出PersistentVolume的in-tree Plugin,如下圖所示。從圖中可以看到,Kubernetes通過訪問樣式給儲存分為三大類,RWO/ROX/RWX。這種分類將原有的儲存概念混淆,其中包含儲存協議,儲存開源產品,儲存商業產品,公有雲儲存產品等等。
如何將Kubernetes中的分類和熟知的儲存概念對應起來呢?本文選擇將其和應用場景進行類比。
  1. 塊儲存通常只支持RWO,比如AWSElasticBlockStore,AzureDisk,有些產品能做到支持ROX,比如GCEPersistentDisk,RBD,ScaleIO等

  2. 檔案儲存(分佈式檔案系統)支持RWO/ROX/RWX三種樣式,比如CephFS,GlusterFS和AzureFile

  3. 物件儲存不需要PV/PVC來做資源抽象,應用可以直接訪問和使用

這裡不得不吐槽Kubernetes社區前期對儲存層的抽象,一個字——亂,把開源專案和商業專案都納入進來。現在社區已經意識到問題並設計了統一的儲存接口層——Flexvolume/CSI。目前來看,CSI將會是Kubernetes的主流,做了完整的儲存抽象層。
多種多樣的應用場景

 

介紹完儲存概念之後,選擇哪種儲存仍然懸而未決。這個時候,請問自己一個問題,業務是什麼型別?選擇合適的儲存,一定要清楚自己的業務對儲存的需求。本文整理了使用容器儲存的場景及其特點。
配置
無論集群配置信息還是應用配置信息,其特點是併發訪問,也就是前邊提到的ROX/RWX,在不同集群或者不同節點,都能夠訪問同樣的配置檔案,分佈式檔案儲存是最優選擇。
日誌
在容器場景中,日誌是很重要的一部分內容,其特點是高吞吐,有可能會產生大量小檔案。如果有日誌分析場景,還會有大量併發讀操作。分佈式檔案儲存是最優選擇。
應用(資料庫/訊息佇列/大資料)
Kafka,MySQL,Cassandra,PostgreSQL,ElasticSearch,HDFS等應用,本身具備了儲存資料的能力,對底層儲存的要求就是高IOPS,低延遲。底層儲存最好有資料冗餘機制,上層應用就可以避免複雜的故障和恢復處理。以HDFS為例,當某個datanode節點掉線後,原有邏輯中,會選擇啟動新的datanode,觸發恢復邏輯,完成資料副本補全,這段時間會比較長,而且對業務影響也比較大。如果底層儲存有副本機制,HDFS集群就可以設置為單副本,datanode節點掉線後,啟動新的datanode,掛載原有的pv,集群恢復正常,對業務的影響縮短為秒級。高性能分佈式檔案儲存和高性能分佈式塊儲存是最優選擇。
備份
應用資料的備份或者資料庫的備份,其特點是高吞吐,資料量大,低成本。檔案儲存和物件儲存最優。
綜合應用場景,高性能檔案儲存是最優選擇。

 

形形色色的儲存產品

 

市面上的儲存產品種類繁多,但是對於容器場景,主要集中在4種方案:分佈式檔案儲存,分佈式塊儲存,Local-Disk和傳統NAS。
分佈式塊儲存包括開源社區的Ceph,Sheepdog,商業產品中EMC的Scale IO,Vmware的vSAN等。分佈式塊儲存不適合容器場景,關鍵問題是缺失RWX的特性。
分佈式檔案儲存包括開源社區的Glusterfs,Cephfs,Lustre,Moosefs,Lizardfs,商業產品中EMC的isilon,IBM的GPFS等。分佈式檔案儲存適合容器場景,但是性能問題比較突出,主要集中在GlusterFS,CephFS,MooseFS/LizardFS。
這裡簡單對比下開源專案的優缺點,僅供參考。
Local-Disk方案有明顯的缺點,尤其是針對資料庫,大資料類的應用。節點故障後,資料的恢復時間長,對業務影響範圍廣。
傳統NAS也是一種檔案儲存,但是協議網關(機頭)是性能瓶頸,傳統NAS已經跟不上時代發展的潮流。

 

分門別類的評估策略

 

儲存的核心需求是穩定,可靠,可用。無論是開源的儲存專案還是商業的儲存產品,評估方法具有普適性,本文會介紹常見的評估項和評估方法。
資料可靠性
資料可靠性是指資料不丟失的概率。通常情況下,儲存產品會給出幾個9的資料可靠性,或者給出最多允許故障盤/節點個數。評估方式就是暴力拔盤,比如說儲存提供3副本策略,拔任意2塊盤,只要資料不損壞,說明可靠性沒問題。儲存採用不同的資料冗餘策略,提供的可靠性是不一樣的。
資料可用性
資料可用性和資料可靠性很容易被混淆,可用性指的是資料是否在線。比如儲存集群斷電,這段時間資料是不在線,但是資料沒有丟失,集群恢復正常後,資料可以正常訪問。評估可用性的主要方式是拔服務器電源,再有查看儲存的部署組件是否有單點故障的可能。
資料一致性
資料一致性是最難評估的一項,因為大部分場景用戶不知道程式寫了哪些資料,寫到了哪裡。該如何評估資料一致性呢?普通的測試工具可以採用fio開啟crc校驗選項,最好的測試工具就是資料庫。如果發生了資料不一致的情況,資料庫要麼起不來,要麼表資料不對。具體的測試用例還要細細斟酌。
儲存性能
儲存的性能測試很有講究,塊儲存和檔案儲存的側重點也不一樣。
塊儲存
fio/iozone是兩個典型的測試工具,重點測試IOPS,延遲和帶寬。以fio為例,測試命令如下:
  1. fio -filename=/dev/sdc -iodepth=${iodepth} -direct=1 -bs=${bs} -size=100% --rw=${iotype} -thread -time_based -runtime=600 -ioengine=${ioengine} -group_reporting -name=fioTest
關註幾個主要引數:iodepth,bs,rw和ioengine。
測試IOPS,iodepth=32/64/128,bs=4k/8k,rw=randread/randwrite,ioengine=libaio
測試延遲,iodepth=1,bs=4k/8k,rw=randread/randwrite,ioengine=sync
測試帶寬,iodepth=32/64/128,bs=512k/1m,rw=read/write,ioengine=libaio
檔案儲存
fio/vdbench/mdtest是測試檔案系統常用的工具,fio/vdbench用來評估IOPS,延遲和帶寬,mdtest評估檔案系統元資料性能。以fio和mdtest為例,測試命令如下:
  1. fio -filename=/mnt/yrfs/fio.test -iodepth=1 -direct=1 -bs=${bs} -size=500G --rw=${iotype} -numjobs=${numjobs} -time_based -runtime=600 -ioengine=sync -group_reporting -name=fioTest
與塊儲存的測試引數有一個很大區別,就是ioengine都是用的sync,用numjobs替換iodepth。
測試IOPS,bs=4k/8k,rw=randread/randwrite,numjobs=32/64
測試延遲,bs=4k/8k,rw=randread/randwrite,numjobs=1
測試帶寬,bs=512k/1m,rw=read/write,numjobs=32/64
mdtest是專門針對檔案系統元資料性能的測試工具,主要測試指標是creation和stat,需要採用mpirun併發測試:
  1. mpirun --allow-run-as-root -mca btl_openib_allow_ib 1 -host yanrong-node0:${slots},yanrong-node1:${slots},yanrong-node2:${slots} -np ${num_procs} mdtest -C -T -d /mnt/yrfs/mdtest -i 1 -I ${files_per_dir} -z 2 -b 8 -L -F -r -u
儲存性能測試不僅僅測試集群正常場景下的指標,還要包含其他場景:
  1. 儲存容量在70%以上或者檔案數量上億的性能指標

  2. 節點/磁盤故障後的性能指標

  3. 擴容過程時的性能指標

 
容器儲存功能
除了儲存的核心功能(高可靠/高可用/高性能),對於容器儲存,還需要幾個額外的功能保證生產環境的穩定可用。
  1. Flexvolume/CSI接口的支持,動態/靜態PV的支持

  2. 儲存配額。對於Kubernetes的管理員來說,儲存的配額是必須的,否則儲存的使用空間會處於不可控狀態

  3. 服務質量(QoS)。如果沒有QoS,儲存管理員只能期望儲存提供其他監控指標,以保證在集群超負荷時,找出罪魁禍首

萬變不離其宗的選擇

 

Kubernetes持久化儲存方案的重點在儲存和容器支持上。因此首要考慮儲存的核心功能和容器的場景支持。綜合本文所述,將選擇項按優先級列舉:
  1. 儲存的三大核心,高可靠,高可用和高性能

  2. 業務場景,選擇分佈式檔案儲存

  3. 擴展性,儲存能橫向擴展,應對業務增長需求

  4. 可運維性,儲存的運維難度不亞於儲存的開發,選擇運維便捷儲存產品

  5. 成本

Q&A;

 

Q:你好,我們公司採用GlusterFS儲存,掛載三塊盤,現在遇到高併發寫小檔案(4KB)吞吐量上不去(5MB/S),請問有什麼比較好的監控工具或方法麽?謝謝!
A:GlusterFS本身對小檔案就很不友好,GlusterFS是針對備份場景設計的,不建議用在小檔案場景,如果可以的話,要麼程式做優化進行小檔案合併,要麼選用高性能的分佈式檔案儲存,建議看看Lustre或者YRCloudFile。
Q:你好,目前開源在用Rook部署Ceph,Ceph對於塊設備儲存性能如何?可以提升嗎?未來?
A:我們最近也在關註Rook專案,Rook的理念是很好的,但是現在Rook就是Ceph的封裝,把Ceph跑到容器中,復用Kubernetes的監控平臺。而Ceph的運維複雜度很高,以目前的做法,專案想要做好,難度會非常大。
 
Q:我看您推薦分佈式檔案儲存,檔案系統能滿足資料庫應用的需求嗎?塊儲存會不會好一些?
A:首先,我推薦的是高性能分佈式檔案系統。資料庫一般對延遲都比較敏感,普通的萬兆網絡+HDD肯定不行,需要採用SSD,一般能將延遲穩定在毫秒以內,通常能夠滿足要求。如果對延遲有特別要求,可以採用NVMe + RoCE的方案,即使在大壓力下,延遲也能穩定在300微秒以內。
Q:請問為什麼說塊儲存不支持RWX?RWX就是指多個節點同時掛載同一塊塊設備並同時讀寫嗎?很多FC儲存都可以做到。
A:傳統的SAN要支持RWX,需要ALUA機制,而且這是塊級別的多讀寫,如果要再加上檔案系統,是沒辦法做到的,這需要分佈式檔案系統來做檔案元資料信息同步。
Q:請問現在的Kubernetes環境下,海量小檔案RWX場景,有什麼相對比較好的開源分佈式儲存解決方案麽?
A:開源的分佈式檔案儲存專案中,沒有能解決海量小檔案的,我在文中已經將主流開源檔案系統都分析了一遍,在設計之初,都是針對備份場景或者HPC領域。
Q:請問,為什麼說Ceph性能不好,有依據嗎?
A:直接用資料說話,我們用NVMe + Ceph + Bluestore測試出來的,延遲在毫秒級以上,而且很不穩定,我們用YRCloudFile + NVMe + RoCE,延遲能50微秒左右,差了幾十倍。
Q:Lustre沒接觸過,性能好嗎,和Ceph有對比過嗎?
A:網上有很多Lustre的性能指標,在同樣的配置下,性能絕對要比Ceph好,不過Lustre全部都是內核態的,容器場景沒辦法用,而且按照部署以及運維難度非常大。Lustre在超算用的比較廣泛。
Q:Lustre只能靠本地磁盤陣列來保證資料冗餘麽?
A:Lustre本身不提供冗餘機制,都是靠本地陣列的,不過EC好像已經在開發計劃中了。
Q:(對於小公司)如果不選用商業儲存,那麼推薦哪款開源實現作為生產儲存(可靠,高性能)。我們之前試了NFS發現速度不穩定?
A:國內還是有很多創業公司,也不貴的。儲存不像其他專案,儲存經不起折騰,一定要用穩定可靠的,Ceph/GlusterFS做了這麼久,大家在採購的時候,還是會依托於某家商業公司來做,自己生產環境用開源專案,風險太大了。
Q:GPFS用來做Kubernetes的PV,性能怎麼樣?
A:用GPFS的話,性能還是有一定保障的,不過GPFS跟Lustre一樣,都是帶著陣列一起賣的,很貴。

赞(0)

分享創造快樂