Dynamic Scheduling with Service Curve for QoS Guarantee of Large-Scale Cloud Storage 论文阅读

摘要

在共享云存储保证应用的服务质量变得尤为重要，而性能隔离，不同的性能要求，特别是苛刻的延迟保证和高系统利用率成为了 QoS 设计的挑战。在本文中提出了基于服务曲线（service curve-based）的 QoS 算法在一个存储系统中同时支持延迟保证应用程序（latency guarantee applications），每秒读写次数保证应用程序（IOPS guarantee applications），最大努力应用程序（best-effort applications）。

引言

不同的高性能存储服务具有不同的访问模式和存储性能要求：

• 在线交易过程（ online transaction process）：具有大量的短期在线事务，有非常严格的延迟要求
• 在线分析处理（ online analytical processing）：具有较复杂的事务量，有吞吐量要求

难点：

• 应用程序在共享存储系统上运行可能由于资源竞争互相干扰
• QoS 保证需要适用于广泛的 SLAs，对于共享存储上的不同应用程序，不容易同时保证不同的性能需求
• 为某个应用程序保留专有资源可以达到很好的 QoS，但同时带来了低利用率的问题，一个期望的 QoS 应该能够持续工作并能够将一个程序的备份资源分配给其他应用程序
• 对于延迟保证应用程序需要保证的是每一个 I/O 响应时间小于规定的时间，通过简单的过度供应资源是不能够保证延迟需求，因此一个期望的 QoS 不仅能够满足每个应用程序的 SLAs 还能够根据系统的综合状况灵活分配资源

应用程序分类：

• latency guarantee application：实现 I/O 响应时间小于延迟限制
• IOPS guarantee application：保证最小带宽
• best-effort application：没有 QoS 要求

本文的贡献：

• 指出现有的基于服务曲线的 QoS 延迟保证机制的两个问题：
  • 为了保证延迟，对带宽的保守估计使得系统过度供应资源，导致了资源利用率低。
  • 当前的服务曲线不适用于不可预测的 I/O 工作负载
• 设计了一种基于服务曲线的 QoS 保证算法，叫 SG-QoS，同时支持 latency guarantee applications， IOPS guarantee applications，best-effort applications。使用了三个优先级队列根据应用程序的服务曲线和 I/O 的紧急状态对 I/O 的进行调度和分发。
• 将 SG-QoS 集成到到 GlusterFS-based 存储系统中，结果表明 SG-QoS 设计优于现有的 QoS 机制

相关工作

• 基于轮询的算法用于分组交换网络的链路共享
• 调度工作分析，讨论了算法的公平性，延迟偏差和计算复杂度
• 大多数 Linux 发行版使用完全公平队列（CFQ）作为默认的 I/O 调度程序
• 磁盘调度算法：Fahrrad，Facade，pClock 和 YFQ
• 在存储系统中实现性能隔离
• 为分布式系统设计的算法：Bourbon，Horizon，PARDA，DSFQ
• 主导资源公平（Dominant resource fairness (DRF)），将单个资源的公平性扩展到多个资源的公平性
• QoS 在云系统上的实施
• Cruz et al 提出了网络中基于服务曲线的 QoS 保证，服务曲线描述了网络元素中接受的服务。该工作分析了带宽和延迟的界限。结论：在一定的约束条件下，同时保证不同的应用程序的所有服务目标与服务曲线是可行的。在分组交换网络中提出了 SCED（service curve-based earliest deadline），SCED 的问题是如果消耗的资源超过了自己的份额，则会有工作量饿死。
• HFSC 提出了分层公平共享算法（hierarchical fair-sharing algorithm），克服了 SCED 的问题同时提供了带宽和延迟的 QoS 保证。但是使用的是分段线性的服务曲线，就不能处理复杂的 I/O 访问模式

背景：基于服务曲线的 QoS 保证

• $b_i(t)$：请求到达曲线，累计的到达请求
• $R_i(t)$：接收服务曲线，累计的接受请求
• $S_i(t)$：服务曲线，代表服务的目标
• $B_i(t)$：堆积的未处理的请求 = $b_i(t)-R_i(t)$
• $l_i(t)$：延迟
• 斜率：表示带宽

设定：工作负载间断性的发出 I/O 请求，故在活动和不活动之间交替

活动的：$B_i(t)>0$ 且 $B_i(t-1)=0$
不活动的：$B_i(t-1)=0$

到达限制：${\mu }_i(t)\ge b_i(t)$

• 可预测的工作负载：通过设置服务曲线的斜率，与到达曲线的距离确定带宽和延迟来保证 QoS 目标。
• 不可预测工作负载：加上到达曲线约束来构造服务曲线

问题公式化

• 说明基于服务曲线的 QoS 机制在延迟保证上存在的两个问题
• 首先讨论了基于服务曲线 QoS 保证所需带宽的下界
• 证明了不可预测的存储 I/O 访问模式下在基于服务曲线的延迟保证下可能会失效

延迟保证所需带宽的保守设置

工作负载间歇性的生成 I/O 请求，静态的配置服务曲线不能适应实时工作负载和 QoS 的变化

$SCED$ 提出了为每个工作负载 $w_i$ 分配一个截止时间 $d_i$

$D_i(t)$ 表示分配给工作负载 $w_i$ 的服务，当工作负载 $w_i$ 变活跃时，根据接收服务曲线 $R_i(t)$ 和 服务曲线 $S_i(t)$ 来更新 $D_i(t)$。$B_i(s)$ 代表了 $b_i(s)$ 和 $R_i(s)$ 的交点

转换成迭代版本：

由迭代版本的式子可以得到以下不等式：

由上式不等式可知 $D_i^0(t)$ 确定了服务曲线带宽的最低要求

最低带宽需要满足所有突发的 I/O 请求要在规定的截止时间内完成服务

• $\tilde{C}(t)$：带宽需求
• ${\sigma }_i$：突发的 I/O 请求大小
• $L_i$：目标延迟
• ${\rho }_i$：I/O 请求到达速率

当 $\frac{{\sigma }_i}{L_i}\ge {\rho }_i$，则有 $\tilde{C}(t)\approx {\sum }_i(\frac{{\sigma }_i}{L_i})$

由于延迟保证对带宽的保守设置导致了峰值带宽与平均带宽之间的差距很大，因此带宽的利用率低。因此在 SG-QoS 中将耦合 IOPS 保证应用程序和延迟保证应用程序去来提高带宽的利用率

• $w_1$ 有延迟保证需求
  • 服务曲线 $S_1(t)$ 是分段线性曲线，其中 ${\rho }_1^1>{\rho }_1^2$
  • 第一段曲线斜率 ${\rho }_1^1$ 为了保证工作负载 $w_i$ 在 $t_0$ 之前突发的 I/O 请求，确保了工作负载 $w_i$ 的 I/O 请求在规定的延迟之前完成
• $w_2$ 有最小吞吐量要求
  • $w_2$ 在 $t_0$ 之前受到 $w_1$ 带宽的影响，将空闲带宽分享给 $w_1$，保证自己在平均 IOPS 下工作同时使得 $w_1$ 在规定的延迟下完成工作

根据上面的例子，可以看到耦合不同的应用程序可以改善系统的灵活性和利用率

延迟保证服务曲线

设计良好的服务曲线的两个挑战：

• 服务曲线 $S_i(t)$ 可以设置为任意函数，但是在实践中为了计算简单通常是线性函数或分段线性函数
• 在存储系统中的 I/O 请求到达曲线是不可预测的

$HFSC$ 使用了两个分段服务曲线确保 QoS，它假设：

• 所有的数据包具有相同的大小并以稳定的速率到达
  
• 到达曲线是楼梯形状的折线
• 由于服务曲线 $S_1(t)$ 第一段斜率较大能够使得第一个数据包在时间 $t_0$ 完成
• 服务曲线 $S_1(t)$ 第二段斜率较小仍然能够使得后续的数据包在时间间隔 $t_0$ 完成
• 因此所有数据包能够在规定的延迟内完成服务
• 虚线 $S_2(t)$ 和 $S_1(t)$ 第二段曲线有相同的斜率
• $HFSC$ 使用 $S_1(t)$ 第一段曲线保证低延迟，第二段曲线保证带宽，然而这种两段线性函数只能适用于上图，例如音频和视频有相同的请求大小和恒定的到达速率

在实际上，存储 I/O 的工作负载模式如下图

• 在 $S_1(t)$ 服务曲线中三个 I/Os 的延迟分别为 $t_1,t_2,t_3>t_0$
• 若想要使得每个 I/O 延迟均为 $t_0$ 则需要使用 $S_3(t)$ 多段线性函数，然而在实际设计一个 $S_3(t)$ 服务曲线是较为困难的
• 因此 $HFSC$ 不适用于不可预测的存储 I/O 延迟保证

SG-QoS

• 该算法使用了三个优先队列来实现：latency queue，IOPS queue，fairness queue
• 共享存储系统中划分了三种类型的应用程序： latency guarantee application，IOPS guarantee application，best-effort application
• 当有 I/O 请求到达时会计算时间标签 $e{t}_i$ 和 $v{t}_i$ 用于后续的调度
• $e{t}_i$ 表示根据 QoS 要求的 I/O 预期完成时间，$v{t}_i$ 根据公平要求表示 I/O 的虚拟时间
• 延迟保证中的 $e{t}_i$ 为到达曲线和服务曲线横坐标的差，$IOPS$ 保证中的 $e{t}_i$ 为曲线的斜率
• $v{t}_i$ 通过公平共享服务曲线来计算
• latency queue 和 IOPS queue 通过 $e{t}_i$ 排序，fairness queue 通过 $v{t}_i$ 排序

队列服务对应关系

• latency application guarantee: latency queue + fairness queue
• IOPS application guarantee: IOPS queue + fairness queue
• best_effort application : fairness queue

队列工作模式

• 当系统繁忙时，latency queue 服务 latency guarantee application，IOPS queue 服务 IOPS guarantee application
• 当系统不繁忙时，所有应用程序遵循公平共享原则由 fairness queue 服务，公平队列是一个分层结构，会按比例的像应用程序分配资源

时间标签计算

Latency Guarantee Application:

• $a{t}_i$ 指的是工作负载的到达时间
• $L_i$ 指的是工作负载的延迟目标
• $RTT(\frac{w}{r})$ 指的是 I/O 的往返时间

IOPS Guarantee Application：

Best-Effort Application：

分发策略

根据 I/O 的紧急状态进行分发

紧急状态计算

• ${\Gamma }_i(t)$ 代表了满足工作负载所有延迟和 IOPS 要求的最大所需的服务，还考虑了时间段 $[t,t+\tau ]$ 未来可能会缺乏服务的情况
• $b_i(t,\tau )=b_i(t+\tau )-b_i(t)$ 代表了将要到达的 I/O 请求
• $R_i(t,\tau )=R_i(t+\tau )-R_i(t)$ 代表了将来接受的 I/O 请求
• 然后由于 I/O 工作负载的动态性，$ma{x}_{\tau }(b_i(t,\tau )-R_i(t,\tau ))$ 难以计算

测量功能

latency guarantee applications：

由于到达曲线 $b_i(t)$ 永远小于达到限制 ${\mu }_i(t)$，因此 ${\Gamma }_i(t)$ 是到达曲线的上界

由于工作负载在活动和非活动之间交替可以得到以下迭代版本：

• $s^j$ 是工作负载活动的开始时间
• 当工作负载断断续续时，${\Gamma }_i^j(t)$ 需要间断更新

为了计算简单提出测量因子 ${\Delta }_i(t)$

测量因子：表示到达曲线 $b_i(t)$ 和 ${\Gamma }_i(t)$ 之间的时间间隔

IOPS Guarantee Applications：

$${\Delta }_i(t)=e{t}_i-IOPS\_et\_las{t}_i$$

重调度

• 如上可知，来自延迟保证和 IOPS 保证应用程序的 I/O 请求可以被分发到公平队列，可能会在公平队列等待一段时间，当系统的流量发生变化时，当有突发的 I/O 请求时，则在公平队列中来自延迟保证和 IOPS 保证应用程序的 I/O 请求可能会违反 QoS 目标。
• 因此若违反 QoS 目标则会重调度到 latency/IOPS queue 获得更高的优先权
• 来自三个队列的 I/O 请求都会触发重新调度检查

该算法在两种模式之间自适应的移动：优先模式和公平共享模式

• 当系统过载时，系统处于优先模式，best-effort application 会很难得到服务，容易饿死
• 当系统空闲时，系统处于公平共享模式，大多数 I/O 都由公平队列按比例服务
• 因此自适应的移动工作模式可以保证在系统过载时帮助优先 I/O 获取资源，也能防止 best-effort application 的 I/O 饿死。从而达到较高的系统利用率

实验评估

为了评估 QoS 算法，在分布式文件系统 GlusterFS-based 平台实现并测试

评估平台拓扑结构

服务器节点和客户机之间用了10G的交换机进行连接，尽可能地让平台免受网络瓶颈的影响。

两个对比实验：

• $SG-QoS$、$HFSC$ 和 $No-QoS$ 的对比
• 多个延迟目标和多个带宽目标的测试

实验一

评估了 $SG-QoS$ 算法的吞吐量和延迟。

应用程序在以下三种状态工作：

• 过饱和
• 接近饱和
• 不饱和
  其中设置的 IOPS 较大，接近系统的容量，同时改变应用程序的数量，在系统中生成不同强度的 I/O 请求。

最大响应时间可能比平均响应时间长得多，所以将响应时间升序排序，取前 95% 作为报告中的数据

Scenario I： Over-Saturation

图（a）:

• 从图 （a）表明提出 $SG-QoS$ 满足所需的吞吐量，效果优于 $No-QoS$ 和 $HFSC$
• $No-QoS$ 和 $HFSC$ 中的 BEA 比 IGA 和 LGA 有更高的吞吐量
• $No-QoS$ 没有做任何措施保护 LGA 和 IGA 不受 BEA 的影响
• $HFSC$ 虽然在 IGA 获得了比 $No-QoS$ 更好的吞吐量，但是仍然没有达到吞吐量目标，由于 $HFSC$ 中的两个分段服务曲线函数无法保证动态 I/O 工作负载下的 LGA 和 IGA
• 在这种情况下，系统处于优先工作模式，BEA 很难得到服务，是在牺牲 BEA 的情况下，LGA 和 IGA 实现了吞吐量保证

图（d）:

• 在 $No-QoS$ 下的所有应用程序获得了相近的延迟，这是因为 $No-QoS$ 并没有区别对待不同的应用程序
• $HFSC$ 有优待 LGA，但是仍然取得了不太理想的延迟性能，是因为不能够在必要时立即动态获取 I/O 的访问状态，因此 LGA 大量的 I/O 不能得到保护
• $SG-QoS$ 取得了 4.68ms 的延迟，符合延迟目标。但是 IGA 比 $No-QoS$ 和 $HFSC$ 具有更高的延迟，说明当 IGA 和 LGA 在竞争资源时，优先了 LGA，将 LGA 的延迟保证作为其第一要务，当 LGA 的延迟得到保证后，IGA 的 I/O 将会追赶它的吞吐量目标

Scenario II：Near-Saturation

IGA 的数量从 12 减少到 8，因此工作负载降低

图（b）:

• $SG-QoS$ 在 LGA 和 IGA 都满足了吞吐量目标，而 $No-QoS$ 和 $HFSC$ 均不能满足 LGA 的吞吐量目标，而相比场景1的吞吐量性能提升显示 BEA 能够在优先级较高的程序实现其目标后获得备用资源
• 在 $No-QoS$ 中，BEA 比 LGA 分配了更多的带宽，是因为 BEA 有更多的应用程序
• 在 $HFSC$ 中，静态的两条分段服务曲线不能保证 LGA 的吞吐量，因为它不适应动态 I/O 工作负载

图（e）：

• 在 $No-QoS$ 下的所有应用程序获得了相近的延迟
• $HFSC$ 不能保证 LGA 的延迟
• $SG-QoS$ 是唯一能够满足 LGA 的延迟目标

在这个场景下，$SG-QoS$ 以混合的工作模式工作，一些 LGA 和 IGA 的 I/O 请求进入到公平队列中，而一些紧急的则进入到 latency queue 和 IOPS queue 以获得更高的优先级。一旦 LGA 和 IGA 实现了它们的目标，则 BEA 可以获得备用资源，而不是饿死

Scenario III：Under-Saturation

系统运行： 4 LGAs, 8 IGAs 和 12 BEAs，跟上面的两种场景相比，系统的容量足够适用于所有应用程序

图（c）：

• 所有的算法均达到了吞吐量目标，因为系统资源的过度供应是的每个应用程序都可以获得足够的带宽
• 此场景下是公平共享的工作模式

图（e）：

• $No-QoS$ 和 $HFSC$ 均不能满足延迟目标
• $HFSC$ 尽管在带宽过度供应的情况下也无法保证动态 I/O 的延迟
• 即使在带宽过度供应的情况下，也不能说明能够保证延迟
• $SG-QoS$ 能够满足延迟目标

在这种场景下，$SG-QoS$ 将大部分 I/O 分配到公平队列中，只有少量的来自 LGA 和 IGA 的 I/O 请求由 latency 和 IOPS queues 服务。不同类型的应用程序按带宽设置的比例公平共享带宽

实验二

Scenario IV：multiple latency targets and multiple throughput targets

从上图可以看到算法 $SG-QoS$ 将不同应用程序和不同的 QoS 目标区分开来，并同时满足了各自的延迟和带宽目标

结论

• 使用三个不同的优先级队列满足应用程序不同的性能要求
• 不同类型的应用程序使用不同的服务曲线
• 不同应用程序的 I/O 请求根据服务曲线和紧急状态在三个队列之间进行调度，从而保证所有应用程序的 QoS 要求
• 将算法集成到 GlusterFS 存储系统中，并进行了深入的评估，结果表明 $SG-QoS$ 在性能保证上优于现有的 QoS 机制