redzilla
Datacenter

A Datacenter in One Room

You don’t need a guarded building to have a datacenter: you need a room where heat gets out, power doesn’t fail and disks don’t betray you. Basic physics + honest math.

≈ 13 min read

One January — high summer in Chile — we got called about "servers shutting themselves off in the afternoon". The "datacenter" was a three-by-three-meter storage room with one rack, a wall-mounted split AC, and a management directive: turn the AC off at closing time, to save money. Every summer afternoon the room climbed from 22 to nearly 40 °C, the servers protected themselves by shutting down, and next morning everything "worked again". Nothing was wrong with the hardware. There was just a misunderstanding with physics.

Your room is already a datacenter

A datacenter is not a building with guards and biometric doors: it's any room where the business keeps its iron. The NVR closet, the rack in the corner, the office that hosts the billing server "just for now". And here's the uncomfortable part: that room obeys exactly the same laws as a Tier IV facility. Electricity turns into heat, heat has to be carried out by air, disks fail on a schedule of their own, and availability is bought with money. The difference between Google and your back room isn't the physics — it's how much budget each law received.

This guide walks through the four calculations that decide whether your room is a small datacenter or a slow oven: space (the rack), heat (BTU), air (flow rate) and promises (the nines). All with verifiable numbers, because in this trade "more or less" gets paid for at 3 a.m.

The rack: 42U of order and physics

The rack unit exists so everything fits: 1U = 1.75 inches = 44.45 mm, a standard that has survived since the days of telephone switchboards. The typical cabinet is 42U: 42 × 44.45 = 1,866.9 mm — 1.87 m of usable space in a frame about two meters tall. In theory that's 42 servers of 1U each. In practice you fit far fewer, and almost never because of space: you run out of power or cooling long before you run out of U.

Weight is the other number everyone underestimates. A switch weighs about 5 kg, a 1U server 12 to 18, a rack-mount UPS with its batteries easily clears 60, and an external battery pack can double that. A moderately populated rack passes half a ton — which is why serious cabinets are rated for 1,000 to 1,500 kg static load, and why placement matters. The rule is load from the bottom: the heaviest gear (UPS, batteries) at the base, servers in the middle, switches and patch panels up top where the cabling arrives. It's not tidiness — it's center of gravity. When you slide a heavy server out on its rails, its entire weight hangs cantilevered in front of the rack; if that server lives near the top, the rack can tip over — with you holding it. Before buying the cabinet, balance U, kilograms and kilowatts in the rack capacity calculator.

Every watt comes in as electricity and leaves as heat

The first law of the datacenter is the first law of thermodynamics: practically every watt your equipment draws becomes heat inside the room. Not "a portion" — all of it. The data a server processes doesn't weigh anything or keep anyone warm; 100 % of that energy ends up in the air. A 10 kW rack is, thermally, five 2 kW space heaters running 24/7 in a closed room. Nobody would leave five heaters on behind a closed door over a long weekend; a medium-density rack is exactly that.

To talk to the HVAC vendor you need to translate units: IT kW × 3412 = BTU/h, which is the unit cooling gear is sold in, and kW ÷ 3.517 = tons of refrigeration (1 TR = 12,000 BTU/h). On top of the IT load, add what the spec sheets forget: a UPS dissipates 4 to 10 % of whatever passes through it, lighting contributes its share, and if the room has a wall facing the afternoon sun, that wall is a heater too. The heat load calculator adds up all the pieces.

A residential air conditioner is designed for human comfort: short duty cycles, a "pleasant" setpoint, and dehumidification tuned for people, not for hardware. A precision unit (CRAC) is built to run all 8,760 hours of the year while controlling temperature and humidity. If you're starting with a split anyway — it happens to the best of us — install two with automatic rotation, size them with headroom, and never switch them off at night: servers don't sleep.

Air: cold aisle, hot aisle

Removing heat isn't just "adding cold": it's traffic management. Servers breathe front to back — cold air in through the face, hot air out the rear. If that hot air loops around and enters the front of the neighboring rack (or its own), the equipment breathes pre-cooked air and runs a fever. The fix is decades old and still standard: face the racks toward each other to form a cold aisle where the air is supplied, and let their backs exhaust into a hot aisle that returns to the CRAC overhead. Cold and hot never mix: they wave at each other from a distance.

Room cross-section: the CRAC pushes cold air under the floor into the cold aisle, racks pull it through once, and hot air returns to the CRAC along the ceiling Room cross-section — cold aisle / hot aisle CRAC cooling perforated tile underfloor plenum RACK A front RACK B front COLD AISLE hot air return hot aisle hot aisle
Cold air enters the cold aisle, crosses the racks exactly once, and returns hot to the CRAC. If cold and hot mix, you pay twice for the same cooling.

So how much air do you need to move? The formula is Q = P ÷ (ρ × cp × ΔT): the heat load divided by air density (≈ 1.2 kg/m³), its specific heat (≈ 1005 J/kg·°C) and the ΔT — how much the air warms up crossing the servers, typically 10 to 15 °C. You can play with kW and ΔT in the airflow and CRAC calculator, but let's size the whole 10 kW room by hand, start to finish:

  1. Heat to remove: 10 kW × 3412 = 34,120 BTU/h. That's the number your HVAC vendor understands.
  2. In tons of refrigeration: 10 ÷ 3.517 = 2.84 TR (same result the other way: 34,120 ÷ 12,000 = 2.84). A 3 TR unit is cutting it close; with N+1 redundancy, two 3 TR units.
  3. Airflow at ΔT = 12 °C: Q = 10,000 ÷ (1.2 × 1005 × 12) = 0.69 m³/s.
  4. In spec-sheet units: 0.69 m³/s × 2119 ≈ 1,464 CFM. For a mental picture: that's about 2,490 m³/h — 25 bathroom exhaust fans blowing at once, for a three-by-three-meter room.
  5. ΔT rules everything: if air mixes and your real ΔT drops to 6 °C, you need double the airflow for the same heat. Aisle containment and plugging gaps isn't cosmetic: it's free airflow.

And how do you know your real ΔT? Your servers already measure it — no extra instruments:

server — temperatures via IPMI
$ ipmitool sdr type Temperature
Inlet Temp       | 04h | ok  |  7.1 | 24 degrees C
Exhaust Temp     | 01h | ok  |  7.1 | 36 degrees C
CPU1 Temp        | 0Eh | ok  |  3.1 | 58 degrees C

Inlet 24 °C, exhaust 36 °C: a ΔT of 12 °C, exactly the one we used. If the inlet reads 30 °C or higher, the problem isn't the CRAC — it's hot air recirculating to the front.

Every empty U without a blanking panel is an air short-circuit: hot air from the back sneaks straight to the front of the gear next door. A blanking panel costs less than lunch; add brush grommets on the raised-floor cutouts and you've just made the best-ROI cooling upgrade in the whole room.

The nines: availability is bought with money

"It can never go down" is the most expensive sentence in the trade, priced per word. Availability is expressed in nines, and the scale is deceptive: between 99 % and 99.999 % there seems to be "almost nothing", but each extra nine divides annual downtime by ten — and multiplies the budget by something suspiciously similar.

AvailabilityMax downtime / yearFeels likeWhat gets you there
99 %3.65 daysa long weekend with no systema lone server, no redundancy
99.5 %43.8 hoursalmost two business daysgood hardware, zero power backup
99.9 %8.77 hoursone full workdayUPS + serious cooling + monitoring
99.99 %52.6 minutesa meeting that ran longN+1 power and cooling
99.999 %5.26 minutesa coffee runfull redundancy, two sites
Ladder of nines: from 99 % with 3.65 days of downtime per year to 99.999 % with 5.26 minutes The ladder of nines — max downtime per year 99 % 99.9 % 99.99 % 99.999 % 3.65 days/yr 8.77 h/yr 52.6 min/yr 5.26 min/yr no redundancy typical hosting needs N+1 carrier class each extra 9: downtime ÷ 10 … and budget × 10
Each step divides annual downtime by 10. Climbing from 99.9 % to 99.99 % costs more than everything below it combined.

How do you climb the steps? With N+1 redundancy: if the load needs N units, you install N+1 so any single failure goes unnoticed. And the golden rule for combining components: in series, availabilities multiply — everything must work, so two 99 % links chained together give 0.99 × 0.99 = 98.01 % (the chain is worse than its weakest link). In parallel, the system forgives: only one needs to work, and two 99 % units in parallel reach 99.99 %. Model the whole chain — utility power, UPS, cooling, server, switch — in the availability and SLA calculator, with the nines and downtime minutes for each configuration.

Disks: RAID is not backup (and writes cost extra)

The painful part first: RAID is not backup. RAID protects against a disk failing; it does nothing against accidental deletion, ransomware or fire — all of which replicate their disaster to the remaining disks enthusiastically and in real time. Backup is another copy, on other hardware, ideally somewhere else. That said, the right RAID level does decide how fast and how tough your storage is, and there's a number almost nobody checks: the write penalty.

Every logical write becomes several physical operations. RAID 10 writes the data and its mirror: 2 operations. RAID 5 must read the old data, read the parity, write the new data and write the new parity: 4. RAID 6, with double parity, needs 6. Run the numbers on a real array: 8 disks at 150 IOPS give 1,200 raw IOPS; with a typical 70 % read / 30 % write mix on RAID 5, you're left with 1,200 ÷ (0.7 + 0.3 × 4) = 632 functional IOPS. Parity ate almost half the array — before the first virtual machine even booted.

LevelWrite penaltyFunctional IOPS (8×150, 70/30)Survives
RAID 0×11,2000 disks — don't even think about it
RAID 10×29231 disk per mirror
RAID 5×46321 disk
RAID 6×64802 disks
With 12 TB disks or larger, rebuilding a RAID 5 can take days — with the array degraded, slow and under maximum stress. It's the worst possible moment for a second disk to fail, and also the most likely one. For big disks: RAID 6 or RAID 10.

Usable capacity and fault tolerance for each level live in the RAID calculator; performance with your actual read/write mix, in the IOPS with RAID penalty calculator.

Growth: don't let 80 % catch you by surprise

Storage never fills up by registered mail: it fills up on a Friday at 6:30 pm. The defense is boring and effective — measure your real monthly growth rate (your business's rate, not the vendor brochure's) and project forward. Careful, though: growth tends to be compound. More customers mean more cameras, more mail and more backups, and the curve steepens on its own.

An example with numbers: you're using 6 TB out of 10, growing 4 % monthly compound. You hit 80 % (8 TB) in 7.3 months and a full disk in 13. Why does 80 % matter? Because above that threshold many filesystems and arrays start degrading performance, and because that's where your room to maneuver ends: migrating, snapshotting or rebuilding a RAID all need free space. Project the exact date with the storage growth calculator and schedule the purchase months ahead: a purchase order moves faster than a dead disk on a Sunday.

The small room and the big datacenter obey the same physics; the difference is who did the math first. Start today: measure your rack's real power draw, convert those kW into BTU and airflow, and write down what one hour of downtime costs you. With those three numbers, every decision in the room — cooling, UPS, RAID, capacity — stops being an act of faith and becomes arithmetic.

Tools to practice with