FAST 16论文sRoute：treating the Storage Stack Like a Network学习记录

论文原文PDF: sRoute: treating the Storage Stack Like a Network

出处：USENIX FAST 16

1. 概述

数据中心中，数据从一个应用最终到达存储服务器不仅要经过网络，还要经过很多的存储层次，这些层次可以称为存储栈(Storage stack)。对于数据中心中一个较为复杂的应用，一个IO请求甚至要经过应用缓存层、虚拟机操作系统(Guest OS)文件系统页高速缓存、Guest OS文件系统、Guest OS IO调度层、Guest OS块缓存、Guest OS块设备驱动、虚拟机管理器、宿主机操作系统(Host OS)网络驱动、缓存服务器、远程存储服务器缓存、远程存储服务器文件系统、远程存储服务器物理磁盘等多达十几层的存储阶段(Stage)。

而一般IO经过这些stage最终到达终点的路径是预先制定好的，这条路缺乏灵活性(hard-coded)，即使仅想改变其中的某个stage，实际更改的时候也可能会涉及到这个stage之上和之下的多个stage。

本文仿照软件定义网络(SDN)的思想，提出了一种软件定义存储的架构sRoute，从原始的数据中心存储中心抽象出数据平面和控制平面，控制平面上的中心化controller随时可以对数据平面上的存储交换机sSwitchs安装“转发规则”，来实时控制IO路径。这样，就实现了包括改变终点、改变中间路径和将点对点路径散布为一点对多点在内的三种基本IO路径更改方法。

2. 整体设计

2.1. 数据平面和sSwitch

数据平面包括原有IO栈的各个stage和本文新加入的特殊stage sSwitch。sSwitch可以插入到IO路径的中任意的stage中，其根据当前的”IO转发规则”对IO进行转发。具体的，sSwitch会检测每个IO请求的header，根据header中包含的IO源点和目的点信息来和当前sSwtich所存的”IO转发规则”进行匹配，然后根据对应规则进行转发。

例1 把所有从VM~1~中到服务器S~1~文件X的读请求都路由到S~2~文件Y，那么VM~1~和S~2~之间的任意一个sSwitch的转发规则可以这样表示：

<VM1, r, //S1/X>  -> (return <IO, //S2/Y>)

例2 把所有到服务器S~1~文件X的IO请求路径中间加入缓存服务器C，那么C中的sSwitch的转发规则可以是这样的：

<*, *, //S1/X> -> (return <IO, //C/X>)
<C, *, //S1/X> -> (return <IO, //S/X>)

2.2. 控制平面和Controller

用户或Controller可以将通过以下四种控制平面API调用，相应的IO转发规则被Controller装入到sSwitch中的，这是Controller最基本的功能。

例对于2.1.节中的例1来说，如果Controller现在要把转发终点从//S2/Y更改为//S3/Z，那么，那么Controller会对那个sSwitch调用以下API指令：

Quiece(<VM1, r, //S1/x>, True)                      //阻塞要更改的路径
Drain(<VM1, r, //S1/x>)                             //将已接到的要更改路径的请求转发完毕
Delete(<VM1, r, //S1/X>  -> (return <IO, //S2/Y>))   //删除老规则
Insert(<VM1, r, //S1/X>  -> (return <IO, //S3/Z>))   //添加新规则
Quiece(<VM1, r, //S1/x>, False)                     //解除阻塞，路径更换完成

除此之外，Controller还应具备将用户策略翻译为控制指令的功能，和判断将规则插入到哪个sSwitch可以获得更小性能开销的功能。

3. 具体实现

sSwitch分为内核部分和用户空间部分，内核部分负责IO分类和服务器内的路由，用户空间部分负责文件级的进一步分类和将IO转发到远程服务器，总共2.5万行代码。controller是用C#语言在用户空间实现的。

服务器内的路由：借助Windows系统的filter driver架构实现。kernel中每个存储层stage都会加入一个filter driver ，来根据控制是否让IO流过当前stage。
远程服务器间的路由：先将IO传到用户空间的sSwitch，sSwitch会通过TCP或RDMA协议传输IO到目的远程服务器。
实现上的局限：对于字节范围的文件锁无法支持，因为这是原来的终点stage的文件系统支持的，而改变终点时，sSwitch的在文件系统之上。

4. 问题和局限性

4.1. 一致性问题

当一个转发规则要发生改变时，要保证每个IO的一致性(per-IO consistency)和每组IO流的一致性(per-Flow consistency)。即对于同一个IO，其路径只能遵循一个IO路径，中途不能改变；对于前后关联的一组IO，要保证路径改变前后不产生请求错误。

per-IO的情况比较容易，用Quiece、Drain API就可以解决，如2.2节中的例子。

per-Flow的情况，由于同一组的两个IO可能来自不同的源，所以带来了多个源的同步的问题。本文给出的基本的解决方案，是类似”两阶段提交”的方法：第一阶段对于所有的源都进行阻塞并在成功后发起同步，所有源之间都确定完成第一阶段之后，才进行第二阶段更改转发规则。对于这种方案，在controller进行插入sSwitch规则时，插入规则的地点也会有多重选择(如下图)，根据方案的不同，发生同步的地点和涉及到的sSwitch数量也不同，而具体哪一种插入方案的效率较高，要由具体的工作负载决定。

4.2. 容错和可用性问题

对于controller: 中心化的controller可以通过副本和类似Paxos的技术实现可用性，这样即使一个controller不可用时，也只会导致性能下降，而不是发生错误。

对于存储转发规则：sSwitch的转发规则也采用了一种新的元数据，用于实现记录sSwitch的所有规则，以加快规则的更改切换；controller也可以在向sSwitch安装规则之前保有所有规则，并进行3副本容错。并且，在每个IO的header中都保有转发规则，这样，在sSwitch不可用时，也可以保证controller知道将IO转发的目的地。

4.3. 局限性

sRoute当前没有提供验证规则是否可行的功能，这样，如果认为制定规则时给出了不可行的路径，就会导致数据丢失。
如果sRoute可以同时控制网络和存储，将会有更好的效果。

5. 三个应用场景

本文具体讲述了3个能从sRoute中得到好处应用场景，分别对应最开始提到的3种最基本的IO路径改变方法。3种场景的具体分析见原论文。

负载均衡实现的尾延迟控制(对应endpoint)
副本集的控制(对应scatter)
文件缓存的控制(对应waypoint)

JciX ~

Jc's Blog