歡迎光臨
每天分享高質量文章
當前位置：知識星球 > 後端 > 正文

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

2019-01-16 分類：後端 閱讀(451) 評論(0)

在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)
標籤：

相關推薦

熱門標籤

iOS (11238)微軟 (4955)Linux (4274)安全 (4180)Python (4161)效能 (3165)運維 (2774)最佳化 (2419).NET (2262)Google (2136)機器學習 (1795)併發 (1613)分散式 (1559)叢集 (1240)SQL (1174)Mysql (1060)區塊鏈 (1017)Docker (977)微服務 (922)面試 (919)Apache (743)NLP (725)Redis (719)Android (668)Git (640)架構師 (632)Nginx (630)Facebook (599)JVM (595)爬蟲 (476)

熱門文章

分享創造快樂