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路径更改方法。

pic1

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的转发规则可以这样表示:

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

2.2. 控制平面和Controller

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

pic2

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

除此之外,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数量也不同,而具体哪一种插入方案的效率较高,要由具体的工作负载决定。

pic3

4.2. 容错和可用性问题

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

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

4.3. 局限性

  1. sRoute当前没有提供验证规则是否可行的功能,这样,如果认为制定规则时给出了不可行的路径,就会导致数据丢失。

  2. 如果sRoute可以同时控制网络和存储,将会有更好的效果。

5. 三个应用场景

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

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

发表评论

电子邮件地址不会被公开。 必填项已用*标注