HDFS启动与架构详解

预知

HDFS是被Hadoop应用使用的一个主要的分布式存储文件系统。一个HDFS集群主要由一个NameNode(管理文件系统元数据)和多个DataNode(存储实际的数据)集成。HDFS的架构请参考我的另一篇文章

HDFS启动过程

NameNode会保存它的命名空间状态信息到本地文件系统。

  • fsimage:保存最后一次执行checkpoint时的命名空间状态信息;
  • etids:日志文件。保存最后一次checkpoint之后的命名空间信息修改变化的日志记录。
  1. 当启动HDFS的时候,会先启动NameNode节点;NameNode从镜像文件(fsimage文件)读取HDFS状态信息;
  2. 接着从日志记录文件(editswenjian )加载状态更新信息;
  3. 然后NameNode节点将HDFS的最新状态写入到fsimage文件(也就是将faimage文件和edits文件合并);
  4. 再重新创建一个新的空的日志文件来记录文件修改等日志记录。
    其中,fsimage文件和edit日志记录文件的位置可以在配置文件hdfs-core.xml中通过dfs.namenode.name.dir参数来指定。

由于NameNode只在启动的时候合并fsimage和edits文件,所以当一个大的集群运行很久之后,edits日志文件就会变得很大,这就会影响在NameNode启动时日志文件的读取速度,从而延长了HDFS的启动时间。这就引出了Secondary NameNode。

特性

Secondary NameNode(在1.0.4版本之后,可由Checkpoint Node替代)

Secondary NameNode会定期的合并fsimage和edits文件,并限制edits日志文件的大小在一定的范围之内。Secondary NameNode通常运行在和NameNode不同的机器上。
Secondary NameNode执行这些操作主要由这两个参数来控制:

  • dfs.namenode.checkpoint.period: 两次连续操作之间的时间间隔,默认1个小时;
  • dfs.namenode.checkpoint.txns: 定义发生在NameNode上的最新事物数,默认一百万个,优先级大于第一个。

Checkpoint Node

Checkpoint Node定期创建命名空间的checkpoint。从NameNode下载fsimage和edits文件到本地进行合并,并上传行的镜像文件给NameNode。Checkpoint Node一般也是运行于一台不同的机器上面,可由命令bin/hdfs namenode -checkpoint启动。Checkpoint node跟Secondary node一样由相同的参数配置控制。

Backup Node

Backup Node除了提供跟Checkpoint Node一样的功能外,它会在内存中运行一个最新的跟NameNode状态同步的内存副本。Backup Node不需要从NameNode下载fsimage和edits日志文件来创建checkpoint(在CheckpointNode和SecondaryNode中可能需要);因为BackupNode总是有一个同NameNode一样的内存副本。NameNode在同一时间只支持一个BackupNode节点;如果有一个BackupNode被使用,那么CheckpointNode是不能够存在的。BackupNode的配置同CheckpointNode一样,他又bin/hdfs namenode -backup命令启动。

机架感知

典型的,一个大的Hadoop集群会被放在一个机群中,在这样的机群中,比起跨机架来说,在相同的机架上网络流量会更好。同时,NameNode也会放置不同的块副本到不同的机架上来增强集群的容错性能。集群管理员可以通过配置变量net.topology.script.file.name来决定节点所属机架的策略。当这个脚本被配置后,每个节点都会运行这个脚本来决定自己所处的机架id。默认所有的节点都属于同一个机架。

安全模式

NameNode启动过程中,加载fsimage和edits文件,然后等待DataNode启动并且向NameNode报告他们的状态;这个时间段之间,NameNode就是出于安全模式。NameNode的安全模式实际就是HDFS处于只读模式,在这个模式下所有的对文件系统的修改操作都不允许。在DataNode已经报告他们的文件块可用之后,NameNode会自动从安全模式下解除。如果有需要,HDFS可以通过bin/hdfs dfsadmin -safemode命令来设置为安全模式状态。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 157,298评论 4 360
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 66,701评论 1 290
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 107,078评论 0 237
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,687评论 0 202
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,018评论 3 286
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,410评论 1 211
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,729评论 2 310
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,412评论 0 194
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,124评论 1 239
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,379评论 2 242
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,903评论 1 257
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,268评论 2 251
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,894评论 3 233
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,014评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,770评论 0 192
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,435评论 2 269
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,312评论 2 260

推荐阅读更多精彩内容

  • 认识HDFS HDFS的特点: 高容错性高吞吐量故障的检测和自动快速恢复流式的数据访问大数据集一次写入,多次读写 ...
    Bloo_m阅读 3,191评论 6 8
  • Hadoop2.X后可以划分为三部分:HDFS、MapReduce和Yarn,本篇主要看一下HDFS。 架构图 进...
    忘净空阅读 1,023评论 1 0
  • (一)分布式文件系统概述 数据量越来越多,在一个操作系统管辖的范围存不下了,那么就分配到更多的操作系统管理的磁盘中...
    时待吾阅读 1,284评论 0 0
  • 1.felicity精听3.5h 2.单词1h 3.读书2h 4.跑步10km 自律意味着想法决定行为,而非情绪....
    cleddie阅读 118评论 0 0
  • 下周三就是冬至了,就要進入數九天,可最近幾天的天氣還是很暖和,雙休日陽光燦爛,有春天的感覺。早上第一次醒來大約四點...
    如心1976阅读 153评论 0 0