Planning power and cooling for a small server room

Start with the load arithmetic, not the hardware

Every server room problem is an arithmetic problem wearing a facilities costume. The room must supply the electrical power the equipment draws and remove the same energy again as heat — those are the same number in two currencies, and both are set by the equipment list, not by the building. Planning therefore starts from the intended estate: nameplate figures overstate real draw, but they are the safe basis for capacity; a sensible plan sizes supply from measured or estimated real loads and keeps nameplate totals as the ceiling check.

Work in kilowatts per rack. A rack of mainstream 1U and 2U servers commonly lands in the mid single digits; a rack carrying GPU nodes can exceed that several times over, because accelerator servers convert electricity to heat with unusual enthusiasm. The per-rack budget is the number that decides how full racks may be, where GPU nodes may live, and whether the estate you are buying actually fits the room you have — which is why it belongs in the hardware inquiry, not after it.

Electrical design: feeds, phases and headroom

Capacity is only the first electrical question. Distribution decides usability: how the load spreads across phases, where the PDUs sit, and how much headroom each feed carries so that a single circuit trip does not darken a row. Redundancy policy turns those choices into expenditure — dual power supplies in every server want two independent feeds to mean anything, and a duplicated supply path costs roughly what it costs whether you plan it early or retrofit it in anger.

Headroom is the cheapest insurance in the room. Electrical work has long lead times and shutdown windows; an estate planned to consume every available amp on day one converts its first expansion into a building project. The experienced rule is to land the initial estate at a comfortable fraction of the room's service capacity and to treat the remainder as the growth budget it is.

Cooling: heat leaves by air, and air has rules

Small rooms cool with air, and air obeys simple, unforgiving geometry. Cold air must reach server intakes; hot exhaust must leave without mixing back into the intake stream. The disciplines that achieve this are cheap and mostly organisational: blanking panels in every empty rack unit, so exhaust cannot shortcut through gaps; consistent front-to-back orientation, so aisles alternate cold and hot instead of averaging into lukewarm; and cable management that keeps the back of the rack from becoming a wall.

Capacity checks use the same kilowatt figure as the electrical plan — the cooling plant must remove the estate's full heat output on the hottest day the building experiences, not the average one. Rooms that 'mostly cope' fail in the first heatwave, taking the estate's most loaded week as their occasion. If the arithmetic says the room is short, denser heat sources like GPU nodes are the first load to relocate or re-phase.

Monitoring: the room that reports itself

Small rooms fail quietly. A cooling unit trips at night; a PDU leg sheds load; inlet temperatures creep a degree a week as filters clog. The defences are sensors and thresholds: temperature at rack intakes — not just at the cooling unit's return — power per feed, and alerts routed to a human who can act. None of this requires enterprise tooling; it requires deciding, in advance, which numbers someone will see and what they will do about them.

Trend data earns its keep at expansion time. A room whose loads and temperatures are known quantities accepts new hardware with arithmetic; a room run on vibes accepts it with anxiety and, eventually, with an incident. Keep the per-rack budget as a living document — the same figure this site asks GPU buyers to state — and update it with every installation.

Where hardware choices lighten the facilities load

Facilities planning and hardware buying are the same conversation held in two rooms. Server power supply ratings must match the feeds the room provides; high-efficiency supplies waste less of the budget as heat inside the chassis; and node selection changes the load shape itself — an efficiency-core fleet draws a flatter, cooler profile than a performance fleet doing the same work. None of these decides a purchase alone, but a brief that states the room's per-rack budget lets the configuration respect it from the first line.

Phasing is the final lever. Estates rarely need every rack live on day one, and facilities capacity can be built in stages that match the rollout — provided the plan exists. Write the room plan before the hardware order, keep both documents together, and the server room becomes what it should be: the dull, reliable substrate the interesting equipment stands on.

The expansion conversation

Every server room plan should end with the expansion conversation held in advance: when the estate doubles, what runs out first — service capacity, distribution, cooling, or physical racks — and what project relieves it. The answer is rarely 'everything at once'; it is usually one constraint with a long lead time, and naming it early converts a future emergency into a scheduled project with a budget line.

Keep the answer with the room plan, next to the per-rack budget document, and revisit both at every installation. Rooms fail estates quietly, by accumulation; the plan is the only participant in the process whose job is to notice. Hardware orders that state the room's budget — as this site asks of GPU buyers especially — are how the noticing becomes routine.

The one-page version

If the whole article compresses to a page on the facilities manager's wall, it is this: know the load in kilowatts per rack; feed it with headroom; remove exactly that much heat on the hottest day; keep cold air and hot air from mixing with blanking panels and orientation; monitor inlets and feeds, and trend them; and write the expansion constraint down before it arrives. Everything else in this article is commentary on those six lines — which is another way of saying the six lines are the job.