向存储资源抢夺说再见！
基于QoS的软件定义存储，向存储资源抢夺说再见！
01
资源抢夺战
对于存储用户来说，正在经历或者未来会面临到的一些情况是：
1、为了让数据更加集中和统一管理，如今一套存储系统中往往部署多项业务。多种工作负载部署在同一存储系统中，可能出现资源抢用的问题，这不仅将导致所有业务的数据读写速度下降，更加影响了用户核心业务的服务能力。正如在日常生活中，由于车辆相互抢道，导致交通堵塞。
2、当某个时间点存储性能的总需求超过系统可以提供的范围时，如何让存储系统确保每项业务都能获得自己的带宽需求，然后使用剩余的资源来为高优先级的业务提供更高的带宽需求？同样，在早晚高峰期，当交通流量超出道路承载范围时，交通部门必须采取一系列措施来确保基本的通行，在此之外，还需要保证例如特殊车辆（急救、消防等）在此期间的优先通行。
3、磁盘损坏、节点故障等异常状况无法避免，更换硬件设备后数据需要做重平衡，如果没有制定相应的带宽分配策略，业务的运行和数据重平衡相互抢占带宽，这将极大影响前端业务用户体验。这就好比遇上道路抢修的情况，原本只需要封闭其中一小段车道，但抢修人员却封闭了整条车道，结果只会加重路面的交通压力……
如何缓解由于对资源的抢占给用户带来的存储瓶颈？在治理交通拥堵过程中，设置潮汐车道和公交专用道等办法为这一难题的解决提供了借鉴。
潮汐车道通过实时监测不同时段交通流量的变化，改变车道灯的指示方向，控制主干道车道行驶方向，来及时调整车道数；公交专用道则确保了在高峰期，城市中主要的出行方式的优先和畅通，在高峰期之后再次允许其它车辆的驶入。潮汐车道和公交专用道在道路并未增加的前提下，通过干预设置，最大化提高了道路使用效率。
02
对症下药
QoS （Quality of Service，服务质量）起源于网络技术，它用来解决网络延迟和阻塞等问题，能够为指定的网络通信提供更好的服务能力。
正如同潮汐车道和公交专用道等交通拥堵治理措施，QoS并没有增加资源和系统能力，但通过服务和资源的优化分配，保障了关键业务的服务质量，同时也能够为其它业务的运行、提供满足服务质量的基本需求。
在本质上归结为四个字：消此长彼，它据此就可以提出一连串问题：首先，如何知道什么时候该消谁？什么时候该长谁？其次，该怎么消该怎么长？这些问题QoS算法可以帮忙解决。
03
鱼与熊掌可兼得
对于存储系统，数据按时间顺序排队（IO Queue）进行写入。这些IO可以划分为两大类，一类是客户端过来的IO，包括文件、对象和块存储；另一类是系统内部活动产生的IO，包括副本复制、Recovery和SnapTrim等。
针对这两大类IO划分，XSKY软件定义存储（SDS）具备两种QoS设置：在线QoS和数据恢复QoS，为用户面向常规业务场景以及数据恢复场景提供完善的服务质量保障，最大化提高存储资源利用率，保障用户体验。
在线QoS
在常规业务场景下，在线QoS支持对块存储卷和文件存储目录进行优先级设置，同时可根据用户的需求进行在线实时修改，即时生效，以应对突发性能需求。
通过在线卷QoS，用户可以根据不同业务的重要性及其对存储性能需求，对相应的卷进行设置。提及在线卷QoS，则不得不提到漏桶(leaky bucket)和令牌桶(Token Bucket)两种限流算法。
漏桶算法：就像漏桶接水一样，水进入到漏桶里，桶里的水通过下面的孔以固定的速率流出。漏桶算法能强行限制数据的传输速率。如下图所示:
漏桶算法能够强行限制数据的传输速率
令牌桶算法：令牌桶算法的原理是系统会以一个恒定的速度往桶里放入令牌，而如果请求需要被处理，则需要先从桶里获取一个令牌，当桶里没有令牌可取时，则拒绝服务。 一旦需要提高速率，则按需提高放入桶中的令牌的速率。 一般会定时(比如100毫秒)往桶中增加一定数量的令牌。
实际上，主流存储大都具备存储QoS，可以对应用适配的最大性能或容量进行限制，这种QoS可以解决一般场景多业务并发时抢占资源的现象，但对于突发业务，往往出现LUN性能不足以提供应用所需，甚至导致业务停顿不可用。
XSKY采用漏桶与令牌桶相结合的IO流管理策略，并进行了大量优化，具备最大MBPS, 最大IOPS等QoS设置值，可以根据业务需求智能控制数据传输速率，而且漏桶无上限，避免了漏桶算法的IO溢出、漏桶丢包的现象。同时还具备突发MBPS、突发IOPS等QoS设置，可以根据突发业务需求，实时智能增加的令牌的数量，保证瞬间或者临时的突发性能要求。
设置QoS
开启QoS效果
例如，某企业正处于产品研发的关键阶段，研发人员的相应代码、文件及资料均在存储上进行存放，为了首要确保研发的顺利进行，这一期间可通过在线QoS功能，为企业内其它部门访问NAS的I/O和带宽进行降级设置，在研发工作告一段落后，再将访问级别设置回来。
数据恢复QoS
在100个4TB硬盘的集群下，采用3副本冗余策略，当某一个硬盘损坏，全速恢复副本大约需要10分钟，但在此期间，如果不设置恢复QoS限制，实测业务IO会下降60%……在实际生产中，这样的突发性能波动是不可容忍的。设置恢复QoS后，数据恢复带宽得到有效限制，保障业务性能下降幅度不超过15%。
在数据恢复场景下，恢复 QoS提供两种策略供用户选择，一种是基于业务优先策略，业务繁忙的时候，集群带宽主要分配给业务；另一种是基于重构优先策略，集群带宽主要分配给数据重构。
XSKY 恢复 QoS提供两种设置——动态设置QoS：对特定业务进行针对性调整；静态设置QoS：XSKY 数据恢复QOS可以数据平衡数据量和业务数据量，分级对恢复IO进行智能限制。
当集群硬件异常，或者进行硬件更换维护时，分布式存储进入数据恢复状态，将失效硬件上的数据重新分布在其他节点，此时将产生Recovery IO。
XSKY SDS 数据恢复进程拥有独立的工作队列和线程池。XSKY存储底层的基本单位是PG，而非整个磁盘（OSD），数据恢复QoS会对两个参数进行控制：“控制不同PG恢复的优先级”和“控制OSD中同时进行恢复的PG数目”。
控制不同PG恢复的优先级：先将PG加入优先级队列，再根据PG的优先级从高到低的顺序出队列，优先级越高的PG越先恢复。
控制恢复的PG数目:一般而言，数据重平衡过程中依然会有客户端业务数据写入，大量PG参与数据重平衡及业务写入操作，重平衡IO及业务IO会导致IO抢占带宽资源的现象，往往会导致业务IO需要等待，延时增大，最终影响业务性能。用户设置静态QoS后，XSKY SDS会根据已有数据量、异常类型、集群配置等关联信息， 同时考虑数据冗余算法，智能控制参与数据重平衡PG的数目。
如下图所示：
在恢复 QoS策略上，例如，在白天业务繁忙的时候，将主要带宽分配给业务，保障业务的顺利运行；而在夜间，业务的低频使用期间，则将主要带宽分配给数据恢复。通过合理的资源调配，鱼（数据恢复）与熊掌（业务运行）可兼得！