Riya walks into a data centre
Arjun Sir takes Riya and Kabir to see a data centre in Navi Mumbai, where one of his old students now works. Behind two security doors is a cold, noisy hall. It is full of tall black cabinets in long rows, with blinking lights and thousands of cables. “This is where your UPI payment, your train ticket and your cloud photos actually live,” he says.
Sir, it's so cold! And so loud. Why are there no screens or keyboards anywhere?
These computers are servers. Nobody sits in front of them. Engineers connect to them over the network from their laptops, maybe from Pune or Bengaluru. The noise is the fans, and the cold air keeps them from overheating.
At my internship they keep saying “the job failed on node 47” and “rack 3 is down”. Is a node just a server?
Yes, Kabir. When a server is part of a cluster, we call it a node. These tall cabinets are racks. Each rack holds 20 to 40 servers stacked like shelves, with its own power strips and a switch at the top that connects them.
And all the racks are connected to each other?
Through bigger switches, yes. That's the whole data centre network. Remember this picture: hall, rack, server. Hadoop knows about every one of these levels, because where the data sits on these shelves decides how fast and how safely your job runs.
Server, node, rack and data centre
A server is a computer designed to run continuously and provide services to other computers over a network. In a cluster, each server is called a node. A rack is a standard cabinet (commonly 42U) that holds many servers along with shared power distribution and a top-of-rack (ToR) switch that connects them. A data centre is a facility that houses many racks together with redundant power, cooling, physical security and a hierarchical network that connects the racks to each other and to the outside world.
A server is a computer with no screen that works all day for others. Put many of them on shelves in one cabinet: that's a rack. Put many racks in one big, cold, guarded building with backup power: that's a data centre. When those servers work together as a team, each one is a node of a cluster.
Words you'll meet in this lesson
Typical numbers to remember (2026, approximate)
| Standard rack height | 42U (about 2 metres); 45U and 48U racks also exist |
|---|---|
| Servers in one rack | about 20–40, depending on server size (1U or 2U), power and cooling |
| Power for one rack | about 5–15 kW in a typical enterprise data centre (GPU racks need much more) |
| A typical Hadoop worker node | 2 CPUs with 32–64 cores in total, 128–512 GB RAM, 8–24 hard disks of 8–20 TB each, a 10–25 Gbps network port |
| Server to ToR switch | 10 or 25 Gbps per server |
| ToR switch to core | a few 40 or 100 Gbps uplinks shared by the whole rack |
| Round-trip time (ping) | about 0.1 ms within a rack; about 0.2–0.5 ms across a data centre; tens of ms between cities |
These are ballpark figures to reason with. Real numbers vary by company, vendor and year.
The same idea at three levels
Beginner Think of a library
- A book is a piece of data.
- A shelf is one server: it holds some books and has a librarian (the CPU) who can read them.
- A cupboard of shelves is a rack. All shelves in one cupboard share one light switch (power) and one door (the ToR switch).
- The whole library building is the data centre, with corridors (the network) between cupboards.
- Fetching a book from your own shelf is fastest; from the next shelf in the same cupboard is quick; from a cupboard across the hall takes longer. Hadoop thinks exactly like this.
Intermediate What is inside a Hadoop node
- CPU cores run tasks. A 32-core node can run many tasks at the same time.
- RAM holds the data a task is working on right now.
- Many plain disks (JBOD: “just a bunch of disks”) store HDFS data. Hadoop worker nodes usually don't use RAID: HDFS already keeps copies on other nodes, and separate disks can be read in parallel.
- The network port joins the node to its rack switch. Data moving between nodes travels through it.
- Master nodes (that run the NameNode or ResourceManager) are built differently: more RAM, mirrored (RAID) disks for important metadata, and dual power supplies, because losing them hurts the whole cluster.
Advanced Why the network shape matters
- Oversubscription: a ToR switch may have 48 server ports of 25 Gbps (1,200 Gbps in total) but only 4 uplinks of 100 Gbps (400 Gbps). That is 3 : 1 oversubscription. If every server sends data out of the rack at once, each gets about a third of its speed.
- So traffic inside a rack is cheaper than traffic between racks. Hadoop's scheduler and HDFS both try to keep work close to the data.
- Rack = failure domain: a rack's switch or power strip can fail, taking every server in it offline together. HDFS therefore places copies of each block on at least two racks.
- Rack awareness: Hadoop does not discover racks by itself. Administrators give it a small script (set with
net.topology.script.file.name) that maps each host to a rack name like/rack1. Without it, every node is in/default-rack. - Modern data centres often use a leaf-spine design (ToR switches are the “leaves”, core switches the “spine”), which keeps the number of hops between any two racks the same.
Exam tip: Define server, node, rack and data centre in one line each, and draw the hierarchy: data centre → racks → servers, with a ToR switch on each rack and core switches joining the racks. Add one line on why the rack matters to Hadoop (it is a failure domain and a bandwidth boundary).
Kinds of servers, roles of nodes, and kinds of data centres
Server shapes
Rack server
A flat box that slides into a rack, 1U or 2U high. The usual choice for Hadoop: 2U servers have room for 12 or more disks.
Most commonBlade server
Thin boards that share one chassis for power and network. Very dense, but few disks per blade, so less suited to storage-heavy Hadoop.
Dense computeTower server
Looks like a big desktop PC. Found in small offices, not in big data centres.
Small officesVirtual machine (VM)
A slice of a physical server that behaves like its own computer. Cloud “instances” are VMs. A cluster node can be a VM.
CloudRoles a node can play in a Hadoop cluster
| Role | What it runs | Typical hardware | How many |
|---|---|---|---|
| Master node | NameNode (knows where all data is), ResourceManager (hands out work) | Lots of RAM, RAID disks, dual power | 2–5, kept very safe |
| Worker node | DataNode (stores data) and NodeManager (runs tasks) | Many cores, many plain disks | Tens to thousands |
| Edge (gateway) node | Client tools: where users log in and submit jobs | Moderate | A few |
You will meet each role in detail in Lesson 1.2 and Module 3. For now: masters coordinate, workers store and compute, edge nodes are the front door.
Where the data centre is
| On-premises | Colocation | Public cloud | |
|---|---|---|---|
| Who owns the building | The company | A data centre provider | The cloud provider |
| Who owns the servers | The company | The company (rents space, power, cooling) | The cloud provider (you rent VMs by the hour) |
| Hadoop example | A bank's own cluster | A telecom's servers in a provider's hall | AWS EMR, Google Dataproc, Azure HDInsight |
| Good for | Strict data control, steady load | Own hardware without building a facility | Fast start, changing load |
In the cloud you still have racks, you just can't see them. Cloud providers offer availability zones (separate buildings in one region) and placement options so that your VMs are spread across failure domains, for the same reason HDFS spreads copies across racks.
Follow one piece of data from one node to another
A task on node dn1 (rack 1) needs a 128 MB block that sits on dn7 (rack 3). Here is the path, hop by hop.
Ask: which rack is each node on?
This is exactly the information Hadoop gets from its rack-topology script: a map from host to rack. Different racks means the data must leave the rack.rack_of = {"dn1": "/rack1", "dn2": "/rack1", "dn7": "/rack3"} print(rack_of["dn1"], "->", rack_of["dn7"])/rack1 -> /rack3Leave the server: the network card
A single hard disk reads around 200 MB/s, far slower than the 25 Gbps (about 3 GB/s) network card. One disk is usually the limit for one block.dn7reads the block from one of its disks and sends it out through its 25 Gbps network card.Up to the rack's ToR switch
The cable from
If the destination were in the same rack (saydn7goes to the switch at the top of rack 3.dn8), the switch would send it straight down todn8. One hop, full speed. That's why same-rack traffic is cheap.Across the core (spine) switch
The ToR switch of rack 3 sends the data up one of its uplinks to the core switch, which forwards it to rack 1's ToR switch.
The uplinks are shared by all 20–40 servers in the rack. When many servers send data out at once, they queue here. This is the busiest, most expensive link in a Hadoop cluster.Down to dn1
Rack 1's switch delivers the data to
Total: 4 hops instead of 0. Moving 128 MB across racks is fine once. Moving terabytes across racks for every job would choke the uplinks. Lesson 1.5 shows how Hadoop avoids this by sending the task to the data instead.dn1, and the task starts reading it.
Two pings and a copy: what Riya types, and where the packets go
Riya logs in to node dn1 and talks to another node in the same rack, then to one in a different rack. Left: her terminal. Right: the path through the data centre.
- Riya logs in from the edge node to dn1, a worker node with 32 cores and 256 GB of RAM.
- She pings dn2, another server in the same rack. The reply comes back in about 0.09 ms.
- She pings dn7 in a different rack. The reply takes about 0.31 ms: still tiny, but a few times longer.
- She copies 10 GB from each. On a quiet network both are fast (the numbers here are illustrative).
- Now 40 servers in rack 3 send data out of the rack at the same time. Her copy from dn7 slows to a crawl.
- Copies inside the rack stay fast. Moving data between racks is the expensive part of a cluster.
- dn1 sits in rack 1. Every server is wired to its rack's ToR switch, and every ToR switch to the core switch.
- dn1 → ToR → dn2: the packet never leaves the rack. Two short hops.
- dn1 → ToR → core → ToR → dn7: four hops, and the packet uses the rack uplinks.
- With little traffic, the uplinks have room, so a cross-rack copy is nearly as fast as a local one.
- The uplinks of rack 3 are shared by all its servers (oversubscription). When they all send at once, packets queue and every cross-rack copy slows down.
- Traffic inside the rack uses only the ToR switch, which has full speed for every port. Hadoop places data and tasks to exploit this.
Ping times and copy speeds in this animation are illustrative. Real values depend on the hardware and on how busy the network is.
Try it yourself: the Cluster Playground
This is a small simulated Hadoop cluster with 2 racks of 3 nodes. You'll use it in almost every lesson of this course. Today, just explore the pieces.
Where these racks are, and who uses them
1. A bank's own data centre, and its disaster-recovery site
Many banks keep customer data in their own (on-premises) data centres for control and regulation, often with a second disaster recovery (DR) site in another city. Their Hadoop clusters for reports and fraud analytics live in these racks.
2. Cloud regions in India
The big cloud providers run regions in India (for example AWS in Mumbai and Hyderabad, Google Cloud in Mumbai and Delhi, Microsoft Azure in Pune, Chennai and Mumbai). A startup can rent 20 nodes there in minutes and run a managed Hadoop or Spark cluster on them.
3. Colocation: your servers, someone else's building
A telecom or e-commerce company may buy its own servers but place them in a provider's data centre, renting space, power, cooling and security by the rack. Navi Mumbai and Chennai are among the big data centre hubs in India.
4. Operations teams: “node 47 has a bad disk”
Data centre and platform teams replace failed disks, power supplies and whole servers every week. They locate a machine by hall, row, rack and slot, exactly the hierarchy in this lesson, and Hadoop keeps running while they do.
5. Hadoop's rack awareness in practice
When a company builds a cluster, an administrator writes the rack-topology script so that HDFS spreads copies of each block over two racks, and the job scheduler prefers nodes near the data. You will configure this yourself in Module 4.
6. Capacity planning for next year's data
Before buying hardware, a team works out how many racks, nodes and disks they need, how much power and cooling that takes, and whether the network uplinks are big enough. Lesson 1.3 does this calculation step by step.
Examples are simplified. Specific companies' setups vary and are often not public.
Describe a cluster in Python
A cluster is just data about machines: which nodes exist, which rack each is on, and what each one has. Here is a small cluster as a Python dictionary, and its total capacity. Then try the challenges.
cluster = {
"/rack1": [{"name": "dn1", "cores": 32, "ram": 256, "disk_tb": 144},
{"name": "dn2", "cores": 32, "ram": 256, "disk_tb": 144}],
"/rack2": [{"name": "dn3", "cores": 32, "ram": 256, "disk_tb": 144},
{"name": "dn4", "cores": 64, "ram": 512, "disk_tb": 192}],
}
nodes = [n for rack in cluster.values() for n in rack]
print("Racks :", len(cluster))
print("Nodes :", len(nodes))
print("Cores :", sum(n["cores"] for n in nodes))
print("RAM :", sum(n["ram"] for n in nodes), "GB")
print("Disk :", sum(n["disk_tb"] for n in nodes), "TB raw")cluster = {A dictionary: the key is the rack name, the value is the list of nodes in that rack. Hadoop stores its view of the cluster in a similar tree.nodes = [n for rack in cluster.values() for n in rack]A list comprehension with twofors: for every rack, take every node. It flattens the racks into one list of nodes.sum(n["cores"] for n in nodes)Add up one field across all nodes. The same pattern gives RAM and disk.
Run it on your PC: look at your computer as a node
An administrator's first question about any node is: how many cores, how much RAM, how much disk? This program answers it for your computer (Windows, macOS or Linux) and compares it with a typical Hadoop worker node. Save it as node_report.py and run it.
How does your machine compare with a worker node?
# node_report.py: look at your own computer the way a cluster admin looks at a node
import os, platform, shutil
def ram_gb():
try: # Linux and macOS
return os.sysconf("SC_PAGE_SIZE") * os.sysconf("SC_PHYS_PAGES") / 1024**3
except (ValueError, AttributeError, OSError): # Windows
import ctypes
class M(ctypes.Structure):
_fields_ = [("len", ctypes.c_ulong), ("load", ctypes.c_ulong), ("total", ctypes.c_ulonglong),
("avail", ctypes.c_ulonglong), ("a", ctypes.c_ulonglong), ("b", ctypes.c_ulonglong),
("c", ctypes.c_ulonglong), ("d", ctypes.c_ulonglong), ("e", ctypes.c_ulonglong)]
m = M(); m.len = ctypes.sizeof(M)
ctypes.windll.kernel32.GlobalMemoryStatusEx(ctypes.byref(m))
return m.total / 1024**3
cores = os.cpu_count()
ram = ram_gb()
disk = shutil.disk_usage(os.path.abspath(os.sep)).total / 1024**4 # in TB
print("Host name :", platform.node())
print("OS :", platform.system())
print("CPU cores :", cores)
print(f"RAM : {ram:.1f} GB")
print(f"Disk : {disk:.2f} TB")
# a typical Hadoop worker node (approximate, 2026)
worker = {"cores": 32, "ram": 256, "disk": 12 * 12}
print("\nOne typical worker node equals about:")
print(f" {worker['cores'] / cores:.0f} of your machines in CPU cores")
print(f" {worker['ram'] / ram:.0f} of your machines in RAM")
print(f" {worker['disk'] / disk:.0f} of your machines in disk")
# In a terminal: python node_report.pyRecorded on a small cloud machine (2 cores, 8 GB RAM, 256 GB disk). On a laptop you will see your own numbers. The disk gap is the biggest: Hadoop worker nodes are built to hold a lot of data, with many disks each.
Counting a cluster, one line at a time
Watch the loop visit each rack, then each node inside it, adding up the cores. Notice the dictionary and the lists appear as numbered objects.
Worked examples: real problems, solved and traced in memory
Three calculations that cluster and data-centre teams do in real life: an inventory, usable storage, and how many servers a rack can really take. Each program runs live and is traced in memory.
How big is each rack?
Problem statement
The operations team has a list of servers with their rack and number of cores. Print how many nodes and cores each rack has.
dn1 r1 32, dn2 r1 32, dn3 r2 32, dn4 r2 64, dn5 r2 32
r1 : 2 nodes, 64 cores r2 : 3 nodes, 128 cores
Approach
- Start with an empty dictionary for the result.
- For each server, create the rack entry if it is new, then add one node and its cores.
- Print one line per rack.
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.
How much data can the cluster really hold?
Problem statement
A cluster has 20 worker nodes with 12 disks of 12 TB each. HDFS keeps 3 copies of every block, and the team keeps 25% of space free for temporary files and growth. How much data can the business actually store?
20 nodes · 12 disks × 12 TB · replication 3 · 25% headroom
Raw disk : 2880 TB After headroom: 2160.0 TB Business data : 720.0 TB
Approach
- Raw capacity = nodes × disks × disk size.
- Keep 25% free: multiply by 0.75.
- Divide by 3 because every block is stored three times.
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.
Space, power or switch ports: what limits a rack?
Problem statement
A 42U rack keeps 2U for the ToR switch and cable management. Servers are 2U, draw 450 W each, and need one switch port each. The rack has a 9 kW power budget and the switch has 48 ports. How many servers can go in, and which limit is reached first?
42U − 2U · 2U servers · 9,000 W, 450 W each · 48 ports
space : 20 servers power : 20 servers ports : 48 servers Limit reached first: space -> 20 servers
Approach
- Work out the limit from each resource separately.
- Store them in a dictionary.
- The smallest limit is the real one;
minwithkey=finds its name.
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 1.1 in one screen
- Server: computer that runs 24×7 for others. In a cluster it is a node.
- Rack: cabinet (often 42U) of 20–40 servers with shared power and a ToR switch.
- Data centre: building with many racks, backup power, cooling, security and core switches.
- Typical worker node: 32–64 cores, 128–512 GB RAM, 8–24 plain disks, 10–25 Gbps network.
- Masters (NameNode, ResourceManager) get safer hardware; workers (DataNode, NodeManager) get many disks and cores.
- Same rack: through one switch, full speed. Across racks: through shared, oversubscribed uplinks.
- A rack is a failure domain: HDFS keeps copies on at least two racks.
- Hadoop learns racks from a topology script (
net.topology.script.file.name); otherwise/default-rack.
Interview and viva questions
What is the difference between a server and a node?
A server is any computer that serves others over a network. A node is a server (or VM) when it is a member of a cluster. All Hadoop nodes are servers; not every server is a Hadoop node.
What is a rack, and why is it important in Hadoop?
A rack is a cabinet holding many servers with shared power and a top-of-rack switch. It matters because all servers in a rack can fail together (switch or power failure) and because bandwidth between racks is limited. HDFS places block replicas on more than one rack, and the scheduler prefers nodes on the same rack as the data.
What hardware would you choose for a Hadoop worker node?
Many CPU cores, enough RAM for the tasks that will run (128–512 GB is common), many large plain hard disks in JBOD (not RAID), and a 10–25 Gbps network card. Masters need more RAM, RAID-protected disks for metadata and redundant power instead.
What is oversubscription?
When the total bandwidth of a switch's server ports is larger than its uplink bandwidth. For example 48 × 25 Gbps down and 4 × 100 Gbps up is 3:1. If all servers send traffic out of the rack at once, each gets only a fraction of its port speed.
How does Hadoop know which rack a node is on?
An administrator configures a topology script or class (net.topology.script.file.name) that maps host names or IP addresses to rack paths like /dc1/rack1. Without it, all nodes are placed in /default-rack.
Practice problems
Quick calculations about servers, racks and networks. The last ones are the kind of planning a platform team does before buying hardware.
Rack height in centimetres
1U is 4.445 cm. How tall, in centimetres, is the usable space of a 42U rack?
42U, 1U = 4.445 cm
186.7 cm
Show solution and explanation
print(round(42 * 4.445, 1), "cm")How it works: 42 × 4.445 = 186.7 cm. With the frame, top and wheels, a 42U rack is about 2 metres tall.
Raw capacity of one node
A node has 12 disks of 16 TB. What is its raw capacity in TB?
12 disks × 16 TB
192 TB
Show solution and explanation
print(12 * 16, "TB")How it works: Raw capacity is just disks × size. Usable capacity is lower (replication and free space), as in worked example 2.
Bits and bytes
A network link is 10 Gbps (gigabits per second). How many GB (gigabytes) per second is that?
10 Gbps
1.25 GB per second
Show solution and explanation
print(10 / 8, "GB per second")How it works: 8 bits make 1 byte, so divide by 8: 10 Gbps = 1.25 GB/s. Network speeds are quoted in bits, disk speeds in bytes.
Oversubscription ratio
A ToR switch has 40 servers on 25 Gbps ports and 4 uplinks of 100 Gbps. Print the ratio as “N : 1”.
40 × 25 Gbps, 4 × 100 Gbps
2.5 : 1
Show solution and explanation
down = 40 * 25
up = 4 * 100
print(f"{down / up:g} : 1")How it works: 1,000 ÷ 400 = 2.5. When every server sends out of the rack at once, each gets 25 ÷ 2.5 = 10 Gbps.
Group hosts by rack
Given a host-to-rack map, print the hosts of each rack in sorted order.
{"dn3": "/r2", "dn1": "/r1", "dn4": "/r2", "dn2": "/r1", "dn5": "/r3"}/r1 ['dn1', 'dn2'] /r2 ['dn3', 'dn4'] /r3 ['dn5']
Show solution and explanation
rack_of = {"dn3": "/r2", "dn1": "/r1", "dn4": "/r2", "dn2": "/r1", "dn5": "/r3"}
by_rack = {}
for host, rack in rack_of.items():
by_rack.setdefault(rack, []).append(host)
for rack in sorted(by_rack):
print(rack, sorted(by_rack[rack]))How it works: setdefault creates an empty list the first time a rack appears. This reverse map (rack → hosts) is how you check that a cluster is balanced across racks.
Same rack or not?
Write a function hops(a, b) that returns 0 if a and b are the same host, 2 if they are on the same rack, and 4 otherwise. Test it on (dn1, dn1), (dn1, dn2) and (dn1, dn3).
rack_of = {dn1: r1, dn2: r1, dn3: r2}dn1 dn1 -> 0 hops dn1 dn2 -> 2 hops dn1 dn3 -> 4 hops
Show solution and explanation
rack_of = {"dn1": "r1", "dn2": "r1", "dn3": "r2"}
def hops(a, b):
if a == b:
return 0
if rack_of[a] == rack_of[b]:
return 2
return 4
for a, b in [("dn1", "dn1"), ("dn1", "dn2"), ("dn1", "dn3")]:
print(a, b, "->", hops(a, b), "hops")How it works: Hadoop uses a very similar “network distance”: 0 for the same node, 2 for the same rack, 4 for another rack in the same data centre.
How many racks to buy?
The business needs to store 900 TB of data. Each node has 144 TB raw, HDFS keeps 3 copies, and 25% is kept free. A rack takes 18 nodes. How many nodes and racks are needed?
900 TB data · 144 TB/node · ×3 · 25% free · 18 nodes/rack
Raw disk needed: 3600.0 TB Nodes: 25 Racks: 2
Show solution and explanation
import math
data_tb = 900
raw_needed = data_tb * 3 / 0.75
nodes = math.ceil(raw_needed / 144)
racks = math.ceil(nodes / 18)
print("Raw disk needed:", raw_needed, "TB")
print("Nodes:", nodes, "Racks:", racks)How it works: Work backwards from business data: × 3 copies, ÷ 0.75 for headroom, ÷ node size, then round up. Lesson 1.3 adds growth and CPU to this.
Power bill for one rack
A rack has 18 servers drawing 450 W each, running all year. Cooling adds 50% on top. Electricity costs Rs 9 per kWh. What is the yearly cost?
18 × 450 W · +50% cooling · 24×365 h · Rs 9/kWh
Power: 12.15 kW Cost per year: Rs 9.6 lakh
Show solution and explanation
kw = 18 * 450 / 1000
kw_with_cooling = kw * 1.5
kwh_year = kw_with_cooling * 24 * 365
print(f"Power: {kw_with_cooling:.2f} kW")
print(f"Cost per year: Rs {kwh_year * 9 / 1e5:.1f} lakh")How it works: About Rs 9.6 lakh a year for one rack, before rent, staff and hardware. Running a cluster has real costs, so teams size it carefully (figures are illustrative).
Real-world scenario questions (asked in company interviews)
Situations about hardware and racks that interviewers describe to see whether you understand the physical side of a cluster.
A whole rack lost power, and some data was unavailable
During maintenance, the power strip of rack 4 failed and all 20 nodes in it went offline at once. Some HDFS files became unreadable even though only one rack was down. What was probably wrong in the setup?
The interviewer is checking: do you know that a rack is a failure domain and that HDFS needs to be told about racks?
Show a strong answer
With correct rack awareness, HDFS stores each block's copies on at least two racks, so losing one rack never loses all copies. If files became unreadable, the cluster most likely had no topology script: every node was in /default-rack, so all three copies of some blocks happened to be in rack 4.
- Configure
net.topology.script.file.nameto map hosts to racks, and restart the NameNode. - Check with
hdfs dfsadmin -printTopology, then runhdfs fsckto find blocks whose replicas are all on one rack. - Let HDFS re-replicate those blocks so they span racks.
Avoid saying: “Increase replication to 5.” More copies on the same rack still fail together.
RAID 5 on every worker node?
A hardware vendor proposes RAID 5 controllers on all 60 worker nodes “for safety”. Your manager asks if that is a good idea for a Hadoop cluster.
The interviewer is checking: do you know why Hadoop workers use JBOD and where RAID still belongs?
Show a strong answer
- HDFS already protects data by replicating blocks across nodes and racks, so RAID on workers mostly duplicates protection and costs disk space and money.
- Independent disks (JBOD) let the DataNode read and write many disks in parallel; RAID 5 adds write overhead and long rebuilds.
- If one JBOD disk fails, the DataNode can keep running on its other disks (with a configured tolerance) and HDFS re-copies the lost blocks.
- But master nodes holding NameNode metadata should use RAID (for example mirrored disks) plus redundant power.
Avoid: saying RAID is useless everywhere. It is still the right choice for masters and many databases.
Jobs are slow every night, but CPUs are idle
Nightly jobs on a 200-node cluster have become slow. Monitoring shows CPU at 30% and disks lightly used, but the ToR uplinks are at 100% during the jobs. What is happening and what would you do?
The interviewer is checking: can you read network symptoms and connect them to oversubscription and data locality?
Show a strong answer
The jobs are network bound on the rack uplinks: lots of data is moving between racks. Possible causes: tasks not running where their data is (poor locality), a big shuffle between stages, or a rack topology that is misconfigured.
- Check the job counters for data-local vs rack-local vs off-rack tasks (Module 8).
- Verify the topology script; a wrong map makes the scheduler think nodes are local when they are not.
- Reduce shuffle volume (combiners, filtering early, better formats like Parquet).
- Long term: more or faster uplinks (lower oversubscription).
Avoid: “add more nodes”. More nodes behind the same uplinks can make it worse.
Buy racks or rent cloud machines?
A 30-person fintech startup expects its data to grow from 2 TB to 50 TB in two years and wants to “build a Hadoop cluster”. The founder asks whether to buy servers and rent rack space, or use the cloud.
The interviewer is checking: do you weigh on-premises, colocation and cloud sensibly instead of having one fixed answer?
Show a strong answer
- Start in the cloud: no upfront hardware, a managed Hadoop/Spark service, pay per hour, grow as data grows. The team stays small.
- Store data in cloud object storage and run clusters only when jobs need them, to save cost.
- Check regulatory needs: financial data may need to stay in India, which Indian cloud regions support.
- Revisit on-premises or colocation later if the load becomes large and steady, where owning hardware can be cheaper.
Avoid: recommending a big on-prem cluster for 2 TB, or claiming the cloud is always cheaper at any scale.