平坦的数据存储中心

July 14, 2015

近期读微软的一篇paper Flat Datacenter Storag,称速度比HDFS快很多,这是不是未来存储的一个趋势呢? ###局部性问题 传统的存储模型是树状的,每一台机器都是树上的一个节点.那么接近根节点的机器的网络带宽肯定会小余在它下面机器的带宽之和.这样造成的结果就是同一个rack传输很快,而不同的rack之间或接近根节点的机器传输就很慢.

所以当效率很重要的时候,开发者就必须要考虑”rack locality”的问题. 比如现在的编程模型MapReduce, Hadoop, Dryad都要考虑局部性,就是把计算放到数据存储的地方而不是把数据转移到计算资源丰富的地方.这个模型适合于可以分解并行的操作,但并不适用于那些必须进行数据移动的操作(排序, distributed join, 矩阵操作).

局部性限制甚至有时候会降低资源利用率. 比如stragglers:如果数据只有一份, 即使其他的机器都空着,这个很慢的机器会拖慢整个任务的时间. 而把这个机器的任务给其他机器的话,就需要进行昂贵的数据移动操作.

如果带宽足够,我们没有必要做树状的存储模型, 而是平坦的存储模型flat storage model (FDS): 所有的计算节点都能以同样的速度访问所有的资源. 这样的话,就没有所谓的局部性了.

FDS的数据都存在blob (binary large object, 二进制大对象)中.向blob中读写则都是以tract为单位的.FDS中的读写都是非阻塞的,当操作完成之后会执行回调函数.FDS也不保证指令是按照收到的顺序执行的,因此client必须执行完一个指令后执行下一个.

并行存储系统的关键问题是数据的存放和归并,即:当写数据时,writer怎么决定使用哪一台服务器?reader又该如何找到之前writer写入的数据? ###元数据服务器 现有系统如HDFS主要使用元数据服务器(metadata server)解决这个问题,writer与元数据服务器通讯以寻找写入一个新数据块的位置;元数据服务器选择一个数据服务器(data server),把信息持久存储并返回给writer。reader与元数据服务器通讯找到存放这块数据的服务器。这个方法的优点在于有着最大的数据存放灵活性和系统状态的可见性。但是,也有缺点:元数据服务器是所有读写操作的关键路径,使得它易成为瓶颈。因为它是故障中心点,所以这些元数据服务器通常使用一致性协议的复制状态机来实现

FDS采取了不同的方法,确实有一个元数据服务器,在正常操作过程中其作用简单而有限:收集系统中活动的tractserver列表和分发它们的信息给客户端,这个列表叫做道定位表或TLT。

现在假设TLT是一个简单的系统tractserver列表。它的顺序是随机且一致的,即:当集 群初始化时,元数据服务器随机生成服务器列表,再把相同的列表分发给每个客户端。当客户端启动时,首先从元数据服务器获取TLT,当想读/写一个tract时,先计算tract的位置。最简单的tract定位是需读取的128位Blob GUID加上64位tract编号,再以TLT中的记录数取模。在TLT中索引这个tract位置,就可以取到读/写该tract的tractserver。读写请求包含完整的Blob GUID和tract编号及(写情况下)数据的有效负载(payload)。reader能找到之前writer写进去的数据,因为寻找tractserver的处理过程是定的:只要有与writer写入该tract时相同的TLT,reader的TLT查找结果将跟writer一样,指向同一个的tractserver。

如果觉得有用,请点star