IEEE?TPDS'22：基于對象級協調的分布式I/O干擾排除系統 - 網安 - 專業的網絡安全產業、社區、知識平臺

I/O干擾是造成分布式文件系統I/O性能下降的主要因素之一。縱觀文件系統的架構，I/O干擾可以發生在應用層、中間件層、以及服務端等多個層級，最終表現為對底層存儲設備的資源競爭。在去中心化的分布式對象文件系統中，我們發現對象請求調度之間的干擾是造成存儲設備資源競爭的根本原因。因此，本工作針對分布式對象文件中各分布式OSD(Object Storage Device)對對象請求的獨立調度造成的I/O干擾問題，提出了對象級協調系統LoomIO，以協調各OSD的IO調度過程。為保證細粒度協調帶來的開銷不影響協調帶來的性能提升，LoomIO采用了wait-free的設計思想保證各對象請求在有限時間內能得到較優的調度結果。LoomIO系統由通信模塊、調度模塊、決策接收/發送模塊組成，分別負責發現及組織互相干擾的請求、對已組織的干擾請求進行用戶自定義的調度以及減少及選擇不一致的調度請求。目前我們實現了LoomIO的整套協調機制并將其嵌入到Ceph文件系統中，對于聚合帶寬、資源利用率以及尾延遲都有顯著的性能提升。

該成果“LoomIO: Object-Level Coordination in Distributed File Systems”收錄于IEEE Transactions on Parallel and Distributed Systems（TPDS）期刊。TPDS是計算機系統領域最權威的國際學術期刊之一，每月出版一期，每期錄用論文20篇左右，影響因子為2.6，主要關注并行與分布式架構、并行與分布式算法、并行與分布式計算應用、及并行與分布式系統軟件等方面的研究。

論文鏈接：
https://doi.org/10.1109/TPDS.2021.3126260

背景與動機

圖1 分布式OSD(Object Storage Device)對對象請求的獨立調度造成的I/O干擾

在分布式對象文件系統中，文件以固定粒度被分割成多個對象并分布在多個OSD中。同時，為防止設備故障等因素造成的數據丟失，對象文件系統通常對對象采用多副本或糾刪碼策略以達到容錯的目的。以糾刪碼策略為例，RS(k,m)表示每個對象被分割成k個數據塊，并計算出m個校驗塊，這k+m個塊分布在k+m個不同的存儲設備上。因此，存儲設備的資源競爭最終來源于多個并發的數據塊I/O。然而，由于去中心化分布式文件系統的特性，決定數據塊I/O目的地的對象請求調度是在各個OSD上獨立進行的，這些獨立的調度之間存在嚴重的I/O干擾問題。如圖1所示，A對象請求的三個分塊分別存放于0、1、2三個OSD上，B對象請求的三個分塊分別存放于1、2、3三個OSD上。并發訪問時，當A和B都選擇直接讀取數據塊，1號OSD將會產生資源競爭。

圖2 I/O干擾造成的動態負載不均

在使用常見I/O負載對Ceph集群進行測試后，如圖2所示，我們發現動態的負載不均系數可以達到靜態的8倍以上，意味著任意時刻某個OSD上的資源競爭情況比其他OSD上的嚴重得多。這主要是因為去中心化分布式文件系統采用的一致性哈希算法（如Crush）通常是為均衡各OSD上的存儲空間而設計的，沒有也無法顧及到運行時的I/O訪問模式。為了解決這個問題，在不影響數據分布的前提下，我們設計了象級協調系統LoomIO，以在運行時動態地協調各對象的調度過程。以圖1為例，在LoomIO的協調下，B可以選擇從2、3兩個OSD讀取一個數據塊和一個校驗塊恢復原始數據，從而達到了負載均衡，減少了資源競爭。

設計與實現

圖3 LoomIO整體設計

LoomIO的協調功能由四個模塊共同完成，分別是通信模塊、決策接收模塊、調度模塊以及決策接收模塊。

1. 通信模塊。通信模塊的主要任務為發現并組織不同OSD上互相干擾的對象請求。為了控制開銷，我們為每個請求分配了一個限時窗口。如圖4所示，整個窗口包含兩個階段：廣播和監聽。在廣播階段，每個對象請求將自己的存儲布局發送給其他OSD。在接收接收，每個OSD監聽其他OSD的廣播。我們將通信窗口相重疊的對象請求定義為互相干擾的對象，即如果A與B互相干擾，則A或B必有一方收到另一方的廣播信息。通過通信窗口的重合情況，我們可以確定一組互相干擾的對象請求之間的關系。我們定義一個對象請求為leader，如果它接收到了其他對象請求的存儲布局，反之，它將成為一個follower。在LoomIO中，一個leader可以有多個follower，一個follower也可以有多個leader。同時，由于所有的對象請求擁有相同大小的時間窗口，我們保證了一個對象請求不可能既是另一個對象請求的follower或者leader。

圖4 通信模塊

2. 調度模塊。得益于通信模塊已經將互相干擾的對象組織完畢，調度模塊的設計可以像單機調度一樣簡單。在LoomIO中，由于我們主要解決的是I/O干擾問題，調度算法只需要簡單地將k個分片請求發送到k個負載最少的OSD上即可。對于每個對象請求，它除了需要調度自己之外，還需要調度follower。所有需要調度的存儲布局都存放在調度列表，調度模塊只需要依次執行即可。作為調度依據，負載表也是很重要的一個數據結構，它需要真實的反應當前各個OSD上的負載情況以更好的指導調度過程。我們使用了低頻的全局更新+本地實時累積來構成負載表。使用低頻的全局更新是因為高頻的監控通常會帶來較大的開銷。一般情況下，集群監控間隔會被設置成秒級，無法為對象請求的毫秒級調度提供準確實時的支持。在監控信息更新的真空期，基于通信模塊提供的全局視野，我們可以得到一個近實時的負載分布。

3. 決策接收/發送模塊。決策接收及發送模塊主要負責follower如何接收與處理leader的決策以及leader如何發送決策。如圖5所示，主要有兩條規則：1，一個leader只有在它的決策表不為空并且存在follower的決策時才需要發送決策；2，一個follower需要檢查接收到的決策并且從他的調度表中去除重復的條目以防止重復調度。通過這兩條規則，我們防止了一個對象請求被多個leader調度并且減少了通信開銷。在實際環境中，由于網絡延遲的原因，決策發送可能會有失敗的情況。具體地，一個follower可能在進行調度前?都沒有收到leader的決策，導致存在不一致的調度結果。但這樣的情況占比很少，根據我們的測試，只有不到5%，對于性能的影響幾乎可以忽略不計。

圖5 決策接收/發送模塊

目前我們使用Redis實現了LoomIO的整套協調機制并將其嵌入到Ceph文件系統中。實驗結果如圖6所示，相比于baseline和現有的兩種調度策略Late-binding及K-optimal，LoomIO在資源利用率、聚合帶寬、以及尾延遲上分別達到了最高35%、31%、54%的提升。

圖6 LoomIO對I/O資源利用率、帶寬及尾延遲有顯著提升

詳細內容請參見：

Yusheng Hua, Xuanhua Shi, Kang He, Hai Jin, Wei Xie, Ligang He, and Yong Chen. "LoomIO: Object-Level Coordination in Distributed File Systems." IEEE Transactions on Parallel and Distributed Systems 33, no. 8 (2022): 1799-1810. DOI: 10.1109/TPDS.2021.3126260