TFS（Taobao File System）团队CODE协作工具

TFS（Taobao File System）是一个高可扩展、高可用、高性能、面向互联网服务的分布式文件系统，TFS由nameserver(NS)、dataserver(DS)、client三个部分组成，详细设计原理参考[丢失link]

TFS适用场景

TFS提供海量文件的可靠存储，尤其适合海量小文件的存储；TFS没有传统文件系统的目录树结构，所有文件处于一个扁平化的名字空间；TFS不支持posix接口，必须通过TFS提供的客户端API(read/write/delete)来读、写、删文件。

TFS最大集群规模

经过实践的最大规模：单集群7PB+存储容量、400+台机器、1000亿+文件(2014年2月数据）；理论上最大集群规模受限于NS的内存大小、网络处理能力。

TFS对大文件的支持

TFS最初开发是针对小文件存储，但TFS也提供了大文件的存取接口，支持大文件没有在服务端做任何特殊改动，而是通过在客户端把大文件划分成多个“小文件分片”来存储，TFS大文件最大为140G，主要受限于分片元信息的大小。

TFS对自定义文件名的支持

默认情况下（只部署NS和DS），往TFS存储一个文件后，TFS的客户端会返回一个T开头的文件名，通过该文件名就能从TFS里读到存储的文件。同时TFS支持用户自定义文件名，但需要部署和rootserver，metaserver依赖mysql来存储“用户自定义文件名”到“TFS文件名”的映射关系，rootserver用来管理多个metaserver。

自定义文件名提供create_dir、create_file、ls_dir、write_file、read_file、delete_file等接口。

TFS对文件去重的支持

默认情况下，TFS存储两个内容相同的文件，会得到两个不同的文件名(对应server端的两份数据）。

TFS客户端提供了文件去重存储接口，TFS的去重依赖于（阿里的一个key/value存储系统），在tair里存储(文件md5、size) ==>(TFS文件名)的映射关系。如果使用去重存储接口，客户端首先会根据文件的md5和大小等信息到tair查询一下，看有没有存储过相同内容的文件，如果有直接返回对应的TFS文件；如果tair中没有对应的映射关系，就插入一条新的映射记录，用于去重。

TFS（Taobao File System）是一个高可扩展、高可用、高性能、面向互联网服务的分布式文件系统，TFS由nameserver(NS)、dataserver(DS)、client三个部分组成，详细设计原理参考

enter image de.ion here

TFS适用场景

TFS最大集群规模

经过实践的最大规模：单集群7PB+存储容量、400+台机器、1000亿+文件(2014年2月数据）；理论上最大集群规模受限于NS的内存大小、网络处理能力。

TFS对大文件的支持

TFS对自定义文件名的支持

自定义文件名提供create_dir、create_file、ls_dir、write_file、read_file、delete_file等接口。

TFS对文件去重的支持

默认情况下，TFS存储两个内容相同的文件，会得到两个不同的文件名(对应server端的两份数据）。

TFS NS单点问题

NS是TFS集群的中心管理节点，TFS通过主备HA的方式来解决单点问题。正常情况下，所有的操作由主NS完成，当主NS服务挂掉时，服务会立即切换到备机。为了保证备机立即能接管服务,TFS做了如下工作：

所有的DS启动后会向主、备NS汇报block信息、并保持心跳
主NS上的block操作会以日志形式记录下来，并后台重放日志将操作同步到备NS
TFS是否支持异地容灾

TFS支持主备集群的模式，在两个机房分别搭建集群，可将其中一个作为主集群，将另一个配置为备集群，所有写入主集群的文件都会同步到备集群。

TFS的一致性语义

新写文件，TFS分配一个文件名，保证该文件的多个副本数据完全一致
更新已存在的文件，不保证文件多个副本一致性（更新不建议使用）
TFS性能如何

不同的工具、不同的测试方法、不同的测试环境得出来的结果都不一样，理论分析下最差情况.

以读小文件（2M以下）为例，假设没有OS的page cache，每一次读请求对应DS的一次磁盘随机IO(大部分情况下是这样的）而磁盘（假设为SATA盘）每秒处理随机读到能力大概在80左右，也就是说单块盘能达到的qps为80/s，假设一台机器10块磁盘，则该机器能达到的qps为800/s。

而实际上，受操作系统缓存、访问特性、集群容量使用（容量使用越小，存储的数据的局部性越高）等因素的影响，机器的实际qps能远大于这个值，实际的随机访问测试中，单台机器（11块SATA盘）qps有超过2000。

如何获取TFS

tfs server（含C++客户端）

svn: http://code.taobao.org/p/tfs/src/branches/dev_for_outer_users/ github: 注：以上两个分支都是基于release-2.2.16修改的
tfs client

java-client: nginx-module:
应该使用哪个版本的TFS?

目前TFS有三个大的稳定版本，1.3、2.0、2.2，大版本内部的升级主要是修复bug、添加小的功能，小版本最新的是最稳定的版本；建议用户使用2.2的最新版本2.2.16。在进行server升级时，NS、DS应该一直使用同一个版本，否则有可能出现协议不兼容的情况。

2.6版本变化较大，与上述的3个版本，数据存储的格式都不兼容，不能直接升级，建议开源用户暂时不要使用。

TFS运行环境要求

64-bit linux os
gcc (阿里使用gcc-4.1.2，使用更高版本gcc时，去掉Werror编译选项，忽略warning即可）
ext3/ext4文件系统
更多依赖及编译安装细节参考安装文档和部署文档

TFS有哪些运维工具?

tfstool: 读、写、删文件，查看block元信息等
ssm：查看集群的server及block信息
admintool: 集群管理工具，包括在线修改ns配置等
ds_client：直接针对DS进行读写删操作（主要是开发DS时用于测试）
更详细的介绍参考TFS运维工具使用

TFS是否有压力测试工具?

tfs-src/tests/batch目录下有三个工具test_batch_write、test_batch_read、test_batch_mix，标准输出为测试结果，标准错误为测试日志。

test_batch_write工具往集群写入文件，写入的文件生成的文件名，在当前目录的wf_文件里(代表线程号）

-d nsip:port 写入集群的NS地址（ip:port形式） -c 每个线程写入次数 -r 写入文件的大小范围，low:high（bytes），实际数据随机生成 -t 写入线程数
test_batch_read工具从集群读入文件，其读取的文件为test_batch_write写入的文件，每个线程从对应的wf_*读取文件列表

-d nsip:port 写入集群的NS地址（ip:port形式） -c 每个线程读取次数 -t 读取线程数 -s 0/1 是否随机读取；如果为1，n号线程会先将wf_n文件里的文件列表随机打散，然后再根据文件名读取文件
test_batch_mix工具进行读、写、更新、删掉混合测试，根据配置的比例，先写入一批文件，然后选择部分文件进行读、或者更新删除。

-d nsip:port 写入集群的NS地址（ip:port形式） -c 每个线程进请求次数 -r 写入文件的大小范围，low:high（bytes），实际数据随机生成 -t 线程数 -o read:write:delete:update比例，比如10:10:2:2
TFS能否在单台机器上运行?

TFS的NS、DS服务是可以部署在同一台机器上的，另外还有个限制，机器数不能小于配置的副本数，如果只有1台机器，则只有将副本数配置为1。

副本数应该配置多大?

生产环境集群副本数据建议配置为3份，有条件的话，最好做异地容灾，配置备份集群（重要的数据，容灾是必不可少的）。

分享下阿里的几种集群配置

集群1主2备，每个集群2个副本（非常重要的数据）
集群1主1备，每个集群2个副本（重要的数据）
单个主集群，3个副本（重要的数据，但能接受机房故障）
单个主集群，2个副本（一定程度接受数据丢失）
生产环境NS应该使用什么配置的机器?

CPU：多核是必须的，NS有很多后台线程，做各种检查来保证数据安全，不浪费的情况下，越牛逼越好
内存：NS占用的内存与集群规模及访问情况情况相关，很难直接给个值出来，建议至少配8G，再根据实际运行情况扩展
硬盘：有一块系统盘就够了，NS的元数据不持久化，而且都是由DS汇报上来的
网卡：千兆网卡，与NS交互的网络包都较小，网络框架tbnet每秒处理的请求数上限在5w左右
生产环境DS应该使用什么配置的机器?

CPU：不需要太好，DS的主要开销在IO上
内存：可按1T存储配1G内存来做参考
硬盘：无要求，通常每个DS进程管理一个块磁盘
网卡：千兆网卡，对于小文件存储来说，一般是IO先到瓶颈
如果CPU配置还行，可以在DS上部署一些CPU密集型的应用，来充分利用CPU资源，比如阿里将图像处理服务器跟DS部署在同一台机器。

NS、DS服务器上线前需要修改什么系统配置么？

ulimit -n 131072 （2T及以下的磁盘适用，不合理配置这个值，会导致TFS无法创建block，从而无法写入文件）
ulimit -c unlimted 万一遇到问题，产生core文件，方便查问题
一个DS管理多大存储空间比较合适?

单台物理机上，每个DS进程管理一块磁盘，2T及以下的磁盘完全没有问题；4T盘刚投入线上使用，应用还不是太成熟（慎用）。

DS上主块、扩展块大小以及比例应该怎么配置?

经验值，主块64M、扩展块4M，主块/扩展块（block_ratio) = 1，如果更新比较多，block_ratio可以调小点。

日志级别应该怎么配置?

TFS里的日志级别有4种，生产环境建议配置为INFO级别

DEBUG: 调试日志
INFO: 重要的信息，方便观察系统运行状况
WARN: 可以忽略的错误，不影响系统继续服务
ERROR: 严重错误，影响继续服务
集群NS、DS运行过程中，重点关注WARN、ERROR日志；DS上每一次读、写、删操作都对应一条INFO日志。

集群里必须包含主备NS么?

备NS不是必须的，但生产环境强烈建议配置主备做HA

NS的HA如何配置?

假设192.168.1.1是vip，主备nameserver的地址分别为192.168.1.101，192.168.1.102

vip必须配置在主备nameserver其中之一上，NS启动时，检测到vip落到自己身上，就确定自己是主NS

在192.168.1.101的ns.conf里

[public] #这里配置NS的vip，如果没有备NS，配置主NS的ip即可 ip_addr = 192.168.1.1 [nameserver] #这里是主备NS的实际ip地址，如果没有备，将其中一个配置为无效地址 ip_addr_list = 192.168.1.101|192.168.1.102
在192.168.1.102的ns.conf里

[public] #这里配置NS的vip ip_addr = 192.168.1.1 [nameserver] #这里是主备NS的实际ip地址，如果没有备，将其中一个配置为无效地址 ip_addr_list = 192.168.1.101|192.168.1.102
主备NS的配置，不管是否有vip，ip_addr这个配置项在主备上一定是相同的，不然就有可能出现两个主了。

NS的HA必须使用heartbeat软件？

任意能实现虚拟ip切换到软件都可以，比如pacemaker、keepalived等

使用heartbeat来做HA的详细配置方式参考TFS nameserver HA配置

主备集群如何配置？

在主集群的所有DS上配置备集群的NS地址(ip:port)，需重启DS生效

slave_nsip = slave_cluster_ns_ip:port
搭建备集群时，如果主集群里已经有数据，应该怎么同步到备集群？

TFS提供了集群间同步文件的工具，sync_by_blk、sync_by_file

sync_by_blk根据“给定的blockid列表”，将这批block里所有的文件从源集群同步到目标集群；sync_by_file根据“给定的TFS文件列表”，将这批文件从源集群同步到目标集群。

-s 源集群NS ip:port -d 目标集群NS ip:port -f block/file list block或者文件列表，每行一个 -e 是否同步已经处于删除状态的文件（不建议） -m modify time，如20140210 只同步20140210写入或修改的文件 -p 日志目录，默认./logs -l 日志级别，默认INFO
NS、DS的配置项是否能在线修改？

NS的配置可以在线修改，参考TFS运维工具使用中的admintool部分

DS的配置不能在线修改，主要原因

重启DS对集群服务影响很小
DS需要修改配置时，通常是所有的DS都要改，在线修改很容易造成"配置只有部分DS被修改"的问题
集群如何升级能不影响服务？

生产环境下，不影响服务的升级步骤

升级备NS，等一段时间，直到所有的DS都汇报block完毕
升级主NS，此时原来的备就会切换为主；主升级后成为备
逐台升级DS （视集群规模，如果机器较多，一次可以升级多台）
文件删除了，但存储空间没有回收?

TFS的删除操作并不会立即回收文件的存储空间，删除只会将文件设置成已删除状态，当一个block内被删除的文件数（或文件总大小）超过一定比例（可配置）时，NS会对该block发起压缩（compact），此时才会回收删除文件的存储空间；compact通常配置在访问低峰期执行。

NS上跟compact相关的一些配置

compact_delete_ratio = 10 # block删除文件数或文件大小超过10%，才会对block做 compact_compact_hour_range = 1~9 # compact只在1点到9点做
** 有磁盘坏掉了，NS没有立即复制丢失的block？**

NS检测到DS退出时，并不是立即开始复制丢失的block，而是会等replicate_wait_time（seconds，NS配置项，建议值300s左右）后才开始复制，如果在这个时间内，这个DS又连上了，则不需要进行复制。这么设计的主要原因是，很多服务器故障是能在短时间内恢复的（google有篇论文里有提到，他们的server故障有90%以上是在15min钟内能恢复的）。

NS上的后台任务可以关闭么?

NS后台主要有复制、迁移（负载均衡）、压缩三种任务，可通过admintool来开启和关闭，默认都开启

复制：当block的副本数低于配置值时，会复制block，为保证数据安全，该任务必须开启
迁移：当DS间的存储使用比例不均衡时，会在多个DS之间迁移block，让存储负载均衡，可选择性关闭
压缩：回收删除文件的存储空间，可选择性关闭（比如在大促期间关闭压缩，能将所有的IO、网络资源都用来服务客户端请求）
如何查看集群的容量使用情况，使用到多少应该扩容

ssm -s ns_ip:port -i “server” 或者 ssm -s ns_ip:port -i “machine”
前者以DS（磁盘）为单位展示，后者以机器为单位展示

通常使用到85%-90%就应该及时扩容了，具体要根据数据增长速度、集群规模来定

集群刚搭建好，还没有写任何数据，ssm就发现集群容量使用并不是0%？

ssm看到的容量使用百分比是“使用的block数 / 总的block数”，一个block一旦创建就认为是使用了，即使block里还没有存储任何文件。

NS启动后，会为每个dataserver创建max_write_filecount（ns配置项）个master block（写的时候的主副本）。

也就是说一个集群搭建完后，不写任何数据的情况下，这个集群就会有max_write_filecount * ds_process_num * max_replication左右个block创建出来。

在写数据的过程中，往这些已经创建的block里写文件是不影响使用容量的，因为从创建时刻他们已经计算到使用容量里了；在不断写到过程中，如果有block满了，就会创建新的block，这时使用容量又会增加。

所以ssm看到的集群使用容量可能有 max_write_filecount * ds_process_num * max_replication / total_block_count的误差，但用这个使用百分比指导扩容是完全没问题的。

TFS扩容时，假设副本数为2，增加的机器数一定要是2的整数倍？

扩容可以是任意数量的机器，机器配置好DS的服务，将每块磁盘对应的服务都启动起来即可，通过ssm来观察扩容的机器是否正常上线工作了。

NS的cpu利用率较高，是否正常?

NS要服务客户端的请求，还要处理DS的心跳、block汇报等，还要负责监视集群的block、server状态，CPU占用率偏高是正常的。

如何监控TFS?

TFS集群需要重点监控及注意的地方

所有NS、DS的服务端口
监控NS、DS的日志，避免其把磁盘空间占满了，磁盘满了总会出些很诡异的问题
监控集群的容量使用情况，容量不足时，尽早扩容
监控NS日志里的lost关键字，如果出现了，说明有block丢失了（block所有副本所在的DS都宕机了）；如果有备集群，可以使用sync_by_blk从备集群恢复
集群读写的qps，ssm -s ns_ip:port -i "server -i 3 -c 0"能持续dump集群各个server的状态，从第二次输出开始（根据两次统计来做差值），每次输出的最后一行的最后4个字段分别是每秒写的次数、每秒写的数据量、每秒读的次数、每秒写的数据量。
NS是TFS集群的中心管理节点，TFS通过主备HA的方式来解决单点问题。正常情况下，所有的操作由主NS完成，当主NS服务挂掉时，服务会立即切换到备机。为了保证备机立即能接管服务,TFS做了如下工作：