Chinaunix首页 | 论坛 | 博客
  • 博客访问: 58514
  • 博文数量: 16
  • 博客积分: 494
  • 博客等级: 下士
  • 技术积分: 140
  • 用 户 组: 普通用户
  • 注册时间: 2010-05-26 16:28
文章分类

全部博文(16)

文章存档

2012年(16)

我的朋友

分类: 服务器与存储

2012-05-28 13:03:30

TFS(淘宝文件系统)架构机制篇
来源:未知 2011-07-27 16:14 
导读:TFS总体架构:一个TFS集群由两个NameServer节点,在TFS中,将大量的小文件(实际用户文件)合并成为一个大文件,这个大文件称为块(Block)。

 -  -  -  -  -  -  - 

TFS(Taobao FileSystem)是一个高可扩展、高可用、高性能、面向互联网服务的分布式文件系统,主要针对海量的非结构化数据,它构筑在普通的Linux机器集群上,可为外部提供高可靠和高并发的存储访问。TFS为淘宝提供海量小文件存储,通常文件大小不超过1M,满足了淘宝对小文件存储的需求,被广泛地应用在淘宝各项应用中。它采用了HA架构和平滑扩容,保证了整个文件系统的可用性和扩展性。同时扁平化的数据组织结构,可将文件名映射到文件的物理地址,简化了文件的访问流程,一定程度上为TFS提供了良好的读写性能。

TFS的总体结构

一个TFS集群由两个NameServer节点(一主一备)和多个DataServer节点组成。这些服务程序都是作为一个用户级的程序运行在普通Linux机器上的。

在TFS中,将大量的小文件(实际数据文件)合并成为一个大文件,这个大文件称为块(Block), 每个Block拥有在集群内唯一的编号(Block Id), Block Id在NameServer在创建Block的时候分配, NameServer维护block与DataServer的关系。Block中的实际数据都存储在DataServer上。而一台DataServer服务器一般会有多个独立DataServer进程存在,每个进程负责管理一个挂载点,这个挂载点一般是一个独立磁盘上的文件目录,以降低单个磁盘损坏带来的影响。

NameServer主要功能是: 管理维护Block和DataServer相关信息,包括DataServer加入,退出, 心跳信息, block和DataServer的对应关系建立,解除。正常情况下,一个块会在DataServer上存在, 主NameServer负责Block的创建,删除,复制,均衡,整理, NameServer不负责实际数据的读写,实际数据的读写由DataServer完成。

DataServer主要功能是: 负责实际数据的存储和读写。

同时为了考虑容灾,NameServer采用了HA结构,即两台机器互为热备,同时运行,一台为主,一台为备,主机绑定到对外vip,提供服务;当主机器宕机后,迅速将vip绑定至备份NameServer,将其切换为主机,对外提供服务。图中的HeartAgent就完成了此功能。

整体结构图
 

TFS的块大小可以通过配置项来决定,通常使用的块大小为64M。TFS的设计目标是海量小文件的存储,所以每个块中会存储许多不同的小文件。DataServer进程会给Block中的每个文件分配一个ID(File ID,该ID在每个Block中唯一),并将每个文件在Block中的信息存放在和Block对应的Index文件中。这个Index文件一般都会全部load在内存,除非出现DataServer服务器内存和集群中所存放文件平均大小不匹配的情况。

另外,还可以部署一个对等的TFS集群,作为当前集群的辅集群。辅集群不提供来自应用的写入,只接受来自主集群的写入。当前主集群的每个数据变更操作都会重放至辅集群。辅集群也可以提供对外的读,并且在主集群出现故障的时候,可以接管主集群的工作。

平滑扩容

原有TFS集群运行一定时间后,集群容量不足,此时需要对TFS集群扩容。由于DataServer与NameServer之间使用心跳机制通信,如果系统扩容,只需要将相应数量的新DataServer服务器部署好应用程序后启动即可。这些DataServer服务器会向NameServer进行心跳汇报。NameServer会根据DataServer容量的比率和DataServer的负载决定新数据写往哪台DataServer的服务器。根据写入策略,容量较小,负载较轻的服务器新数据写入的概率会比较高。同时,在集群负载比较轻的时候,NameServer会对DataServer上的Block进行均衡,使所有DataServer的容量尽早达到均衡。

进行均衡计划时,首先计算每台机器应拥有的blocks平均数量,然后将机器划分为两堆,一堆是超过平均数量的,作为移动源;一类是低于平均数量的,作为移动目的。

移动目的的选择:首先一个block的移动的源和目的,应该保持在同一网段内,也就是要与另外的block不同网段;另外,在作为目的的一定机器内,优先选择同机器的源到目的之间移动,也就是同台DataServer服务器中的不同DataServer进程。
当有服务器故障或者下线退出时(单个集群内的不同网段机器不能同时退出),不影响TFS的服务。此时NameServer会检测到备份数减少的Block,对这些Block重新进行数据复制。

在创建复制计划时,一次要复制多个block, 每个block的复制源和目的都要尽可能的不同,并且保证每个block在不同的子网段内。因此采用轮换选择(roundrobin)算法,并结合加权平均。

由于DataServer之间的通信是主要发生在数据写入转发的时候和数据复制的时候,集群扩容基本没有影响。假设一个Block为64M,数量级为1PB。那么NameServer上会有 1 * 1024 * 1024 * 1024 / 64 = 16.7M个block。假设每个Block的元数据大小为0.1K,则占用内存不到2G。

存储机制

在TFS中,将大量的小文件(实际用户文件)合并成为一个大文件,这个大文件称为块(Block)。TFS以Block的方式组织文件的存储。每一个Block在整个集群内拥有唯一的编号,这个编号是由NameServer进行分配的,而DataServer上实际存储了该Block。在NameServer节点中存储了所有的Block的信息,一个Block存储于多个DataServer中以保证数据的冗余。对于数据读写请求,均先由NameServer选择合适的DataServer节点返回给客户端,再在对应的DataServer节点上进行数据操作。NameServer需要维护Block信息列表,以及Block与DataServer之间的映射关系,其存储的元数据结构如下:

nameserver元数据
 

在DataServer节点上,在挂载目录上会有很多物理块,物理块以文件的形式存在磁盘上,并在DataServer部署前预先分配,以保证后续的访问速度和减少碎片产生。为了满足这个特性,DataServer现一般在EXT4文件系统上运行。物理块分为主块和扩展块,一般主块的大小会远大于扩展块,使用扩展块是为了满足文件更新操作时文件大小的变化。每个Block在文件系统上以“主块+扩展块”的方式存储。每一个Block可能对应于多个物理块,其中包括一个主块,多个扩展块。
在DataServer端,每个Block可能会有多个实际的物理文件组成:一个主Physical Block文件,N个扩展Physical Block文件和一个与该Block对应的索引文件。Block中的每个小文件会用一个block内唯一的fileid来标识。DataServer会在启动的时候把自身所拥有的Block和对应的Index加载进来。

容错机制

1. 集群容错
TFS可以配置主辅集群,一般主辅集群会存放在两个不同的机房。主集群提供所有功能,辅集群只提供读。主集群会把所有操作重放到辅集群。这样既提供了负载均衡,又可以在主集群机房出现异常的情况不会中断服务或者丢失数据。

2. NameServer容错
Namserver主要管理了DataServer和Block之间的关系。如每个DataServer拥有哪些Block,每个Block存放在哪些DataServer上等。同时,NameServer采用了HA结构,一主一备,主NameServer上的操作会重放至备NameServer。如果主NameServer出现问题,可以实时切换到备NameServer。
另外NameServer和DataServer之间也会有定时的heartbeat,DataServer会把自己拥有的Block发送给NameServer。NameServer会根据这些信息重建DataServer和Block的关系。

3. DataServer容错
TFS采用Block存储多份的方式来实现DataServer的容错。每一个Block会在TFS中存在多份,一般为3份,并且分布在不同网段的不同DataServer上。对于每一个写入请求,必须在所有的Block写入成功才算成功。当出现磁盘损坏DataServer宕机的时候,TFS启动复制流程,把备份数未达到最小备份数的Block尽快复制到其他DataServer上去。 TFS对每一个文件会记录校验crc,当客户端发现crc和文件内容不匹配时,会自动切换到一个好的block上读取。此后客户端将会实现自动修复单个文件损坏的情况。

并发机制

TFS现在只支持小文件,对于同一个文件来说,多个用户可以并发读。
现有TFS并不支持并发写一个文件。一个文件只会有一个用户在写。这在TFS的设计里面对应着是一个block同时只能有一个写或者更新操作。

TFS文件名的结构

TFS的文件名由块号和文件号通过某种对应关系组成,最大长度为18字节。文件名固定以T开始,第二字节为该集群的编号(可以在配置项中指定,取值范围 1~9)。余下的字节由Block ID和File ID通过一定的编码方式得到。文件名由客户端程序进行编码和解码,它映射方式如下图:

文件名组成

TFS客户程序在读文件的时候通过将文件名转换为BlockID和FileID信息,然后可以在NameServer取得该块所在DataServer信息(如果客户端有该Block与DataServere的缓存,则直接从缓存中取),然后与DataServer进行读取操作。

TFS性能数据

1. 软件环境描述
【测试机软件情况描述】
(1) Red Hat Enterprise Linux AS release 4 (Nahant Update 8)
(2) gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-11)
(3) 部署了TFS客户端程序
【服务器软件情况描述】
(1) Red Hat Enterprise Linux Server release 5.4 (Tikanga)
(2) gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-9)
(3) 部署了2台DataServer程序。
【服务器软件情况描述】
(1) Red Hat Enterprise Linux Server release 5.4 (Tikanga)
(2) gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-46)
(3) 部署了2台NameServer(HA)程序。
2. 硬件环境描述
【测试机硬件情况描述】
(1) 一枚八核Intel(R) Xeon(R) CPU E5520 @ 2.27GHz
(2) 内存总数8299424 kB
【服务器硬件情况描述】cpu/memory等
(1) 一枚八核Intel(R) Xeon(R) CPU E5520 @ 2.27GHz
(2) 内存总数8165616 kB
3. 随机读取1K~50K大小的文件性能

读文件性能

Read的TPS随着线程数的增加而增加,增长逐渐趋缓,到90线程的时候达到第一个高峰,此时再增加读线程,则TPS不再稳定增长。
4. 随机写入1K~50K大小的文件

写文件性能

Write的TPS在线程数60左右达到高峰,此时再增加写入线程,TPS不再稳定增长。
5. 在不同线程写压力下的读文件性能




压力测试

压力测试
 

可以看出随着写压力的增加,读文件的TPS会大幅下滑。当写压力达到一定程度时读文件TPS趋缓。

同时,对平均大小为20K的文件进行了测试,测试中读:写:更新:删除操作的比率为100:18:1:1时,在!DataServer服务器磁盘util访问达到80%以上时,响应时间如下:

TYPESUCCCOUNTFAILCOUNTAVG(us)MIN(us)MAX(us)
read1000000208869251170418
write1800001719224951660686
update100004848957551205119
delete1000014221382591651

TYPE:操作类型
SUCCCOUNT:成功个数
FAILCOUNT:失败个数
AVG:平均响应时间
MIN:最短响应时间
MAX: 最大响应时间

更多TFS开源信息请见



什么是TFS?
 
TFS,Taobao File System,淘宝文件系统,淘宝内部使用的分布式文件系统,主要针对海量小文件的随机读写访问性能做了特殊优化,承载着淘宝主站所有图片、商品描述等数据的存储。
 
TFS有什么特点
 
完全扁平化的数据组织结构,抛弃了传统文件系统的目录结构。
在块设备基础上建立自有的文件系统,减少EXT3等文件系统数据碎片带来的性能损耗
单进程管理单块磁盘的方式,摒除RAID5机制
带有HA机制的中央控制节点,在安全稳定和性能复杂度之间取得平衡。
尽量缩减元数据大小,将元数据全部加载入内存,提升访问速度。
跨机架和IDC的负载均衡和冗余安全策略。
完全平滑扩容
 
TFS在淘宝的应用规模
 
  • 数百台PCServer
  • PB级数据量
  • 百亿数据级别
 
TFS的性能参数
 
TFS在淘宝的部署环境中前端有两层缓冲,到达TFS系统的请求非常离散,所以TFS内部是没有任何数据的内存缓冲的,包括传统文件系统的内存缓冲也不存在。我们主要的性能参数不是IO吞吐量,而是单台PCServer提供随机读写IOPS。由于大家硬件型号不同,当然也是因为一些技术保密的原因,我们很难给出一个参考值来说明性能。但基本上我们可以达到单块磁盘随机IOPS理论最大值的60%左右,整机的输出随盘数增加而线性增加。 
 
TFS的逻辑架构图
TFS逻辑架构图
  • TFS尚未对最终用户提供传统文件系统API,需要通过TFSClient进行接口访问,现有JAVA、JNI、C、PHP的客户端
  • TFS的NameServer作为中心控制节点,监控所有数据节点的运行状况,负责读写调度的负载均衡,同时管理一级元数据用来帮助客户端定位需要访问的数据节点
  • TFS的DataServer作为数据节点,负责数据实际发生的负载均衡和数据冗余,同时管理二级元数据帮助客户端获取真实的业务数据。 
 
TFS发展历史
 
TFS1.0简介
 
2007年6月,淘宝自主开发的分布式的文件系统, TFS(Taobao File System)1.0上线运行,主要解决海量小文件的分布式存储
 
集群规模:200台PC Server(146G*6 SAS 15K Raid5) 
文件数量: 亿级别
系统部署存储容量: 140 TB
实际使用存储容量: 50 TB
单台支持随机IOPS200+,流量3MBps
 
TFS1.0的特性
 
•集群由一对Name Server和多台Data Server构成 
•Data Server运行在挂很多硬盘的Linux主机上
•以block文件的形式存放数据文件(一般64M一个block)
•文件名内置元数据信息,用户自己保存TFS文件名与实际文件的对照关系–使得元数据量特别小
•如T2auNFXXBaXXXXXXXX_!!140680281.jpg,名字中含有逻辑的block_no和object_no等 
•block存多份保证数据安全
•利用ext3文件系统存放数据文件
•磁盘raid5做数据冗余
 
TFS1.3简介
 
2009年6月,TFS(TaobaoFile System)1.3上线运行
 
集群规模440台PC Server (300G*12 SAS 15K RPM) + 30台PC Server (600G*12 SAS 15K RPM) 
文件数量:百亿级别
系统部署存储容量:1800 TB
当前实际存储容量:995TB
单台Data Server支持随机IOPS900+,流量15MB+
目前Name Server运行的物理内存是217MB(服务器使用千兆网卡)
2010下半年开始部署PC Server (1T SATA * 12) 
 
TFS1.3的特性
 
所有的元数据全部都内存化
清理磁盘空洞
容量和负载的均衡策略
平滑的扩容
数据安全性的冗余保证
几秒内完成Name Server故障自动切换
容灾策略
性能大幅提升


阅读(1356) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~