云梯的多namenode和跨机房之路 罗李（花名：鬼厉） guili.ll@taobao.com @luoli523

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

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

项目背景 曾经限制云梯扩展性的因素 现在 NameNode处理RPC性能 NameNode内存 JobTracker处理RPC性能 JDK限制 。。。 现在 云梯集群机房机位不够 数据量的日增长速度让云梯机房最多支撑到2013年6月底

项目背景 云梯机房机位已满 存储利用率超过85% 计算利用率接近100% 几乎每天都有新的存储和计算资源的申请

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

NameNode的扩展性 性能压力：存储容量 性能压力：RPC请求压力 多NameNode的目的：水平扩展，分散Client的RPC请求压力 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 Jobtracker的扩展性由hadoop 2.0 Yarn解决，这里不涉及

跨机房网络限制 带宽 延时 故障 单机房内：点对点的带宽1Gbps 跨机房间（5000 vs. 5000）：点对点的带宽≈20Mbps 总带宽较小，容易被打满，成为瓶颈 延时 1ms之内 -> 5-10ms 对离线作业的影响可控 故障 机房间网络故障如何处理？ 如何保障断网后，任意一个机房内部的服务是否正常？

数据和计算如何跨机房分布 N个资源组，M个机房 任意资源组的计算/存储资源不超过单个机房总量 GroupA DC1 GroupC GroupB DC2 GroupD 任意资源组的计算/存储资源不超过单个机房总量 单个计算任务 (Job) 的所有 Task 在同一机房内运行 (默认)产生的数据只写到本地机房 也有部分数据需要跨机房写 (默认)只读取本机房的文件副本 也有少部分作业直接跨机房读 这里的资源组包括计算和存储资源，存储资源就是HDFS上保存的数据 资源组被绑定到一个固定的机房。如果是完全独立的资源组，怎么划分都没有问题，只需要保证多个机房之间的资源分布均衡。 考虑到资源组之间有相互依赖，这里的依赖就是就是跨组的数据访问，如何更好的把数据和计算做跨机房分布是我们遇到的最大难题。 尽量减少跨机房的数据流量

跨机房的架构 NN1 NN2 JT1 JT2 用户Gateway 内部网络 机房1 机房2 独享带宽 /group/A /group/C /group/B /group/D 机房1 机房2 NN1 Cross Node NN2 DN TT DN TT DN TT DN TT 独享带宽 DN TT DN TT DN TT /group/B/tbl1 Task Task Task Task Task /group/A /tbl2 JT1 JT2 groupA groupB

技术实现

多namenode方案 —— federation 业界有成功案例：Facebook 原始方案：单机房多NameNode 目的：拆分Namespace /group/A /group/C /group/B /group/D NN1 NN2 DN DN DN DN DN DN Pool1 /disk*/p1 Block Pools Pool2 /disk*/p2

Namespace split distcp？ —— 慢，代价大 FastCopy？ —— 快很多，没有物理拷贝，但仍然太慢 我们的方案 From Facebook https://issues.apache.org/jira/browse/HDFS-2139 从源NameNode上获取文件信息和 block 信息，并在目标 NameNode 上创建同样的文件 获取 block 所在 DataNode 信息 在DataNode上多个block pool之间复制数据（Hard Link） block report 给目标 NameNode 我们的方案

Namespace split 我们的拆分方案 NN1 NN2 /group/B /group/D /group/A /group/B /group/C /group/D /group/A /group/C /group/A /group/B /group/C /group/D 1，nn2 load fsimag1 NN1 NN2 3，pool1 report to NN1 4，pool2 report to NN2 DN1 DN2 DN3 Pool1 /disk*/p1 Pool2 /disk*/p2 Pool1 /disk*/p1 Pool2 /disk*/p2 Pool1 /disk*/p1 Pool2 /disk*/p2 2，hardlink pool1 to pool2

对Client透明：ViewFS 用户无需感知集群多机房的细节 HDFS多NameNode MapReduce 计算 ViewFS 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

对Client透明：ViewFS NewFileSystem fs.hdfs.impl hdfs://nn.ali.com:9000/group/A/file ViewFileSystem Config: mount table Zookeeper Watch ViewFS Admin Tools Update /group/A /group/B nn1.ali.com nn2…. nn3.ali.com

对Client透明：ViewFS create mkdir open Yunti3 View Distributed Distributed fs.hdfs.impl = Yunti3FileSystem hdfs://hdpnn:9000 /group/A -> nn1 /group/C-> nn1 /group/B -> nn2 /group/D -> nn2 Yunti3 FileSystem viewfs://nsX ZooKeeper View FileSystem Distributed FileSystem hdfs://nn1:9000 hdfs://nn2:9000 Distributed FileSystem Distributed FileSystem Client /group/A /group/C /group/B /group/D NameNode (NS1) NameNode (NS2)

MR ProxyNode MR ProxyNode： Job 调度机制优化：把计算调度到数据所在的地方 每个 JobTracker 只调度一个机房内的作业 ProxyNode 直接处理 JobClient 请求，并自动转发给相应的 JobTracker 或 ResourceManager 提供同一的Job查询接口（Web UI / App） Job 调度机制优化：把计算调度到数据所在的地方 跨机房列表中的数据正在传输中（DC1->DC2），DC2上的 Job 被暂停调度，等待传输完毕 Ad-hoc查询，DC2上的 Job 需要读DC1上的数据，Job暂停调度，通知 CrossNode，数据传输完毕后继续调度 跨机房数据 Join，DC1大表，DC2小表，Job 调度到DC1上，跨机房直接读取DC2数据，无需等待 第3个优化需要打破资源组和机房之间的绑定关系

MR proxynode (cont.) MR ProxyNode RM1 JT1 JT2 RM2 Mapping: JobClient JobClient Mapping: groupA -> JT1 groupB -> JT2 MR ProxyNode 计算还是跟着数据走? Proxy的图，JT，RM都画上 HA是个小问题 RM1 JT1 JT2 RM2 NM TT TT TT TT TT TT NM

数据跨机房迁移 CN1 CN2 CN2 NN1 NN2 NN2 /g/D 3:3 /g/B 3:3 /g/B 3:3 /g/B /g/D /g/A /g/C NN1 NN2 NN2 Pool2 DN1 Pool1 Pool2 DN2 Pool1 Pool2 DN3 Pool1 Pool2 DN4 Pool1 Pool2 DN5 Pool1 Pool2 DN6 Pool1 block copy DataCenter1 DataCenter2

CROSSNODE 一个独立的服务，对NameNode发送指令 主要功能 根据预置的跨机房文件列表计算待拷贝的文件 维护文件原始副本数，跨机房副本数，实际副本数等状态信息 从NameNode实时同步文件创建，移动，删除等信息 对跨机房的流量进行监控和限速 CrossFsck 检查当前跨机房文件的副本放置状况，并指挥NameNode 进行纠正 尽量减少对HDFS的改动

CrossNode (cont.) 跨机房数据迁移，几十PB的数据迁移 如何预先知道需要跨机房的文件？ HDFS文件副本复制不及时？ 将整个资源组的数据作为跨机房文件列表（/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 谢谢！