@HUST张友东work@taobaozyd_com@126.com
分类：LINUX
2014-03-0619:06:32
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中没有对应的映射关系，就插入一条新的映射记录，用于去重。
TFSNS单点问题
NS是TFS集群的中心管理节点，TFS通过主备HA的方式来解决单点问题。正常情况下，所有的操作由主NS完成，当主NS服务挂掉时，服务会立即切换到备机。为了保证备机立即能接管服务,TFS做了如下工作：
TFS是否支持异地容灾
TFS支持主备集群的模式，在两个机房分别搭建集群，可将其中一个作为主集群，将另一个配置为备集群，所有写入主集群的文件都会同步到备集群。
TFS的一致性语义
TFS性能如何
不同的工具、不同的测试方法、不同的测试环境得出来的结果都不一样，理论分析下最差情况.
以读小文件（2M以下）为例，假设没有OS的pagecache，每一次读请求对应DS的一次磁盘随机IO(大部分情况下是这样的）而磁盘（假设为SATA盘）每秒处理随机读到能力大概在80左右，也就是说单块盘能达到的qps为80/s，假设一台机器10块磁盘，则该机器能达到的qps为800/s。
而实际上，受操作系统缓存、访问特性、集群容量使用（容量使用越小，存储的数据的局部性越高）等因素的影响，机器的实际qps能远大于这个值，实际的随机访问测试中，单台机器（11块SATA盘）qps有超过2000。
如何获取TFS
tfsserver（含C++客户端）
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运行环境要求
TFS有哪些运维工具
TFS是否有压力测试工具
tfs-src/tests/batch目录下有三个工具test_batch_write、test_batch_read、test_batch_mix，标准输出为测试结果，标准错误为测试日志。
test_batch_write工具往集群写入文件，写入的文件生成的文件名，在当前目录的wf_文件里(代表线程号）
-dnsip:port写入集群的NS地址（ip:port形式）-c每个线程写入次数-r写入文件的大小范围，low:high（bytes），实际数据随机生成-t写入线程数test_batch_read工具从集群读入文件，其读取的文件为test_batch_write写入的文件，每个线程从对应的wf_*读取文件列表
-dnsip:port写入集群的NS地址（ip:port形式）-c每个线程读取次数-t读取线程数-s0/1是否随机读取；如果为1，n号线程会先将wf_n文件里的文件列表随机打散，然后再根据文件名读取文件test_batch_mix工具进行读、写、更新、删掉混合测试，根据配置的比例，先写入一批文件，然后选择部分文件进行读、或者更新删除。
-dnsip:port写入集群的NS地址（ip:port形式）-c每个线程进请求次数-r写入文件的大小范围，low:high（bytes），实际数据随机生成-t线程数-oread:write:delete:update比例，比如10:10:2:2TFS能否在单台机器上运行
TFS的NS、DS服务是可以部署在同一台机器上的，另外还有个限制，机器数不能小于配置的副本数，如果只有1台机器，则只有将副本数配置为1。
副本数应该配置多大
生产环境集群副本数据建议配置为3份，有条件的话，最好做异地容灾，配置备份集群（重要的数据，容灾是必不可少的）。
生产环境NS应该使用什么配置的机器
生产环境DS应该使用什么配置的机器
如果CPU配置还行，可以在DS上部署一些CPU密集型的应用，来充分利用CPU资源，比如阿里将图像处理服务器跟DS部署在同一台机器。
NS、DS服务器上线前需要修改什么系统配置么？
一个DS管理多大存储空间比较合适
单台物理机上，每个DS进程管理一块磁盘，2T及以下的磁盘完全没有问题；4T盘刚投入线上使用，应用还不是太成熟（慎用）。
DS上主块、扩展块大小以及比例应该怎么配置
经验值，主块64M、扩展块4M，主块/扩展块（block_ratio)=1，如果更新比较多，block_ratio可以调小点。
日志级别应该怎么配置
TFS里的日志级别有4种，生产环境建议配置为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的vipip_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等
主备集群如何配置？
在主集群的所有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源集群NSip:port-d目标集群NSip:port-fblock/filelistblock或者文件列表，每行一个-e是否同步已经处于删除状态的文件（不建议）-mmodifytime，如20140210只同步20140210写入或修改的文件-p日志目录，默认./logs-l日志级别，默认INFONS、DS的配置项是否能在线修改？
DS的配置不能在线修改，主要原因
集群如何升级能不影响服务？
生产环境下，不影响服务的升级步骤
文件删除了，但存储空间没有回收
TFS的删除操作并不会立即回收文件的存储空间，删除只会将文件设置成已删除状态，当一个block内被删除的文件数（或文件总大小）超过一定比例（可配置）时，NS会对该block发起压缩（compact），此时才会回收删除文件的存储空间；compact通常配置在访问低峰期执行。
compact_delete_ratio=10#block删除文件数或文件大小超过10%，才会对block做compact_compact_hour_range=1~9#compact只在1点到9点做**有磁盘坏掉了，NS没有立即复制丢失的block？**
NS上的后台任务可以关闭么
如何查看集群的容量使用情况，使用到多少应该扩容
ssm-sns_ip:port-i"server"或者ssm-sns_ip:port-i"machine"前者以DS（磁盘）为单位展示，后者以机器为单位展示
通常使用到85%-90%就应该及时扩容了，具体要根据数据增长速度、集群规模来定
集群刚搭建好，还没有写任何数据，ssm就发现集群容量使用并不是0%？
ssm看到的容量使用百分比是“使用的block数/总的block数”，一个block一旦创建就认为是使用了，即使block里还没有存储任何文件。
NS启动后，会为每个dataserver创建max_write_filecount（ns配置项）个masterblock（写的时候的主副本）。
也就是说一个集群搭建完后，不写任何数据的情况下，这个集群就会有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集群需要重点监控及注意的地方
做文件存储，访问文件时就得打开文件啊
我ulimit-n设置的为65535时确实遇到了“toomanyxxxx”的错误，改成ulimit-n131072，重启ds就好了；就是不明白为啥会需要那么多，同一个时刻怎么会需要打开那么多文件？？？
主备实时热备＋客户端缓存
这种结构其实就是传统的HA模式，瓶颈就是NAMESERVER。如何解决这个瓶颈呢！！？？