Help Center/ MapReduce Service/ Component Operation Guide (LTS)/ Using Yarn/ Common Issues About Yarn/ Why May A Single NodeManager Fault Cause MapReduce Task Failures in the Superior Scheduling Mode?
Updated on 2022-11-18 GMT+08:00

Why May A Single NodeManager Fault Cause MapReduce Task Failures in the Superior Scheduling Mode?

Question

In Superior scheduling mode, if a single NodeManager is faulty, why may the MapReduce tasks fail?

Answer

In normal cases, when the attempt of a single task of an application fails on a node for three consecutive times, the AppMaster of the application adds the node to the blacklist. Then, the AppMaster instructs the scheduler not to schedule the task to the node to avoid task failure.

However, by default, if 33% nodes in the cluster are added to the blacklist, the scheduler ignores the blacklisted nodes. Therefore, the blacklist feature is prone to become invalid in small cluster scenarios. For example, there are only three nodes in the cluster. If one node is faulty, the blacklist mechanism becomes invalid. The scheduler continues to schedule the task to the node no matter how many times the attempt of the task fails on the node. As a result, the number of attempts of the task reaches the maximum (4 times by default for MapReduce). And the MapReduce tasks failed.

Workaround:

The yarn.resourcemanager.am-scheduling.node-blacklisting-disable-threshold parameter indicates the threshold for ignoring blacklisted nodes, in percentage. You are advised to increase the value of this parameter based on the cluster scale. For example, you are advised to set this parameter to 50% for a three-node cluster.

Currently, the Capacity scheduler does not have this problem. The reason is that the Capacity scheduler allocates resources based on the heartbeat messages reported by NodeManager. When the NodeManager of a node is disconnected, the heartbeat of the node is lost, and the Capacity scheduler does not allocate tasks to the node.

The framework design of the Superior scheduler is time-based asynchronous scheduling. When the NodeManager is faulty, ResourceManager cannot quickly detect that the NodeManager is faulty (10 minutes by default). Therefore, the Superior scheduler still schedules tasks to the node, causing task failures.