作者：吳香偉 發(fā)表于 2017/01/24
版權聲明：可以任意轉載，轉載時務必以超鏈接形式標明文章原始出處和作者信息以及版權聲明
喜歡請點擊右邊打賞，謝謝支持！
存儲QoS是個可以做很大也可以做很小的特性。SolidFire認為將QoS歸類為特性太兒戲，QoS應該是存儲系統(tǒng)設計之初就要仔細考慮的架構問題。的確，分析了一眾主流存儲大廠后還是覺得它在這方面做得最細致最全面。同時也有些廠商做得比較簡陋，只提供了帶寬或者IOPS的限速功能。這或許在某些場景中已經(jīng)夠用，但我認為一個完整的QoS方案至少要包括對帶寬、IOPS的預留、上限和優(yōu)先級控制，如果再精細點還可以考慮IO的粒度、延遲、突發(fā)、空間局部性、系統(tǒng)內部IO、用戶IO、緩存、磁盤等要素。
分布式存儲都有很長的IO路徑，簡單的IOPS限速功能通常在路徑的最前端實現(xiàn)。例如OpenStack Cinder默認使用QEMU完成存儲塊的限速功能，QEMU對存儲來說已經(jīng)屬于客戶端的角色了。
QoS的本質總結起來就四個字：消此長彼，它并不會提高系統(tǒng)整體處理能力，只是負責資源的合理分配。據(jù)此就可以提出一連串問題了：首先，如何知道什么時候該消誰什么時候該長誰？其次，該怎么消該怎么長？這兩個問題QoS算法可以幫忙解決，可以參考我的另外一篇文章《聊聊dmclock算法》。在這兩個問題之前還需要選擇一塊風水寶地，能夠控制希望可以控制的IO，否則即使知道何時控制以及如何控制也鞭長莫及無能為力。風水寶地的選擇可以參考我的另外一篇文章《拆開Ceph看線程和隊列》。
對Ceph來說，OSD的ShardedOpWq隊列是個不錯的選擇，因為幾乎所有重量級的IO都會經(jīng)過該隊列。這些IO可以劃分為兩大類，一類是客戶端過來的IO，包括文件、對象和塊存儲；另一類是系統(tǒng)內部活動產(chǎn)生的IO，包括副本復制、Scrub、Recovery和SnapTrim等。第一類IO由于涉及到一些敏感內容暫不考慮，本文主要分析第二類IO，這也是本文叫做下篇的原因。
Recovery
| 配置項 | 默認值 | 說明 |
|---|
