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