拿到kata container virtiofs這個(gè)測(cè)試任務(wù)時(shí)我的第一反應(yīng)是終于不用再跟9p那套共享存儲(chǔ)死磕了。之前線上跑Kata容器凡是涉及掛載宿主機(jī)目錄的場(chǎng)景基本都踩過9p的坑幾百個(gè)文件的編譯任務(wù)能卡到懷疑人生Java進(jìn)程在共享盤上起不來mmap相關(guān)調(diào)用要么報(bào)錯(cuò)要么性能慘不忍睹。這次virtiofs從原理到壓測(cè)完整跑了一遍中間還撞了幾個(gè)比較隱蔽的穩(wěn)定性問題整理成這篇技術(shù)分析給正在做Kata容器存儲(chǔ)選型的同學(xué)一個(gè)參考。這篇文章不是簡(jiǎn)單夸virtiofs有多快而是把測(cè)試方案、結(jié)果數(shù)據(jù)、原理拆解和踩坑記錄都攤開講。適合正好在調(diào)Kata運(yùn)行時(shí)、計(jì)劃把hostPath遷移到virtiofs、或者在考慮容器和虛擬機(jī)混合存儲(chǔ)方案的工程師。1. 為什么Kata Containers的共享存儲(chǔ)會(huì)選virtiofs從9p的痛點(diǎn)說起1.1 Kata的存儲(chǔ)路徑到底特殊在哪Kata Containers的本質(zhì)是用輕量虛擬機(jī)隔離容器每個(gè)Pod其實(shí)是一個(gè)小虛擬機(jī)有自己的內(nèi)核。這個(gè)設(shè)計(jì)帶來一個(gè)很直接的問題宿主機(jī)目錄要怎么讓虛擬機(jī)里的進(jìn)程看到。普通容器比如純r(jià)unc靠Linux內(nèi)核共享文件系統(tǒng)層namespace一切目錄直接掛進(jìn)來性能接近本地盤。Kata不行它和宿主機(jī)之間的邊界是虛擬化層文件系統(tǒng)必須穿過這條邊界。早期方案是9p九號(hào)項(xiàng)目文件協(xié)議在QEMU里做了個(gè)fsdev后端Kata這邊作為客戶端掛載。聽起來不難對(duì)吧但實(shí)際用起來凡是正經(jīng)業(yè)務(wù)負(fù)載9p幾乎都能把性能打崩。我把線上幾個(gè)真實(shí)案例搬過來測(cè)試問題立刻暴露。1.2 9p的三大痛點(diǎn)mmap、協(xié)議棧、元數(shù)據(jù)先說mmap。Java服務(wù)、Node.js、Nginx這類進(jìn)程對(duì)mmap依賴很重比如JVM加載jar包、共享內(nèi)存映射。9p的mmap實(shí)現(xiàn)沒有真正的內(nèi)存映射底層是靠read/write系統(tǒng)調(diào)用模擬的也就是說每次page fault都要向host發(fā)起一輪完整請(qǐng)求。線上Java應(yīng)用在9p共享盤上偶發(fā)卡頓壓測(cè)時(shí)直接出現(xiàn)長(zhǎng)時(shí)間停頓這本身就是不可接受的。再就是協(xié)議開銷。9p是傳統(tǒng)的request/response模型每個(gè)操作在guest內(nèi)核、QEMU進(jìn)程、host VFS之間來回穿梭。單次操作的延遲比本地文件系統(tǒng)高一個(gè)量級(jí)一旦并發(fā)量上來guest側(cè)的內(nèi)核線程和QEMU進(jìn)程的CPU就會(huì)被協(xié)議處理占滿吞吐上不去。最致命的是元數(shù)據(jù)操作。創(chuàng)建、刪除、stat、readdir這些小文件場(chǎng)景9p基本暴露全部缺陷。我這邊跑過一個(gè)簡(jiǎn)單的編譯模擬測(cè)試創(chuàng)建一萬個(gè)小文件再逐個(gè)stat9p用了將近三分鐘本地盤不到兩秒。這種差距已經(jīng)不屬于調(diào)優(yōu)能解決的范疇是協(xié)議和應(yīng)用場(chǎng)景不匹配。1.3 virtiofs的方向轉(zhuǎn)變從通用協(xié)議到專用虛擬設(shè)備virtiofs和9p最大的區(qū)別在于它不再把自己當(dāng)成一個(gè)通用網(wǎng)絡(luò)文件系統(tǒng)來設(shè)計(jì)而是專門為“宿主機(jī)和虛擬機(jī)之間共享文件”這個(gè)場(chǎng)景定制的虛擬設(shè)備。它走的是virtio設(shè)備框架guest里有一個(gè)內(nèi)核驅(qū)動(dòng)通過virtqueue和QEMU通信。文件操作請(qǐng)求采用FUSE協(xié)議格式但不需要經(jīng)過/dev/fuse設(shè)備而是直接由內(nèi)核模塊對(duì)接virtqueue。host側(cè)則由一個(gè)用戶態(tài)守護(hù)進(jìn)程virtiofsd來接收請(qǐng)求轉(zhuǎn)換成普通的Linux系統(tǒng)調(diào)用訪問宿主機(jī)文件系統(tǒng)。這個(gè)架構(gòu)上的改變把原來QEMU進(jìn)程內(nèi)的協(xié)議處理拆出來了。virtiofsd可以獨(dú)立調(diào)度、獨(dú)立調(diào)優(yōu)而且DAX直通能力也是在virtio框架下才有空間實(shí)現(xiàn)。9p是給Plan 9遺產(chǎn)做的通用文件協(xié)議virtiofs則是給虛擬化場(chǎng)景專門畫的一條新賽道。從Kata 2.x開始默認(rèn)把shared_fs切到virtiofs不是沒有道理的。2. virtiofs的核心機(jī)制拆解DAX緩存與FUSE協(xié)議的配合邏輯2.1 FUSE協(xié)議在virtiofs里被重新實(shí)現(xiàn)了一遍很多人以為virtiofs就是“虛擬機(jī)里掛了個(gè)FUSE”這個(gè)理解不夠準(zhǔn)確。標(biāo)準(zhǔn)FUSE的路徑是用戶態(tài)進(jìn)程 - /dev/fuse - 內(nèi)核FUSE模塊 - 用戶態(tài)daemon。virtiofs把這條鏈路簡(jiǎn)化了guest內(nèi)核的virtio_fs驅(qū)動(dòng)直接扮演FUSE模塊的角色請(qǐng)求封裝成FUSE消息格式通過virtqueue直接發(fā)給host的virtiofsd。這樣做的好處是省掉了一層字符設(shè)備和用戶態(tài)上下文切換。FUSE消息結(jié)構(gòu)本身已經(jīng)被大量文件系統(tǒng)驗(yàn)證過協(xié)議字段齊全特別適合做文件語義的精細(xì)化控制比如lookup緩存、屬性超時(shí)、目錄項(xiàng)的負(fù)緩存。virtiofsd收到請(qǐng)求后翻譯成open、read、write、getattr、readdir這些系統(tǒng)調(diào)用命中宿主機(jī)的VFS和page cache。所以從功能視角看guest里的文件系統(tǒng)體驗(yàn)非常接近本地文件系統(tǒng)從性能視角看合理的緩存策略下很多操作根本不需要穿透到host在guest內(nèi)就能完成。2.2 DAX window為什么能繞開guest page cache這是virtiofs最有技術(shù)含量的部分。普通文件共享路徑里guest讀文件時(shí)數(shù)據(jù)要經(jīng)過guest page cache - virtqueue - QEMU內(nèi)存拷貝 - virtiofsd - host VFS - host page cache。每一層都有開銷尤其是大塊數(shù)據(jù)傳輸內(nèi)存拷貝和CPU占用非?？捎^。DAXDirect Access的思路是在虛擬機(jī)地址空間里開辟一塊PCI BAR窗口把host端文件頁直接映射進(jìn)去。guest里的進(jìn)程mmap一個(gè)virtiofs文件時(shí)內(nèi)核可以把guest物理地址直接映射到這塊BAR區(qū)域CPU訪問它就像訪問普通內(nèi)存一樣。真正讀到的其實(shí)是host page cache里的文件頁寫的時(shí)候也直接寫進(jìn)host page cache。整條鏈路省掉了virtqueue通信和QEMU內(nèi)部的拷貝動(dòng)作。當(dāng)然DAX不是萬能的。窗口大小是有限資源由Kata配置里的virtio_fs_cache_size控制映射以2MB大頁粒度對(duì)齊文件多而碎的時(shí)候很可能把窗口耗盡。窗口耗盡后virtiofs會(huì)回退到普通virtqueue路徑性能斷崖下跌。我后面壓測(cè)的時(shí)候就真實(shí)遇到了這個(gè)問題一會(huì)兒細(xì)說。2.3 cache三檔到底怎么選none、auto、alwaysvirtiofs的緩存策略直接決定數(shù)據(jù)一致性和性能表現(xiàn)生產(chǎn)環(huán)境不能只開一個(gè)默認(rèn)值完事。cachenone是所有讀寫都穿透到hostguest不持有page cache。語義最強(qiáng)性能最差適合數(shù)據(jù)庫、分布式存儲(chǔ)這類絕對(duì)不能讀到舊數(shù)據(jù)的場(chǎng)景。cacheauto是Kata的默認(rèn)策略guest可以緩存文件和目錄的屬性以及目錄項(xiàng)但文件數(shù)據(jù)還是要走h(yuǎn)ost。它引入了attr超時(shí)機(jī)制定期向host校驗(yàn)文件變化類似NFS的attribute cache行為。大多數(shù)配置類、日志類共享目錄用auto就夠了。cachealways則是最大緩存策略guest對(duì)文件數(shù)據(jù)和元數(shù)據(jù)都全面緩存寫回延遲交給guest內(nèi)核管理。性能最好但多客戶端共享同一文件時(shí)一致性風(fēng)險(xiǎn)很高。我通常只建議用在單寫多讀、只讀共享這類場(chǎng)景。選擇策略時(shí)記住一句話緩存放guest性能好但一致性弱緩存放host一致性穩(wěn)但性能回調(diào)。沒有絕對(duì)最優(yōu)要按目錄用途拆分掛載。3. 測(cè)試環(huán)境與測(cè)試矩陣設(shè)計(jì)不能只看帶寬和IOPS3.1 壓測(cè)環(huán)境說明我這次測(cè)試用的是一臺(tái)x86服務(wù)器32核、128G內(nèi)存系統(tǒng)盤和數(shù)據(jù)盤都是NVMe SSD。宿主機(jī)內(nèi)核版本5.15系列Kata Containers版本跑過2.4.x和2.5.x兩代QEMU用的7.x系列。普通容器對(duì)照組直接跑在宿主機(jī)上。測(cè)試方式是用Kata拉起一個(gè)完整的容器在里面掛載virtiofs共享目錄然后跑各類基準(zhǔn)和模擬負(fù)載。對(duì)照組則把Kata的shared_fs切回9p同樣基準(zhǔn)再跑一遍。最后還有一個(gè)本地盤的基準(zhǔn)值作為底限參照。這個(gè)環(huán)境不算特殊理論上能在大部分主流服務(wù)器上復(fù)現(xiàn)。3.2 為什么拒絕只跑fio如果只跑fio的順序讀、順序?qū)憊irtiofs和9p的差距并不會(huì)顯得特別夸張因?yàn)轫樞騃O更多受限于設(shè)備本身。真實(shí)業(yè)務(wù)里共享目錄的痛點(diǎn)基本都在隨機(jī)小文件、元數(shù)據(jù)操作和應(yīng)用對(duì)mmap的依賴上這些恰好在純fio簡(jiǎn)單模式下會(huì)被掩蓋。所以我設(shè)計(jì)了九個(gè)場(chǎng)景覆蓋典型業(yè)務(wù)負(fù)載方向大文件順序讀寫、4K隨機(jī)讀寫、元數(shù)據(jù)密集操作、小文件并發(fā)創(chuàng)建刪除、mmap隨機(jī)訪問、帶fsync的數(shù)據(jù)庫模擬、多線程混合讀寫、跨容器同目錄并發(fā)訪問、git倉庫和代碼編譯這種高頻小IO場(chǎng)景。每個(gè)場(chǎng)景都有明確的工具、指標(biāo)和模擬目標(biāo)。工具方面用了fio做塊IO和混合負(fù)載sysbench做文件IO模擬git和編譯任務(wù)模擬真實(shí)開發(fā)場(chǎng)景Python腳本控制小文件并發(fā)。指標(biāo)不只記錄帶寬和IOPS還記錄了P99延遲、CPU占用率、耗時(shí)總量因?yàn)樯a(chǎn)上更關(guān)心長(zhǎng)尾延遲。3.3 Kata配置改動(dòng)細(xì)節(jié)在Kata的configuration.toml里核心配置就三塊shared_fs virtio-fs virtio_fs_cache_size 8192 virtio_fs_extra_args [-o, cacheauto]shared_fs指定使用virtiofsvirtio_fs_cache_size控制DAX窗口大小單位MBextra_args里可以傳virtiofsd的參數(shù)。對(duì)照組我把shared_fs改回9p即可其他參數(shù)保持不動(dòng)。這里特別提醒一點(diǎn)修改cache策略后Kata需要重啟運(yùn)行時(shí)和Pod才能生效不能熱更新。測(cè)試之前務(wù)必確認(rèn)running Pod已經(jīng)被新配置接管否則結(jié)果會(huì)串。4. 性能實(shí)測(cè)對(duì)比九種場(chǎng)景下virtiofs與9p的真實(shí)差距4.1 結(jié)果總覽virtiofs全面領(lǐng)先但仍不是本地盤所有場(chǎng)景我都以本地盤作為100%基準(zhǔn)對(duì)比9p和virtiofs的表現(xiàn)。表格里的數(shù)據(jù)是我這個(gè)環(huán)境下的實(shí)測(cè)值用來定性和看趨勢(shì)沒問題換到不同硬件會(huì)有浮動(dòng)但比例關(guān)系基本可以參考。測(cè)試場(chǎng)景9p相對(duì)性能virtiofs相對(duì)性能備注順序讀大文件35%88%virtiofs接近本地盤順序?qū)懘笪募?2%64%寫路徑開銷明顯4K隨機(jī)讀9%72%9p災(zāi)難級(jí)表現(xiàn)4K隨機(jī)寫7%41%寫放大問題需關(guān)注元數(shù)據(jù)密集操作3%58%9p基本不可用小文件并發(fā)創(chuàng)建刪除4%52%目錄項(xiàng)緩存有作用mmap隨機(jī)訪問失敗/極慢67%DAX直通效果明顯帶fsync的數(shù)據(jù)庫模擬2%38%fsync是最大瓶頸混合讀寫業(yè)務(wù)負(fù)載12%61%綜合表現(xiàn)參考9p在4K隨機(jī)讀上只有本地盤的9%這解釋了很多線上卡頓。virtiofs在隨機(jī)讀、mmap上表現(xiàn)最好幾乎追上本地盤但隨機(jī)寫和fsync場(chǎng)景還是明顯落后這反映了寫路徑的固有成本。4.2 好消息和壞消息哪些場(chǎng)景能放心用先說好消息。隨機(jī)讀、順序讀、mmap三個(gè)場(chǎng)景virtiofs表現(xiàn)非常接近本地盤尤其是DAX直通模式下讀取大文件幾乎沒有協(xié)議開銷。這類負(fù)載包括代碼目錄共享、模型文件讀取、只讀配置加載、日志歸集讀取直接用virtiofs放心。元數(shù)據(jù)操作方面virtiofs比9p提升了一個(gè)數(shù)量級(jí)。它借助FUSE協(xié)議的屬性緩存和目錄項(xiàng)緩存在cacheauto下表現(xiàn)已經(jīng)可接受。代碼編譯這種大量創(chuàng)建臨時(shí)文件再刪除的場(chǎng)景virtiofs跑下來耗時(shí)大約是本地盤的1.8倍9p則要慢將近二十倍。壞消息集中在寫路徑。順序?qū)懙南鄬?duì)性能只有64%隨機(jī)寫只有41%fsync場(chǎng)景更是掉到38%。寫操作在DAX模式下直接寫host page cachevirtiofsd后續(xù)還要維護(hù)一致性這里面有額外開銷。再加上guest和host兩層page cache寫放大問題在隨機(jī)小寫時(shí)比較明顯。4.3 并發(fā)上去了性能反而掉下來測(cè)試中我特別觀察了并發(fā)線程數(shù)從1逐步增加到32時(shí)的表現(xiàn)。virtiofs在小并發(fā)下表現(xiàn)優(yōu)秀但并發(fā)超過一定閾值后性能曲線先漲后跌出現(xiàn)了明顯的吞吐回退。host側(cè)的virtiofsd進(jìn)程CPU占用率一路上漲最終成為瓶頸。9p在同樣并發(fā)測(cè)試中更慘線程數(shù)即使只有8就出現(xiàn)大量的IO等待整個(gè)容器幾乎卡死。virtiofs至少能撐到更高并發(fā)但也不是無限可擴(kuò)展的。這個(gè)問題在Kata容器密度較高、多個(gè)Pod同時(shí)掛載相同共享目錄時(shí)會(huì)放大。后來排查發(fā)現(xiàn)virtiofsd在較老版本里線程模型是受限的大量并發(fā)請(qǐng)求集中在同一個(gè)工作線程上處理CPU單核跑滿后其余請(qǐng)求全部排隊(duì)。官方后來的實(shí)現(xiàn)逐步改進(jìn)了并發(fā)模型但如果你還在跑老版本壓測(cè)時(shí)最好把并發(fā)摸清楚別被小并發(fā)數(shù)據(jù)迷惑。5. 穩(wěn)定性與異常場(chǎng)景踩坑記錄鎖語義、崩潰恢復(fù)和緩存一致性5.1 多容器同目錄并發(fā)flock能用但寫緩存會(huì)打架測(cè)試時(shí)我用兩個(gè)Kata容器同時(shí)掛載同一宿主目錄通過flock對(duì)同一個(gè)文件做互斥寫。實(shí)測(cè)下來flock在virtiofs上是能工作的因?yàn)関irtiofsd最終在host上以普通文件方式打開文件所有鎖都匯聚到host內(nèi)核處理跨虛擬機(jī)的鎖語義是可靠的。但有個(gè)問題容易踩坑當(dāng)兩個(gè)容器都用cacheauto或always時(shí)guest各自保留文件數(shù)據(jù)緩存。一個(gè)容器寫入數(shù)據(jù)后另一個(gè)容器可能在一段時(shí)間內(nèi)看不到最新內(nèi)容即使鎖已經(jīng)釋放。鎖解決的是寫互斥并不解決緩存刷新。這在分布式任務(wù)共享狀態(tài)文件時(shí)會(huì)帶來詭異問題。我的處理方案是涉及多客戶端讀寫的目錄強(qiáng)制用cachenone寧可比性能也不賭一致性。5.2 fuse request timeout導(dǎo)致的I/O error高并發(fā)壓測(cè)時(shí)guest里偶爾報(bào)出I/O error應(yīng)用直接異常退出。起初以為是磁盤問題后來反復(fù)復(fù)現(xiàn)發(fā)現(xiàn)是FUSE請(qǐng)求超時(shí)機(jī)制在起作用。當(dāng)virtiofsd處理不過來guest發(fā)出的請(qǐng)求長(zhǎng)時(shí)間得不到響應(yīng)guest內(nèi)核FUSE模塊就會(huì)標(biāo)記連接異常并返回EIO。這個(gè)問題的觸發(fā)點(diǎn)有兩個(gè)一是virtiofsd單線程瓶頸二是guest側(cè)請(qǐng)求隊(duì)列積壓。我臨時(shí)把并發(fā)和iodepth降下來才能穩(wěn)定跑完測(cè)試后來調(diào)整了virtiofsd的并發(fā)配置并監(jiān)控host側(cè)CPU才把它壓住。碰到I/O error時(shí)不要急著懷疑文件系統(tǒng)損壞先看host側(cè)virtiofsd進(jìn)程是不是已經(jīng)CPU跑滿再檢查guest內(nèi)核日志里的fuse超時(shí)記錄。有條件的情況下?lián)Q用新版運(yùn)行時(shí)并適當(dāng)增大FUSE超時(shí)配置能有效規(guī)避這類假故障。5.3 mmap MAP_SHARED在業(yè)務(wù)里的真實(shí)表現(xiàn)DAX直通對(duì)mmap的支持是virtiofs相對(duì)9p的最大優(yōu)勢(shì)之一。我在測(cè)試?yán)镉脙蓚€(gè)進(jìn)程共享一個(gè)映射文件做狀態(tài)同步運(yùn)行良好互相修改立即可見性能接近本地共享內(nèi)存映射。但分布式場(chǎng)景下要清醒認(rèn)識(shí)一點(diǎn)mmap寫的數(shù)據(jù)先落在host page cache真正落盤要等host內(nèi)的pdflush機(jī)制觸發(fā)。如果host突然斷電所有落在page cache里但未寫盤的數(shù)據(jù)都會(huì)丟失。9p時(shí)代大家習(xí)慣了慢反而不會(huì)丟太多virtiofs快了數(shù)據(jù)丟失窗口也變大了。數(shù)據(jù)庫和消息隊(duì)列這類數(shù)據(jù)不能丟的組件哪怕virtiofs支持mmap也不建議把數(shù)據(jù)目錄放上來。mmap共享文件做狀態(tài)同步、鎖協(xié)調(diào)這類非關(guān)鍵數(shù)據(jù)場(chǎng)景才是它的正確戰(zhàn)場(chǎng)。5.4 數(shù)據(jù)庫類負(fù)載能跑但別勉強(qiáng)我用sysbench在virtiofs上模擬了數(shù)據(jù)庫IO結(jié)果能跑但絕不驚艷。O_DIRECT支持方面測(cè)試下來virtiofs在打開文件時(shí)會(huì)傳遞對(duì)齊的direct IO請(qǐng)求能正常工作但隨機(jī)寫和fsync的短板仍然存在。數(shù)據(jù)庫的崩潰恢復(fù)高度依賴fsync速度和寫順序這恰好是virtiofs最弱的地方。如果業(yè)務(wù)方堅(jiān)持把MySQL這類組件放到共享目錄我的建議是數(shù)據(jù)目錄用塊存儲(chǔ)或本地盤只有配置文件、臨時(shí)目錄這類非關(guān)鍵數(shù)據(jù)放到virtiofs。拿virtiofs扛數(shù)據(jù)庫性能上去了但可靠性在下降屬于拿核心資產(chǎn)換便利不劃算。6. 生產(chǎn)配置建議與最后的選型邊界6.1 我們線上最終采用的Kata配置經(jīng)歷了這輪測(cè)試后我線上環(huán)境給出了一個(gè)相對(duì)保守但穩(wěn)定的配置方案shared_fs virtio-fs virtio_fs_cache_size 4096 virtio_fs_extra_args [-o, cacheauto]cache選auto保證默認(rèn)情況下元數(shù)據(jù)有緩存文件數(shù)據(jù)由host控制一致性。如果業(yè)務(wù)目錄是單寫多讀而且對(duì)性能有極致要求再單獨(dú)加一份extra_args切換成cachealways。DAX窗口我設(shè)了4G。窗口太大會(huì)占掉guest內(nèi)存地址空間太小在大文件并行讀寫時(shí)很快耗盡回退到普通路徑。4G對(duì)大部分共享目錄已經(jīng)夠用。如果你需要看具體填充情況可以在guest里用mmap映射后觀察后端命中的比例但我實(shí)測(cè)很難拿到準(zhǔn)確數(shù)字更多是靠壓測(cè)判斷窗口是否夠用。6.2 掛載規(guī)劃不同用途目錄用不同策略生產(chǎn)上不建議一個(gè)共享目錄包打天下。我現(xiàn)在的做法是把共享存儲(chǔ)按用途拆成三個(gè)掛載點(diǎn)配置和只讀數(shù)據(jù)用cachealways追求最快的重復(fù)讀。代碼目錄和工作目錄用cacheauto兼顧性能和一致性?？缛萜鲄f(xié)作的狀態(tài)目錄用cachenone保證任何寫入都能被其他消費(fèi)者盡快看到。三種目錄落在相同的物理路徑池里只是掛載參數(shù)不同。這樣拆下來每一類目錄都能在自己的策略下達(dá)到最優(yōu)狀態(tài)也避免了緩存語義互相干擾。6.3 什么場(chǎng)景還是別用virtiofsvirtiofs不是萬能的。數(shù)據(jù)庫數(shù)據(jù)目錄、分布式存儲(chǔ)WAL日志、內(nèi)容尋址存儲(chǔ)的臨時(shí)寫緩沖這幾類對(duì)寫延遲和fsync可靠性要求極高的場(chǎng)景我仍然堅(jiān)持用本地塊設(shè)備或者專門的存儲(chǔ)方案。虛擬化文件共享層天然存在協(xié)議轉(zhuǎn)換和雙緩存無論怎么優(yōu)化都不可能比直通塊設(shè)備更穩(wěn)。同樣如果你需要多個(gè)Kata虛擬機(jī)強(qiáng)一致地共享同一個(gè)文件并且要求實(shí)時(shí)可見virtiofs即使配cachenone也不是最佳選擇。這種場(chǎng)景最好的歸宿仍然是分布式存儲(chǔ)用戶態(tài)協(xié)議或者直接共享塊設(shè)備由guest自己跑文件系統(tǒng)。6.4 測(cè)試過程中值得繼續(xù)深挖的方向virtiofs還在快速演進(jìn)。新的virtiofsd實(shí)現(xiàn)改了線程模型高并發(fā)吞吐相比早期版本有明顯提升。DAX機(jī)制上也有針對(duì)不同文件粒度做單獨(dú)緩存控制的嘗試未來配置會(huì)更靈活。如果后續(xù)還有精力我打算做兩件事一是把virtiofs和宿主機(jī)本地存儲(chǔ)做一層組合只把熱數(shù)據(jù)放共享盤冷數(shù)據(jù)回本地看看能否兼顧共享和性能二是針對(duì)多Kata實(shí)例同時(shí)掛載同一大文件做并發(fā)模式測(cè)試把剛才提到的緩存一致性問題量化成工程指標(biāo)。這兩個(gè)方向弄明白Kata共享存儲(chǔ)這塊就算徹底盤清楚了。寫這篇分析的時(shí)候我回想最開始被9p折磨的日子還是要感慨一句virtiofs出現(xiàn)之后Kata Container的共享目錄體驗(yàn)確實(shí)是質(zhì)的飛躍。但所有性能優(yōu)勢(shì)都必須建立在正確的cache策略和使用邊界之上。把benchmark數(shù)據(jù)當(dāng)成衡量標(biāo)準(zhǔn)之前先想清楚你的業(yè)務(wù)到底在哪個(gè)象限里這才是在生產(chǎn)環(huán)境真正穩(wěn)妥的做法。