hdfs rack机架感知配置

本文详细介绍了如何在Hadoop集群中启用机架感知功能,通过脚本配置来识别不同节点的实际物理位置,从而优化数据传输路径和提高集群性能。通过实例展示了配置步骤和网络拓扑计算方法。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

大型Hadoop集群以机架的形式来组织的,同一个机架上不同节点间的网络状况比不同机架之间更为理想,默认情况下,hadoop的机架感知是没有被启用的。

所有的机器Hadoop都默认在同一个默认的 机架下,以名为”/default-rack”,这种情况下,任何一台datanode机器,不管物理上是否属于同一个机架,都

会被认为是在同一个机架下。

启动hadoop机架感知只需要在core-default.xml中加入net.topology.script.file.name属性配置
<property> 
<name>net.topology.script.file.name</name> 
<value>/home/sy/script.py</value> 
</property> 


这个配置选项的value指定为一个可执行程序,通常为一个脚本,该脚本接受一个参数,输出一个值。接受的参数通常为某台datanode机器的ip地址,而输

出的值通常为该ip地址对应的datanode所在的rack
/home/sy/script.pyimport sys  
rack = {"dn177.tj":"rack1",  
        dn178.tj":"rack1",  
        dn179.tj":"rack1",  
        dn180.tj":"rack1",  
        dn186.tj":"rack2",  
        dn187.tj":"rack2",  
        dn188.tj":"rack2",  
        dn190.tj":"rack2",  
        "192.168.1.177":"rack1",  
        "192.168.1.178":"rack1",  
        "192.168.1.180":"rack1",  
        "192.168.1.186":"rack1",  
        "192.168.1.187":"rack2",  
        "192.168.1.188":"rack2",  
        "192.168.1.190":"rack2",  
        } 
if __name__=="__main__":  
    print "/" + rack.get(sys.argv[1],"rack0") 

最好把主机名和ip都配上。
将脚本属性改为可执行  chmod a+x script.py
重启namenode,如果配置成功 namenode 启动日志中会输出:
org.apache.hadoop.net.NetworkTopology: Adding a new node: /rack1/192.168.1.177:50010 

(如果机架比较复杂,机架上边还有交换机,可把"192.168.1.190":"rack2",改为"192.168.1.190":"/switch1/rack2",本人猜测,还没实践。)


使用CDH的的话,配置机架有两种方法:

1.就是上边说的配置net.topology.script.file.name属性,

2.就是配置CM主页中的主机中的分配




网络拓扑机器之间的距离

有了机架感知,NameNode就可以画出上图所示的datanode网络拓扑图。


D1,R1都是交换机,最底层是datanode。则H1的rackid=/D1/R1/H1,H1的parent是R1,R1的是D1。这些rackid信息可以通过topology.script.file.name配置。有了这些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
### HDFS机架感知配置及工作原理 #### 一、HDFS 机架感知的工作原理 HDFS机架感知是为了优化数据存储和读取效率而设计的一种机制。它通过识别节点在网络中的位置来决定数据块的分布方式,从而减少跨机架的数据传输开销并提升系统的可靠性。 具体来说,在默认情况下,HDFS 使用三副本策略保存文件数据块。第一个副本通常存放在写入请求所在的节点上;第二个副本会被放置到另一个不同的机架上的某个 DataNode 中;第三个副本则被放到与第二个副本相同的机架但不同节点的位置[^3]。这种布局能够有效降低单个机架故障带来的风险,同时也提高了数据访问速度。 #### 二、HDFS 机架感知配置方法 要启用 HDFS机架感知功能,管理员需要完成以下几个方面的设置: 1. **定义网络拓扑结构** 需要在 `core-site.xml` 文件中指定脚本路径用于解析 IP 地址对应的物理位置关系(即所谓的“反向 DNS 查询”)。此脚本应返回类似于 `/rackX/datacenterY` 这样的字符串表示形式。 ```xml <property> <name>topology.script.file.name</name> <value>/path/to/rack-awareness-script.sh</value> </property> ``` 2. **编写 Rack-Aware 脚本** 创建一个可执行 Shell 或其他语言编写的程序用来接收传入参数——DataNodes 的主机名/IP地址列表,并输出相应的机架信息。例如: ```bash #!/bin/bash case $1 in node1|node2) echo "/rack1" ;; node3|node4) echo "/rack2" ;; *) echo "/default-rack" ;; esac ``` 上述例子简单演示了一个小型集群内的两层架构划分逻辑。 #### 三、HDFS 主节点故障切换机制概述 对于 NameNode 的高可用性保障方面,现代版本的 Apache Hadoop 提供了两种主要解决方案:ZooKeeper Failover Controller 和 Quorum Journal Manager (QJM)[^4]。前者依赖外部协调服务 Zookeeper 实现自动化的 Master Election 流程;后者则是基于共享日志存储实现同步更新元数据变更记录的目的。 当 Active NN 出现异常停止运行时,Standby NN 将接管其职责成为新的活动实例继续提供对外的服务接口。整个过程涉及到了一系列复杂的内部通信协议以及状态迁移操作,确保整个转换期间不会丢失任何未提交事务或者破坏已有的一致性约束条件。 ```python from kazoo.client import KazooClient zk = KazooClient(hosts='localhost:2181') zk.start() @zk.ChildrenWatch("/hadoop-ha/ha-cluster") def watch_children(children): print("Current active namenode:", children[0]) # Ensure proper cleanup on exit. try: pass # Your application logic here... finally: zk.stop() ``` 以上 Python 示例展示了如何利用 Kazoo 库监听 HA 模式下 NameNodes 的选举事件变化情况。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

sunyang098

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值