6. hadoop HDFS机架感知

本文介绍了Hadoop中机架感知的概念及其实现方法,包括通过编写机架感知程序和使用脚本两种方式,旨在提高数据可靠性和访问性能。

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

实验环境

hadoop版本: 2.6.5
master: 192.168.1.160
slave1: 192.168.1.161

机架感知

一个hadoop分布式集群会有很多的服务器,由于受到机架槽位和交换机网口的限制,通常大型的分布式集群都会跨好几个机架,机架内的服务器之间的网络速度通常都会高于跨机架服务器之间的网络速度,并且机架之间服务器的网络通信通常受到上层交换机间网络带宽的限制。

HDFS对数据文件是分block存储,每个block默认有3个副本(也可以配置大于3),HDFS对副本的存放策略如下:

  1. 第一个block副本放在和client所在的node里(如果client不在集群范围内,则这第一个node是随机选取的)。
  2. 第二个副本放置在与第一个节点不同的机架中的node中(随机选择)。
  3. 第三个副本放置在与第一个副本所在节点同一机架的另一个节点上。
  4. 如果还有更多的副本则随机放在集群的node里。

这样的策略主要是为了数据的可靠性和数据访问的性能考虑。

  • 数据分布于不同的机架上,就算整个机架挂掉后,其他机架上还有冗余备份,整个集群依然能对外服务。
  • 数据分布于不同的机架上,运行mapreduce任务时可以就近获取所需的数据。

hadoop对机架的感知并非是自适应的,而是需要使用者告诉hadoop机器(ip)与机架的对应关系。

实现

hadoop机架感知可以有两种方式实现,编写机架感知程序和脚本方式。

机架感知程序

  1. 实现接口DNSToSwitchMapping

    import org.apache.hadoop.net.DNSToSwitchMapping;
    import java.util.ArrayList;
    import java.util.List;
    
    public class MyDNSToSwitchMapping implements DNSToSwitchMapping {
    
        @Override
        public List<String> resolve(List<String> list) {
            List<String> paths = new ArrayList<String>();
            if (list != null && !list.isEmpty()) {
                for (String hostname : list) {
                    String rackPath = "";
                    if ("master".equals(hostname)) { //以主机名来判断,实验环境中只有master和slave1。
                        rackPath = "/rack1";
                    } else {
                        rackPath = "/rack2";
                    }
                    paths.add(rackPath);
                }
            }
            return paths;
        }
    
        @Override
        public void reloadCachedMappings() {
        }
    
        @Override
        public void reloadCachedMappings(List<String> list) {
        }
    }
    

pom.xml

```
<dependency>
	<groupId>org.apache.hadoop</groupId>
	<artifactId>hadoop-client</artifactId>
	<version>2.6.5</version>
</dependency>
```
  1. 将上述代码打包,上传到master节点hadoop根目录share/hadoop/common/lib下。

     mvn package -Dmaven.test.skip=true
    
  2. 修改core-site.xml配置。

    <property>       
        <name>net.topology.node.switch.mapping.impl</name>                
        <value>com.tongfang.learn.MyDNSToSwitchMapping</value>
    	<!-- 根据实际的类全路径(加上包名)配置-->
    </property>
    
  3. 将jar包和修改的配置分发到slave1节点上,重新启动节点

    ./sbin/start-dfs.sh 
    
  4. 查看集群机器分布情况

    [hadoop@master hadoop-2.6.5]$ ./bin/hdfs  dfsadmin -printTopology
    Rack: /rack1
       192.168.1.160:50010 (master)
    Rack: /rack2
       192.168.1.161:50010 (slave1)
    

    可以看出机器分布于rack1和rack2两个机架。

脚本
hadoop也提供了脚本的方式来配置机架感知方式,常见的实现方式有shell脚本和python脚本两种方式,这里以python脚本为例。

  1. 编写感知脚本,并授予执行权限。

    #!/usr/bin/python
    #coding=utf-8
    import sys
    rack={
              "192.168.1.160":"/dc1/rack1",
              "192.168.1.161":"/dc1/rack2",
              "master":"/dc1/rack1",
              "slave1":"/dc1/rack2",
            }
            
    if __name__=="__main__":
    	print rack.get(sys.argv[1], "default-rack") #主机名或ip不存在,则使用默认机架default-rack
    

由于没有找到确切的文档说明 到底是主机名还是ip地址会被传入到脚本,所以在脚本中最好兼容主机名和ip地址。

添加执行权限:

	chmod +x test.py
  1. 在master上修改core-site.xml配置。

    <property>
    	<name>net.topology.script.file.name</name>
    	<value>/home/hadoop/test.py</value>
    	<!-- 根据脚本实际路径配置 -->
    </property
    
  2. 将脚本和修改的配置分发到slave1上,并重启集群

    ./sbin/start-dfs.sh 
    
  3. 查看集群机器分布情况。

    [hadoop@master hadoop-2.6.5]$ ./bin/hdfs  dfsadmin -printTopology
    Rack: /dc1/rack1
       192.168.1.160:50010 (master)
    Rack: /dc1/rack2
       192.168.1.161:50010 (slave1)
    
    

可以看出机器分布于 /dc1/rack1和/dc1/rack2两个机架。

### 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=&#39;localhost:2181&#39;) 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 的选举事件变化情况。 ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值