Hadoop学习：HDFS 机架感知

220次阅读

共计 2343 个字符，预计需要花费 6 分钟才能阅读完成。

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

目录：

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

常用策略：

hdfs 在缺省配置下副本数是 3 个，通常的策略是：

第一个副本放在和 Client 相同机架的 Node 里（如果 Client 不在集群范围，第一个 Node 是随机选取不太满或者不太忙的 Node）
第二个副本放在与第一个 Node不同的机架中的 Node
第三个副本放在与第二个 Node 所在机架里不同的 Node. 示例图如下：

Hadoop 学习：HDFS 机架感知

默认情况下，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