Server, node, rack and data centre

Before Hadoop, meet the hardware it runs on. This lesson walks through a data centre: servers stacked in racks, a switch on top of each rack, core switches joining the racks. You will see what is inside a typical Hadoop worker node, why traffic inside a rack is cheaper than traffic between racks, and why Hadoop treats a rack as one unit that can fail.

Module 1 · Foundations: before Hadoop⏱ 22 minBeginner → IntermediateCluster PlaygroundRuns in your browser (Python)Check your own PC8 practice problems
1 The story

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.

Data centre hall row A row B One rack (42U) switch (ToR) server 1server 2server 3 server 4server 5… Each server = a node CPU 32 cores RAM 256 GB Disk 12 × 12 TB Net 25 Gbps Hall → row → rack → server. A Hadoop cluster is built from exactly these pieces. myphatshala.in
Riya

Sir, it's so cold! And so loud. Why are there no screens or keyboards anywhere?

Arjun Sir

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.

Kabir

At my internship they keep saying “the job failed on node 47” and “rack 3 is down”. Is a node just a server?

Arjun Sir

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.

Riya

And all the racks are connected to each other?

Arjun Sir

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.

2 Definition

Server, node, rack and data centre

Formal definition (write this in exams)

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.

In simple words

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

ServerA computer built to run 24×7 and serve other computers. Usually has no screen or keyboard.
NodeOne server (or virtual machine) that is part of a cluster.
RackA tall metal cabinet with shelves for servers, shared power and one network switch.
U (rack unit)The height unit of a rack: 1U = 1.75 inches (4.445 cm). A 2U server takes two slots.
ToR switch“Top of rack” switch: connects every server in one rack, and links the rack to the rest of the network.
Core (spine) switchA large switch that connects all the ToR switches, so racks can talk to each other.
NICNetwork interface card: the server's network port, for example 25 Gbps.
Commodity hardwareOrdinary, affordable servers from normal vendors, not special super-reliable machines.
BandwidthHow much data a link can carry per second (Gbps). 10 Gbps ≈ 1.25 GB/s.
LatencyHow long one small message takes to arrive. Inside a data centre: a fraction of a millisecond.

Typical numbers to remember (2026, approximate)

Standard rack height42U (about 2 metres); 45U and 48U racks also exist
Servers in one rackabout 20–40, depending on server size (1U or 2U), power and cooling
Power for one rackabout 5–15 kW in a typical enterprise data centre (GPU racks need much more)
A typical Hadoop worker node2 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 switch10 or 25 Gbps per server
ToR switch to corea 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

Pick your level. New to this? Start at Beginner and climb.

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).

3 Types and ways to use it

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 common

Blade 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 compute

Tower server

Looks like a big desktop PC. Found in small offices, not in big data centres.

Small offices

Virtual 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.

Cloud

Roles a node can play in a Hadoop cluster

RoleWhat it runsTypical hardwareHow many
Master nodeNameNode (knows where all data is), ResourceManager (hands out work)Lots of RAM, RAID disks, dual power2–5, kept very safe
Worker nodeDataNode (stores data) and NodeManager (runs tasks)Many cores, many plain disksTens to thousands
Edge (gateway) nodeClient tools: where users log in and submit jobsModerateA 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-premisesColocationPublic cloud
Who owns the buildingThe companyA data centre providerThe cloud provider
Who owns the serversThe companyThe company (rents space, power, cooling)The cloud provider (you rent VMs by the hour)
Hadoop exampleA bank's own clusterA telecom's servers in a provider's hallAWS EMR, Google Dataproc, Azure HDInsight
Good forStrict data control, steady loadOwn hardware without building a facilityFast 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.

4 Step by step

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.

  1. Ask: which rack is each node on?

    rack_of = {"dn1": "/rack1", "dn2": "/rack1", "dn7": "/rack3"}
    print(rack_of["dn1"], "->", rack_of["dn7"])
    /rack1 -> /rack3
    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.
  2. Leave the server: the network card

    dn7 reads the block from one of its disks and sends it out through its 25 Gbps 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.
  3. Up to the rack's ToR switch

    The cable from dn7 goes to the switch at the top of rack 3.

    If the destination were in the same rack (say dn8), the switch would send it straight down to dn8. One hop, full speed. That's why same-rack traffic is cheap.
  4. 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.
  5. Down to dn1

    Rack 1's switch delivers the data to dn1, and the task starts reading it.

    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.
5 See it happen

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.

Same rack vs another rack 6 steps
What you see riya@edge-01 : ~ $ ssh dn1 Welcome to dn1 (rack1) $ nproc ; free -g | head -2 32 Mem: 251 total … $ ping -c 1 dn2 64 bytes from dn2: time=0.09 ms Same rack: about a tenth of a millisecond. $ ping -c 1 dn7 64 bytes from dn7: time=0.31 ms Another rack: a few times longer. $ scp dn2:/data/part-01 . part-01 10GB 2.2GB/s 00:04 $ scp dn7:/data/part-07 . part-07 10GB 1.9GB/s 00:05 Quiet network: both copies are fast. (40 nodes on rack 3 now copying out of the rack at the same time) $ scp dn7:/data/part-07 . part-07 10GB 0.4GB/s 00:25 Busy uplinks: the same copy is 5× slower. $ scp dn2:/data/part-01 . part-01 10GB 2.2GB/s 00:04 Inside the rack it is still fast. Lesson: keep traffic inside the rack. myphatshala.in
Behind the screen core switch rack 1 rack 3 ToR switch ToR switch dn1 dn2 dn3 … dn7 dn8 … dn9 … logged in here via ToR only2 hops 4 hops via core uplinks quiet 40 servers share a few uplinks: queue rack-local:not affected myphatshala.in

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.

6 Real-world use

Where these racks are, and who uses them

DCDR

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.

Transactions→Racks in the bank's DC→Copy at the DR site
region

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.

App data→VMs in a cloud region→Pay per hour

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.

Own servers→Rented racks→No building to run

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.

Alert→Find rack + slot→Swap the disk
rack 1rack 2

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.

Host list→host → /rackN script→Rack-aware Hadoop

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.

Data growth→Nodes, racks, power→Purchase order

Examples are simplified. Specific companies' setups vary and are often not public.

7 Run the code

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")
Racks : 2 Nodes : 4 Cores : 160 RAM : 1280 GB Disk : 624 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 two fors: 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.py
Host name : vm OS : Linux CPU cores : 2 RAM : 7.8 GB Disk : 0.25 TB One typical worker node equals about: 16 of your machines in CPU cores 33 of your machines in RAM 585 of your machines in disk

Recorded 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.

8 Line by line

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.

Example 1BeginnerOperations · inventory

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.

Input
dn1 r1 32, dn2 r1 32, dn3 r2 32, dn4 r2 64, dn5 r2 32
Expected output
r1 : 2 nodes, 64 cores
r2 : 3 nodes, 128 cores

Approach

  1. Start with an empty dictionary for the result.
  2. For each server, create the rack entry if it is new, then add one node and its cores.
  3. 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.

Example 2IntermediateStorage planning · capacity

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?

Input
20 nodes · 12 disks × 12 TB · replication 3 · 25% headroom
Expected output
Raw disk      : 2880 TB
After headroom: 2160.0 TB
Business data : 720.0 TB

Approach

  1. Raw capacity = nodes × disks × disk size.
  2. Keep 25% free: multiply by 0.75.
  3. 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.

Example 3AdvancedData centre · rack planning

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?

Input
42U − 2U · 2U servers · 9,000 W, 450 W each · 48 ports
Expected output
space : 20 servers
power : 20 servers
ports : 48 servers
Limit reached first: space -> 20 servers

Approach

  1. Work out the limit from each resource separately.
  2. Store them in a dictionary.
  3. The smallest limit is the real one; min with key= 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.

9 Quiz and revision

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.

P1Easy

Rack height in centimetres

1U is 4.445 cm. How tall, in centimetres, is the usable space of a 42U rack?

Input
42U, 1U = 4.445 cm
Expected output
186.7 cm
Show solution and explanation
print(round(42 * 4.445, 1), "cm")
186.7 cm

How it works: 42 × 4.445 = 186.7 cm. With the frame, top and wheels, a 42U rack is about 2 metres tall.

P2Easy

Raw capacity of one node

A node has 12 disks of 16 TB. What is its raw capacity in TB?

Input
12 disks × 16 TB
Expected output
192 TB
Show solution and explanation
print(12 * 16, "TB")
192 TB

How it works: Raw capacity is just disks × size. Usable capacity is lower (replication and free space), as in worked example 2.

P3Easy

Bits and bytes

A network link is 10 Gbps (gigabits per second). How many GB (gigabytes) per second is that?

Input
10 Gbps
Expected output
1.25 GB per second
Show solution and explanation
print(10 / 8, "GB per second")
1.25 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.

P4Medium

Oversubscription ratio

A ToR switch has 40 servers on 25 Gbps ports and 4 uplinks of 100 Gbps. Print the ratio as “N : 1”.

Input
40 × 25 Gbps, 4 × 100 Gbps
Expected output
2.5 : 1
Show solution and explanation
down = 40 * 25
up = 4 * 100
print(f"{down / up:g} : 1")
2.5 : 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.

P5Medium

Group hosts by rack

Given a host-to-rack map, print the hosts of each rack in sorted order.

Input
{"dn3": "/r2", "dn1": "/r1", "dn4": "/r2", "dn2": "/r1", "dn5": "/r3"}
Expected output
/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]))
/r1 ['dn1', 'dn2'] /r2 ['dn3', 'dn4'] /r3 ['dn5']

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.

P6Medium

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).

Input
rack_of = {dn1: r1, dn2: r1, dn3: r2}
Expected output
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")
dn1 dn1 -> 0 hops dn1 dn2 -> 2 hops dn1 dn3 -> 4 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.

P7Business problem

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?

Input
900 TB data · 144 TB/node · ×3 · 25% free · 18 nodes/rack
Expected output
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)
Raw disk needed: 3600.0 TB Nodes: 25 Racks: 2

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.

P8Business problem

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?

Input
18 × 450 W · +50% cooling · 24×365 h · Rs 9/kWh
Expected output
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")
Power: 12.15 kW Cost per year: Rs 9.6 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.

Platform team · reliabilityFresher

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.name to map hosts to racks, and restart the NameNode.
  • Check with hdfs dfsadmin -printTopology, then run hdfs fsck to 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.

Infrastructure · hardware choice1–3 years

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.

E-commerce · performance1–3 years

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.

  1. Check the job counters for data-local vs rack-local vs off-rack tasks (Module 8).
  2. Verify the topology script; a wrong map makes the scheduler think nodes are local when they are not.
  3. Reduce shuffle volume (combiners, filtering early, better formats like Parquet).
  4. Long term: more or faster uplinks (lower oversubscription).

Avoid: “add more nodes”. More nodes behind the same uplinks can make it worse.

Startup · architectureFresher

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.