</> MAANG.io

Expert

Design landmark systems in depth, from Dynamo, GFS, Bigtable and Kafka to payments and ads pipelines.

0 of 232 solved 0%

Section 10: When Forty Machines Vanish at Once - Reliability & Operations: Rack Loss, Master Loss & a Shared Cluster

Executive Summary: Section 8 survived one dead worker. Here the failures get bigger. When rack 10 loses its switch at minute 4, 40 machines vanish together: about 1,800 completed and 80 in-progress map tasks re-run as about half a wave on the remaining 3,920 map slots, 80 reduce tasks restart in map slots freed when the map phase ends, and rack-aware GFS placement keeps every split readable. The job lands under a minute late, inside the 15-min SLO. When the master dies, the job aborts and is resubmitted. Dying at minute 6 loses 6 min and the rerun finishes right at the SLO; the worst case loses about 8 min. Master death hits about 0.006% of jobs, and abort-and-resubmit is the right trade until jobs run for hours. Then the cluster view: ~1,000 jobs a day, one master each, a cluster scheduler, preemption made cheap by re-execution, and status pages and counters that let Riya run the job alone.

Interviewer: "One machine dying is easy. A top-of-rack switch fails and you lose forty at once. Walk me through it, minute by minute."

You: "Good, because correlated failure is where a design that only sounds fault-tolerant falls apart. Let's take rack 10. It holds w-0417, the machine that was running Riya's split 88,213."

Rack 10 Goes Dark at Minute 4

At minute 4 the inlinks job is about three minutes into its map phase when rack 10's switch dies. To the master, 40 machines just stop answering heartbeats. It can't tell crashed from cut off, and the design never needs to.

Flowchart of the rack 10 switch failure at minute 4: 40 machines become unreachable, losing completed map output on 40 local disks, in-progress map tasks, 80 reduce tasks, and the GFS replicas on rack 10; the lost maps mean about 1,800 completed and 80 in-progress maps re-run elsewhere, which costs about half a wave on 3,920 map slots; the 80 reduces restart in freed map slots and re-fetch; and for the lost GFS replicas, input is still readable from other racks while GFS re-replicates in the background.

At minute 4 each rack-10 machine has finished about 45 map tasks (3 minutes × 2 slots ÷ 8 s), so ≈ 1,800 completed maps go back to idle because their output sits on unreachable local disks (Decision 3's bill, as Section 8 promised), plus 80 in progress. Unstarted tasks were never assigned to rack 10, so the surviving slots simply pull them as before. The re-runs are about half a wave on the remaining 3,920 map slots, and the cluster is 2% smaller for the rest of the map phase, which costs a few seconds. Had the rack died at the end of the map phase, all 40 × 78 = 3,120 would re-run on the critical path: one 8-s wave plus 15 s of detection.

GFS makes the re-runs possible. Split 88,213 had replicas on w-0417 (rack 10), w-1123 (rack 28) and w-1160 (rack 29), because rack-aware placement never puts all replicas on one rack. The master reschedules it on w-1123, still replica-local. Locality survives losing a whole rack.

Time Event What the framework does
4:00 Rack 10 switch fails Nothing yet. The heartbeats just stop arriving
4:00–4:15 3 heartbeats missed (5 s apart) 1,960 machines keep mapping; reducers retry failed fetches
4:15 40 workers declared dead ≈ 1,800 completed and 80 in-progress map tasks, plus 80 reduce tasks, reset to idle. Reducers are told those maps will re-run
4:15 onward Re-execution Maps join the idle queue on 3,920 map slots, mostly replica-local: about half a wave of extra work
≈ 6.3 min Map phase ends, a few seconds late 80 reduces restart in freed map slots and re-fetch 250 MB each (≈ 20–40 s at the cross-rack share)
Background GFS notices lost replicas Re-replicates rack 10's chunks (see the Google File System module)
≈ 8.5–9 min Job completes Under a minute late, against a 15-min SLO

The 80 restarted reducers are the bigger cost. Every surviving reduce slot already holds a reducer, so they start in map slots freed when the map phase ends and re-fetch 250 MB each, ≈ 20–40 s at the cross-rack share, before their normal 1.5 min of sorting and reducing. The map re-runs themselves cost seconds, because they ran in parallel mid-phase. The same loss during the reduce phase would add up to ≈ 1.5 min, still inside budget. The 2004 paper offers a sanity check: its sort benchmark with 200 worker processes killed mid-run took 933 s instead of 891 s, only 5% longer. That was killed processes on healthy machines, which the cluster scheduler restarted at once, so it's a lower bound on a rack loss, not a replica of one.

Interviewer: "You said the machines might still be alive behind the dead switch. What if the switch comes back and those zombies report in?"

You: "Section 8's atomic commits handle it. A zombie map's completion is for a task already reassigned; the first completion wins and the duplicate is ignored. A zombie reducer can only finish by renaming its temp file in GFS, deterministic code means both attempts hold the same bytes, and the atomic rename leaves exactly one part-NNNNN. No fencing tokens, no membership protocol. 'Dead' and 'unreachable' get the same treatment, safely, because every commit is idempotent."

Key Insight: Re-execution scales from one failure to forty with no new mechanism. Fine-grained tasks (Decision 5) spread the lost work cluster-wide, rack-aware replicas keep input readable, and atomic commits defuse zombies. A rack costs half a wave and a re-fetch, not a rerun.

Quick check before moving on:


Sign in to continue reading

The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.

Sign in to read the full lesson

Sign in to MAANG.io

Use your Google or Microsoft account — no password to remember.

Continue with Google Continue with Microsoft

Please accept the terms above to continue.