云原生的開源分布式文件系統(tǒng)及應(yīng)用實踐

1、ChubaoFS：云原生的開源分布式文件系統(tǒng)及應(yīng)用實踐目錄云原生應(yīng)用存儲現(xiàn)狀ChubaoFS帶來的變革架構(gòu)設(shè)計典型應(yīng)用支撐實踐云原生社區(qū)現(xiàn)狀后續(xù)工作及收益云原生應(yīng)用存儲現(xiàn)狀本地文件系統(tǒng)需要POSIX語義并且對性能要求比較高的應(yīng)用，目前很多會采用本地文件系統(tǒng)，原因是POSIX語義在性能上并不適合分布式系統(tǒng)應(yīng)用容器的調(diào)度被局限在特定的物理節(jié)點，物理節(jié)點故障需要數(shù)據(jù)遷移，與云原生的 理念背道而馳如果應(yīng)用需要高可用，需要自己來做Replication和Failover容量受到局限，擴容較復(fù)雜生態(tài)強相關(guān)的分布式文件系統(tǒng)如Hbase+HDFS需要給特定應(yīng)用單獨部署集群，資源使用率較低云原生應(yīng)用存儲現(xiàn)狀Co

2、ntd對象存儲應(yīng)用需要使用對象存儲接口，一般自研應(yīng)用使用較多，一些傳統(tǒng)的數(shù)據(jù)庫應(yīng)用無法使用，如數(shù)據(jù)庫備份場景不適合順序追加寫的場景，追加需要讀取整個blob分布式塊存儲應(yīng)用使用塊存儲接口的開發(fā)成本較高，一般自研應(yīng)用使用較少云原生應(yīng)用存儲現(xiàn)狀Contd為什么不用通用分布式文件系統(tǒng)設(shè)計復(fù)雜，運維難度高，需要專業(yè)的運維團隊大文件順序讀寫性能較好，但是對于小文件的支持較差高并發(fā)的元數(shù)據(jù)操作會有熱點問題多租戶的支持較差，提供基礎(chǔ)設(shè)施的部門經(jīng)常需要給每個大的業(yè)務(wù)方部署單獨集群POSIX語義并不適合分布式系統(tǒng)，性能成為瓶頸ChubaoFS帶來的變革設(shè)計理念在資源有限的情況下（存儲介質(zhì)、網(wǎng)絡(luò)等），tradeo

3、ff妥協(xié)是不可避免的，評判標(biāo)準(zhǔn)是滿足上層業(yè)務(wù)的需求保持簡單設(shè)計 - 系統(tǒng)穩(wěn)定性提高 - 運維負(fù)擔(dān)降低允許業(yè)務(wù)方bluffingChubaoFS帶來的變革 應(yīng)用層面應(yīng)用無狀態(tài)化客戶端基于FUSE框架，使用掛載的方式，提供POSIX文件系統(tǒng)接口使用本地文件系統(tǒng)的應(yīng)用可以平滑遷移到ChubaoFS分布式文件系統(tǒng)云原生應(yīng)用調(diào)度不再受物理節(jié)點限制，真正體現(xiàn)cloud native可靠的分布式文件系統(tǒng)性能盡可能遵循POSIX語義，以滿足應(yīng)用需求為準(zhǔn)，例如，Hbase，MySQL，Elasticsearch，TensorFlow，Spark等常見應(yīng)用均可直接跑在ChubaoFS上支持跨客戶端寫同一個文件不同

4、位置，但是寫相同位置沒有明確定義不支持跨節(jié)點客戶端的O_APPEND寫請求ChubaoFS帶來的變革- 應(yīng)用層面Contd可擴展性理論上容量可以無限擴容，應(yīng)用無需關(guān)注存儲資源高可用應(yīng)用不需要考慮高可用性，專注于業(yè)務(wù)即可ChubaoFS帶來的變革 基礎(chǔ)設(shè)施層面統(tǒng)一存儲資源替換本地文件系統(tǒng)，及傳統(tǒng)的分布式文件系統(tǒng)，CephFS，MooseFS，GlusterFS，HDFS等，無需單獨部署集群集群支持多租戶，不同應(yīng)用共享存儲資源，提高資源利用率運維簡單所有管理命令均可通過Http請求完成，無需專業(yè)的運維團隊架構(gòu)設(shè)計框架集群由若干data nodes組成（物理）每個data node包含若干parti

5、tions（邏輯）每個partition包含若干extent file大小文件構(gòu)成大文件由多個extent組成小文件聚合至預(yù)分配extent小文件刪除使用punch hole復(fù)制協(xié)議順序?qū)?primary-backup protocol覆蓋寫 multi-raft protocol架構(gòu)設(shè)計- Data SubsystemDistributed in-memory storage for meta data復(fù)制協(xié)議使用multi-raft元數(shù)據(jù)持久化由Raft日志及snapshot保證所有元數(shù)據(jù)緩存在內(nèi)存中框架集群由若干meta nodes組成meta nodes包含若干partitions每個

6、partition由三臺nodes組成Raft復(fù)制組應(yīng)對高并發(fā)及大量小文件操作inode不局限于父目錄所在的partition允許存在inode無對應(yīng)dentry，不允許存在dentry無對應(yīng)inode架構(gòu)設(shè)計- Meta SubsystemSpark on ChubaoFS現(xiàn)狀目前業(yè)界普遍的觀點是，出于性能考慮，原生Spark不能直接使用分布式文件系統(tǒng)， 一般使用本地文件系統(tǒng)。Spark應(yīng)用運行在容器中，被Kubernetes調(diào)度時，會有局限性基礎(chǔ)設(shè)施部門也無法預(yù)知需要提供多少存儲資源，造成資源利用率降低Spark應(yīng)用如果使用分布式文件系統(tǒng)，一般會接external shuffle serv

7、ice模塊，增加 開發(fā)成本真的沒有辦法嗎？通過分析shuffle讀寫模型發(fā)現(xiàn)兩個特點：順序?qū)?，且write/fsync比率較高；任務(wù)中 寫入的數(shù)據(jù)較短時間內(nèi)會被再次讀到。Spark on ChubaoFS Contd使能FUSE writeback feature，調(diào)整一些Spark參數(shù)，ChubaoFS完全可以達到與本 地文件系統(tǒng)接近的性能真實Spark業(yè)務(wù)及TeraSort均有測試ElasticSearch on ChubaoFS現(xiàn)狀大部分都在使用本地文件系統(tǒng)容器集群中，造成資源利用率低，且不容易擴容替代本地文件系統(tǒng)同等存儲介質(zhì)條件下（SSD，SAS/SATA HDD），TPS是本地文件系

8、統(tǒng)的80%左右， 考慮到使用分布式存儲的巨大收益，性能在業(yè)務(wù)方接受范圍內(nèi)動態(tài)擴容，無需關(guān)注容量資源零副本，高可用由分布式文件系統(tǒng)保證云原生社區(qū)現(xiàn)狀 開發(fā)相關(guān)Kubernetes CSI driver支持Container Storage Interface Spec v0.3 和 v1.0可以PV/PVC方式使用ChubaoFS避免容器中的mount操作，更好的安全性，因為mount操作需要容器privileged啟動與應(yīng)用的容器隔離，避免用戶態(tài)客戶端進程被誤殺動態(tài)創(chuàng)建刪除Volume，無需提前靜態(tài)創(chuàng)建風(fēng)險：每個Volume都在宿主機有掛載點，目前Kubernetes在調(diào)度時并未考慮掛載數(shù)量

9、這一因素，有可能造成某個物理節(jié)點掛載過多Helm/Operator (WIP)進一步簡化server端的部署和運維云原生社區(qū)現(xiàn)狀 社區(qū)相關(guān)CNCF社區(qū)CNCF Landscape，cf.io/selected=chubao-fsCNCF Storage SIG audit（done）Preparing TOC Sandbox presentation前景展望分布式文件系統(tǒng)在云原生社區(qū)的應(yīng)用并不廣泛，目標(biāo)是通過更加中立和開放的平臺CNCF， 改變大家對于分布式文件系統(tǒng)的固有印象，為云原生應(yīng)用選擇存儲方案時提供更多選擇OpenSDS/SODA社區(qū)ChubaoFS filesystem driver合入主干后續(xù)工作及收益支持部分對象存儲接口協(xié)議打通文件系統(tǒng)和對象存儲，一份數(shù)據(jù)可以通過兩種協(xié)議訪問Erasure Coding冷數(shù)據(jù)備份場景下，可以使用EC volume，進一步節(jié)省存儲資源詳細(xì)開發(fā)任務(wù)列表/chubaofs/chubaofs/projects/1Misc開源 /chubaofs/chubaofsApache 2.0Haifeng Liu, et al., CFS: A Distr