[FAST'20] DC-Store
DC-Store: Eliminating Noisy Neighbor Containers using Deterministic I/O Performance and Resource Isolation
作者机构： KAIST, Samsung
论文概要
Abstract
DC-Store是一个storage framwork，可以在多容器执行环境下提供确定的I/O性能。DC-Store在硬件级别上实现了多个NVM sets，通过消除内部的资源竞争，每个NVM Set都可以保证可确定的SSD访问时间。在并行性方面，DC-Store的软件支持可以感知NVM Sets，而且可以启发Linux Kernel在NVM Set之间隔离Noisy Neighbor、进行page frame的回收。 我们对DC-Store的硬件和软件进行原型化，并在一个真实的系统中对它们进行评估。评估结果表明，与baseline系统相比，DC-Store上的容器数据密集型应用程序的平均执行时间缩短了31%。
硬件级设计
如果仅仅将SSD进行分区，然后供多个container使用，在底层的闪存上会有很多的冲突。
其实这是一个很显然的问题。对SSD进行逻辑分区，其实是一种比较奇怪的做法。除非对SSD进行特殊处理，不然在FTL层进行地址映射之后，其物理地址空间都是重叠的。
Overview
如图a，SSD向上暴露多个存储卷，每个都有自己的firmware，比如FTL。对上层来说，这些都是物理区分的NVM Sets。因此，host需要在不同的NVM Set上部署完全不同的存储堆栈实例，每个实例都可以mount到不同的容器上。
硬件设计
如图b。Divided SSD有很多低功耗的cores，每个都有instruction/data memory (I-cache/D-cache) 。同时也有自己的scratchpad memory，用做延迟敏感的、或者共享data的访问。这些core都通过LPDDR4与一个全局的DRAM相连，这个DRAM也可以通过DMA访问。这个DRAM可以用来缓存host段的请求，以及管理FTL的映射信息。每个core都可以有一个或多个闪存控制器(FMC)，每个core都连接着闪存channels。
全局DRAM的存储地址空间从一开始就分配给了每个core。由于禁用了last-level的cache，闪存固件实例，不同core之间的操作不会互相干扰。
这种静态划分的策略，使得multi-core管理变得简单；同时允许flash固件同时操作相互隔离的、不同的DRAM和存储区域，因此每个NVM Set的FTL可以相互独立地进行地址转换。
NVM set control
host端连接下层的core/firmware需要通过PCIe physical functions (PFs)。虽然在理想情况下，PF的数量是不受限制的，但是在真实场景下，PF的数量往往是受限的，很可能是小于core的数量的，因此本文还提出了NVM set-aware command arbitrator (SACA)。
SACA的作用是以round-robin的策略分发NVMe请求队列（SQ）中的请求。 这样即便PF的数量是小于core数的，依然可以并行地为每个SQ的不同NVM sets发出NVMe, SSD可以在不同flash通道上为其提供服务。 总之就是，即便PF个数首先，SACA可以将同一个SQ/CQ的请求派遣到不同的NVM sets中。
I/O Tacker:系统级支持
page frame回收干扰。由于在Linux中，container是被当值一个进程来处理的，因此请求页面调度(demand paging)导致的I/O请求都会只想host操作系统指定的swap disk 或者 file上，这是仅仅通过设备级性能隔离无法解决的问题。
他们在这里做了实验，在第一个分区上运行读请求（fio），后面的分区运行memory hungry application。随着后面分区的增多，第一个分区依然受到很大影响。 “this unfortunately makes the average and worst-case latency of random reads as high as 22% and 931%, respectively.”
基于所有权的I/O隔离
为了消除memory-hungry容器对其他容器的影响，本文设计的I/O Tacker将swap area绑定到了固定的NVM set上。
后面的部分由于与kernel联系紧密，暂时没有往后看。日后有需求再看。
我的思考
引用格式
GB/T
Last updated
Was this helpful?