如何发挥快存储作I/O缓存的潜能

近些年，I/O密集型应用（如数据库，VDI等）在企业级场景中应用广泛。这类应用往往对I/O速率和延迟有较高的要求。为了满足前端应用的需求，同时考虑到性价比，后端存储往往采用I/O缓存+主存储的架构。过去，I/O缓存采用SSD而主存储采用HDD，如今随着超快存储的普及以及SSD成本的下降，超快存储（I/O缓存）+SSD（主存储）的架构开始进入大众视野，这类新架构存在什么新挑战？旧架构中的配置能否直接用于新架构？本文将通过详细的研究为您揭开面纱。

一、研究背景

存域网（Storage Area Network，简称SAN）把多个服务器连接到一个共享存储池中，在企业环境下被广泛应用。如下图1，主机层（Host Layer）包括了连接到SAN的各个服务器，各种企业负载运行在服务器上，通过专用的网络（如光纤）访问后端存储。存储层（Storage Layer）主要是存储设备，如SATA SSD、NVMe 设备。存储设备分为主存储和I/O缓存。主存储通常被组织为RAID，以进行数据保护。

图1 I/O密集应用与存域网

正如前文所说，I/O缓存则可以是超快存储，如P5800X Optane SSD、Intel持久化内存等。它们的性能、价格与传统SATA SSD的对比如下表1所示。可见无论是随机读写带宽还是延迟，超快存储都比SATA SSD好，但是价格也贵了不少。纯粹用超快存储作为后端存储不现实，将它们当作现有SSD存储阵列之上的小型I/O缓存才是良计。

表1 三类超快存储与SATA SSD的工艺、接口、性能、架构对比表

二、研究动机

过去针对超快存储+SSD架构的研究要么假定了某个特殊场景、要么只考虑简单的架构，无法为企业级SAN架构的应用提供参考。当然，还需要考虑一个前提是：我们是否需要重构I/O缓存架构？能否依照旧的SSD+HDD架构下的相关研究进行配置？

答案是：要。

在新的架构下，首先，缓存架构的选择本身已经成为性能瓶颈，而旧架构下设备才是。如下图2（a）所示。作者比较了三类开源的工业级的缓存架构：OpenCAS、DM-Cache和EnhanceIO，并且下发4K读，比较了100%和85%潜在的缓存命中率的区别，可见在传统SSD-HDD架构下，瓶颈在设备上，各个架构的表现差异不大；而在新的Ramdisk-SSD架构下，不同缓存架构带来的IOPS差异明显。

其次，如下图2（b）所示，传统缓存架构下，缓存命中率下降会带来带宽下降，但新架构下未必，把部分I/O适当offload到主存储可以均衡负载，反而可以提高带宽。这种性能趋势的差异进一步验证了重构缓存架构的必要性。

图2 重构I/O缓存的动机

三、研究内容：缓存架构分析框架

为了充分理解超快存储作为I/O缓存时的行为并为之后的设计做准备，作者提出一个实验分析框架，包含以下四个要点：

1）使用工业级的I/O缓存模块；

2）使用真实的系统和数据；

3）结合实验结果与源码，分析工业级I/O缓存；

4）设计多种测试用例以覆盖I/O工作集的各种访问模式，同时结合真实的trace进行最终分析。

首先，I/O缓存大致可以分为三个模块：查询策略、cacheline大小与缓存提升策略和缓存刷回策略。如下表2所示，其中CG表示粗粒度，FG表示细粒度，HT表示重度多线程，LT表示轻度多线程。在后续的实验中，主要讨论以下三个问题：

什么样的查询逻辑能保证最好的并行性？
cacheline大小多少比较合适？缓存提升策略该用哪种？
缓存刷回策略该用哪种？

表2 I/O缓存模块的组成

其次，整个分析框架与系统执行流如下图3所示。首先看（a），简单来说，首先输入软硬件场景配置和I/O缓存模块配置，并且输入测试场景，随后生成测试负载，配置存储架构，随后开始性能测试，在测试过程中，记录(a)中Log Recording中的四个指标，测试完成后，Offline Part会自动处理所记录的指标，生成分析图表。（b）则为系统架构，由图可见，作者利用Linux的Device Mapper封装了各类缓存架构，并根据设备层的I/O调度器决定数据存入I/O缓存或者主存。

图 3 分析框架（a）与系统启动后的执行流程（b）

在测试分析中，用到的I/O缓存架构与相关配置如下表3所示。

表3 使用到的I/O缓存架构

其他配置为：

I/O缓存：RAMDisk
主存储：9×Samsung SM863a 1.92TB SSDs (MegaRAID9361)
存储服务器：: Chenbro with dual-socket Intel Xeon E5-2620 v4 8-core CPUs（32 logical cores）
真实负载：
VDI Traces （读密集）：I/O缓存大小为工作集的1%
Microsoft Exchange Traces（半读半写）：I/O缓存大小为工作集的5%
Oltpbench TPCC（写密集）：I/O缓存大小为工作集的5%

四、分析与发现

4.1查询管理：如何实现最佳的并行性？

三类（从左至右依次为OpenCAS、DM-Cache和EnhanceIO）查询架构如下图4所示。