TFS和TAIR的昨天今天和明天——楚材

• 退出集群
数据服务器的退出不影响TFS服务 TFS检测到DS退出后，会针对该DS拥有的数据做复制 TFS重新均衡数据
20
安全及容灾
• 数据的安全
数据内容校验 机架间的RAID1 机房间的RAID1
• 容灾
NameServer之间的HA 多份数据存在避免DataServer出现问题引起的数据丢失 机房间数据镜像，应用可以通过配臵方便实时切换访问
Dynamic Table TBNet
Slab Pool LRU In Slab Double And Move By Query Powerful Config Server
数据分布 Consistent Hashing 底层通信 Libevent
内存分配 数据交换 内存扩充 服务管理 Slab Pool LRU In Slab Double And Move By Query Manually Managed
32
TAIR2.0的物理架构
33
TAIR2.0的主要性能参数
• • • • 10K以内数据PUT 1MS左右 1K以内数据PUT 800US左右 10K以内数据GET 400US～500US 读写比例8：1，单服务器支撑TPS 6W+
34
TAIR2.0的应用情况
• • • • • • 淘宝主站所有产品线 服务器数量 143台 缓冲数据量 2.5T+ 支撑峰值TPS 300K+ 单日支撑请求量 9G+ 平均命中率 90%
4
TFS1.0来了
• 那个时候，通常碰到这种情况是找多隆的
淘宝应该有自己的分布式文件系统，可参考的只有GFS， 这也是TFS命名的由来（Taobao File System）。解决的 问题只有一个，海量小文件的分布式存储。我们决定使用 这种技术方案。
MasterServer NameServer ChunkServerDataServer 分级索引 冗余和IDC间互备
• 是传统的树状还是扁平化的KV？
树状的优势
自顶向下，数据结构非常直观 目录和文件集合操作可以在一个节点内进行 符合一般文件系统的使用习惯 目录信息统计发散程度不高
树状的劣势
inode的限制 寻址方案并非最优
• 我们决定使用经过排序后的扁平化KV解决这个问 题
27
TFS的未来……….
殊途同归，同样参考了MDBM的一些思想
页式内存管理 动态哈希算法扩容
但也发展了两个方向，嵌入式 OR 分布式
30
TAIR的提出
• TAIR Taobao pAIR
第一个提出这个概念的人 若海
• TAIR1.0的情况
很简单，TAIR作为Proxy实现数据的分布和寻址，后端通 过网络访问一组Mysql数据库服务器作为存储 2008年，若海加入存储组，我们开始计划一个分布式的 KV引擎，第一个版本就是2009年3月推出的用来替代 TDBM的分布式缓存系统TAIR2.0
进行文件级别元数据的存储，必须具有以下要求
支持百亿级别的对象的存储和访问 性能要求很高，并且尽量减少网络开销 高效支持Range获取 稳定程度高，至少5个9以上
满足这些要求之后，具有以下功能
存储文件级别元数据 调度数据根据访问特性在不同集群之间流动
26
MetaServer架构的选择
18
容量和负载的均衡策略
• 平滑灵敏的负载策略
读写流量负载均衡 复制、整理负载均衡 实时动态反馈参数加权平均
• 块复制策略
按块复制 单个文件损坏的自动恢复功能
• 块分布均衡策略
DataServer主机间的均衡 DataServer进程间的均衡
19
平滑扩容
• 加入集群
TFS集群容量不足时，只需将新的机器部署好应用程序以后，即可 加入到运行中的TFS集群 TFS会根据容量的比率，自动选择写入新数据到新服务器 TFS会在适当的时候对所有的数据服务器进行数据均衡
• 建立开源社区，与世界一起进步
28
TBSTORE的时代
• TBStore TaoBaoStore
淘宝在2007年之前的主要缓存系统
固定哈希取模 数据没有冗余 后台使用BDB 一些先天性的缺陷 作为缓冲，使用BDB并不合适 固定哈希取模的方式太不灵活
29
两个TDBM
• TDBM TaoBao DataBase in Memory • TDBM Tiny DataBase in Memory
TFS&TAIR 昨天、今天和明天
1
TFS&TAIR 昨天、今天和明天
Agenda
TFS的发展轨迹
TFS之前，原始社会的美好 TFS1.0，青铜冶炼成功 TFS1.3，终于用上铁了 TFS2.0及以后
TAIR的前世今生
TBStore、两个TDBM？ TAIR1.0TAIR2.0 TAIR2.2的融合 接下来，路在何方？
12
TFS1.3的逻辑架构
Application/Client
Mysql Dup Store
filename refcount crc,size
Data
block id, file id/ allocate
NameServer
HA heartbeat
NameServer
dataserver id (block id, file id)
31
TAIR2.0出现
• TAIR2.0的主要参考对象是MemCached
技术点 Memcached TDBMOld
Hashing And Modulo Simply epoll
Memory Page LRU In Page Dynamic Hashing Config Server
TAIR2.0
• 痛苦的UIC之旅
35
持久化的探索
• TAIR 2.1的推出
TAIR2.1是一个中间过渡版本，实现了持久化，缺陷在于
持久化引擎不稳定 每个节点都由两台互备的服务器组成，写性能无法充分释放 目前使用于淘宝内部系统
8
TFS1.0的特征
• TFS1.0有鲜明的适应淘宝需求的特征
集群由一对NameServer和多台DataServer构成 以block文件的形式存放数据文件 Block备份多份数据保证数据安全 利用ext3文件系统存放数据文件 磁盘raid5做数据冗余 文件名内臵元数据信息，用户自己保存TFS文件名与实际文件的对 照关系
heartbeat message control message heartbeat message
DataServer
dsp1
hda
DataServer
dsp1
hda
dsp2
hda
dsp3
hda
dsp2
hda
dsp3
hda
13
TFS1.3的运行状况
• 2009年8月正式上线 • 期间总共有30分钟左右不可用时间，可用性在 99.99%以上，而且稳定程度在不停提升。 • 集群规模
11
我们有新人加入
• 2008年7月，曲山、宗岱加入淘宝
经过一个季度左右的原有代码熟悉、稳定和组织结构变化 ，我们有了两条管用的枪，开始启动TFS1.3项目。主要实 现下面这些功能
DataServer实现每进程管理一块磁盘 DataServer在磁盘设备文件上实现专有的文件系统 分布式的排重数据库 通信框架改造
存储、管理数据文件 处理客户端文件访问请求 复制、整理、备份数据文件
17
TFS1.3的特性
• TFS1.3提供了一些重要的功能特性
主block+扩展block，实现block内部的顺序读写 所有的元数据全部都内存化 清理磁盘空洞 容量和负载的均衡策略 平滑的扩容 数据安全性的冗余保证 容灾策略 性能大幅提升
数据量以超过业务增量三Leabharlann Baidu的速度增长，同时淘宝的影响 越来越大，数据的安全也更加重要，后果就是
对小文件的存储无法优化 文件数量大，网络存储设备无法支撑 扩容成本高，10T的存储容量需要几百万￥ 连接的服务器越来越多，网络连接数已经到达了网络存储设 备的瓶颈 单点，容灾和安全性无法保证
NameServer
NameServer
Data
heartbeat message
heartbeat message
DataServer
dsp1
hda
DataServer
dsp1
hda
dsp2
hda
dsp3
hda
dsp2
hda
dsp3
hda
25
MetaServer的提出
• 我们走上了传统文件系统的老路
T 1 nsXXXgZvdFXXXXXX .suffix
T 1 nsXXXgZvdFbi3cjc
10
事实证明好日子不会长久
• TFS1.0很快遇到了自己的问题
RAID5和自身的block互备功能重复 block的频繁更新，产生了大量的磁盘文件碎片 用作数据排重的MySql服务器成为了性能瓶颈，同时也成为了威 胁稳定的风险点 使用了一些并不恰当的通信技术，在TFS的应用场景下，多线程多 连接同步通信机制有时候甚至会搞垮一台服务器 最重要的是，随着数据量和访问量的急剧增加，单机IOPS输出不 足已经成为严重问题
21
TFS1.3的性能
• 10：1读写比例下，1M以内数据单次读请求最大 latency 60ms以内，性能曲线随数据大小线性变 化 • 10：1读写比例下，1M以内数据单次写请求最大 latency 220ms以内，性能曲线随数据大小线性 变化 • 单机支撑随机IOPS900+ • 对2K～2M的数据访问支持良好。
24
TFS2.0的逻辑草图
filename refcount
Application/Client
Meta Data Store
heartbeat message heartbeat message
Data
block id, file id/ allocate dataserver id (block id, file id)
2
TFS之前
• 那是在2007年之前
淘宝业务量超过易贝易趣不到两年，数据尚未爆炸性增长 我们使用NetApp提供的网络存储设备 NetApp F810C NetApp FAS980C
文件数量:千万级别 理论存储容量:50TB 实际存储容量:15TB
大家都很Happy！
3
TFS之前
• 但是很快我们就笑不出来了
22
我们又被赶着跑了
• 新的需求产生
应用中出现了一些问题
完全扁平化，无权限管理的情况已不再适用 大文件的存储需求越来越迫切 成本并非最优化 用户自己存储文件名对照关系，麻烦且效率无法保证
23
TFS2.0的规划
• 功能点的规划
我们对TFS2.0需要解决的问题作了一些探讨
权限和目录的加入 传统文件系统功能的补充 分级存储概念的提出 用户自己命名文件 大文件的分片存储，大小尺寸文件同时支持
400台PCServer 300*6 SAS 15K 文件数量 百亿级别 理论存储容量 1PB 实际存储容量 600TB 单台支持随机IOPS 900+，流量15MB+
14
架构稳定下来了
• 我们终于可以开始谈TFS组件的功能了
首先是中心的控制节点NameServer，它有以下一些功能
5
TFS1.0物理架构图
6
TFS1.0逻辑架构
7
TFS1.0的运行状况
• 2007年6月正式上线 • 出过两到三次严重故障，三个月后基本稳定 • 集群规模
200台PCServer 146*6 SAS 15K Raid5 文件数量 亿级别 理论存储容量 60TB 实际存储容量 50TB 单台支持随机IOPS 200+，流量3MB+
所有一级元数据的管理 负责文件到达DataServer的定位，写文件块的分配 数据更新一致性控制 DataSever管理 数据备份监控，数据分布和垃圾回收
15
NameServer管理的一级元数据
16
DataServer的功能
• DataServer是实际存储数据的地方，它有以下一 些功能
9
TFS文件名的规则
block id file id
12345 9453861048773957244
block id
file sequence id
hash of suffix
12345 1234556
1是TFS 集群编号
2201148553
16位文 件名编码 文件名 后缀
tfs文件 名以T开 头