作者：吴香伟 发表于 2017/01/24
版权声明：可以任意转载，转载时务必以超链接形式标明文章原始出处和作者信息以及版权声明
喜欢请点击右边打赏，谢谢支持！
存储QoS是个可以做很大也可以做很小的特性。SolidFire认为将QoS归类为特性太儿戏，QoS应该是存储系统设计之初就要仔细考虑的架构问题。的确，分析了一众主流存储大厂后还是觉得它在这方面做得最细致最全面。同时也有些厂商做得比较简陋，只提供了带宽或者IOPS的限速功能。这或许在某些场景中已经够用，但我认为一个完整的QoS方案至少要包括对带宽、IOPS的预留、上限和优先级控制，如果再精细点还可以考虑IO的粒度、延迟、突发、空间局部性、系统内部IO、用户IO、缓存、磁盘等要素。
分布式存储都有很长的IO路径，简单的IOPS限速功能通常在路径的最前端实现。例如OpenStack Cinder默认使用QEMU完成存储块的限速功能，QEMU对存储来说已经属于客户端的角色了。
QoS的本质总结起来就四个字：消此长彼，它并不会提高系统整体处理能力，只是负责资源的合理分配。据此就可以提出一连串问题了：首先，如何知道什么时候该消谁什么时候该长谁？其次，该怎么消该怎么长？这两个问题QoS算法可以帮忙解决，可以参考我的另外一篇文章《聊聊dmclock算法》。在这两个问题之前还需要选择一块风水宝地，能够控制希望可以控制的IO，否则即使知道何时控制以及如何控制也鞭长莫及无能为力。风水宝地的选择可以参考我的另外一篇文章《拆开Ceph看线程和队列》。
对Ceph来说，OSD的ShardedOpWq队列是个不错的选择，因为几乎所有重量级的IO都会经过该队列。这些IO可以划分为两大类，一类是客户端过来的IO，包括文件、对象和块存储；另一类是系统内部活动产生的IO，包括副本复制、Scrub、Recovery和SnapTrim等。第一类IO由于涉及到一些敏感内容暂不考虑，本文主要分析第二类IO，这也是本文叫做下篇的原因。
Recovery
| 配置项 | 默认值 | 说明 |
|---|
