Trex-Group / trex-bigdata

11 stars 6 forks source link

[Hadoop]Slave节点之间的通信 #13

Closed McKey1911 closed 7 years ago

McKey1911 commented 7 years ago

在配置好1Master+2Slaves的Hadoop集群之后,动态添加了一个Slave节点DataNode3(CentOS6.8)。 使用以下命令: hadoop-daemon.sh start datanode yarn-daemon.sh start nodemanager ※使用hadoop-daemon.sh start tasktracker的时候说 no longer supported ※命令是参考老师在另一个issue里分享的资料

操作的时候,我将NameNode上的Hadoop中的各个需要配置的xml以及slaves文件copy到DataNode3,masters文件原来也是想copy过去的,但是操作漏了。 在NameNode上添加DataNode3的DNS信息,在DataNode3上添加NameNode的DNS信息,然后在DataNode3节点执行上述两条命令,启动成功了。

我的疑惑是,我没有配置原有的Slave节点与新增加的Slave节点之间的DNS信息,也就是说对于Hadoop来说,一个Slave节点不是必须要意识到其它的Slave节点的存在。当然,使用IP的话它们之间可以通信。 但是,data replication对于Hadoop也是非常重要的,各个Slave节点之间应该会有data的传输。我对这个传输机制很困惑。是Master做出决策然后告诉Slave节点A将数据传给Slave节点B,同时将B的IP也告诉A吗? 根据老师提供的手顺,DataNode-1和DataNode-2的slaves文件里都有对方主机名并且在hosts里配置了DNS信息。这么做有什么理由吗? @xenron 希望得到您的回答。

xenron commented 7 years ago

先把你的问题,分拆为2个小问题,由浅入深

conf/master 先弄明白这个文件,这是要设置 Secondary NameNode 的配置文件(可以尝试增加仅仅作为Secondary NameNode而不是DataNode的节点) 同理,考虑一下conf/slave的作用是什么,尝试试验一下,验证自己的假设。 追加试验1:DataNode节点能否删除 conf/master 文件 追加试验2:DataNode节点能否删除 conf/slave 文件 参考文档1:(查找关键字:Secondary NameNode) https://hadoop.apache.org/docs/r1.2.1/hdfs_user_guide.html 参考文档2:(docker的配置脚本里面包含了很多小彩蛋,试着读读看) https://github.com/trex-group/Big-Data/blob/master/01_Guide/environment/docker/Hadoop_Ubuntu_Bin/hadoop-master/files/init/configure-members.sh

data replication 简单来说,一切都是NameNode在控制 每个 DataNode 都向 NameNode 的 TCP 9000 端口,定期发送heartbeats(心跳消息),如果 NameNode 不能接收心跳消息,就表明连通性丢失。(conf/core-site.xml) 对于数据块分布而言,有个基本的概念rack-aware(机架感知),针对全部datanode节点之间的延迟时间/带宽,判断是否在同一个机架上。 分布式系统的特性之一就是保证数据不丢失,一台server down 或者一个机架down,或者一个数据中心 down,都尽量要保证数据完整,机架感知就是为了当一个机架 down掉的时候,在其上保存的数据,在其他机架/数据中心,还有另外的备份。

原理大概说完了,下面说两个场景。 第一,集群状态不变的前提下,client端写入新文件 client向namenode提交请求,接受namenode返回的可用节点信息(节点编号,数据块位置等),向datanode写入数据 当数据量较大的时候,可能会写入到多个datanode中 datanode在接收文件完毕后,会根据机架策略和副本数量,以pipeline的方式,向另一个datanode2发送文件,以此类推,直到达到副本数量 第二,向集群追加新的datanode,导致数据块分布不均匀 可以进行Rebalancer(sbin/start-balancer.sh)

大体上的数据分布策略 (1) 将数据块的一个副本放在正在写这个数据块的节点上。 (2) 尽量将数据块的不同副本分布在不同的机架/不同的数据中心上,集群可在完全失去某一机架/数据中心的情况下还能存活。 (3) 一个副本通常被放置在和写文件的节点同一机架的某个节点上,可以减少跨越机架的网络I/O。 (4) 尽量均匀地将HDFS数据分布在集群的DataNode中。

查看一个文件的数据块 $HADOOP_HOME/bin/hadoop fsck /input/LICENSE.txt -files -locations -blocks

dadahu commented 7 years ago

你好,我是小白。 刚买了电脑,还没时间搞环境,看到大家聊的活得火热,发个水贴见谅。

每个 DataNode 都向 NameNode 的 TCP 9000 端口,定期发送heartbeats(心跳消息),如果 可以理解为NameNode为服务中心,DataNode是每个客户端,类似于websocket机制不。

大体上的数据分布策略 可以理解为,一份数据在多个地方,这样分不数据的整体容量将会是原数据容量的好多倍。 现在容量便宜哈哈。

xenron commented 7 years ago

@dadahu 赶快加入,世界有你更精彩 :1st_place_medal: 内存大点儿,能折腾的内容比较多,话说我家电脑32GB。。。

McKey1911 commented 7 years ago

谢谢回答。 将DataNode节点的conf/master,conf/slaves 文件删除,在NameNode节点启动yarn,dfs正常,DataNode节点的服务也正常启动了。 我将conf/slaves 文件scp到DataNode3节点,并配置该节点使其可以免密码ssh登陆到其它节点。然后在这个节点执行停止yarn和dfs的shell,发现其它节点上的DataNode进程、NodeManager进程都停止了,只剩下NameNode节点还在运行ResourceManager进程。 也就是说,在DataNode节点可以停止其它节点的服务。 但是我想不到这么做的好处。并且我猜生产环境不见得会在各个DataNode配置slaves文件。 当然,我觉得在DataNode节点配不配置slaves文件什么的好像也不是什么重点。

接下来该学习Docker了。