QoS对于服务多租户多业务的整体零碎来说，不论对网络还是存储，都分外重要，没有QoS，会造成不同租户及业务之间对资源的抢占，用户A用爽了，用户B却遭了殃，频频投诉，这是系统管理员最头疼的事件。咱们明天就来讨论一下分布式存储系统中的QoS算法。进入正题之前，咱们先来理解背景常识，即什么是QoS，分布式QoS又是什么，有哪些常见的QoS算法。最初咱们再来探讨本文正题：mClock算法和dmClock算法。
01 什么是QoS
QoS是Quality of Service的缩写，它起源于网络技术，用以解决网络提早和阻塞等问题，可能为指定的网络通信提供更好的服务能力。
放到存储系统中，QoS用来保障肯定的存储服务质量，具体个别指如下几个方面：
- 为高优先级的业务提供更高的服务质量（包含IOPS、带宽、延时等数据拜访服务）。零碎服务能力无限，为高优先级业务配置更高的QoS，为低优先级业务配置更低的QoS，正当分配资源，满足不同级别业务的需要。
- 管制资源争夺：比方当存储系统产生故障复原时，防止集群外部复原争夺资源，保障用户业务不受影响。
可见QoS并没有减少零碎服务能力，它只是通过对系统能力的优化调配，保障要害业务服务质量，同时满足一般业务的根本需要。比方零碎能力是100，为高优先级业务数据库调配90，为低优先级的后盾备份业务分配资源10。
02 什么是分布式QoS
那么QoS如何实现？如果所有业务都会通过一个入口进入零碎，则零碎能感知每个业务对系统资源的用量，在这个入口上做流控，就能做到对资源拜访的调控。
比方在一个Linux服务器上跑多个业务，它们共享同一个ext4本地文件系统，指标要管制每个业务的带宽。咱们将QoS算法运行在该服务器上，通过感知每个业务的实时带宽，就能做对各个业务的QoS管制。
如果有多个Linux服务器下面跑了多个业务，它们通过NFS共享远端同一个ext4文件系统，指标依然是管制每个业务的带宽。此时QoS算法如果实现在业务端，因为业务跑在多个服务器上，相互间无奈感知其它Linux服务器带宽用量，继而无奈实现整体的QoS管制。比方服务器A上只跑了一个低优先业务，它认为本人独占存储，继而大压力读写，争夺了服务器B上高优先级业务的带宽，因而对于分布式业务，通常很难在客户端实现对整体集群的QoS管制。
但这个场景中，QoS算法能够实现在共享的ext4文件系统端，即NFS server端，因为所有业务流量都会流向这里，故而能感知和管制各个业务端对文件系统的流量要求。
近年来基于x86服务器的分布式存储系统风行，即在多个x86服务器部署分布式存储软件，构建出一套分布式存储系统，对外提供一套对立的存储服务。如果是分布式块存储，用户能够将这套分布式块存储集群看成一个集中的SAN设施。如果是分布式文件存储，用户则能够将这套分布式文件存储集群当成一个本地文件系统（如ext4, xfs）来用。
但问题来了，在这样的分布式存储中如何做QoS？
分布式块存储比拟特地，一个虚构块设施个别仅被一个中央挂载应用，故而能够在这个挂载点做QoS，分布式块存储的QoS也较为成熟和常见。
所以咱们明天次要探讨分布式文件存储。文件系统个别都通过client端mount后进行应用，一个文件系统会服务多个client端，用户业务散布在各个client，因此无奈在client端做QoS算法，因为client间对其它client资源用量是不感知的。咱们仿佛也无奈在存储端做QoS算法，尤其是分布式并行文件系统，因为存储端各节点是分布式的，业务数据从不同client端发动，间接流向不同的存储端节点。
咱们将这种场景称之为分布式QoS场景。相比单机QoS场景，它更具挑战。事实上，在分布式文件存储市场上，不论是开源还是商业产品，对共享目录级别的QoS，并不常见。
03 常见的QoS算法
令牌桶（token bucket）算法，漏桶（leaky bucket）算法，这是最为常见的两种单机QoS算法。这两种算法网上材料和示例有很多，这里只简略形容。
令牌桶算法中，零碎以指定策略（比方匀速）往桶中放入令牌，业务申请被解决时，须要先从桶中获取令牌。当桶中没有令牌时，业务申请将不被解决。这样能通过管制令牌生成的速率，来管制业务申请被解决的速率。
漏桶算法中，构想一个漏桶接水，桶里的水将匀速流出。不论业务申请到来有多快，这些申请被解决（即从漏桶流出）的速率都是恒定的。
二者的区别是，漏桶算法能强行限度业务申请速率，而令牌桶除了能限速之外，还能容许肯定的突发申请解决。个别在实现中会联合漏桶和令牌桶算法。
mClock算法解析
mClock算法来自VMWare发表于OSDI 2010的论文《mClock: Handling Throughput Variability for Hypervisor IO Scheduling》。
他们认为，在服务器上跑多个虚拟机（VM），VM里跑各种各样的用户业务，hypervisor须要做好资源管理。CPU、内存方面已有很多成熟办法，但对共享存储资源的治理上并没有太好的办法。正如论文中举例（下面论文截图右表）一样，VM5独占共享存储时，性能很高，当运行更多VM，共享存储面临更大IO压力时，VM5性能受影响降落了40%，不满足业务需要。
论文认为，面对不同类型的VM，一个适合的QoS算法要求能满足每个VM的最低需要，同时不超过预设设置，且能依据优先级不同，调配不同权重的资源。mClock就是这样的算法，mClock能解决下面例子中VM5受影响而性能降落的问题。
mClock的算法思维是，
- 指定权重（Weight, W）、预留（Reservation, R）和下限（Limit, L）：给定一组散布在不同服务器上的VM，依据业务需要，为每个VM指定一组参数，参数有三类，别离是Weight、Reservation和Limit。如果VM更重要，能够为之指定更大的Weight。Reservation示意必须满足的最低需要。如果指定了Limit，则示意该业务所得资源最多不会超过指定值。
- 在共享存储侧，每个VM的IO申请到来时，mClock算法依据Weight、Reservation和Limit配置给申请打上三个独立的标签。打标签算法如下图公式，其中R示意Reservation标签，L示意Limit标签，P示意Proportional标签，亦即Weight标签。
共享存储侧依据标签值给IO申请排序，并按序解决。
通过举例来了解打标签、按标签值排序的含意和成果。假如有三个用户A、B、C，其Weight别离是1/2、1/3、1/6。假如每个用户都间断地发申请，则依据公式，每个申请以1/w为距离打标签，则：
- A用户申请的Weight标签序列为：2, 4, 6, 8, 10, ...
- B用户申请的Weight标签序列为：3, 6, 9, 12, ...
- C用户申请的Weight标签序列为：6, 12, 18, 24, ...
排序后为A2, B3, A4, A6, B6, C6, A8, B9, A10, B12, C12, A14, B15, A16, ...， 或简化成ABAABCABAABCABA。
共享存储按这个序列来解决申请，最终达到的成果是解决的A申请占总数的1/2，解决的B申请占总数的1/3，解决的C申请占总数的1/6。即是遵循Weight配置的。
思考几种场景，
场景1：如果C用户“歹意”发送超过权重的申请，是否会抢占AB的资源？比方发送程序是ABCCCCCCAAB，C超发申请的标签值很快就变得很大，在ABC整体标签排序中，C超发申请会被排在前面，因而不会因为发的快而抢占AB的资源。
场景2：如果AB收回的申请很少，C收回的申请多，标签队列中有大量C的标签，C申请会被解决，资源不会被闲置。
场景3：如果A刚开始收回的申请少，但前面某时忽然“暴发”，是否会使得BC被“饿死”？并不会，因为依据标签算法，A“暴发期”申请的标签值会思考过后的工夫值（咱们可将工夫序列了解为1、2、3这样递增的序列，用以示意逻辑工夫，而非17点55分这种物理时钟），A先期申请少，“暴发期”申请(p+1/w)也会小，如果不思考t，则“暴发期”申请标签都小，会“饿死”BC的申请。但max(p+1/w, t)之后了，则不会有饿死景象。
Reservation、Limit标签队列相似于Weight标签队列，造成多个队列。而标签在含意上跟工夫相干，因而mClock算法可了解为是multi-Clock的缩写。
mClock算法联合解决Weight, Reservation, Limit三个队列后的成果是：
- 如果系统资源不够所有人分，则优先满足Reservation和Limit。
- 如果系统资源足够分，则按Weight去调配。
以上是对mClock算法直观的了解，更谨严的了解、更多的场景剖析请参考论文。有了这些直观了解之后，咱们无妨还能够去思考一下它和令牌桶算法的区别。
dmClock算法解析
dmClock意为distributed mClock，这里distributed何解？
mClock解决的场景仍是单机场景，只管在论文举例中，申请来自散布在多个服务器上的VM，但mClock算法仍是运行在“繁多节点”上的，即运行在共享存储侧的服务器上。
在后面局部咱们探讨了“分布式QoS”，即申请来自于多个client端，发往多个server端。这种场景下mClock不再实用，因为mClock是单机的，如果在每个server上都运行一个mClock算法，这些算法实例是互相独立的。比方假如A申请Reservation为Ra，A申请平均地发到3个server S1 S2 S3上，S1 S2 S3别离会满足Ra，最终后果是S1 S2 S3整体满足3*Ra，是指定Reservation的3倍。
仿佛须要S1 S2 S3上的mClock算法实例须要相互间建立联系，沟通彼此解决的申请状况，互相协调一下，能力使QoS的后果正确。
但显然这样的协调老本是很高的，这也不是dmClock的做法。dmClock算法在mClock根底上，对打标签公式做了微调：
流程上相似mClock，仍是先为不同业务指定(W, R, L)，据此在client侧为不同业务申请打标签，比方打Weight标签时，不再是+1/w，而是+delta/w。要害是了解这里的delta。
仍用下面剖析mClock时采纳的例子，假如某个client上有三个业务A B C，Weight别离是1/2, 1/3, 1/6，假设ABC按Weight匀速地发申请，则申请序列为ABAABCABAABCABA，申请会按外部存储规定发往ServerA，ServerB或ServerC，比方：
选定ServerB收到的第3个申请A，它的标签值的+delta/w中的delta=2，含意是ServerB上次收到申请，和这次收到申请间接，这个client向其余Server发送了2个申请。
04 总结
咱们探讨了QoS、分布式QoS、令牌桶等常见QoS算法，最初举例剖析了mClock和dmClock算法。
对于dmClock，咱们思考一个进一步的问题。在咱们下面举例中，咱们假如三个业务A B C都从一个client中收回。如果业务A B C自身是分布式的，即比方业务A是散布在多个client上，从多个client上都会收回A的申请，这些申请都会依据外部存储规定发往多个后端Server，此时dmClock还能实用吗？欢送大家思考和探讨。