The implementation of high availability for yarn Explorer

Resource Manager High Availability

. The ResourceManager (RM) is responsible for tracking the resources in a cluster, and scheduling applications (e.g., mapred UCE jobs). Prior to Hadoop 2.4, the ResourceManager are the single point of failure in a YARN cluster. The High Availability feature adds redundancy in the form of a active/standby ResourceManager pair to remove this Otherwi Se single point of failure.

The RM is responsible for tracking the resources in the cluster and then dispatching specific applications like Mr. Prior to the Hadoop2.4 version, an RM could be a single point in a yarn cluster that could cause a cluster failure. By increasing redundancy in the form of primary and standby RM, the high availability feature avoids a single point of problem resulting in cluster unavailability.

ResourceManager HA is realized through a active/standby architecture-at any point of time, one of the RMs are Active, an D one or more RMs is in Standby mode waiting to take over should anything happen to the Active. The trigger to transition-to-active comes from either the admin (through CLI) or through the integrated Failover-controlle R when Automatic-failover is enabled.

The RM Ha feature is implemented through a master-slave backup architecture: At any time, one of the multiple RM services is served as the primary RM, and one or more of the RM is on standby, and when there is an incident with the primary RM, the standby RM is able to take over. If you want to trigger a switch to the primary RM transaction, it can be input from the command line by an administrator, or it can be triggered by an integrated failover controller after the automatic failover function switch is turned on.

Manual transitions and failover manually triggering failover

When automatic failover was not enabled, admins has to manually transition one of the RMs to Active. To failover from one RM to the other, they is expected to first transition the ACTIVE-RM to Standby and transition a Stan Dby-rm to Active. All this can is done using the "yarn rmadmin" CLI.

When the auto-failover feature is not open, the administrator must manually set up one of the multiple RM to master service status. In order to switch from one RM to another, you need to switch the primary RM settings from active to standby state first, and then switch a standby to active failover. These actions can be performed via the Yarn rmadmin command line.

Automatic Failover automatic failover

The RMs has an option to embed the zookeeper-based activestandbyelector to decide which RM should is the Active. When the active goes down or becomes unresponsive, another RM was automatically elected to being the active which then takes O Ver. Note, there is no need to run a separate ZKFC daemon as are the case for HDFS because Activestandbyelector Embedd Ed in RMs acts as a failure detector and a leader elector instead of a separate ZKFC deamon.

RM has an option to embed an zookeeper-based primary and standby selector, which can determine which RM should be active. When the primary RM is hung or unable to respond, the other RM is automatically elected as the primary RM and then taken over. Note that there is no need to start a separate ZKFC daemon, because for HDFs, the master-slave selector embedded in RM can work as a fault detection module and as a leader voter instead of an independent ZKFC daemon.

Client, Applicationmaster and NodeManager on RM failover clients, application Master node, Node Manager failover on resource Manager

When there was multiple RMs, the configuration (yarn-site.xml) used by clients and nodes was expected to list all the RM S. Clients, Applicationmasters (AMs) and Nodemanagers (NMs) Try connecting to the RMs in a round-robin fashion until they Hit the Active RM. If the active goes down, they resume the round-robin polling until they hits the "new" active. This default retry logic is implemented as  Org.apache.hadoop.yarn.client.ConfiguredRMFailoverProxyProvider . You can override the logic by implementing  Org.apache.hadoop.yarn.client.RMFailoverProxyProvider   and setting the value of  yarn.client.failover-proxy-provider  to the class name.

When there are multiple resource managers, the configuration (yarn-site.xml) used by the node and the client needs to enumerate all the resource managers. The client, the application master, and the node manager try to poll the explorer to access the Master Resource Manager. If the primary resource manager is hung up, they continue to execute the circular query until the new master node is found. The default retry logic is implemented in Org.apache.hadoop.yarn.client.ConfiguredRMFailoverProxyProvider. You can override the retry logic by implementing the Org.apache.hadoop.yarn.client.RMFailoverProxyProvider class . Then replace the class name with the value of the Yarn.client.failover-proxy-provider.

Recovering prevous active-rm ' s state fixes the status of the previous Master resource Manager

With the Resourcemanger Restart-enabled, the RM being promoted to a active state loads the RM internal state and continue s to operate from where the previous active left as much as possible depending on the RM restart feature. A new attempt is spawned for each managed application previously submitted to the RM. Applications can checkpoint periodic Ally to avoid losing any work. The State-store must is visible from the both of Active/standby RMs. Currently, there is, Rmstatestore implementations For Persistence-filesystemrmstatestore and Zkrmstatestore. TheZkrmstatestoreImplicitly allows write access to a single RM at any point in time, and hence are the recommended store to use on an HA CLU Ster. When using the Zkrmstatestore, there are no need for a separate fencing mechanism to address a potential split-brain situat Ion where multiple RMs can potentially assume the Active role. When using the Zkrmstatestore, it's advisable to not set the "zookeeper. Digestauthenticationprovider.superdigestZookeeper cluster to ensure, the Zookeeper Admin does not having access to YARN Application/user Crede Ntial information.

When the Resource Manager restart feature is turned on, the resource manager, which is set to active state, loads its internal state and resumes operations as much as possible from where it was stopped from the previous active resource manager. The resource manager attempts to resubmit each managed application that was previously committed to the resource manager. The application avoids missing tasks by regularly setting checkpoints. The state store must be visible to both active and standby resource managers. Currently, there are two resource manager state stores that implement persistent storage: Filesystemrmstatestore and Zkrmstatestore. Zkrmstatestore allows for immediate updating of status to a single resource manager, so it is also recommended as a storage option in highly available clusters. When using Zkrmstatestore, there is no need to set up a separate defense mechanism to deal with the potential for multiple resource managers to set themselves as active in the state of the brain fissure. When using the Zkrmstatestore, It is recommended that you do not set zookeeper.DigestAuthenticationProvider.superDigest this configuration in the zookeeper cluster to ensure that zookeeper administrators do not obtain confidential information about yarn users and applications.

See the original: https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/ResourceManagerHA.html

ResourceManager restart:https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/resourcemanagerrestart.html

The implementation of high availability for yarn Explorer