Introducing Hadoop | 59
3.4.4 NameNode Failure Management
Now that you have an understanding of how replication handles failures in DataNodes, let us
take a look at failure management for the NameNode. As you now realize, the NameNode is the
most important node in the cluster. Without the NameNode, we will have no idea which le is
stored on which DataNode. In the mappings that the NameNode holds within itself, the block
locations are not persistent. These block locations are stored in memory for quick lookup, where
it is called block caching.
If the NameNode fails, then the file block locations in memory will be completely lost.
Therefore, there will be no way to reconstruct where and how a particular file is distributed,
which DataNode has the original copy, and which DataNodes hold the replicas. In fact, each time
a Hadoop cluster is restarted, all the DataNodes send their block locations for the files contained
in them to the NameNode, so that the NameNode can store this in memory. As such, backing up
the NameNode information becomes extremely critical for the availability and reliability of the
cluster.
NameNode failures are handled in two different ways as listed below.
a. Use of metadata files
b. Using a secondary NameNode
Let us examine these strategies briey.
a. Use of metadata files: There are two metadata files that allow the reconstruction of the
information in the NameNode. The first is the FsImage (file system image file), and the
second one is the edits file. These two files store file system metadata and provide a mech-
anism for reconstructing NameNode mappings in case of failure. The FsImagefile holds a
snapshot of the file system when the Hadoop cluster is first started up, when no operations
have been performed upon a fresh restart. The FsImagefile is then loaded into the memory
to be used. The edits file contains log information of all edits on files made across HDFS
from the time that the Hadoop cluster was restarted. Thus, at any given point in time,
FsImage and edits together contain the current state of the file system. Both these files
FIGURE 3.16 Fault tolerant of NameNode with edit logs and FsImage
DataNode
Active
NameNode
NameNode high
availability (HA)
Standby
NameNode
FsImageEdit logs
Journal node
Reads at NameNode
startup and merge
with edit logs
M03 Big Data Simplified XXXX 01.indd 59 5/10/2019 9:57:33 AM
60 | Big Data Simplied
have a default backup location on the local file system of the NameNode. You can also
configure this backup to be on a remote disk. In fact, you can also specify multiple backup
locations. Each backup can be on a different host, thereby ensuring that the NameNode
data is never lost. However, using metadata files as a backup strategy, is not always an opti-
mum solution. Merging these two files, the FsImage and edits, is a very resource-intensive
operation. Hadoop clusters tend to be long running. They are not meant to be restarted
often. It can have thousands of jobs, where all of them manipulating the file system. Thus,
the log information in edits will be very large, and the combination of FsImage and edits is
not trivial.
b. Using the secondary NameNode: It is a much easier way to bring back the system online.
The secondary NameNode is an exact backup of the NameNode.
The original NameNode has its FsImage and edits file, the secondary NameNode copies over
the FsImage and edits from the original NameNode, and it runs on a completely different
machine.
The secondary NameNode and the original NameNode sync up their information to make
sure that they are up to date with each other, where it is called checkpointing. After the
secondary NameNode gets its copy of the metadata files, it merges these two files together
to get an updated FsImage. It applies every transaction, every file edit in the edits log to the
FsImage to get an updated FsImage.
This updated FsImage is then copied back to the NameNode, so the NameNode will replace
its FsImage from the checkpointed FsImage on the secondary NameNode. The edits files on
both these machines are reset to empty, and it does not contain any logs, as the FsImage is now
up to date with all edits. At this point, both the NameNode and the secondary NameNode are
in sync and up to date.
Checkpointing of this kind is done at a specific frequency, which is configurable. In case of
NameNode failure, the secondary NameNode is simply promoted to be the NameNode and
a new machine on the cluster is made the secondary NameNode.
FIGURE 3.17 Fault tolerant of NameNode with secondary NameNode
Secondary
NameNode
Active
NameNode
Standby
NameNode
FsImageFsImage
Query for edit logs
Copy the updated fsimage back
to NameNode for future use
High availability
of NameNode
Updated fsimage with
edit logs to sync with
HDFS metadata in
NameNode
M03 Big Data Simplified XXXX 01.indd 60 5/10/2019 9:57:33 AM
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.