University Data Center Sizing for Research Computing: A Two-Workload Framework

Administrative IT is predictable. A rack of virtualization hosts running the student information system, financial aid, HR, and email draws a fairly flat 4-6 kW per rack, spikes modestly during registration weeks, and idles the rest of the year. Standard hot-aisle/cold-aisle air cooling handles it without drama, and a UPS sized for graceful shutdown covers the risk profile: if it goes down for twenty minutes during a planned failover, nobody's semester is at risk.

Research computing doesn't behave that way. A single rack of GPU nodes for machine learning or molecular dynamics can pull 30-50 kW or more, and unlike admin load, it runs at or near that ceiling for days or weeks during an active simulation or training run. That density moves the cooling conversation from CRAC units to rear-door heat exchangers or direct liquid cooling, and the power conversation from "enough circuits" to "enough amperage per rack, with room to add more."

The two workloads also fail differently. A researcher's node going down mid-job means re-running a computation that may have run for days — expensive in time even if no data is lost. An admin system going down mid-transaction means a support ticket. Those are different availability requirements, and forcing them into one uptime target either overspends on redundancy for research nodes or underspends on the systems that actually need it.

Sizing starts with what the researchers plan to run, not a generic square-footage estimate. A CPU-bound cluster for genomics alignment or statistical modeling looks like a beefed-up admin rack — call it 8-12 kW per rack, air-cooled, standard networking. A GPU cluster for deep learning or large-scale simulation is different: modern accelerators concentrate enough heat per rack unit that air cooling struggles past roughly 20 kW per rack, which is why most new GPU deployments plan liquid cooling at the rack or chip level from the outset rather than retrofitting it later.

Power distribution has to match that density. A rack pulling 40+ kW needs higher-amperage PDUs and circuits sized with headroom for the next GPU generation, not just this year's — accelerator power draw has climbed with each refresh, and a facility wired to today's exact number is undersized in a few years. Building 20-30% headroom into the research zone's power and cooling specifically, above the margin used for admin systems, is the difference between a facility that absorbs the next grant-funded cluster and one that needs a construction project to do it.

Network design matters as much as power. Clusters running distributed training or tightly coupled simulations need low-latency, high-bandwidth interconnects between nodes — a different fabric than the 1/10 GbE that comfortably serves file shares and admin applications. Planning that fabric as a separate zone, rather than extending the campus network core, keeps a burst of research traffic from degrading performance for everyone else.

Full separation into two physical facilities is rarely the right answer for a campus budget, and it isn't necessary. Physical security, fire suppression, generator backup, and the building envelope itself are worth sharing — they don't scale with workload type, and duplicating them is pure overhead. What shouldn't be shared is the electrical distribution downstream of the main switchgear, the cooling loop, and the network core: those need independent sizing and zoning so a research cluster's peak draw or a cooling-loop fault doesn't cascade into the other zone.

A practical layout treats the facility as one building with two data halls, or one hall with two clearly zoned areas: a standard-density zone for admin, storage, and CPU-bound research on conventional air cooling, and a high-density zone provisioned for liquid cooling and heavy power with room to expand as GPU adoption grows. That zoning decision, made at the design stage, is far cheaper than adding liquid cooling to a room that wasn't plumbed for it.

Staging and integration benefit from the same separation. Admin refresh hardware — servers, switches, UPS units — is a known quantity most integrators handle routinely: unboxing, racking, cabling, burn-in before delivery. GPU nodes and their cooling infrastructure benefit from a staging partner who can validate the liquid-cooling connections and network fabric before it reaches campus, since a DOA node found after installation costs a research team weeks, not hours.

Admin infrastructure and research computing hardware age on different clocks, and a single five-year refresh cycle for the whole facility ignores that. Administrative servers and storage typically run a comfortable 5-7 year lifecycle before performance or support-contract economics push a refresh. GPU hardware for research computing moves faster — new accelerator generations arrive roughly every 12-24 months with meaningful performance and efficiency gains, and grant-funded research groups often want to refresh sooner to stay competitive for compute-intensive proposals.

Budgeting for that means separating capital planning lines for the two zones rather than bundling everything into one facility-wide request. It also means the physical and electrical infrastructure — longest lifecycle, highest replacement cost — should be sized for the research hardware two generations out, not just this cycle's, since ripping out PDUs and cooling loops for the next GPU refresh is far more disruptive than swapping servers.