云梯的多 namenode 和跨机房之路

罗李（花名：鬼厉）guili.ll@taobao.com@luoli523

提纲

• 项目背景• 构建跨机房集群的困难• 我们的方案

项目背景

• 云梯集群• Hadoop 集群• 版本代码有云梯开发团队维护• 2009 年开始上线服务• 跨机房之前（ 2013 年 4 月）规模 4500 台， 109PB• 大集群，多租户（ >5000 ），多资源组 (>150)• 生产任务、数据分析、数据开发和测试共享集群• 计算分时，存储和计算 quota• 目前规模： 5000 × 2 （分布在 2 个 IDC ）

项目背景

• 曾经限制云梯扩展性的因素• NameNode 处理 RPC 性能• NameNode 内存• JobTracker 处理 RPC 性能• JobTracker 带宽• JDK 限制• 。。。

• 现在• 云梯集群机房机位不够• 数据量的日增长速度让云梯机房最多支撑到 2013 年 6 月底

项目背景

• 云梯机房机位已满• 存储利用率超过 85%• 计算利用率接近 100%

• 几乎每天都有新的存储和计算资源的申请

1. NameNode 的扩展性2. 机房间网络限制3. 数据应该如何跨机房分布？4. 计算应该如何跨机房分布？5. 几十 PB 数据的迁移，带数据升级6. 怎样做到对用户透明？7. 方案是否能扩展到多机房（ >=3 ）？

需要解决的问题

NAMENODE 的扩展性

• 性能压力：存储容量• N 亿文件， N 亿 block• 可垂直扩展：物理内存， 96GB->192GB->…->1TB?

• 性能压力： RPC 请求压力• 几乎所有的 RPC 是有状态的，需要全局锁，更新树• Client 请求 : 5000(slaves) * 20(slots/slaves) = 10w 并发• DataNode 请求 : blockReport & heartbeat ≈ 2000 qps• 垂直扩展？ CPU 主频 1.8GHz->3.2GHz->??? 多核 ???

• 多 NameNode 的目的：水平扩展，分散 Client 的 RPC请求压力

• 借鉴成熟的方案—— HDFS Federation

跨机房网络限制

• 带宽• 单机房内：点对点的带宽 1Gbps• 跨机房间（ 5000 vs. 5000 ）：点对点的带宽≈ 20Mbps• 总带宽较小，容易被打满，成为瓶颈

• 延时• 1ms 之内 -> 5-10ms• 对离线作业的影响可控

• 故障• 机房间网络故障如何处理？• 如何保障断网后，任意一个机房内部的服务是否正常？

数据和计算如何跨机房分布

• N 个资源组， M 个机房GroupA

GroupC

GroupB

DC1

DC2GroupD

• 任意资源组的计算 / 存储资源不超过单个机房总量• 单个计算任务 (Job) 的所有 Task 在同一机房内运行• ( 默认 ) 产生的数据只写到本地机房

• 也有部分数据需要跨机房写• ( 默认 ) 只读取本机房的文件副本

• 也有少部分作业直接跨机房读

尽量减少跨机房的数据流量

跨机房的架构

机房 1 机房 2

独享带宽

用户Gateway

内部网络

NN1 NN2

JT1 JT2

/group/B/group/D

/group/A/group/C

DNTT

DNTT

DNTT DN

TTDNTT

groupB

DNTT

groupA

Task

Task

Task

TaskTask

DNTT /group/

B/tbl1

/group/A/tbl2

CrossNode

技术实现

多 NAMENODE 方案 —— FEDERATION

• 业界有成功案例： Facebook• 原始方案：单机房多 NameNode• 目的：拆分 Namespace

NN1

DN DN DN DN DN DN

NN2

Pool1/disk*/p1

Pool2/disk*/p2

/group/B/group/D

/group/A/group/C

BlockPools

NAMESPACE SPLIT

• distcp ？ —— 慢，代价大• FastCopy ？ —— 快很多，没有物理拷贝，但仍然太慢

• From Facebook• https://issues.apache.org/jira/browse/HDFS-2139

1. 从源 NameNode 上获取文件信息和 block 信息，并在目标 NameNode 上创建同样的文件

2. 获取 block 所在 DataNode 信息3. 在 DataNode 上多个 block pool 之间复制数据（ Hard

Link ）4. block report 给目标 NameNode

• 我们的方案

NAMESPACE SPLIT

• 我们的拆分方案

NN1 NN2/group/A/group/B/group/C/group/D

Pool2/disk*/p2

DN1

Pool1/disk*/p1

Pool2/disk*/p2

DN2

Pool1/disk*/p1

Pool2/disk*/p2

DN3

Pool1/disk*/p1

/group/A/group/B/group/C/group/D

1 ， nn2 load fsimag1

2 ， hardlink pool1 to pool2

3 ， pool1 report to NN1 4 ， pool2 report to NN2

/group/A/group/C

/group/B/group/D

对 CLIENT 透明： VIEWFS

• 用户无需感知集群多机房的细节

• HDFS 多 NameNode• ViewFS

• MapReduce 计算• JobTracker Proxy• ResourceManager Proxy （ Hadoop 2.0 ）

对 CLIENT 透明： VIEWFS

• 配合HDFS Federation使用• 要点：

• Client Side Mount Table• 屏蔽多 namespace细节• fs.default.name: hdfs://nn.ali.com:9000/ -> viewfs://nsX/• Defaut filesystem: DistributedFileSystem -> ViewFileSystem• 用户路径随之改变

• 我们的改进• Zookeeper 保存 Mount table ，方便更新和统一管理• 需要对以下场景真正的透明化

• 用户代码 hard code ： hdfs://nn.ali.com:9000/ • Hive元数据库： hdfs://nn.ali.com:9000/group/tb/hive/tb1• Hive local mode ：把非 hdfs 开头的路径作为 local 方式

• 一个新的 FileSystem封装了 ViewFileSystem

NewFileSystem

对 CLIENT 透明： VIEWFS

Zookeeper

nn1.ali.com nn2…. nn3.ali.com

/group/A /group/B

Config: mount table

ViewFileSystem

hdfs://nn.ali.com:9000/group/A/file

fs.hdfs.impl

ViewFSAdminTools

UpdateWatch

对 CLIENT 透明： VIEWFS

Yunti3FileSystem

ViewFileSystem

DistributedFileSystem

DistributedFileSystem

DistributedFileSystem

NameNode(NS1)

NameNode(NS2)

mkdir

ZooKeeper

createopen

Client

viewfs://nsX

hdfs://nn1:9000 hdfs://nn2:9000

hdfs://hdpnn:9000

/group/B/group/D

/group/A/group/C

fs.hdfs.impl = Yunti3FileSystem

/group/A -> nn1/group/C-> nn1/group/B -> nn2/group/D -> nn2

MR PROXYNODE

• MR ProxyNode ：• 每个 JobTracker 只调度一个机房内的作业• ProxyNode 直接处理 JobClient 请求，并自动转发给相应

的 JobTracker 或 ResourceManager• 提供同一的 Job查询接口（ Web UI / App ）

• Job 调度机制优化：把计算调度到数据所在的地方1. 跨机房列表中的数据正在传输中（ DC1->DC2 ）， DC2

上的 Job 被暂停调度，等待传输完毕2. Ad-hoc查询， DC2 上的 Job 需要读 DC1 上的数

据， Job暂停调度，通知 CrossNode ，数据传输完毕后继续调度

3. 跨机房数据 Join ， DC1 大表， DC2 小表， Job 调度到DC1 上，跨机房直接读取 DC2 数据，无需等待

MR PROXYNODE (CONT.)

JobClient JobClient

MR ProxyNode

JT1 JT2

TT TT TT TT TT TT

Mapping: groupA -> JT1 groupB -> JT2

NM NM

RM1 RM2

数据跨机房迁移

NN1 NN2

Pool2

DN1

Pool1

Pool2

DN2

Pool1

Pool2

DN3

Pool1

DataCenter1 DataCenter2

Pool2

DN4

Pool1

Pool2

DN5

Pool1

Pool2

DN6

Pool1

/g/A/g/C

/g/B/g/D

CN1 CN2/g/B 3:3

/g/D 3:3

block copy

NN2/g/B/g/D

CN2/g/B 3:3

CROSSNODE

• 一个独立的服务，对 NameNode 发送指令

• 主要功能1. 根据预置的跨机房文件列表计算待拷贝的文件2. 让 NameNode 增加跨机房的文件副本3. 维护文件原始副本数，跨机房副本数，实际副本数等状

态信息4. 从 NameNode实时同步文件创建，移动，删除等信息5. 对跨机房的流量进行监控和限速6. CrossFsck 检查当前跨机房文件的副本放置状况，并指挥 NameNode 进行纠正

CROSSNODE (CONT.)

• 跨机房数据迁移，几十 PB 的数据迁移• 将整个资源组的数据作为跨机房文件列表（ /group/B ）• 副本数 3:0 -> 3:3 -> 0:3

• 如何预先知道需要跨机房的文件？• 通过历史作业分析得到大部分需要跨机房的文件或目录• 形成一个跨机房文件列表，作为 CrossNode 的输入

• HDFS 文件副本复制不及时？• JobTracker 对所有的 Job输入做检查• 和 CrossNode进行通信• 可以暂停 Job 的执行

CROSSNODE 内部结构

/a/b DC2/c/d DC2

云梯现在的样子

• 多 NameNode ，跨越 2 个物理机房：• HDFS Federation

• 跨机房副本管理，数据迁移• CrossNode

• 多机房对用户透明• ViewFS• MR ProxyNode

• 规模已接近万台（还没到一万，到那天我会告诉大家的）• 可存储数据容量 220PB

云梯将来的样子

• 对外服务？• 云端企业私有 hadoop 集群？• 集成分布式解决方案？

• 搭载云梯 hadoop 版本• 搭载我们的 hbase 版本和 hive 版本

• hadoop淘宝开源发行版？• 。。。。。

加入我们

•阿里巴巴数据平台事业部•阿里巴巴技术保障部• 我们正在招聘 Hadoop/Hbase/Hive 开发工程师，运维工程师， SA ， Java工程师，数据开发工程师，算法工程师，妹子等等。。。

• guili.ll@taobao.com dawu@taobao.com• @luoli523 @淘大舞（此乃牛人）

Q & A

谢谢！