hadoop(三):hdfs 机架感知

        client 向 Active NN 发送写请求时,NN为这些数据分配DN地址,HDFS文件块副本的放置对于系统总体的可靠性和性能有关键性影响。一个简单但非优化的副本放置策略是,把副本分别放在不一样机架,甚至不一样IDC,这样能够防止整个机架、甚至整个IDC崩溃带来的错误,可是这样文件写必须在多个机架之间、甚至IDC之间传输,增长了副本写的代价,是否有较优的方案来解决这个问题呢?node

目录:apache

  • 经常使用策略
  • 机架配置
  • 分配原理

经常使用策略:vim


  • hdfs 在缺省配置下副本数是3个,一般的策略是:
  1. 第一个副本放在和Client相同机架的Node里(若是Client不在集群范围,第一个Node是随机选取不太满或者不太忙的Node)
  2. 第二个副本放在与第一个Node不一样的机架中的Node
  3. 第三个副本放在与第二个Node所在机架里不一样的Node. 示例图以下:

  • 默认状况下,Hadoop机架感知是没有启用的,这时任何一台 DN 机器,无论物理上是否属于同一个机架,NN 都会默认将他们默认为在/default-rack下, 此时,就很容易出现以前提到的增添机架间网络负载的状况,如咱们前面单节介绍基于 hdp2.4安装的集群就没指定rack, 以下图所示。

机架配置:网络


  • hdfs 的机架感知功能须要在NN机器的hadoop下 core-site.xml里配置net.topology.script.file.name选项,这个配置选项的value指定为一个可执行程序,一般为一个脚本,该脚本接受一个参数,输出一个值
  • 接受的参数一般为datanode机器的ip地址,而输出的值一般为该ip地址对应的datanode所在的rackID
  • Namenode启动时,会判断该配置选项是否为空,若是非空,则表示已经启用机架感知的配置,此时namenode会根据配置寻找该脚本,并在接收到每个datanode的heartbeat时,将该datanode的ip地址做为参数传给该脚本运行,并将获得的输出做为该datanode所属的机架,保存到内存的一个map
  • 脚本的编写,参见Hadoop官方给出的脚本:http://wiki.apache.org/hadoop/topology_rack_awareness_scripts
  • 在 hdp2.4 安装后的 hadoop 目录下的配置文件中, 查看 hadoop的 core-site.xml 文件,已经设置了此选项,以下图
  • 查看 topology_script.py 脚本,里面使用的文件是 topology_mappings.data,用vim编辑此文件,换成真实的网络拓扑,以下
    [network_topology]
    hdp2=/rack1
    192.168.2.2=/rack2
    hdp3=/rack2
    192.168.2.99=/rack1
  •  手工修改配置文件,重启服务后修改内容会被冲掉,因此用咱们在 ambaria 上去修改,选择 "host" -> "Action" -> "Selected hosts" -> "hosts" --> "set Rack" 修改每台host对应的rack, 保存修改,重启因修改配置而受影响的组件服务,成功后示例以下,这时再去看 topology_mappings.data 的内容已经修改为功:app

  •     

分配原理:oop


  • 有了机架感知,NameNode就能够画出下图所示的datanode网络拓扑图,
  • 最底层是Hx是 datanode, 则H1的rackid=/D1/R1/H1,H1的parent是R1,R1的是D1,有了这些rackid信息就能够计算出任意两台datanode之间的距离
    distance(/D1/R1/H1,/D1/R1/H1)=0  相同的datanode
    distance(/D1/R1/H1,/D1/R1/H2)=2  同一rack下的不一样datanode
    distance(/D1/R1/H1,/D1/R1/H4)=4  同一IDC下的不一样datanode
    distance(/D1/R1/H1,/D2/R3/H7)=6  不一样IDC下的datanode
  •  写文件时根据策略输入 dn 节点列表,读文件时按与client由近到远距离返回 dn 列表性能

相关文章
相关标签/搜索