[PACT'13] S-CAVE

S-CAVE: Effective SSD Caching to Improve Virtual Machine Storage Performance

论文概要

Abstract

SSD Cache系统的两个目标：

  1. 最大化利用共享的SSD Cache；

  2. 保证VM之间的性能隔离

本文设计并实现了S-CAVE，一个基于hypervisor的SSD caching工具，从①VM，②存储设备收集并利用runtime信息。

不需要修改① guest OS, ② 用户应用 和 ③ 下方的存储系统。

需要解决关键问题： 如何在多个VM之前分配有限的共享SSD cache，来实现目标。

主要通过两个步骤实现：

  1. 提出一个有效的metric来决定每个VM对SSD缓存空间的需求；

  2. 将缓存需求信息纳入动态控制机制，S-CAVE能够有效地为每个虚拟机提供公平的缓存空间份额，同时实现最佳利用共享固态硬盘缓存设备的目标。

按照hypervisor的限制，S-CAVE最小化了memory space和计算时间的开销。在vSphere ESX这个被广泛使用的VMWare商用hypervisor上进行了实现。实验展示出了它对数据密集型应用的strong effectiveness。

文章的思路

如下图所示，在多个虚拟机共享SSD缓存系统的情况下，SSD缓存的位置有三个选项。

S-CAVE

  • 选择1：直接由VM申请虚拟的SSD（本质上是一种静态分区技术）

    • 对VM来说将能发挥出最大的性能，因为它有丰富的信息，同时又能完全控制SSD cache

    • 保证了虚拟机之间的隔离性，因为他们的cache空间互不干扰

    • （缺）需要修改Guest OS 或者应用，从而可以管理缓存设备。这几乎难以实现

    • （缺）固态盘的大小无法动态调整，因此无法最大化存储资源利用率（像DRAM那样swap in/out的成本是很高的）

  • 选择2：固态盘cache作为存储系统的一部分，可以是主机端或者远程存储服务器

    • easy-to-use

    • 只需要在存储系统内部改进，无需VM或者hypervisor参与

    • （缺）虚拟化系统和存储系统之间是原始的块设备接口，语义信息传递很有限，无法最优化整体性能

    • （缺）虚拟机系统和存储系统的管理是没有联系的，因此虚拟机之间可能发生I/O干扰

  • 选择3：固态盘cache由虚拟机管理程序直接管理

    • 可以以透明的方式管理固态盘cache，不需要修改Guest OS或者应用；

    • 大多数请求，尤其是所有的I/O都要经过hypervisor，在收集关键信息方面很有优势

    • hypervisor有对硬件资源的完全访问权限，因此可以直接执行空间分配，最大限度提高资源利用。

通过上述分析，本文在hypervisor中进行SSD缓存的分配，总体设计如下图所示。

图2a 整体架构

每个VM都有一个Cache Monitor模块，这个模块有两个作用：

  • 管理其分配的Cache

  • 保证Cache对VM透明

为了在多个VM之间有效分配Cache空间，又设置了一个Cache Space Allocator，用来收集并分析来自每个Cache Monitor的缓存使用信息，并作出缓存分配决策。

下图是Cache Monitor和Block Management的详细视图：

图2b

几个定义：

  • Global Pool：cache设备的所有block的集合

  • Private Pool：分配给一个VM的一组数据块

每个Block又三个元数据字段：引用计数器、脏位以及VM标识（VM ID）。引用计数器记录块上的命中次数，并在块重新加载新数据时重置为零。脏位由写操作设置。虚拟机标识标记块的所有权。Private Pool中的所有数据块具有相同的虚拟机标识，一个空闲数据块的VM ID是“null”。

Cache Monitor由3个组件组成：

  • Hash table：用于在cache设备上查找块，{LBN, CBN};

  • Space Manager：管理VM的private pool中的块。包括：

    • cache的insert、eviction等正常操作

    • 从globa pool中取空闲块，扩展Private Pool

    • 释放private pool的块，放回global pool

  • Statistic collector：观察private pool的i/o活动，用来更新rECS、AllocUnit以及其他信息

Cache Space Allocator扮演中央控制角色，并负责根据来自每个虚拟机的统计收集器的信息，在多个虚拟机之间做出cache分配决策。

S-CAVE的关键就是为每个VM分配合适比例的cache空间，这个可以分为两步：

  1. 确定每个VM的cache需求

  2. 根据所有VM的需求来总体划分cache空间

下面具体讲一下这两步如何进行。

确定一个VM的Cache需求

确定cache需求有一些相关的研究，比如

  • CPU cache：通过每个cache unit的命中率

  • main memory: 时间窗口中命中率的变化

这些都和SSD cache不兼容：

  1. cpu cache、Memory cache的过滤作用，SSD cache观察到的局部性弱很多；

  2. SSD cache通常容量很大，这进一步降低了命中率的优势和敏感性

因此，本文采取rECS作为需求的指标。

rECS: Ratio of Effective Cache Space

有效使用的cache空间（给定时间窗口内，访问的unique cache单元的个数） / 已分配的cache空间总大小

rECS的runtime评估

这个与Cache替换算法的选择有很大关系，这里选择CLOCK策略，可以用数组来实现，而不是链表。CLOCK的低锁争用和低空间开销是很重要的原因。每个空间管理器都维护自己的时钟来管理其private pool。

每个VM有两个计数器NVMiallN_{VM_i}^{all}和NVMieN_{VM_i}^e，前者是分配给VMiVM_i的总块数，后者是给定时间窗口内访问过的块数。

为了获得准确的rECS值，我们需要在一个时间窗口内完成对所有参考计数器的扫描。因此，我们面临着准确性和效率之间的权衡。一个小的时间窗口可以实现及时的缓存分配调整，但使按时完成完整扫描变得不切实际。较长的时间窗口允许扫描按时完成，但会降低缓存分配对运行时动态的响应。因此这里采用了抽样技术，每个时间窗口被分成多个小的采样周期，并由空闲周期交错，以最小化计算开销。在每个采样周期内，扫描从随机块开始，当采样周期超时时停止。时间窗口的最终rECS值是所有采样周期的平均值。

为了进一步降低精度损失，我们使用平滑参数α，参考前面的旧值：

rECS=rECSold∗α+rECSsampled∗(1−α)rECS = rECS_{old} * \alpha + rECS_{sampled}*(1-\alpha)

确定一个VM的Cache需求

具体算法如下图所示：

Algo 1

Allocation Unit: 算法每次调整虚拟机的Cache空间，变化量都是AllocUnit(VMi)AllocUnit(VM_i)决定的，这个是虚拟机在一个时间窗口内可以从硬盘访问的平均块数。换句话说，本质上这是VM最近miss的I/O的吞吐。

我的思考

Previous[MSST'14] CBM

Last updated

Was this helpful?