QoS需求背景

伴随着互联网应用的高速度发展，日益产生的海量非结构化数据需要海量存储。对象存储能够提供海量存储的解决方案，支持百亿或者千亿对象产品规格。越来越多企业将对象存储作为企业数据湖进行应用，企业各类数据均汇入对象存储数据湖进行统一存储，各类应用对接数据湖进行数据消费和分析。

不同的业务需要不同的服务质量保障，同时业务的重要性也各不相同，需要保障核心、敏感业务的服务质量不受其他应用的冲击，对于分布式存储的服务质量QoS(Quality of Service)管控的需求越来越强烈。

XSKY星辰天合多年来不断投入分布式QoS上的技术投入，不但获得了多个QoS相关专利，并将技术与产品结合，打造成熟的分布式存储QoS特性。

分布式QoS实现难点

复杂度

对象存储为了满足大规模高并发的需求，保持性能和容量的线性扩展，一般都是采用多网关同时对外服务的实现方案，这就给整体服务质量QoS带来了比较大的挑战。

性能影响

全局的分布式QoS需要一个统一的决策者，所有的请求都需要在这个决策者的控制之下。但在大规模高并发场景下，这个决策者本身容易成为瓶颈，影响业务性能。并且每个业务请求都需要向决策者发送申请，OPS限制需要1:1的发送，带宽限制为达到精细化调控可能需要拆分为更多申请，这些申请对通信资源也是一个巨大的占用。

动态平衡

对象存储网关本身是无状态的，可以根据业务需求新增或删除，或者异常场景的网关退出等，这些都会导致整体网关拓扑的变化。此时分布式QoS需要能满足以上各种场景，在网关拓扑发生变化时能快速恢复整体QoS能力。

下一代对象QoS方案

总体架构

令牌桶机制是本地QoS一种较好的实现方案，具有响应快、低延迟且能应对突发状况，但不具备多网关协调能力。XSKY星辰天合的分布式QoS解决方案基于本地令牌桶机制进行全面升级，往上建立了一套网关之间QoS信息的交互机制，再汇总进行协同控制。

同时，为了提升多网关QoS服务运行的稳定性，又添加了一套心跳检测与MasterQoS切换机制，确保在异常情况下也能平稳运行。

本方案具体由如下三个模块共同实现：MQ模块、HQ模块、令牌桶(Ratelimiter)

运行机制

具体运行机制如下：

● 首先从所有网关中选择一个MasterQoS作为决策者

● MasterQoS从所有注册的网关中选取一批成为HandleQoS，每个HQ负责对应的一批桶的QoS配额分配

● 其他网关与HQ交互，上报本地QoS信息并获取最新配额，更新本地配置

● 在各个网关运行本地令牌桶，提供QoS服务

性能考虑

由于需要应对大规模高并发的应用场景，我们希望提供的QoS服务响应时间尽可能少、网关之间交互的信息尽可能少，以减少对性能的影响。并且当桶数量较大（如达到100000规模）时，能同时提供QoS服务。

为此，XSKY星辰天合做了如下优化：

● 把桶进行分类，组成不同的桶队列，每个桶队列对应一个HandleQoS，每次交互QoS信息以桶队列为单位。即无论增加多少桶，桶队列个数不变的情况下，网关之间的交互信息数量不会变化。

● 为防止单个HQ处理太多QoS条目成为瓶颈，把HQ设定为多个且可配置的，用户可根据业务需要自由调整HQ数量，分担业务压力

● 整个QoS服务只有极少数的数据需要写入数据库，几乎全内存运行，提高了运行效率，也降低了对数据库的压力

● HQ把配额分配到各个网关，各个网关独立提供本地QoS服务，大大降低了延迟

功能特色

QoS角色控制

XSKY星辰天合提供了详细的QoS角色（桶、用户、租户）和功能控制，并且角色和下图中的功能可任意组合，既可单独使用也可全部开启，满足用户的各种需求。

快速恢复机制

心跳检测与MQ切换机制保证了能快速发现网关拓扑的变化，并自动完成调整，可以实现QoS服务的快速恢复：

● 普通网关加入退出可以在5s内实现QoS效果

● MQ/HQ异常可以在30s内实现重新选举，恢复QoS效果，并且在恢复期间本地QoS继续提供服务，对业务影响降到最低

总结

XSKY星辰天合在专利层面对QoS进行了多次迭代，在下一代对象存储中将进一步升级为最新专利技术保护的QoS特性，帮助客户更好的进行业务管控和划分。