云梯的多 namenode 和跨机房之路
Post on 29-Jan-2016
124 Views
Preview:
DESCRIPTION
Transcript
云梯的多 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
谢谢!
top related