云梯的多namenode和跨
机房之路
罗李(花名:鬼厉)
guili.ll@taobao.com
@luoli523
提纲
• 项目背景
• 构建跨机房集群的困难
• 我们的方案
项目背景
• 云梯集群
• Hadoop集群
• 版本代码有云梯开发团队维护
• 2009年开始上线服务
• 跨机房之前(2013年4月)规模4500台,109PB
• 大集群,多租户(>5000),多资源组(>150)
• 生产任务、数据分析...
项目背景
• 曾经限制云梯扩展性的因素
• NameNode处理RPC性能
• NameNode内存
• JobTracker处理RPC性能
• JobTracker带宽
• JDK限制
• 。。。
• 现在
• 云梯集群机房机位不够
• 数据...
项目背景
• 云梯机房机位已满
• 存储利用率超过85%
• 计算利用率接近100%
• 几乎每天都有新的存储和计算资源的申请
1. NameNode的扩展性
2. 机房间网络限制
3. 数据应该如何跨机房分布?
4. 计算应该如何跨机房分布?
5. 几十PB数据的迁移,带数据升级
6. 怎样做到对用户透明?
7. 方案是否能扩展到多机房(>=3)?
需要解决的问题
NAMENODE的扩展性
• 性能压力:存储容量
• N亿文件,N亿block
• 可垂直扩展:物理内存,96GB->192GB->…->1TB?
• 性能压力:RPC请求压力
• 几乎所有的RPC是有状态的,需要全局锁,更新树
• Clien...
跨机房网络限制
• 带宽
• 单机房内:点对点的带宽1Gbps
• 跨机房间(5000 vs. 5000):点对点的带宽≈20Mbps
• 总带宽较小,容易被打满,成为瓶颈
• 延时
• 1ms之内 -> 5-10ms
• 对离线作业的影响可控...
数据和计算如何跨机房分布
• N个资源组,M个机房
GroupA
GroupC
GroupB
DC1
DC2
GroupD
• 任意资源组的计算/存储资源不超过单个机房总量
• 单个计算任务 (Job) 的所有 Task 在同一机房内运行
• ...
跨机房的架构
机房1 机房2
独享带宽
用户
Gateway
内部网络
NN1 NN2
JT1 JT2
/group/B
/group/D
/group/A
/group/C
DN
TT
DN
TT
DN
TT DN
TT
DN
TT
grou...
技术实现
多NAMENODE方案 —— FEDERATION
• 业界有成功案例:Facebook
• 原始方案:单机房多NameNode
• 目的:拆分Namespace
NN1
DN DN DN DN DN DN
NN2
Pool1
/disk*/p...
NAMESPACE SPLIT
• distcp? —— 慢,代价大
• FastCopy? —— 快很多,没有物理拷贝,但仍然太慢
• From Facebook
• https://issues.apache.org/jira/browse...
NAMESPACE SPLIT
• 我们的拆分方案
NN1 NN2
/group/A
/group/B
/group/C
/group/D
Pool2
/disk*/p2
DN1
Pool1
/disk*/p1
Pool2
/disk*/p2
...
对CLIENT透明:VIEWFS
• 用户无需感知集群多机房的细节
• HDFS多NameNode
• ViewFS
• MapReduce 计算
• JobTracker Proxy
• ResourceManager Proxy(Hadoo...
对CLIENT透明:VIEWFS
• 配合HDFS Federation使用
• 要点:
• Client Side Mount Table
• 屏蔽多namespace细节
• fs.default.name: hdfs://nn.ali.c...
NewFileSystem
对CLIENT透明:VIEWFS
Zookeeper
nn1.ali.com nn2…. nn3.ali.com
/group/A /group/B
Config: mount table
ViewFileSyste...
对CLIENT透明:VIEWFS
Yunti3
FileSystem
View
FileSystem
Distributed
FileSystem
Distributed
FileSystem
Distributed
FileSystem
Na...
MR PROXYNODE
• MR ProxyNode:
• 每个 JobTracker 只调度一个机房内的作业
• ProxyNode 直接处理 JobClient 请求,并自动转发给相应
的 JobTracker 或 ResourceMan...
MR PROXYNODE (CONT.)
JobClient JobClient
MR
ProxyNode
JT1 JT2
TT TT TT TT TT TT
Mapping:
groupA -> JT1
groupB -> JT2
NM NM...
数据跨机房迁移
NN1 NN2
Pool
2
DN1
Pool
1
Pool
2
DN2
Pool
1
Pool
2
DN3
Pool
1
DataCenter1 DataCenter2
Pool
2
DN4
Pool
1
Pool
2
DN5...
CROSSNODE
• 一个独立的服务,对NameNode发送指令
• 主要功能
1. 根据预置的跨机房文件列表计算待拷贝的文件
2. 让NameNode增加跨机房的文件副本
3. 维护文件原始副本数,跨机房副本数,实际副本数等状态
信息
4....
CROSSNODE (CONT.)
• 跨机房数据迁移,几十PB的数据迁移
• 将整个资源组的数据作为跨机房文件列表(/group/B)
• 副本数 3:0 -> 3:3 -> 0:3
• 如何预先知道需要跨机房的文件?
• 通过历史作业分析得...
CROSSNODE内部结构
/a/b DC2
/c/d DC2
云梯现在的样子
• 多NameNode,跨越2个物理机房:
• HDFS Federation
• 跨机房副本管理,数据迁移
• CrossNode
• 多机房对用户透明
• ViewFS
• MR ProxyNode
• 规模已接近万台(还没...
云梯将来的样子
• 对外服务?
• 云端企业私有hadoop集群?
• 集成分布式解决方案?
• 搭载云梯hadoop版本
• 搭载我们的hbase版本和hive版本
• hadoop淘宝开源发行版?
• 。。。。。
Q & A
谢谢!
of 27

云梯的多Namenode和跨机房之路

How to build a hadoop cluster which cross datacenters
Published on: Mar 3, 2016
Published in: Engineering      
Source: www.slideshare.net


Transcripts - 云梯的多Namenode和跨机房之路

  • 1. 云梯的多namenode和跨 机房之路 罗李(花名:鬼厉) guili.ll@taobao.com @luoli523
  • 2. 提纲 • 项目背景 • 构建跨机房集群的困难 • 我们的方案
  • 3. 项目背景 • 云梯集群 • Hadoop集群 • 版本代码有云梯开发团队维护 • 2009年开始上线服务 • 跨机房之前(2013年4月)规模4500台,109PB • 大集群,多租户(>5000),多资源组(>150) • 生产任务、数据分析、数据开发和测试共享集群 • 计算分时,存储和计算quota • 目前规模:5000 × 2 (分布在2个IDC)
  • 4. 项目背景 • 曾经限制云梯扩展性的因素 • NameNode处理RPC性能 • NameNode内存 • JobTracker处理RPC性能 • JobTracker带宽 • JDK限制 • 。。。 • 现在 • 云梯集群机房机位不够 • 数据量的日增长速度让云梯机房最多支撑到2013年6月底
  • 5. 项目背景 • 云梯机房机位已满 • 存储利用率超过85% • 计算利用率接近100% • 几乎每天都有新的存储和计算资源的申请
  • 6. 1. NameNode的扩展性 2. 机房间网络限制 3. 数据应该如何跨机房分布? 4. 计算应该如何跨机房分布? 5. 几十PB数据的迁移,带数据升级 6. 怎样做到对用户透明? 7. 方案是否能扩展到多机房(>=3)? 需要解决的问题
  • 7. 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
  • 8. 跨机房网络限制 • 带宽 • 单机房内:点对点的带宽1Gbps • 跨机房间(5000 vs. 5000):点对点的带宽≈20Mbps • 总带宽较小,容易被打满,成为瓶颈 • 延时 • 1ms之内 -> 5-10ms • 对离线作业的影响可控 • 故障 • 机房间网络故障如何处理? • 如何保障断网后,任意一个机房内部的服务是否正常?
  • 9. 数据和计算如何跨机房分布 • N个资源组,M个机房 GroupA GroupC GroupB DC1 DC2 GroupD • 任意资源组的计算/存储资源不超过单个机房总量 • 单个计算任务 (Job) 的所有 Task 在同一机房内运行 • (默认)产生的数据只写到本地机房 • 也有部分数据需要跨机房写 • (默认)只读取本机房的文件副本 • 也有少部分作业直接跨机房读 尽量减少 跨机房的 数据流量
  • 10. 跨机房的架构 机房1 机房2 独享带宽 用户 Gateway 内部网络 NN1 NN2 JT1 JT2 /group/B /group/D /group/A /group/C DN TT DN TT DN TT DN TT DN TT groupB DN TT groupA Task Task Task TaskTask DN TT /group/B /tbl1 /group/A /tbl2 Cross Node
  • 11. 技术实现
  • 12. 多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 Block Pools
  • 13. 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 • 我们的方案
  • 14. 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
  • 15. 对CLIENT透明:VIEWFS • 用户无需感知集群多机房的细节 • HDFS多NameNode • ViewFS • MapReduce 计算 • JobTracker Proxy • ResourceManager Proxy(Hadoop 2.0)
  • 16. 对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
  • 17. 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 ViewFS Admin Tools Update Watch
  • 18. 对CLIENT透明:VIEWFS Yunti3 FileSystem View FileSystem Distributed FileSystem Distributed FileSystem Distributed FileSystem NameNode (NS1) NameNode (NS2) mkdir ZooKeeper create open 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
  • 19. 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数据,无需等待
  • 20. MR PROXYNODE (CONT.) JobClient JobClient MR ProxyNode JT1 JT2 TT TT TT TT TT TT Mapping: groupA -> JT1 groupB -> JT2 NM NM RM1 RM2
  • 21. 数据跨机房迁移 NN1 NN2 Pool 2 DN1 Pool 1 Pool 2 DN2 Pool 1 Pool 2 DN3 Pool 1 DataCenter1 DataCenter2 Pool 2 DN4 Pool 1 Pool 2 DN5 Pool 1 Pool 2 DN6 Pool 1 /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
  • 22. CROSSNODE • 一个独立的服务,对NameNode发送指令 • 主要功能 1. 根据预置的跨机房文件列表计算待拷贝的文件 2. 让NameNode增加跨机房的文件副本 3. 维护文件原始副本数,跨机房副本数,实际副本数等状态 信息 4. 从NameNode实时同步文件创建,移动,删除等信息 5. 对跨机房的流量进行监控和限速 6. CrossFsck 检查当前跨机房文件的副本放置状况,并指挥 NameNode 进行纠正
  • 23. CROSSNODE (CONT.) • 跨机房数据迁移,几十PB的数据迁移 • 将整个资源组的数据作为跨机房文件列表(/group/B) • 副本数 3:0 -> 3:3 -> 0:3 • 如何预先知道需要跨机房的文件? • 通过历史作业分析得到大部分需要跨机房的文件或目录 • 形成一个跨机房文件列表,作为CrossNode的输入 • HDFS文件副本复制不及时? • JobTracker对所有的Job输入做检查 • 和CrossNode进行通信 • 可以暂停Job的执行
  • 24. CROSSNODE内部结构 /a/b DC2 /c/d DC2
  • 25. 云梯现在的样子 • 多NameNode,跨越2个物理机房: • HDFS Federation • 跨机房副本管理,数据迁移 • CrossNode • 多机房对用户透明 • ViewFS • MR ProxyNode • 规模已接近万台(还没到一万,到那天我会告诉大家的) • 可存储数据容量220PB
  • 26. 云梯将来的样子 • 对外服务? • 云端企业私有hadoop集群? • 集成分布式解决方案? • 搭载云梯hadoop版本 • 搭载我们的hbase版本和hive版本 • hadoop淘宝开源发行版? • 。。。。。
  • 27. Q & A 谢谢!

Related Documents