干貨 | 如何評估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為例，測試命令如下：

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：我看您推薦分布式文件存儲，文件系統能滿足數據庫應用的需求嗎？塊存儲會不會好一些？
A：首先，我推薦的是高性能分布式文件系統。數據庫一般對延遲都比較敏感，普通的萬兆網絡+HDD肯定不行，需要采用SSD，一般能將延遲穩定在毫秒以內，通常能夠滿足要求。如果對延遲有特別要求，可以采用NVMe + RoCE的方案，即使在大壓力下，延遲也能穩定在300微秒以內。

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做了這么久，大家在采購的時候，還是會依托于某家商業公司來做，自己生產環境用開源項目，風險太大了。

以上內容根據2019年1月10日晚微信群分享內容整理。分享人張文濤，北京焱融科技存儲架構師，負責容器存儲產品的架構設計和研發。

關于焱融云

焱融云是一家以軟件定義存儲技術為核心競爭力的高新技術企業，在分布式存儲等關鍵技術上擁有自主知識產權，是高性能分布式存儲解決方案的行業領導者。針對各行業業務特性，打造個性化行業解決方案，提供一站式的產品與服務。焱融云系列產品已服務于金融、政府、制造業、互聯網等行業的眾多客戶。了解更多焱融科技信息，請訪問官網http://www.yanrongyun.com。