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