“Don't log in to the NameNode!”
On his third day, Kabir needs to run a quick script on the cluster. He finds the host name of the biggest, most powerful server, the NameNode, logs in to it, and starts a Python job that reads a large file into memory. Five minutes later the whole team's chat lights up: “HDFS is slow!”, “NameNode GC pauses!”, “Who is on nn1?” His lead calls him over, calm but firm.
Kabir, which machine did you use?
The one with the most RAM… nn1. I thought it would be fastest.
It is the most important machine in the cluster. The NameNode keeps all of HDFS's metadata in its memory. Your script took memory and CPU from it, so it paused, and every user's reads and writes waited.
So where should he have run it?
On an edge node, the machine built for people. Every cluster has roles: masters that coordinate and must be protected, workers that store and compute and are managed by YARN, utility nodes for supporting services, and edge nodes where users and tools connect. Today you'll learn each role, what runs on it, and how companies lay them out for small and large clusters.
And I'll never touch nn1 again.
Node roles in a Hadoop cluster
Nodes in a Hadoop cluster are assigned roles according to the services they run. Master nodes host the coordinating daemons (NameNode and its standby, ResourceManager, JobHistory Server, and in HA setups JournalNodes and ZKFCs) and are provisioned for reliability. Worker nodes (historically “slave” nodes) host DataNodes and NodeManagers and provide the cluster's storage and compute capacity. Edge nodes (also called gateway or client nodes) host client libraries, configuration and tools, and are the controlled entry point for users and applications; they run no core daemons. Utility (management) nodes host supporting services such as ZooKeeper, the Hive Metastore and its database, HiveServer2, Oozie, security and cluster-management servers.
Masters are the managers: few, important, protected. Workers are the staff: many, doing the storage and processing. Edge nodes are the reception desk where people come in to submit work. Utility nodes run the helper services everyone else depends on. Users only ever log in at reception.
Words you'll meet in this lesson
*-site.xml files copied to an edge node so tools know where the masters are.Typical hardware by role (2026, approximate)
| Master | 64–512 GB RAM (NameNode heap grows with files), mirrored (RAID 1) disks for OS and metadata, dual power supplies, 25 Gbps network |
|---|---|
| Worker | 32–64 cores, 128–512 GB RAM, 8–24 plain data disks (JBOD), 10–25 Gbps network |
| Edge | Moderate CPU/RAM, space for user home directories and tools, connected to both the cluster network and the corporate network |
| Utility | Moderate; reliable disks for ZooKeeper and the metastore database |
| Counts | Masters: 2–5 · Utility: 1–3 · Edge: 1 per few dozen users · Workers: everything else |
Roles at three levels
Beginner A hospital again
- Masters = the records office and the bed manager. If they stop, everyone stops, so nobody else is allowed to use their desks.
- Workers = the wards, where the actual work happens. There are many, and one can close for repairs.
- Edge node = reception. Visitors come here, not into the records office or the operating theatre.
- Utility = the pharmacy and the IT room: support services the whole hospital relies on.
Intermediate What runs where in a typical medium cluster
- master1: active NameNode, ZKFC, JournalNode, ZooKeeper.
- master2: standby NameNode, ZKFC, JournalNode, ZooKeeper, ResourceManager.
- master3 / utility: JournalNode, ZooKeeper, standby ResourceManager, JobHistory Server, Hive Metastore + database, HiveServer2.
- edge1–2: HDFS/YARN/Hive/Spark clients, Hue or Jupyter, scheduler workers; user logins.
- worker1–N: DataNode + NodeManager (and, for HBase, a RegionServer).
- The three JournalNodes and three ZooKeeper servers sit on three different machines so the cluster survives losing any one of them.
Advanced Why roles are kept separate
- Blast radius: a user's runaway process on a master can pause the NameNode (long Java garbage-collection pauses) and stall the whole cluster.
- Resource accounting: work on workers must go through YARN so it is counted, queued and limited. A script started by hand on a worker steals memory YARN thinks is free, and containers get killed.
- Security: only edge nodes are reachable from the corporate network; masters and workers sit on a private cluster network. Users get Kerberos tickets on the edge node.
- Upgrades and failures: workers are replaced like identical parts; masters are changed carefully, one at a time, with failover.
- Cloud versions: managed services keep the same roles: Amazon EMR has a primary node, core nodes (HDFS + YARN) and task nodes (YARN only); Google Dataproc has master and worker nodes plus optional secondary workers.
Exam tip: For “Explain the types of nodes in a Hadoop cluster”, list master, worker (slave), edge/gateway and utility, the daemons on each, and one reason each is separated (masters protected, workers managed by YARN, edge as the controlled entry point). A small layout diagram earns full marks.
The roles, side by side
| Master | Worker | Edge / gateway | Utility | |
|---|---|---|---|---|
| Runs | NameNode(s), ResourceManager(s), JobHistory, JournalNodes, ZKFC | DataNode, NodeManager | Client tools and configs, notebooks, schedulers | ZooKeeper, Hive Metastore + DB, HiveServer2, Oozie, Ranger, manager |
| How many | 2–5 | Most of the cluster | 1–several | 1–3 |
| Users log in? | No (admins only) | No | Yes | No (admins only) |
| If one fails | Failover to standby; serious | Re-replicate, re-run tasks; routine | Users move to another edge node | Depends on the service; usually HA |
| Hardware focus | RAM, reliability | Disks, cores | Network, user space | Reliability |
Example layouts by cluster size
Learning / test (1 machine)
Pseudo-distributed: every daemon on one machine. Fine for practice, never for production. You'll build this in Module 4.
1 nodeSmall (5–20 nodes)
1 master (NameNode, RM, JobHistory), 1 edge node, workers. Optional second master for HA.
Start-up, departmentMedium (20–200 nodes)
3 masters (HA NameNodes and RMs, 3 JournalNodes, 3 ZooKeepers), 1–2 utility, 2+ edge nodes, workers.
Most enterprisesLarge (200+ nodes)
Dedicated machines per master service, 5 ZooKeepers, federated NameNodes, many edge nodes behind a load balancer.
Banks, telecoms, webWhen someone gives you access to a cluster, first ask: “Which host is the edge node?” Run every command, notebook and script there. If you ever need to look at a master or worker, it should be an admin task with a clear reason.
Designing the roles for a 30-node cluster
Decide what must be highly available
TiffinGo's dashboards depend on HDFS all day, so they want NameNode and ResourceManager HA.
HA means two NameNodes, two ResourceManagers, three JournalNodes and three ZooKeeper servers, spread over three machines so any one can fail.Place the masters
Put m1, m2 and m3 on different racks and power feeds. The active NameNode gets the lightest load of other services.masters = { "m1": ["NameNode (active)", "ZKFC", "JournalNode", "ZooKeeper"], "m2": ["NameNode (standby)", "ZKFC", "JournalNode", "ZooKeeper", "ResourceManager"], "m3": ["JournalNode", "ZooKeeper", "ResourceManager (standby)", "JobHistoryServer"], } print(sum(1 for roles in masters.values() if "JournalNode" in roles), "JournalNodes")3 JournalNodesAdd utility services
Hive Metastore with its database and HiveServer2 go on a utility node (or on m3 in a small cluster).
The metastore database holds every table definition: back it up and give it a standby, or every Hive and Spark SQL query stops.Add edge nodes
Two edge nodes with the client configuration, Hive Beeline, spark-submit, Jupyter and the Airflow workers.
Two, so users can keep working while one is patched. Only these two are reachable from the office network.Everything else is a worker
The workers provide all storage and compute, so capacity planning (Lesson 1.3) is done on these 24, not on all 30.total, masters, utility, edge = 30, 3, 1, 2 print(total - masters - utility - edge, "workers (DataNode + NodeManager)")24 workers (DataNode + NodeManager)
One Hive query: what Riya does on the edge node, and which role does what
Riya runs a SQL query from the edge node. Left: her screen. Right: the request travelling through each kind of node.
- Riya logs in to edge1 and connects Beeline (the Hive client) to HiveServer2.
- She types a GROUP BY query on the
orderstable. - The query is running. She sees only a progress message.
- Progress shows map and reduce tasks. They run somewhere on the cluster, not on her machine.
- The result table appears.
- From start to finish, Riya used only the edge node. Every other role worked on her behalf.
- The edge node runs only the client (Beeline). It sends the query to HiveServer2 on the utility node over JDBC (port 10000 by default).
- HiveServer2 asks the Hive Metastore (also on the utility node, backed by a database) where the
orderstable lives in HDFS and what its columns are. - It then talks to the masters: the NameNode for the files' block locations, the ResourceManager to start an ApplicationMaster for the query.
- Map and reduce tasks run in containers on the workers, mostly on the nodes holding the table's blocks.
- Results flow back through HiveServer2 to Riya's Beeline session on the edge node.
- Every role did one job. None of the work ran on the edge node or on a master.
Try it yourself: roles in the playground
The playground's Client box is the edge node, the dark boxes are masters, and every DataNode box is a worker. Use it to see why each role matters.
Roles in real platforms
1. Cluster managers assign roles
In Cloudera Manager or Apache Ambari, an admin builds a cluster by assigning roles to hosts (“NameNode on m1”, “DataNode on all workers”, “Gateway on edge1”). The tool installs, configures and monitors each role.
2. Cloud clusters keep the same roles
Amazon EMR has a primary node (masters), core nodes (HDFS + YARN) and task nodes (YARN only, safe to remove). Google Dataproc has master and worker nodes, with optional secondary (preemptible) workers that add compute only.
3. Data science on edge nodes
Analysts open Jupyter or Hue on an edge node and submit Spark or Hive work to YARN. Their notebooks never run heavy processing on the edge itself; the cluster does it.
4. Incident reviews
A common root cause in incident reports: “a user ran a script on a master” or “a manual process on workers exhausted memory, so YARN killed containers”. The fix is usually access control: logins only on edge nodes.
5. Quorum services on separate machines
ZooKeeper and JournalNodes are always placed on three (or five) different machines and racks, so the majority survives a failure. Putting all three on one host is a classic design-review mistake.
Simplified. Exact role layouts differ by distribution and company.
Plan the roles for a cluster
This program assigns roles to the machines of a cluster: three masters for HA, one utility node, two edge nodes, and workers for the rest. Then it prints the plan. Try the challenges to check a layout for mistakes.
def plan(total, ha=True):
masters = 3 if ha else 1
utility, edge = 1, 2 if total >= 20 else 1
workers = total - masters - utility - edge
roles = {}
for i in range(1, masters + 1):
roles[f"master{i}"] = "master"
roles["util1"] = "utility"
for i in range(1, edge + 1):
roles[f"edge{i}"] = "edge"
for i in range(1, workers + 1):
roles[f"worker{i}"] = "worker"
return roles
roles = plan(30)
summary = {}
for host, role in roles.items():
summary[role] = summary.get(role, 0) + 1
print(summary)masters = 3 if ha else 1High availability needs three machines for the JournalNode and ZooKeeper majorities; without HA, one master.utility, edge = 1, 2 if total >= 20 else 1Tuple assignment:utility = 1, andedgeis 2 for bigger clusters, 1 for small ones.workers = total - masters - utility - edgeEvery remaining machine is a worker: storage and compute.
Counting roles, one line at a time
Watch the loop turn a host-to-role map into a summary: a dictionary that counts how many hosts have each role.
Worked examples: real problems, solved and traced in memory
Three tasks from real cluster design reviews: lay out a cluster, find rule violations in someone else's layout, and cost the hardware by role. Each runs live and is traced in memory.
Lay out a 12-node cluster without HA
Problem statement
A college lab gets 12 servers for a Hadoop cluster. No HA is needed. Assign 1 master, 1 edge node and the rest as workers, and print the daemons each host will run.
12 hosts · no HA
lab01 ['NameNode', 'SecondaryNameNode', 'ResourceManager', 'JobHistoryServer'] lab02 ['(clients only)'] lab03 ['DataNode', 'NodeManager'] lab12 ['DataNode', 'NodeManager'] Workers: 10
Approach
- Host 1 is the master: NameNode, SecondaryNameNode, ResourceManager, JobHistoryServer.
- Host 2 is the edge node: no daemons, only clients.
- Hosts 3–12 are workers: DataNode and NodeManager.
Solution: run it live
What happens in memory, step by step
Recorded from a real Python run: press Next to execute one line at a time. Watch variables change in each frame, and lists and dictionaries (numbered #1, #2 …) fill up as objects.
Find the mistakes in a proposed layout
Problem statement
A teammate proposes this layout. Check three rules: (1) no DataNode or NodeManager on a master; (2) ZooKeeper on an odd number of distinct hosts; (3) the two NameNodes on different racks. Print every violation.
m1 (rack1): NameNode, ZooKeeper, DataNode · m2 (rack1): NameNode, ZooKeeper · m3 (rack2): ZooKeeper, ZooKeeper
Rule 1: m1 runs worker daemons
Rule 2: ZooKeeper on 4 servers but 3 hosts
Rule 3: both NameNodes on {'rack1'}Approach
- Loop over hosts; flag worker daemons on a master.
- Collect hosts running ZooKeeper; compare distinct count with total and check it is odd.
- Compare the racks of the two NameNode hosts.
Solution: run it live
What happens in memory, step by step
Recorded from a real Python run: press Next to execute one line at a time. Watch variables change in each frame, and lists and dictionaries (numbered #1, #2 …) fill up as objects.
What does each role cost?
Problem statement
For a 40-node cluster with 3 masters, 1 utility, 2 edge and 34 workers, compute the hardware cost per role and the share spent on workers. Prices (illustrative): master Rs 9 lakh, utility Rs 5 lakh, edge Rs 4 lakh, worker Rs 12 lakh.
3 × 9 L · 1 × 5 L · 2 × 4 L · 34 × 12 L
master : 3 x Rs 9 lakh = Rs 27 lakh utility : 1 x Rs 5 lakh = Rs 5 lakh edge : 2 x Rs 4 lakh = Rs 8 lakh worker : 34 x Rs 12 lakh = Rs 408 lakh Total Rs 448 lakh; workers are 91%
Approach
- Multiply count × price for each role.
- Sum for the total.
- Worker share = worker cost ÷ total.
Solution: run it live
What happens in memory, step by step
Recorded from a real Python run: press Next to execute one line at a time. Watch variables change in each frame, and lists and dictionaries (numbered #1, #2 …) fill up as objects.
Check yourself
Quick revision
Lesson 3.3 in one screen
- Master: NameNode(s), ResourceManager(s), JobHistory, JournalNodes, ZKFC. Few, reliable, protected.
- Worker: DataNode + NodeManager. Many, identical, replaceable. All work goes through YARN.
- Edge / gateway: client tools + configs, user logins, notebooks, schedulers. No core daemons.
- Utility: ZooKeeper, Hive Metastore + DB, HiveServer2, Oozie, Ranger, cluster manager.
- Quorum services (ZooKeeper, JournalNodes) on 3 or 5 different hosts; NameNodes on different racks.
- Layouts: 1 node (learning) · small: 1 master + edge + workers · medium: 3 masters, utility, 2 edges · large: dedicated masters, federation.
- Cloud: EMR primary / core / task; Dataproc master / primary workers / secondary workers.
- Rule of thumb: users only on edge nodes.
Interview and viva questions
What is an edge node in Hadoop?
A machine that has the Hadoop client libraries, configuration files and tools (hdfs, yarn, hive/beeline, spark-submit, notebooks) but runs no core cluster daemons. It is the controlled entry point for users and applications: they log in there, interact with HDFS and submit jobs, while the work runs on the workers. It is often the only cluster host reachable from the corporate network.
What runs on master nodes?
The coordinating services: the active and standby NameNodes (with ZKFCs), JournalNodes for the shared edit log, the ResourceManager(s), the JobHistory Server, and often ZooKeeper. In non-HA clusters, the Secondary NameNode. Masters are sized for memory and reliability and protected from user workloads.
Why not run DataNodes on master nodes?
Storage and compute work on a master competes with the master daemons for memory, CPU and disk I/O, risking pauses or crashes that affect the whole cluster. It also makes masters harder to maintain, because taking one down would also remove data and compute capacity.
How many ZooKeeper servers should a cluster have?
An odd number, usually 3 for most clusters and 5 for large or critical ones, each on a different host and ideally on different racks. ZooKeeper needs a majority to operate, so 3 servers tolerate one failure and 5 tolerate two; 4 servers still tolerate only one.
How do node roles map to cloud services like EMR?
EMR's primary node runs the master services; core nodes run HDFS DataNodes and YARN NodeManagers; task nodes run only NodeManagers, so they can be scaled in and out freely. Dataproc similarly has master nodes, primary workers (HDFS + YARN) and optional secondary workers (compute only, often preemptible).
Practice problems
Small programs and calculations for planning and checking node roles.
How many workers?
A 50-node cluster has 3 masters, 2 utility nodes and 3 edge nodes. How many workers?
50 − 3 − 2 − 3
42 workers
Show solution and explanation
print(50 - 3 - 2 - 3, "workers")How it works: 42 workers. Capacity planning uses this number, not 50.
Quorum survivors
For 3 and 5 ZooKeeper servers, print the majority size and how many failures each survives.
[3, 5]
3 servers: majority 2 | survives 1 failure(s) 5 servers: majority 3 | survives 2 failure(s)
Show solution and explanation
for n in [3, 5]:
majority = n // 2 + 1
print(n, "servers: majority", majority, "| survives", n - majority, "failure(s)")How it works: 3 → majority 2, survives 1. 5 → majority 3, survives 2.
Role of a host
Given a dictionary of host roles, print the role of edge2 and of worker7.
{"edge2": "edge", "worker7": "worker", "m1": "master"}edge2: edge | worker7: worker
Show solution and explanation
roles = {"edge2": "edge", "worker7": "worker", "m1": "master"}
print("edge2:", roles["edge2"], "| worker7:", roles["worker7"])How it works: A host-to-role inventory is the first thing to keep in any cluster runbook.
Group hosts by role
Turn a host → role map into role → sorted list of hosts.
{"w2": "worker", "m1": "master", "e1": "edge", "w1": "worker", "m2": "master"}edge ['e1'] master ['m1', 'm2'] worker ['w1', 'w2']
Show solution and explanation
roles = {"w2": "worker", "m1": "master", "e1": "edge", "w1": "worker", "m2": "master"}
by_role = {}
for h, r in roles.items():
by_role.setdefault(r, []).append(h)
for r in sorted(by_role):
print(r, sorted(by_role[r]))How it works: The same reverse mapping cluster managers show as “hosts by role”.
Racks of the masters
Check that the three masters are on three different racks; print the racks used and whether the rule holds.
{"m1": "r1", "m2": "r2", "m3": "r2"}Racks used: ['r1', 'r2'] | all different: False
Show solution and explanation
rack = {"m1": "r1", "m2": "r2", "m3": "r2"}
used = set(rack.values())
print("Racks used:", sorted(used), "| all different:", len(used) == len(rack))How it works: m2 and m3 share r2: losing that rack would take two of three JournalNodes and ZooKeepers, breaking the majority.
Edge nodes for the users
Each edge node comfortably serves about 25 active users. With 140 users and one spare for maintenance, how many edge nodes are needed?
140 users · 25 per node · +1 spare
7 edge nodes
Show solution and explanation
import math
print(math.ceil(140 / 25) + 1, "edge nodes")How it works: 6 for the load plus 1 spare: 7. Big companies put edge nodes behind a load balancer.
Task nodes for a sale weekend
An EMR cluster has 20 core nodes. For a sale weekend, analytics needs 3× the usual compute for 60 hours. Task nodes cost Rs 30 per hour (spot). How many task nodes and what extra cost?
20 core · 3× compute · 60 h · Rs 30/h
Add 40 task nodes; extra cost Rs 72000
Show solution and explanation
core = 20
extra_nodes = core * 3 - core
cost = extra_nodes * 60 * 30
print("Add", extra_nodes, "task nodes; extra cost Rs", cost)How it works: 40 task nodes for Rs 72,000 (illustrative price). Task nodes add compute without HDFS, so removing them after the weekend is safe.
Cost of the outage from a user on a master
A user's script on the NameNode host caused a 40-minute HDFS slowdown. 120 analysts were blocked, each costing Rs 900 per hour, and 3 nightly SLAs were missed at Rs 50,000 each. Estimate the cost.
40 min · 120 analysts · Rs 900/h · 3 × Rs 50,000
Lost time: Rs 72,000 | SLA penalties: Rs 150,000 | Total: Rs 222,000
Show solution and explanation
people = 120 * 900 * 40 / 60
sla = 3 * 50_000
print(f"Lost time: Rs {people:,.0f} | SLA penalties: Rs {sla:,} | Total: Rs {people + sla:,.0f}")How it works: About Rs 2.2 lakh for one mistake (illustrative). A second edge node and restricted logins cost far less.
Real-world scenario questions (asked in company interviews)
Role questions are about judgement: where things should run, and what to do when someone breaks the rules.
Lay out roles for a 20-node cluster
You have 20 identical servers and the business wants HDFS to keep running even if one master fails. How do you assign roles?
The interviewer is checking: do you know which services need HA and how to place quorums?
Show a strong answer
- 3 masters on different racks: active NameNode + ZKFC on m1, standby NameNode + ZKFC on m2, and JournalNode + ZooKeeper on all three; ResourceManager (and a standby) on m2/m3; JobHistory on m3.
- 1 utility node for Hive Metastore + database and HiveServer2 (or on m3 if budget is tight).
- 1–2 edge nodes for users and tools.
- 14–15 workers with DataNode + NodeManager.
Avoid: putting DataNodes on the masters “to use the disks”.
Containers keep getting killed on one worker
Tasks on worker w12 are often killed with “running beyond physical memory limits” or the node runs out of memory. Other workers are fine.
The interviewer is checking: do you consider work happening outside YARN?
Show a strong answer
- Log in (as an admin) and check what else is running:
topoften shows a user's script, a stray Python process or a forgotten service on that worker. - YARN offers memory based on configuration; anything running outside YARN takes memory YARN believes is free, so the OS or YARN kills containers.
- Stop the stray process, move the user to the edge node, and restrict logins on workers.
- If nothing extra is running, check the node's memory settings against its real RAM.
Avoid: simply raising container memory for all jobs.
Analysts want SSH access to every node
The analytics team asks for SSH to all cluster machines “to debug jobs faster”.
The interviewer is checking: can you meet the real need while protecting the cluster?
Show a strong answer
- Give access to edge nodes only. Masters and workers stay on the private cluster network, reachable by admins.
- Provide what they actually need for debugging: the ResourceManager and JobHistory UIs,
yarn logs -applicationIdfor container logs (with log aggregation on), and the Spark History Server. - Use Kerberos and Ranger so their permissions are the same whatever tool they use.
Avoid: a flat “no” without offering the tools that solve their problem.
Scale down an EMR cluster safely
An EMR cluster has 10 core nodes and 30 task nodes. Overnight, the load drops. Your manager asks you to remove 25 nodes to save money.
The interviewer is checking: do you know which cloud roles hold data?
Show a strong answer
- Remove task nodes first: they run only YARN, so removing them loses no HDFS data (running tasks are retried elsewhere).
- Removing core nodes means decommissioning their DataNodes so HDFS can copy their blocks away first, which is slow and risky if done in bulk.
- Better still, keep data in S3 and size HDFS (core nodes) small, so the cluster can shrink freely, or use managed autoscaling.
Avoid: terminating core nodes directly; with replication 3 on a small cluster you can lose blocks.