http://code.taobao.org/trac/tfs/wiki/intro
简介¶
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服务器部署好应用程序并启动即可。这些dataserver服务器会向nameserver进行汇报。nameserver会根据dataserver容量的比率和dataserver的负载决定新数据写往哪台dataserver的服务器。根据写入策略,容量较小,负载较轻的服务器新数据写入的概率会比较高。同时,在集群负载比较轻的时候,nameserver会对dataserver上的Block进行均衡,使所有dataserver的容量尽早达到均衡。
进行均衡计划时,首先计算每台机器应拥有的blocks平均数量,然后将机器划分为两堆,一堆是超过平均数量的,作为移动源;一类是低于平均数量的,作为移动目的。
移动目的的选择:首先一个block的移动的源和目的,应该保持在同一网段内,也就是要与另外的block不同网段;另外,在作为目的的一定机器内,优先选择同机器的源到目的之间移动,也就是同台dataserver服务器中的不同dataserver进程。
当有服务器故障或者下线退出时(单个集群内的不同网段机器不能同时退出),不影响TFS的服务。此时nameserver会检测到备份数减少的Block,对这些Block重新进行数据复制。
在创建复制计划时,一次要复制多个block, 每个block的复制源和目的都要尽可能的不同,并且保证每个block在不同的子网段内。因此采用轮换选择(roundrobin)算法,并结合加权平均。
数据块管理¶
TFS以块的方式组织文件的存储。在nameserver节点中存储了所有的Block的信息,一个Block存储于多个dataserver中以保证数据的冗余。对于数据读写请求,均先由nameserver选择合适的dataserver节点返回给客户端,再在对应的dataserver节点上进行数据操作。nameserver需要维护Block信息列表,以及Block与dataserver之间的映射关系,其存储的元数据结构如下:
在dataserver节点上,在挂载目录上会有很多物理块,物理块以文件的形式存在磁盘上,并在dataserver部署前预先分配,以保证后续的访问速度和减少碎片产生。为了满足这个特性,DataServer?现一般在EXT4文件系统上运行。物理块分为主块和扩展块,一般主块的大小会远大于扩展块,使用扩展块是为了满足文件更新操作时文件大小的变化。每个Block在文件系统上以“主块+扩展块”的方式存储。每一个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
(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%以上时,响应时间如下:
TYPE SUCCCOUNT FAILCOUNT AVG(us) MIN(us) MAX(us)
read 100000 0 20886 925 1170418
write 18000 0 17192 2495 1660686
update 1000 0 48489 5755 1205119
delete 1000 0 14221 382 591651
Attachments
filename.png (43.7 KB) - added by chuyu@… 3 weeks ago. 文件名组成
metadata.png (46.4 KB) - added by chuyu@… 3 weeks ago. nameserver元数据
read.png (9.1 KB) - added by chuyu@… 3 weeks ago. 读文件性能
write.png (8.5 KB) - added by chuyu@… 3 weeks ago. 写文件性能
rs10.png (9.3 KB) - added by chuyu@… 3 weeks ago. 压力测试
rs100.png (8.0 KB) - added by chuyu@… 3 weeks ago. 压力测试
structure.png (53.3 KB) - added by chuyu@… 3 weeks ago. 整体结构图
分享到:
相关推荐
TFS(Taobao !FileSystem)是一个高可扩展、高可用、高性能、面向互联网服务的分布式文件系统,主要针对海量的非结构化数据,它构筑在普通的Linux机器集群上,可为外部提供高可靠和高并发的存储访问。TFS为淘宝提供...
淘宝分布式文件服务器taobao file system tfs配置文件 为线上正在使用的生产配置 具体配置项可视自己服务微调,配置项含义参考tfs.taobao.org的文档说明.有无备份集群不影响TFS的运行,若没有,则去掉备份集群的配置
### TFS(Taobao File System)功能说明及使用详解 #### 一、TFS概览 **TFS(Taobao File System)**是一款专为淘宝网设计的分布式文件系统,其核心目标是处理大规模的非结构化数据。该系统通过在普通的Linux...
其主要包含两个核心组件:分布式文件系统HDFS(Hadoop Distributed File System)和并行计算框架MapReduce。HDFS为海量数据提供了高容错、高吞吐量的存储机制,而MapReduce则负责将复杂的大规模计算任务分解为可并行...
淘宝自主研发了TFS(Taobao File System),这是一个分布式文件系统,专门针对大规模电子商务场景设计。TFS能够高效处理大量图片、商品描述等非结构化数据,极大地提升了用户体验和系统性能。此外,淘宝还构建了自己...
此外,Hadoop还包括了一个分布式文件系统——HDFS(Hadoop Distributed File System),能高效地存储和处理PB级别的数据。 在大数据分析中,Hadoop常常被用于数据预处理、数据清洗、数据挖掘等阶段,尤其适合处理非...
淘宝采用了分布式存储系统,例如Hadoop HDFS或自研的TFS(Taobao File System),这些系统能够提供高可用性、高扩展性和低成本的数据存储。分布式存储将图片数据分割并分布到多台服务器上,确保即使单个节点故障,也...
淘宝的分布式文件存储引擎,简称TFS(Taobao File System),是阿里巴巴集团为解决大规模电商网站数据存储问题而设计的一款高性能、高可用的文件系统。它主要服务于淘宝内部的大量在线业务,如商品图片、用户数据等...
#### TFS (Taobao File System) TFS是阿里巴巴自研的分布式文件系统,主要用于存储和管理大量的非结构化数据,如图片、视频等。通过TFS,淘宝能够高效地管理和提供丰富的多媒体内容,提升用户体验。 #### Tair ...
FSO(File System Object)是ASP中的一个对象模型,它允许开发者在服务器端对文件和文件夹进行操作,比如创建、删除、移动、读取和写入文件。这对于构建购物系统至关重要,因为网站需要处理用户上传的商品图片、生成...
在对分布式文件系统进行选型研究时,除了FastDFS之外,还有Hadoop HDFS(Hadoop Distributed File System)和淘宝的TFS(Taobao File System)。这些系统均基于GoogleFS的设计原理,并对开源实现进行了改进。在选择...
Hadoop是目前最为流行的开源分布式存储和计算框架,以HDFS(Hadoop Distributed File System)和MapReduce为两大核心。云梯对Hadoop的主要功能进行了扩展与改造,以适应淘宝的业务需求。 在安全性方面,云梯进行了...
淘宝分布式文件系统(TFS,Taobao File System)是阿里巴巴集团为解决大规模互联网服务中的海量数据存储问题而设计的一种高性能、高可用的分布式文件系统。它由C++语言编写,旨在提供大规模的数据共享和访问能力,...
Hadoop的核心组件包括HDFS(Hadoop Distributed File System)和MapReduce。HDFS提供了高容错性的分布式文件系统,能够存储和处理PB级别的数据。MapReduce则是一种编程模型,用于大规模数据集的并行计算,将复杂的...
为了克服这些困境,淘宝网决定自主开发专门针对海量小文件存储的文件系统——TFS(淘宝文件系统,Taobao File System)。TFS的诞生旨在解决大规模图片存储的难题,提升读取速度,降低延迟,并确保系统的高可用性和...