hdfs 机架感知

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

目录：

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

常用策略：

---

• 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 的内容已经修改成功：

•      

分配原理：

---

• 有了机架感知，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 列表