DockOne微信分享(一九九):如何評估Kubernetes持久化存儲方案

收藏待读

DockOne微信分享(一九九):如何評估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方式如下:

DockOne微信分享(一九九):如何評估Kubernetes持久化存儲方案

動態PV需要引入StorageClass的概念,使用方式如下:

DockOne微信分享(一九九):如何評估Kubernetes持久化存儲方案

社區列舉出PersistentVolume的in-tree Plugin,如下圖所示。從圖中可以看到,Kubernetes通過訪問模式給存儲分為三大類,RWO/ROX/RWX。這種分類將原有的存儲概念混淆,其中包含存儲協議,存儲開源產品,存儲商業產品,公有雲存儲產品等等。

DockOne微信分享(一九九):如何評估Kubernetes持久化存儲方案

如何將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。

這裡簡單對比下開源項目的優缺點,僅供參考。

DockOne微信分享(一九九):如何評估Kubernetes持久化存儲方案

Local-Disk方案有明顯的缺點,尤其是針對數據庫,大數據類的應用。節點故障後,數據的恢復時間長,對業務影響範圍廣。

傳統NAS也是一種文件存儲,但是協議網關(機頭)是性能瓶頸,傳統NAS已經跟不上時代發展的潮流。

分門別類的評估策略

存儲的核心需求是穩定,可靠,可用。無論是開源的存儲項目還是商業的存儲產品,評估方法具有普適性,本文會介紹常見的評估項和評估方法。

數據可靠性

數據可靠性是指數據不丟失的概率。通常情況下,存儲產品會給出幾個9的數據可靠性,或者給出最多允許故障盤/節點個數。評估方式就是暴力拔盤,比如說存儲提供3副本策略,拔任意2塊盤,只要數據不損壞,說明可靠性沒問題。存儲採用不同的數據冗餘策略,提供的可靠性是不一樣的。

數據可用性

數據可用性和數據可靠性很容易被混淆,可用性指的是數據是否在線。比如存儲集群斷電,這段時間數據是不在線,但是數據沒有丟失,集群恢復正常後,數據可以正常訪問。評估可用性的主要方式是拔服務器電源,再有查看存儲的部署組件是否有單點故障的可能。

數據一致性

數據一致性是最難評估的一項,因為大部分場景用戶不知道程序寫了哪些數據,寫到了哪裡。該如何評估數據一致性呢?普通的測試工具可以採用fio開啟crc校驗選項,最好的測試工具就是數據庫。如果發生了數據不一致的情況,數據庫要麼起不來,要麼表數據不對。具體的測試用例還要細細斟酌。

存儲性能

存儲的性能測試很有講究,塊存儲和文件存儲的側重點也不一樣。

塊存儲

fio/iozone是兩個典型的測試工具,重點測試IOPS,延遲和帶寬。以fio為例,測試命令如下:

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為例,測試命令如下:

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並發測試:

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:我們用的是Ceph分佈式存儲,目前有一個場景是客戶視頻存儲,而對於持續的寫入小文件存在丟幀的現象,經過我們系統級別和底層文件系統調優,加上Ceph參數的設置,勉強性能得改善,但是數據量上來性能會如何也不得而知道了(經過客戶裸盤測試,前面用軟RAID方式性能還是可以)請問在這方面你有什麼建議么?謝謝!我們客戶是在特殊的場景下,屬於特定機型,而且是5400的sata盤!rbd塊存儲!還有一個現象就是磁盤利用率不均,這也是影響性能的一個人原因,即便我們在調pg數,也會有這個問題。在額外請教一個問題,bcache可以用內存做緩存么?FlushCache相比,這兩個哪個會更好一點?

A:您用的是CephFS還是rbdc因為Ceph在性能上缺失做的還不夠,有很多隊列,導致延遲很不穩定,這個時候,只能忍了,不過還是建議用Bcache做一層緩存,可以有效緩解性能問題。Crush算法雖然比一致性hash要好很多,但是因為沒有元數據,還是很難控制磁盤熱點問題。FlushCache已經沒有人維護了,Bcache還有團隊在維護,所以如果自己沒有能力,就選用Bcache。

Q:你好,目前開源在用Rook部署Ceph,Ceph對於塊設備存儲性能如何?可以提升嗎?未來?

A:我們最近也在關注Rook項目,Rook的理念是很好的,但是現在Rook就是Ceph的封裝,把Ceph跑到容器中,復用Kubernetes的監控平台。而Ceph的運維複雜度很高,以目前的做法,項目想要做好,難度會非常大。

Q:我看您推薦分佈式文件存儲,文件系統能滿足數據庫應用的需求嗎?塊存儲會不會好一些?

A:首先,我推薦的是高性能分佈式文件系統。數據庫一般對延遲都比較敏感,普通的萬兆網絡+HDD肯定不行,需要採用SSD,一般能將延遲穩定在毫秒以內,通常能夠滿足要求。如果對延遲有特別要求,可以採用NVMe + RoCE的方案,即使在大壓力下,延遲也能穩定在300微秒以內。

Q:您用的分佈式文件存儲,不同用戶間如何隔離?

A:分佈式文件系統有ACL權限控制,也可以加AD/LDAP

Q:請問為什麼說塊存儲不支持RWX?RWX就是指多個節點同時掛載同一塊塊設備並同時讀寫嗎?很多FC存儲都可以做到。

A:傳統的SAN要支持RWX,需要ALUA機制,而且這是塊級別的多讀寫,如果要再加上文件系統,是沒辦法做到的,這需要分佈式文件系統來做文件元數據信息同步。

Q:傳統SAN支持對同一數據塊的並行讀寫,很多AA陣列都不是用ALUA的,而是多條路徑同時有IO,當然要用到多路徑軟件。相反用ALUA的不是AA陣列。

A:AA陣列解決的是高可用問題,對同一個lun的並發讀寫,需要trunk級的鎖去保證數據一致性,性能不好。

Q:的很多傳統商業存儲,包括塊存儲,也都做了CSI相關的插件,是不是如果在容器里跑一些性能要求高的業務,這些商業的塊存儲比文件存儲合適?

A:生產環境中,我強烈建議選用商業存儲。至於塊存儲還是文件存儲,要看您的業務場景。首選是商業的文件存儲。

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一樣,都是帶着陣列一起賣的,很貴。

以上內容根據2019年1月10日晚微信群分享內容整理。分享人 張文濤,北京焱融科技存儲架構師,負責容器存儲產品的架構設計和研發 。DockOne每周都會組織定向的技術分享,歡迎感興趣的同學加微信:liyingjiesd,進群參與,您有想聽的話題或者想分享的話題都可以給我們留言。

原文 : DockOne

相關閱讀

免责声明:本文内容来源于DockOne,已注明原文出处和链接,文章观点不代表立场,如若侵犯到您的权益,或涉不实谣言,敬请向我们提出检举。