I. Overview
Today I wrote about building a high availability (HA) environment.
Hadoop-HA mode is roughly divided into two (personal understanding in learning):
namenode high availability
yarn high availability
1. Namenode HA
Namenode is a very important component in HDFS, which is equivalent to the heart of the HDFS file system. In the display distributed cluster environment, there may still be Namenode crashes or various accidents. Therefore, the high-availability model has its effect.
The approximate process of namenode HA configuration (personal understanding):
Before starting the namenode, you need to start the newly introduced (QJM) Quorum Journal Manager in hadoop 2.x. QJM is mainly used to manage the data synchronization between the namenodes. When the active namenode data is updated, it will be passed to QJM. QJM is in all namenodes. Synchronize between, and finally QJM synchronizes the updated data of the active namenode to the standby namenode.
When multiple namenodes are started, the host address of the namenode is configured, and the isolation mechanism is also configured, because SB (split-brain) conditions are prone to occur. The so-called sb status means that when multiple namenodes are in normal state, one is active and multiple standby. If the communication between namenodes is blocked for a certain period of time due to non-namenodes such as the network, it is easy to have multiple active devices and it is easy to grab resources.
Introduce zookeeper to monitor the namenode, because in general, if the active namenode crashes, you need to manually switch the standby Namenode to active. Very inhumane. Multiple namenodes can be monitored through zookeeper. When the active namenode crashes, zookeeper immediately informs the leader of zookeeper to perform active/standby elections, elect one of the standby namenodes, and set it to active mode to replace the crashed namenode.
2. Yarn HA
I think the role of Yarn HA is similar to Namenode HA, both of which are used to prevent accidents in the heart component from causing the entire cluster to collapse.
Yarn HA configuration process (personal understanding):
After configuring support for zookeeper in yarn-site.xml, when ResourceManager is started, Active ResourceManager will write its own status information to the zookeeper cluster.
After starting other ResourceManager, they will be in standby state.
When the active ResourceManager stops unexpectedly, zookeeper will elect a ResourceManager in the standby state, then write the state information of the original ResourceManager to the standby ResourceManager, and finally set the standby ResourceManager to the active state, completing the active-standby switch.
Hadoop 2.0 background
HDFS and MapReduce in Hadoop 1.0 have problems in terms of high availability and scalability-problems with HDFS
NameNode single point of failure, difficult to apply to HA in online scenarios
NameNode is under too much pressure and memory is limited, which affects scalability F
-MapReduce's problem response system
JobTracker access pressure is high, affecting system scalability
It is difficult to support computing frameworks other than MapReduce, such as Spark, Storm, etc.
HDFS 2.x
-Solve the single point of failure and memory limitation issues in HDFS 1.0. -Solve single point of failure
HDFS HA: Solved by Active and Standby NameNode
If the primary NameNode fails, switch to the standby NameNode
-Solve the problem of limited memory
HDFS Federation
Horizontal expansion, support multiple NameNode;
(2) Each NameNode is in charge of a part of the directory;
(1) All NameNodes share all DataNode storage resources
-2.x is only a change in the architecture, the way of use remains unchanged
-Transparent to HDFS users
-Commands and APIs in HDFS 1.x can still be used
HDFS 2.0 HA
-Active and standby NameNode-Solve single points of failure (attributes, location)
The active NameNode provides external services, and the standby NameNode synchronizes the metadata of the active NameNode for switching
All DataNodes simultaneously report data block information (location) to two NameNodes
JNN: cluster (attribute)
standby: standby, complete the merge of the edits.log file to generate a new image, push back to ANN
-Two switching options
Manual switching: switch between active and standby through commands, you can use HDFS upgrades and other occasions
Automatic switching: based on Zookeeper
-Automatic switching scheme based on Zookeeper
ZooKeeper Failover Controller: monitors the health status of the NameNode,
And register NameNode with Zookeeper
After the NameNode hangs up, ZKFC competes for the lock for the NameNode, and the NameNode that obtained the ZKFC lock becomes active
HDFS 2.x Federation
--Distribute metadata storage and management to multiple nodes through multiple namenode/namespace, so that the namenode/namespace can be horizontally expanded by adding machines. --The load of a single namenode can be distributed to multiple nodes, and the performance of HDFS will not be reduced when the HDFS data scale is large. Multiple namespaces can be used to isolate different types of applications, and the storage and management of HDFS metadata for different types of applications can be assigned to different namenodes.
