基于HDFS的高可靠性存储系统的研究*

李明明，李　伟

(1.西安科技大学 通信与信息工程学院，陕西 西安 710054；2.西安邮电大学 自动化学院，陕西 西安 710121)



基于HDFS的高可靠性存储系统的研究*

李明明1，李伟2

(1.西安科技大学 通信与信息工程学院，陕西 西安 710054；2.西安邮电大学 自动化学院，陕西 西安 710121)

由于机器硬件故障导致的重要文件丢失对工作造成了极大影响。HDFS分布式文件系统通过文件副本机制提高了存储的可靠性。但HDFS中NameNode单点故障问题导致了当NameNode岩机时，整个集群不可用，从而导致了用HDFS进行文件存储不是100%的安全可靠。文中通过UCarp虚拟IP软件建立NameNode的备份节点。当HDFS岩机时，备份节点会自动竞争为新的NameNode，为集群提供元数据服务，从而保证HDFS在任何时候都不会有数据丢失现象，提高了HDFS的可靠性。

Hadoop平台；分布式文件系统；名字节点；备份节点；UCarp

2.SchoolofAutomation，Xi’anUniversityofPosts&Telecommunications，Xi’an710121，China)

0　引　言

由于机器硬件故障导致的重要文件丢失对于工作造成极大的影响。常用的存储方式如FCSAN存储，由于成本较高而不能被大多数企业接受。

Hadoop是由Apache基金会开发的分布式系统基础架构。主要包括HDFS分布式文件系统，MapReduce并行计算框，HBase数据库和Zookeeper分布式锁等模块。其核心是HDFS和MapReduce.Hadoop可以使得用户在不了解分布式底层细节的情况下开发分布式程序，充分利用集群的高速运算及存储能力，具有可靠性、高效性、可伸缩的特点[1-4]。Hadoop可架构在普通服务器或普通计算机上，成本较低，任何人都可使用。与传统的并行计算技术MPI相比较，MPI更适合于计算密集型任务的处理，而Hadoop由于具有分布式文件系统的支撑，更适合处理数据密集型或数据计算同时密集型任务。作为一个并行数据处理引擎Hadoop 表现非常突出，目前已成为云计算并行计算方面事实上的标准[5-6]。

HDFS通过文件冗余存储保证了文件安全。通常文件会被存为3个副本。其中的2个副本在同一个机架上的两上不同节点上，第三个副本在不同机架的另一个节点上，这样保证了无论是任何一个DataNode岩机或者即使有一个机架网络不通时，也不会影响文件的使用。3个DataNode同时岩机的概率非常小，可以认为不会发生。该机制大大提高了存储的可靠性。HDFS常作为云存储的解决方案之一。

但是在HADOOP1.0中，存在着NameNode单点故障的问题。如果NameNode岩机，整个集群会失效。通常情况下Secondary NameNode并不是NameNode的热备份[7]。由于某种原因，比如上层程序不支持，有些Hadoop不能马上迁移到2.0，那1.0中的HDFS问题如果能得到妥善解决，将会大大增强集群的稳定性，并使HDFS可以作为高可靠性存储的一种廉价且有效的解决方案[8-10〗[11-13]。

文中提出了一种通过IP地址争用软件Ucarp，使得在NameNode岩机时，BackupNode能作为NameNode的备份而代替NameNode的作用。从而有效解决了Hadoop1.0中，NameNode单点故障的问题[14]。

1　NameNode单点故障问题描述

1.1HDFS架构图

图1　HDFS架构图Fig.1　HDFS architecture

图1为HDFS架构图。HDFS是一个古老的master-slave结构。包含4个组成部分。NameNode，DataNode，Secondary NameNode和Client.

NameNode是master，其作用是管理HDFS名字空间，管理数据块映射信息，配置副本策略，处理客户端读写请求，存储元数据。它实际不读写文件，只是分配那个DataNode应该读写文件。

DataNode是Slave，存储实际数据块，执行数据块读写，是真正的能够进行数据读写的节点。DataNode通过心跳机制向NameNode汇报自己的运行情况。

Secondary NameNode：并非NodeNode的热备；其主要作用是辅助NameNode，分担NameNode的工作量，即定期合并元数据信息。它会定期合并fsimage和fsedits，推送给NameNode；在紧急情况下，可辅助恢复NameNode。

Client：客户端，用来访问hdfs中的数据。作用包括文件切分、与NameNode交互，获取文件位置信息、与DataNode交互，读取或写入数据、管理HDFS、访问HDFS等。

由于有副本策略，即使DataNode岩机，也不会丢数据；但由于NameNode占有绝对重要的地位。一旦NameNode岩机，整个集群中的数据将无法访问，这就是NameNode单点故障问题。为了应对NameNode岩机造成的影响，一方面，在集群配置时，NameNode应选性能优秀的设备。另一方面，可通过第3节介绍的办法解决这个问题。为说明原理，需要进一步了解HDFS的元数据文件合并流。通常大家有一个误解，认为Secondary NameNode是NameNode的备份。其实，Secondary NameNode由于其设计机理是为了分担NameNode的工作量，它并不能作为NameNode的备份。

1.2HDFS元数据镜象文件合并流程

NameNode 2个重要文件：fsimage元数据镜象文件，用来保存文件系统的目录树；edits元数据操作日志，其中存储的是针对目录树的修改操作。 这2个文件都是保存在NameNode的磁盘上的文件。

元数据镜像是内存中保存一份最新的文件系统目录树。只有有了它，NameNode才能知道那个文件块存储在什么位置，才能作为整个集群的心脏控制Client与DataNode之间数据的读写访问。而内存中的镜像是由磁盘上的2个文件fsimage与edits定期合并得到的。

因为NameNode在启动时需要合并fsimage与edits2个文件生成一个新的元数据镜像，edits文件过大将导致NameNode重启速度变慢。Secondary namenode负责定期合并fsimage与edits文件，从最初设计的角度看，SecondaryNameNode并非NameNode的热备份。图2是HDFS中的元数据镜象文件合并流程示意图。

图2　元数据镜象文件合并流程Fig.2　Metadata image file merge process

FSDirectory是内存中的目录树，用来保存文件系统中有那些目录，各目录中有那些文件，FSDirectory是内存中的数据，edits和fsimage是磁盘上的数据，一旦节点挂掉之后，内存中的数据FSDirectory马上就会丢掉，只留下磁盘上的数据edits，和fsimage，可以通过磁盘上的文件合并出内存中的FSDirectory，合并的工作量是很大的，该工作不能交给NameNode做，因为NameNode要为用户提供访问请求，管理整个集群，其任务非常多，若合并FSDirectory的工作交给NameNode做，NameNode的压力会非常大，因此引入新的角色，Secondary NameNode，用它来定期合并2个文件。假设client创建了一个文件，/home/dong，会记录在FSDirectory中，同时，磁盘上的日志文件edits会被修改，fsimage不会被修改。

默认情况下，SecondaryNameNode每个小时会唤醒一个进程与NameNode通信，说要对2个文件进行一次合并；此时，NameNode会创建一个新的文件，edits.new，有新的用户操作请求就写到新的edits.new中，同时，把2个旧的文件edits和fsimage拖到SecondaryNameNode上。SecondaryNameNode将fsimage加载到内存中，并重做edits，生成新的fsimage叫fsimage.ckpt，并将其推送到NameNode。NameNode将fsimage.ckpt文件重命名为fsimage，并将edits.new重命名为edits.这样的做法使得edits要小很多。另外，fsimage.ckpt其实是NameNode的fsimage的副本。如果NameNode挂掉，则可用secondaryNameNode上的fsimage.ckpt代替NameNode上的fsimage.由于默认SecondaryNameNode一小时才会合并一次，这一小时之内的数据就会丢失。虽然这个时间是可以设置的。但是如果时间太短，增加了元数据镜像文件合并的频率，太短的合并时间导致Secondary NameNode因负载太重而不可用。因此，采用Secondary NameNode总是存在从最后一次文件合并至岩机时间内的数据丢失问题，所以它不能作为NameNode的备份。

2　基于UCarp的高可靠性存储系统方案

每一个系统都有一个管理的部分，HDFS的主节点(Namenode)就相当于电脑的系统所在盘。如果电脑的系统所在盘损坏，后果是可想而知的，电脑必然不能启动，更不提使用电脑中的文件资料了。同样，HDFS的主节点(Namenode)宕机也必然会影响HDFS的整体工作。

在Hadoop0.21.0之后的版本中实现了BackupNode机制。在BackupNode的内存中保存一份和NameNode元数据完全一致的镜像。当元数据发生变化时，NameNode与BackupNode同步更新，此时BackupNode可直接利用自身的镜像，无需再从NameNode进行下载。该机制使得BackupNode与Secondary NameNode相比较效率更高，并且元数据同步更新，恢复时可以保证与最新的元数据一致。

2.1Hadoop集群配置

本实验中，需要4台机器。一台当作主节点NameNode00，另一台是备份节点NameNode01，另外2台是数据节点，分别称为DataNode01，DataNode02.为了在NameNode岩机后，由BackupNode接管NameNode的工作，整个过程不需要改变DataNode的配置，需要在主节点NameNode00和备份节点NameNode01上安装虚拟IP软件UCarp，两者共用一个虚拟IP，当NameNode宕机后，Backupnode自动竞争到虚拟IP，Hadoop集群的数据节点自动指向Backupnode，修改Backupnode的配置文件后，Backup即能以active身份启动，此时集群仍然能够正常运行，保证数据不丢失。这几台节点的配置见表1.

masters：hadoop的secondary-masters主机列表，当启动Hadoop时，其会在当前主机上启动NameNode和JobTracker，然后通过SSH连接此文件中的主机以作为备用NameNode；正常情况下应该写SecondaryNameNode的IP地址。这里把NameNode00和NameNode01的masters都写成自己的IP地址，意思就是让NameNode00和NameNode01分别作为自己的SecondaryNameNode以实现元数据文件合并功能。即在本实验中，没有配置SecondaryNameNode.如果设备多，也可以配置单独的SecondaryNameNode.DataNode中的masters的配置没有用。

表1　Hadoop集群各节点配置表

slavers：Hadoop集群的slave(datanode)和tasktracker的主机列表，master启动时会通过SSH连接至此列表中的所有主机并为其启动DataNode和taskTracker进程；

core-site.xml中的fs.default.name用于定义hdfs的名称节点和其默认的文件系统。其值是一个URI，即NameNode的RPC服务器监听地址。一般值为：hdfs：//192.168.1.11：9 000，这里的ip地址正常情况下是NameNode的IP地址；

Hdfs-site.xml中的dfs.http.address属性的值配置的是NameNode的web管理端口。通常应配为192.168.1.11：50 070，其中IP地址为NameNode的IP地址。

本实验关键点在于

1)将NameNode的fs.default.name和dfs.http.address的IP均配置为0.0.0.0，使得NameNode可以在本地所有IP地址上监听，客户端可以通过本机的实际IP和虚拟IP访问NameNode；

2)BackupNode上的fs.default.name和dfs.http.address的IP配置为NameNode的IP192.168.1.11，使得Backup Node可以访问NameNode；

3)DataNode上的fs.default.name和dfs.http.address的IP均配置为虚拟IP地址192.168.1.9，当NameNode岩机后，Backup Node节点会接替NameNode的虚拟IP地址，这些对于DataNode是透明的，DataNode无需任何更改。

2.2安装UCarp软件

为了实现备份节点到主节点的切换，需要在主节点NameNode00和备份节点NameNode01上安装虚拟IP软件Ucarp.在以上2台机器上，切换到软件所在目录/root/Desktop/software，输入安装命令

rpm-ivh ucarp-1.5.2-1.el5.i386.rpm

复制脚文中件到/etc/下，脚文中件为ucarp.sh，vip-up.sh，vip-down.sh，拖动即可。

Namenode00的脚本内容为

ucarp.sh：

#!/bin/sh

echo “123456” | sudo-S ucarp--interface=eth0--srcip=192.168.1.11--vhid=1--pass=mypassword--addr=192.168.1.9

--preempt--neutral--advbase=1--upscript=/etc/vip-up.sh--downscript=/etc/vip-down.sh

vip-up.sh：

#! /bin/sh

echo “123456” | sudo-S /sbin/ip addr add 192.168.1.9/24 dev eth0

vip-down.sh：

#! /bin/sh

echo “123456” | sudo-S /sbin/ip addr del 192.168.1.9/24 dev eth0

其中ucarp.sh为ucarp的启动脚本。Srcip=192.168.1.11为NameNode00的真实IP，addr=192.168.1.9为对外的虚拟IP.

在NameNode01(Backup Node)上安装Ucarp时，需要将srcip后面的值改为NameNode01的真实IP：192.168.1.22，虚拟IP仍为192.168.1.9，这样2个节点才能共用同一个IP地址。其余部分的配置文件完全相同。由于2个节点共用了同一个IP地址，先启动的节点会争用到192.168.1.9这个IP，对外表现的IP地址就是192.168.1.9，所有的DataNode就会把具有192.168.1.9的节点当作NameNode来看待，它就在整个集群中充当NameNode的角色。

在Namenode00上启动ucarp，在数据节点上ssh192.168.1.9能显示登陆到Namenode00上即说明安装成功。启动命令：

/etc/ucarp.sh

2.3实验过程

本实验为了证明当NameNode00岩机后，可以用NameNode01替代NaomeNode00，保证数据不丢失。

1)启动4台设备，并先后在Namenode00，和Namenode01上用以下命令启动虚拟IP软件；

# nohup /etc/ucarp.sh &

2)测试一下Namenode00是否竞争到192.168.1.9的虚拟IP地址。在任意数据节点上ssh一下虚拟IP.若能看到NoameNode00的名字，表示NameNode00况争到了虚拟IP地址；

# ssh 192.168.1.9 hostname

3)在NomeNode00上启动Hadoop集群，并保证HDFS启动成功；

# cd /home/user/hadoop-0.21.0

# bin/start-dfs.sh&

以上命令会启动NamdNode00，DataNode01，DataNode02.

4)以Backup方式启动Namenode01.

# cd /home/user/hadoop-0.21.0

# bin/hadoop-daemon.sh start Namenode-Backup

5)在Namenode01上查看HDFS文件目录信息。结果如图3所示；

# bin/hadoop dfs-lsr/

图3　在Backupnode上查看HDFS目录Fig.3　View HDFS directory in backupnode

6)在Namenode0上将Hadoop.pdf文件上传到HDFS系统中；

再次在Namenode01上查看HDFS文件目录信息。结果如图4所示，可见Hadoop.pdf文件已上传成功，且备份节点与主节点已经同步。

bin/hadoop dfs-lsr/

图4　Backupnode与Namenode成功同步Fig.4　Backupnode synchronized with namenode

7)现在将Namenode00关机，模拟Namenode00岩机故障。修改Namenode01配置文件。

修改hadoop安装目录conf文件夹中的core-site.xml中的fs.default.name属性和hdfs-site.xml中的dfs.http.address属性，使2个文件中对应的IP地址由192.168.1.11变为0.0.0.0，别的不用变；

8)结束Namenode01上的Namenode进程。先用jps命令查出Namenode进程号，再结束进程。然后以以active方式启动NameNode01.图5和图6分别是结束Backup进程及以Active方式启动NameNode01的命令及运行结果；

# Jps

# kill-9 4596

# bin/hadoop-daemon.sh start Namenode

图5　结束Backup进程Fig.5　Backup process finishing

图6　以Active方式启动NameNode01Fig.6　Start up namenode01 in active mode

9)从HDFS上拷贝Hadoop.pdf到Namenode01桌面的result文件夹中，看是否能成功。当然，result文件夹首先是空的。可以看到，result文件中成功下载了测试文件，并没有因为Namenode的宕机而丢失文件。实验成功。实验结束后从图7可见成功下载了文件；

# hadoop fs-get Hadoop.pdf.

图7　文件未丢失Fig.7　File without loss

10)为了进一步了解该备份机制的性能，用一个很大的文件，从一台配置为client的设备上上传至HDFS，文件开始上传后，在文件传输过程中让NameNode岩机，然后用BackupNode代替NameNode，发现该文件仍能正确从HDFS上被下载下来。这是由于当文件已经开始传输后，就与NameNode没有关系了，是client与DataNode直接通信进行文件传输的。该实验进一步说明了这种备份机制的可靠性。

3　结　论

1)通过主节点(Namenode00)宕机的过程中，成功将测试文件拷贝到本地目录。实现了存储的重要资料文件零丢失，达到了预期目标；

2)这个功能是巧妙而又实用的，让无数由于硬盘毁灭性损坏而丢失重要文件资料的普通用户看到了希望的曙光；

3)对于传统的存储介质，HDFS分布式文件系统的优越性是显而易见的，在廉价的硬件基础之上，搭建一个平台即能达到存储文件质的飞跃；

4)以上实验中，备份节点向主节点的切换是冷切换的，实现备份节点向主节点热切换，将是进一步的研究内容。

References

[1]Tom White.Hadoop权威指南[M].曾大聃，周傲英，译.北京：清华大学出版社，2010.

Tom White.Hadoop-the definitive guide[M].ZENG Da-ran，ZHOU Ao-ying，Translation.Beijing：Tsinghua University Press，2010.

[2]李伟.Hadoop平台下的分形图像压缩编码[J].测控技术，2014，33(4)：50-53.

LI Wei.Fractal image compression implemented in Hadoop platform[J].Measurement & Control Technology，2014，33(4)：50-53.

[3]文艾，王磊.高可用性的HDFS-Hadoop分布式文件系统深度实践[M].北京：清华大学出版社，2012.

WEN Ai，WANG Lei.High availability of HDFS-depth practice of hadoop distributed file system[M].Beijing：Tsinghua University Press，2012.

[4]彭渊.大规模分布式系统架构与设计实战[M].北京：机械工业出版社，2014.

PENG Yuan.Large scale distributed system architecture and design practice[M].Beijing：Machinery Industry Press，2014.

[5]王鹏.云计算的关键技术与应用实例[M].北京：人民邮电出版社，2010.

WANG Peng.Key techniques and application of cloud computing[M].Beijing：People Post Press，2010.

[6]林子雨.大数据技术原理与应用[M].北京：人民邮电出版社，2015.

LIN Zi-yu.Big data theory and application[M].Beijing：People Post Press，2015.

[7]Hadoop.Hadoop官网[EB/OL].http://hadoop.apache.org.2015-03-22/2016-04-06.

Hadoop.Hadoop official website[EB/OL].http://hadoop. apache.org. 2015-03-22/2016-04-06.

[8]郝秦霞．智能分户供暖监控系统的无线温控器设计[J]．西安科技大学学报，2013，33(6)：737-740．

HAO Qin-xia．Design of wireless temperature controller based on household heating control system[J]．Journal of Xi’an University of Science and Technology，2013，33(6)：737-740．

[9]来望银．视频监控系统在火灾报警中的应用[J]．西安科技大学学报，2013，33(4)：400-403．

LAI Wang-yin．Application of video surveillance system in fire alarm[J]．Journal of Xi’an University of Science and Technology，2013，33(4)：400-403．

[10]马卜林．煤矿井下WiFi人员定位GIS系统设计与实现[J]．西安科技大学学报，2012，32(3)：301-304．

MA Bo-lin．The design and implementation of WiFi localization GIS for mine[J]．Journal of Xi’an University of Science and Technology，2012，32(3)：301-304．

[11]汪正进，武风波，李国民，等.Linux平台下的无线视频寻迹小车[J].西安科技大学学报，2015，35(1)：105-109.

WANG Zheng-jin，WU Feng-bo，LI Guo-min，et al.Wireless video tracing car under Linux system[J].Journal of Xi’an University of Science and Technology，2015，35(1)：105-109．

[12]杨著，郝丹，范太华.高性能硬件平台与嵌入式Linux的建构[J].西安科技大学学报，2006，26(2)：251-267.

YANG Zhu，HAO Dan，FAN Tai-hua.Set up a high performance hardware platform and an embedded Linux operation system[J].Journal of Xi’an University of Science and Technology，2006，26(2)：251-267．

[13]孙弋，袁晓霞．矿井有限空间WIFI信号测评系统研究[J]．西安科技大学学报，2013，33(5)：544-549．

SUN Yi，YUAN Xiao-xia．Research of mine limited space WIFI signal evaluation system[J]．Journal of Xi’an University of Science and Technology，2013，33(5)：544-549.

[14]UCARP实现自动故障恢复[EB/OL].http://blog.chinaunix.net/uid-20196318-id-28752.html.

UCARP Auto Recovery[EB/OL].http://blog.chinaunix.net/uid-20196318-id-28752.html.

High reliable storage system based on HDFS

LI Ming-ming1，LI Wei2

(1.CollegeofCommunicationandInformationEngineering,Xi’anUniversityofScienceandTechnology,Xi’an710054,China;

Hardware failure caused important file loss has affected our work.HDFS(Hadoop Distributed File System)can improve the storage reliability through multi-copy mechanism.But the single point failure problem of NameNode makes the HDFS not 100% safe because when NameNode fail，the whole cluster become not available.The paper makes use of the BackupNode of Hadoop to be the backup of NameNode by the help of Ucarp virtual IP software.When NameNode fails，BackupNode will compete to be the new NameNode which provides meta data service for the whole cluster，guarantees HDFS will not loss data at any time，improving the reliability of HDFS.

Hadoop；HDFS；NameNode；BackupNode；UCarp

10.13800/j.cnki.xakjdxxb.2016.0321

1672-9315(2016)03-0428-06

2015-10-20责任编辑：高佳

西安科技大学2014年度教育教学改革与研究项目(JG14014)

李明明(1977-)，女，陕西蓝田人，副教授，E-mail:limmwork@aliyun.com

TP 312

A