大规模分布式存储系统-分布式文件系统

存储 存储软件 分布式 分布式
分布式文件系统是分布式存储系统(键值系统、表格系统、数据库系统)的底层基础部件,其所起的主要功能有两个:一个是存储文档、图像、视频之类的Blob类型数据;另外一个是作为分布式表格系统的持久化层。

分布式文件系统是分布式存储系统(键值系统、表格系统、数据库系统)的底层基础部件,其所起的主要功能有两个:一个是存储文档、图像、视频之类的Blob类型数据;另外一个是作为分布式表格系统的持久化层。

我们来看看业界是如何构建各家基础的分布式文件系统。

[[206500]]

Google文件系统(GFS)

GFS系统的节点可分为三种角色:GFS Master(主控服务器)、GFS ChunkServer(CS,数据块服务器)以及GFS客户端。GFS文件被划分为固定大小的数据块(chunk),由主服务器在创建时分配一个64位全局唯一的chunk句柄。CS以普通的Linux文件的形式将chunk存储在磁盘中。为了保证可靠性,chunk在不同的机器中复制多份,默认为三份。客户端访问GFS时,首先访问主控服务器节点,获取与之进行交互的CS信息,然后直接访问这些CS,完成数据存取工作。需要注意的是,GFS中的客户端不缓存文件数据,只缓存主控服务器中获取的元数据,整体架构如图1所示。

1、租约机制

GFS系统中通过租约( lease)机制将chunk写操作授权给ChunkServer。拥有租约授权的ChunkServe称为主ChunkServer,其他副本所在的ChunkServer称为备ChunkServer。租约授权针对单个chunk,在租约有效期内,对该chunk的写操作都由主ChunkServer负责,从而减轻Master的负载。一般来说,租约的有效期比较长,比如60秒,只要没有出现异常,主ChunkServer可以不断向Master请求延长租约的有效期直到整个chunk写满。GFS为每个chunk维护一个版本号,每次给chunk进行租约授权或者主ChunkServer重新延长租约有效期时,Master会将chunk的版本号加1。

主ChunkServer向Master重新申请租约并增加对应副本的版本号,如果有备副本下线的话,重新上线后如果版本号太低,会被Master发现,从而将其标记为可删除的chunk,Master的垃圾回收任务会定时检查,并通知ChunkServer将此副本回收掉,从以上机制可见,版本号在整个机制中起到了至关重要的作用。

2、一致性模型

GFS主要是为了追加(append)而不是改写(overwrite)而设计的。一方面是因为改写的需求比较少,或者可以通过追加(加上版本号)来实现,比如可以只使用GFS的追加功能构建分布式表格系统Bigtable;另一方面是因为追加的一致性模型相比改写要更加简单有效。这种模式下,可能出现记录在某些副本中被追加了多次,即重复记录;也可能出现一些可识别的填充记录,应用层需要能够处理这些问题(幂等)。GFS的这种一致性模型是追求性能导致的,这增加了应用程序开发的难度。

3、追加流程

图2中,分离数据流与控制流主要是为了优化数据传输,每一台机器都是把数据发送给网络拓扑图上“最近”的尚未收到数据的节点。

4、容错机制

  • Master容错

操作日志+checkpoint+实时热备。GFS Master的修改操作总是先记录操作日志,然后修改内存。当Master发生故障重启时,可以通过磁盘中的操作日志恢复内存数据结构。另外,为了减少Master宕机恢复时间,Master会定期将内存中的数据以checkpoint文件的形式转储到磁盘中,从而减少回放的日志量。所有的元数据修改操作都必须保证发送到实时热备才算成功。

  • ChunkServer容错

GFS采用复制多个副本的方式实现ChunkServer的容错,另外,ChunkServer会对存储的数据维持校验和。GFS以64MB为chunk大小来划分文件,每个chunk又以Block为单位进行划分,Block大小为64KB,每个Block对应一个32位的校验和。当读取一个chunk副本时,ChunkServer会将读取的数据和校验和进行比较,如果不匹配,就会返回错误,客户端将选择其他ChunkServer上的副本。

5、Master设计

由于GFS中的文件一般都是大文件,因此,文件命名空间占用内存不多。这也就说明了Master内存容量不会成为GFS酌系统瓶颈;另外,从负载均衡的角度考虑,可以限制每个Chunk-Server“最近”创建的数量;每个chunk复制任务都有一个优先级,按照优先级从高到低在Master排队等待执行;Master会定期扫描当前副本的分布情况,如果发现磁盘使用量或者机器负载不均衡,将执行重新负载均衡操作;在进行副本重均衡时,要注意限制拷贝速度,否则会影响性能。

  • 垃圾回收

GFS采用延迟删除的机制,Master定时检查,如果发现文件删除超过一段时间(默认为3天,可配置),那么它会把文件从内存元数据中删除,为了减轻系统的负载,垃圾回收一般在服务低峰期执行,比如每天晚上凌晨1:00开始。系统对每个chunk都维护了版本号,过期的chunk可以通过版本号检测出来。Master仍然通过正常的垃圾回收机制来删除过期的副本。

  • 快照

快照( Snapshot)操作是对源文件/目录进行一个“快照”操作,生成该时刻源文件/目录的一个瞬间状态存放于目标文件/目录中o GFS中使用标准的写时复制机制生成快照,也就是说,“快照”只是增加GFS中chunk的引用计数,表示这个chunk被快照文件引用了,等到客户端修改这个chunk时,才需要在ChunkServer中拷贝chunk的数据生成新的chunk,后续的修改操作落到新生成的chunk上。(不改就不拷贝,只引用)

6、 ChunkServer设计

Linux文件系统删除64MB大文件消耗的时间太长且没有必要,因为ChunkServer是一个磁盘和网络IO密集型应用,因此,删除chunk时可以只将对应的chunk文件移动到每个磁盘的回收站,以后新建chunk的时候可以重用。

自动化对系统的容错能力提出了很高的要求,Google在软件层面的努力获得了巨大的回报,由于软件层面能够做到自动化容错,底层的硬件可以采用廉价的错误率较高的硬件,比如廉价的SATA盘,这大大降低了云服务的人力及硬件成本。

Google的成功经验也表明了一点:单Master的设计是可行的。单Master的设计不仅简化了系统,而且还能够较好的实现一致性。另外,Master维护的元数据很多,需要设计高效的数据结构,占用内存小,并且能够支持快照操作。支持写时复制的B树能够满足Master的元数据管理需求,然而,它的实现是相当复杂的。

Taobao File System

TFS设计时采用的思路是:多个逻辑图片文件共享一个物理文件。通过<块ID,文件编号>来唯一确定一个文件。

1、系统架构

  • TFS整体架构

NameServer通过心跳对DataServer的状态进行监测;每个DataServer上会运行多个dsp进程,一个dsp对应一个挂载点,这个挂载点一般对应一个独立磁盘,从而管理多块磁盘,TFS中Block的实际数据都存储在DataServer中,大小一般为64MB,默认存储三份。

TFS是写少读多的应用,即使每次写操作都需要经过NameNode也不会出现问题,这大大简化了系统的设计,同一时刻每个Block只能有一个写操作,多个客户端的写操作会被串行化。客户端首先向NameServer发起写请求,NameServer需要根据DataServer上的可写块、容量和负载加权平均来选择一个可写的Block,并且在该Block所在的多个DataServer中选择一个作为写入的主副本(Primary),如果所有的副本都修改成功,主副本会首先通知NameServer更新Block的版本号,成功以后才会返回客户端操作结果,整个流程如图3所示。

2、讨论

相比GFS,TFS的写流程不够优化,***,每个写请求都需要多次访问NameServer;第二,数据推送也没有采用流水线方式减小延迟。这也是由特定历史时期的特定业务需求所决定的,淘宝的系统是需求驱动,用***的成本、最简单的方式解决用户面临的问题,TFS NameServer不需要保存文件目录树信息,也不需要维护文件与Block之间的映射关系。

由于用户可能上传大量相同的图片,因此,图片上传到TFS前,需要去重。一般在外部维护一套文件级别的去重系统( Dedup),采用MD5或者SHA1等Hash算法为图片文件计算指纹( FingerPrint)。图片写入TFS之前首先到去重系统中查找是否存在指纹,如果已经存在,基本可以认为是重复图片;图片写入TFS以后也需要将图片的指纹以及在TFS中的位置信息保存到去重系统中。去重是一个键值存储系统,淘宝内部使用Tair来进行图片去重。图片的更新操作是在TFS中写入新图片,并在应用系统的数据库中保存新图片的位置,图片的删除操作仅仅在应用系统中将图片删除。

随着系统的规模越来越大,商用软件往往很难满足需求,通过采用开源软件与自主开发相结合的方式,可以有更好的可控性,系统也有更高的可扩展性。互联网技术的优势在于规模效应,随着规模越来越大,单位成本也会越来越低。

3、内容分发网络

淘宝CDN采用分级存储。由于缓存数据有较高的局部性,在Squid服务器上使用SSD+SAS+SATA混合存储,图片随着热点变化而迁移,最热门的存储到SSD,中等热度的存储到SAS,轻热度的存储到SATA。通过这样的方式,能够很好地结合SSD的性能和SAS、SATA磁盘的成本优势。

责任编辑:武晓燕 来源: 码码的土狼
相关推荐

2017-10-27 08:40:44

分布式存储剪枝系统

2017-09-04 08:49:17

存储原理架构

2017-07-18 09:51:36

文件存储系统

2017-04-14 09:48:25

分布式存储系统

2010-11-01 05:50:46

分布式文件系统

2017-10-16 10:24:47

LogDevice存储系统

2017-12-18 10:47:04

分布式存储数据

2018-09-29 14:08:04

存储系统分布式

2013-03-22 14:44:52

大规模分布式系统飞天开放平台

2018-11-20 09:19:58

存储系统雪崩效应

2017-10-19 08:45:15

存储系统HBase

2017-10-12 09:36:54

分布式存储系统

2016-01-12 14:59:40

分布式存储分布式存储架构

2010-11-15 13:24:07

分布式文件系统

2013-06-18 14:00:59

HDFS分布式文件系统

2013-01-07 10:29:31

大数据

2012-08-31 16:04:11

HDFS分布式文件系统

2010-06-04 18:45:43

Hadoop分布式文件

2012-09-19 13:43:13

OpenAFS分布式文件系统

2012-09-19 15:05:24

MogileFS分布式文件系统
点赞
收藏

51CTO技术栈公众号