skip to content

In a Hadoop 3 cluster, which daemons run on the master nodes and which run on every worker node?

level: juniorimportance: must knowfreq 52%

answer

  1. small brain tier, wide muscle tier
  2. two systems, same machines
  3. one stores, one schedules
  4. the pair that sits on every worker
  5. NameNode and ResourceManager coordinate, they do not store

basics

~20 s

Master nodes run the coordinators: the HDFS NameNode (plus JournalNodes and ZKFC when HA is on) and the YARN ResourceManager. Every worker runs a DataNode for storage and a NodeManager for compute, co-located so containers read local blocks.

solid answer

~40 s

Hadoop splits coordination from capacity. The **master** tier runs the HDFS `NameNode`, which holds the namespace and block map in memory, and the YARN `ResourceManager`, which hands out containers. In an HA cluster the master tier also runs a second NameNode, three `JournalNode`s, one `DFSZKFailoverController` (ZKFC) next to each NameNode, and an external ZooKeeper ensemble. Every **worker** node runs a `DataNode` — it stores blocks on the disks listed in `dfs.datanode.data.dir` and heartbeats and block-reports to the NameNode — and a `NodeManager`, which advertises the node's resources and launches containers. DataNode and NodeManager are deliberately co-located so a task can usually read its input off local disk. Auxiliary services (MapReduce JobHistoryServer, HttpFS, Timeline Server) live on master or edge nodes. `jps` on a host tells you which tier it is.

code

text · 9 lines
text
# master node
14231 NameNode
14550 DFSZKFailoverController
14802 JournalNode
15104 ResourceManager

# worker node
9012 DataNode
9310 NodeManager

go deeper

for a junior

Be able to name the four core daemons and where each runs: NameNode and ResourceManager on masters, DataNode and NodeManager on every worker. Knowing that jps shows them is worth a sentence.

for a middle

Explain what each daemon actually holds — the NameNode's in-memory namespace and block map, the NodeManager's advertised memory and vcores — and why DataNode and NodeManager are co-located for locality.

for a senior

Show you have operated this: which hosts carry JournalNodes and ZKFC, why edge nodes exist, what a missing DataNode on a NodeManager host does to job performance, and how you verify daemon health from the UIs.

for a principal

Own the placement policy — master-node count and isolation, whether to keep storage and compute co-located at all versus a disaggregated object-store design, and what that choice costs in network capacity and locality.

## The shape of a Hadoop cluster A Hadoop cluster is two tiers of long-running Java daemons. The **master** tier is small (typically three to five machines) and holds all the coordination state; the **worker** tier is everything else and holds the data and does the work. Both HDFS and YARN follow the same master/worker split, and the two systems are deployed onto the same machines so that computation can be scheduled next to its data. ## Master-side daemons **NameNode (HDFS).** Keeps the entire filesystem namespace — the directory tree, file names, permissions, and the list of blocks each file is made of — in memory, and persists changes to an on-disk `fsimage` plus an edit log under `dfs.namenode.name.dir`. It also holds the *block map*: which DataNode currently has which block replica. That map is never persisted; it is rebuilt from DataNode block reports at startup. **ResourceManager (YARN).** The cluster-wide scheduler. It tracks the resources every NodeManager advertises, accepts application submissions, and allocates containers to applications. It does not run user code itself. **JournalNode (HDFS HA only).** A small daemon holding a copy of the shared edit log. You run an odd number, usually three, spread across separate machines. **ZKFC / DFSZKFailoverController (HDFS HA only).** One process per NameNode host. It health-checks its local NameNode and participates in a ZooKeeper election to decide which NameNode is active. **ZooKeeper.** Not a Hadoop daemon, but an external ensemble (3 or 5 nodes) that both HDFS automatic failover and ResourceManager HA depend on. **Secondary NameNode.** Present only in a *non*-HA cluster, where it periodically merges the edit log into a new `fsimage`. In an HA cluster it does not exist — the standby NameNode does that work. ## Worker-side daemons **DataNode.** Stores blocks as ordinary files on each of the local disks listed in `dfs.datanode.data.dir` (JBOD, one directory per disk — you do not RAID DataNode disks). It sends a heartbeat every few seconds (`dfs.heartbeat.interval`, 3 seconds by default) and a full block report periodically, and it serves and receives block data on its own data-transfer port. **NodeManager.** Advertises the node's usable memory and vcores (`yarn.nodemanager.resource.memory-mb`, `yarn.nodemanager.resource.cpu-vcores`), launches and monitors containers on request from the ResourceManager, kills containers that exceed their limits, and runs auxiliary services such as `mapreduce_shuffle`. Every worker runs exactly one of each. One of the containers a NodeManager launches will be an **ApplicationMaster** — a per-application process, not a cluster daemon, that asks the ResourceManager for the rest of its containers. ## Auxiliary and edge services The MapReduce **JobHistoryServer**, the YARN **Timeline Server**, **HttpFS**, and the HDFS **Router** (for federation) are optional daemons usually placed on master or edge hosts. *Edge* or *gateway* nodes run no cluster daemon at all: they just carry `$HADOOP_CONF_DIR` and the client jars so users can submit jobs. ## How the daemons find each other Nothing is auto-discovered. Workers find the masters through the site XML files pushed to every node — `fs.defaultFS` in `core-site.xml` points DataNodes and clients at HDFS, `yarn.resourcemanager.hostname` (or the HA `rm-ids` set) in `yarn-site.xml` points NodeManagers at the ResourceManager. The `etc/hadoop/workers` file (called `slaves` before Hadoop 3) is only used by the `start-dfs.sh`/`start-yarn.sh` helper scripts to SSH out and start daemons; a config-managed cluster often does not use it at all. ## Checking a node `jps` lists the JVMs on a host, and their class names are the daemon names above. The web UIs are the other quick check — and their default ports moved in Hadoop 3: the NameNode UI is on 9870 (it was 50070 in Hadoop 2), the DataNode UI on 9864, the Secondary NameNode on 9868; the ResourceManager UI stayed on 8088 and the NodeManager on 8042. A worker that shows a NodeManager but no DataNode is the classic cause of "all my tasks read over the network": YARN will happily schedule there, but there is no local data to read.

  • Why are the DataNode and NodeManager deliberately placed on the same machine?
    For data locality. The ResourceManager is told where each block lives, so it can place a container on a node that already holds the input block, and the task reads from local disk instead of pulling the block across the rack uplink. Separating storage and compute nodes is a legitimate design today, but it trades locality for elasticity and leans much harder on the network.
  • Is the ApplicationMaster a cluster daemon like the NodeManager?
    No. The ApplicationMaster is created per application, inside a YARN container on some worker node, and it dies when the application finishes. It negotiates the application's remaining containers with the ResourceManager and monitors its own tasks. The NodeManager, by contrast, is a permanent daemon on every worker regardless of what is running.
  • What does an edge or gateway node run?
    No cluster daemons — only the Hadoop client jars and a copy of `$HADOOP_CONF_DIR`. Users log in there to run `hdfs dfs`, submit jobs, or run Hive/Spark clients. Keeping submission off the master nodes stops user JVMs from competing with the NameNode and ResourceManager for memory.

saying these in an interview costs you the question

  • Says the NameNode stores the actual file data
  • Thinks the Secondary NameNode is a hot standby that takes over
  • Claims DataNodes discover the NameNode automatically on the network
  • Says the ApplicationMaster is a permanent daemon on each worker
  • Puts a NameNode on every node so metadata is replicated

context

resolving links…