hdfs和yarn高可用对比

el/2024/7/24 1:55:25

序言

   总有一天你会笑着说出曾经令你痛苦的事情,毕竟有些东西虽然不是你想要的,但是却是你自找的,表面上是无奈,实际上是懒得去做选择,成功的路只有一条,而失败的路则是各种各样的原因。

     得不到的时候念念不忘,得到的时候,却不珍惜,这到底是为什么呢?是忘记了出发的初心还是产生了新的欲望而反被其折磨?

高可用

   1 高可用架构对比

    HDFS的出现,就是为了解决海量数据的存储问题,从而采用分布式架构存储文件,将一个大文件按照block块来切分,然后分布在不同的机器,不同的机架中,数据节点能水平扩容,从而能海纳百川,存储海量数据。

    HDFS是为了存储数据的,从而要保证数据的可靠性,从而就有了datanode数据节点的三副本机制,而且在数据写入的时候,是流水线的方式写入,也就是正常情况下三节点数据写入成功才返回客户端成功,特殊情况下,写入一个也成,毕竟她自带了副本复制机制,也就是当副本数不满足设定的时候,会找到距离近的,负载低的,把数据再复制过去。

    HDFS是为了支持海量数据的分析计算的,就像MapReduce程序,文件多副本存储,也就意味着当同一份数据被三个任务跑的时候,可以分布在三台机器上,从而充分的发挥机器的算力。

    HDFS是分布式存储的,从而需要一个相当于字典的索引数据,有什么数据,有多少块,权限是啥,用户是啥,从而就有了namenode,既然有了名称服务器,那就意味着要持久化存储,需要保存相关的一些数据,保存的就是fsimage和edit日志信息,在客户端上传数据的时候,将操作日志记录在edit中,然后返回给客户端,而fsimage则是相当于内存的数据,可以理解为基线,像基准测试一样。

    如上图所示,可以看到很多的组件,包括zkfc,还有QJM集群,再看看yarn集群的高可用。

    对比一下就会看到,yarn集群的高可用架构比hdfs的要简单太多了,没有zkfc,没有qjm集群,只需要一个zk集群来负责选举出active的resourcemanager就好了。

    为什么差别这么大?这就是持久化数据的高可用和无状态高可用的区别了,hdfs的namenode要保持高可用,必须要保证数据同步,从而需要一个共享存储QJM来存放edits日志,然后同步到standby的节点上去,而对于resourcemanager来说,并不需要持久化啥数据,也就是无状态的,就像容器一样,直接删除,再创建一个完全没问题,所以差别来说,就是因为需要保存一些数据,这就是有状态和无状态之分。

    无状态的可以理解为结婚了,没有娃,而有状态的你可以理解为结婚了有了娃,那有了娃怎么办,你得有人看着吧,说分手就分手,对于无状态是可以的,对于有状态的你得找个人看着,就是一个standby了,而另外一个负责赚钱养家,那就是active了,最怕的就是两个都去赚钱了,然后都active了,俗称脑裂split brain,这个时候一般直接打死一个,让你没事就知道赚钱,打死的那个就是standby,只要看着孩子就成,如果两个都看着孩子,就是两个都不去赚钱了,也就是都是standby,其实还好,只是暂时没钱,不会孩子没人管。。。对于无状态的来说,其实还好,都出去赚钱,最多就是钱多了,也就是执行的任务数量多了点,相当于任务重跑了一下,可能会有数据重复,只要任务设计的好,就不会出现这种问题了,那要是两个都不去赚钱,变成了standby,那么就只能喝西北风了,毕竟刚结婚,还有一大堆的task在那等着需要资源resource呢。

    2 近看hdfs

    近看一朵花,远看豆腐渣,很多东西,看的太深,就忘记了全局层面的东西,埋头看路,低头看天,啥都没有。。。

#数据节点存储的数据,包括block块数据,还有数据的校验码
[root@KEL subdir11]# pwd
/$HADOOP_HOME/$DATADIR/dfs/data/current/BP-184102405-192.168.1.10-1612873956948/current/finalized/subdir0/subdir11
[root@KEL subdir11]# cat blk_1073744840
1,1613991123,admin,admin
[root@KEL subdir11]# cat blk_1073744840_4016.meta 
ʗE[root@KEL subdir11]# file blk_1073744840_4016.meta 
blk_1073744840_4016.meta: raw G3 data, byte-padded

    在查看数据节点存储数据的时候,需要注意的是,这些数据块和校验信息并不会存储在namenode里面,这个是datanode和namenode进行通信获取,在启动的时候,会统一汇报,这个也是所谓的安全模式safemode,此时你只能查,不能修改增加元数据。

    再看一下namenode保存的内容:

 #namenode保存的内容,包括edits日志和fsimage
   edits_0000000000000053943-0000000000000053944edits_inprogress_0000000000000053945
  fsimage_0000000000000053730fsimage_0000000000000053730.md5fsimage_0000000000000053930fsimage_0000000000000053930.md5edits_0000000000000013106-0000000000000013107  seen_txidedits_0000000000000013108-0000000000000013109  VERSION
63  edits_0000000000000013110-0000000000000013111
[root@KEL current]# pwd
/$HADOOP_HOME/$DATA_DIR/dfs/name/current
[root@KEL current]# file fsimage_0000000000000053730
fsimage_0000000000000053730: data
[root@KEL current]# file fsimage_0000000000000053730.md5 
fsimage_0000000000000053730.md5: ASCII text
[root@KEL current]# cat fsimage_0000000000000053730.md5 
2c8359248cbcc504dca7e3020f8bb309 *fsimage_0000000000000053730

    可以看到其中有大量的edtis文件,用来记录相关的操作信息,edits的可以理解为历史的,当前正在使用的inprogress。

#使用lsof可以查看当前进程占用的文件
java    2560 root  233u   /edits_inprogress_0000000000000053951
[root@KEL current]# jps
2560 NameNode
[root@KEL current]# lsof -p 2560|grep -v jar

    可以使用命令查看fsimage和edits的内容:

#将fsimage转换成xml
[root@KEL current]# hdfs oiv -p xml -i fsimage_0000000000000053730 -o fsimage.xml
[root@KEL current]# vim  fsimage.xml <?xml version="1.0"?><fsimage><NameSection><genstampV1>1000</genstampV1><genstampV2>1002</genstampV2><genstampV1Limit>0</genstampV1Limit><lastAllocatedBlockId>1073741826</lastAllocatedBlockId><txid>37</txid></NameSection><INodeSection><lastInodeId>16400</lastInodeId><inode><id>16385</id><type>DIRECTORY</type><name></name><mtime>1392772497282</mtime><permission>theuser:supergroup:rwxr-xr-x</permission><nsquota>9223372036854775807</nsquota><dsquota>-1</dsquota></inode>...remaining output omitted..

    查看edits文件内容:

#将edits log转换成xml格式查看,这个里面没内容
[root@KEL current]# hdfs oev -p xml -i edits_0000000000000013122-0000000000000013123 -o edits.xml
[root@KEL current]# vim edits.xml 
[root@KEL current]# cat edits.xml 
<?xml version="1.0" encoding="UTF-8"?>
<EDITS><EDITS_VERSION>-63</EDITS_VERSION><RECORD><OPCODE>OP_START_LOG_SEGMENT</OPCODE><DATA><TXID>13122</TXID></DATA></RECORD><RECORD><OPCODE>OP_END_LOG_SEGMENT</OPCODE><DATA><TXID>13123</TXID></DATA></RECORD>
</EDITS>

    查看journal node保存的内容:

#保存的都是edits文件,active写入,standby的读出
[root@KEL current]# cat last-promised-epoch 
78
[root@KEL current]# cat last-writer-epoch 
78
[root@KEL current]# ls -l edits_*|wc -l
5652

    在高可用架构中,zkfc其实就是namenode的zookeeper连接客户端,当namenode进程挂了之后,zkfc进程是第一时间知道的,然后就执行fence程序,把namenode的状态设置为standby,但是当zkfc进程挂了呢,那就要等一段时间了,因为zkfc只负责自己namenode节点的生杀大权。

    在进行高可用搭建的时候,还需要进行格式化


http://www.ngui.cc/el/5239886.html

相关文章

三月闲聊

序言 生活原本很沉闷&#xff0c;但跑起来有风。 工欲善其事必先利其器&#xff0c;当你有一些想法的时候&#xff0c;如果没有合适的工具&#xff0c;那将是一个很痛苦的过程。。。至于有多痛苦呢&#xff0c;越追求细节的越enjoy。。。 风言风语 1 在理论的指导下实践 无论是…

七月闲聊

序言 风都停了&#xff0c;所以闲下来瞎聊聊。。。 最近头有点痒&#xff0c;可能是要长脑子了。。。 风言风语 1 开源与商业 看最近的天气&#xff0c;总是不太安稳&#xff0c;一会儿暴风雨&#xff0c;一会儿插喉咙&#xff0c;多事之秋。 谈到商业产品的时候&#xff0c;总…

八月闲聊

序言 远方就是窗外的风景&#xff0c;可望而不可及&#xff0c;在家呆的太久&#xff0c;都忘记了今夕是何年。 如果你来南京玩&#xff0c;记得带好你的绿码。。。 风言风语 1 尊重你的用户&#xff0c;也尊重你自己 可以吵架&#xff0c;但是吵架是为了更好的去了解对方&…

平淡让你无脑?

序言 我的意中人&#xff0c;一定会驾着五彩祥云来打死我。。。平凡之间的平淡。 空花幻月&#xff0c;都是用来迷惑众生的。。。听我讲道理&#xff0c;比死还难受。 风言风语 最近都在升级&#xff0c;产品种类繁多&#xff0c;但是从整体的角度来说&#xff0c;都是点点几个…

从一个小问题探讨解题思路

序言 前奏一响&#xff0c;心一动&#xff0c;就是跑路的信号&#xff0c;从入门到删库。。。你看这篇文章&#xff0c;她像不像一封辞职信。 运维的终点在哪儿&#xff1f;如果运维的终点是没有运维&#xff0c;那么这一切又将有什么存在的含义&#xff1f; 风言风语 问题背景…

敏捷运维

序言 表面上都是自由的&#xff0c;实际上四周围墙&#xff0c;无法跨越&#xff1b;表面上都有很多选择&#xff0c;实际上没得选。 成功是一种考验&#xff0c;失败也是&#xff0c;原因能想出来吗&#xff1f; 敏捷运维&#xff0c;敏捷开发&#xff0c;在各种压力进行运维&…

c++中单独大括号的用法

经常看到大的工程中使用单独的大括号&#xff0c;其用法主要是使用单独大括号里面的临时变量。

记录一些cmake的用法

今天用add_directory时&#xff0c;出现了 “you have changed variables that require your cache to be deleted. Configure will be re-run and you may have to reset some variables.” 这样的死循环&#xff0c;原来是要将这条命令加到cmake头部。 顺带记录一些cmake的用…

c++ getline

背景&#xff1a;经常需要读取图像的文件&#xff0c;记录一下 1.getline用法 主要用于获取string中的一行&#xff0c;调用时可以设置单个的分隔符&#xff1b;其中单个的分隔符相当于行中的ifstream中的换行符&#xff02;\n&#xff02;&#xff0c;依次读取分隔的字符. ge…

修改YOLOv3-tiny结构之后

1.为了提高tiny的识别精度&#xff0c;利用11卷积层在原YOLOv3-tiny的基础上做了一些修改&#xff0c;增加了卷积深度&#xff1b; 具体是在每个33卷积层后加入了4个33和11卷积层&#xff0c;然后调整YOLO层的相加层数&#xff08;route&#xff09; 2.在voc数据集上进行训练&…