Rack server buying guide: form factor, processors and memory

Form factor first: what the rack unit buys

Height is the first decision because it bounds all the others. A 1U server halves the space per node and caps memory slots, drive bays and expansion; a 2U server doubles the space and opens all three. Neither is better — they are answers to different questions. Stateless tiers that exist in dozens (web front ends, container nodes, application fleets) belong in 1U, where density is the metric and per-node depth barely matters.

Hosts that carry state or depth — virtualisation servers with hundreds of gigabytes of memory, database machines with banks of NVMe drives, GPU carriers — belong in 2U, because their configurations physically do not fit in half the height. The commonest buying error in this category is choosing height by habit and discovering the constraint mid-configuration. Decide the workload's memory and drive shape first; the height usually decides itself.

Processors: platform, then tier, then count

The processor decision has three layers and they should be made in order. Platform first: Intel Xeon or AMD EPYC, a choice driven by core-count arithmetic, per-core licensing, and whatever standard the estate already runs. Tier second: within a platform, the range from efficiency cores to maximum-clock parts maps to workload shape — many small requests want thread count, fewer heavy threads want clock speed. Count last: one socket or two, which interacts with memory layout and licence exposure.

Two traps recur. The first is buying cores the workload cannot use while starving the memory those cores need — thread count impresses in a spreadsheet and idles in production. The second is ignoring per-core licensing until after the hardware decision; on licensed workloads the software can cost more than the server, and a high-core platform choice should be made with that number on the table. A good configuration quote surfaces both.

Memory: the quiet performance line

Memory decides more real-world performance than any other configuration line, and it is the line buyers most often under-specify. Virtualisation guests consume it whether they compute or not; database buffer pools convert it directly into avoided disk reads; analytics jobs spill to storage when it runs out. The sizing rule that survives contact with production is simple: state the workload's working set, then populate memory to hold it with growth room.

Population matters as well as capacity. Memory channels reward balanced populations — the same total spread evenly across channels outperforms a lopsided layout — and the number of slots in the chassis caps the upgrade path. A 2U host with 32 slots buys its second life cheaply; a fully populated smaller chassis is finished growing the day it arrives. On the quote, memory should appear as size, module count and population, not as a single gigabyte figure.

Storage inside the server: boot, cache, capacity

Internal drives divide into three jobs. Boot drives should be small, mirrored and boring — their only task is to never be the reason a node is down. Cache and hot tiers want NVMe, where latency, not capacity, is the purchase. Capacity tiers take the large SATA and SAS drives, where cost per terabyte rules. Mixing the jobs — booting from the capacity pool, caching on spinning disks — is how servers acquire mysterious performance problems.

The strategic question behind the layout is how much storage belongs inside the server at all. Estates with shared arrays keep hosts nearly diskless and stateless; estates without them concentrate drives in the hosts and accept the coupling. Both are legitimate designs. What is not legitimate is drifting into one while budgeting for the other — the quote should state which design it prices.

The small lines that decide installation day

Power supplies, rail kits and management controllers are the lines nobody writes articles about, and they decide whether installation day is an hour or a week. Power supplies must match the rack's feed and the redundancy policy; a mismatched rating discovered at the rack face stops the whole row. Rails seem trivial until a chassis arrives with the wrong kit for the rack standard in the hall.

Remote management — iLO, iDRAC, XClarity, iBMC depending on the line — is the operator's daily interface with the machine for its whole life. Estates standardise on it for good reason. Name the management standard your team runs in the inquiry, and treat it as a platform factor alongside the processor, not as an accessory.

Making quotes comparable

Two quotes for the same model are comparable only when the configurations are written in the same detail: processor model and count, memory size and population, drive models and layout, power and rails, management options. Anything less compares badges. The habit that protects buyers is boring and total: get the configuration in writing, line by line, before comparing prices — and keep the written configuration with the order, because it is also the document the shipment gets checked against.

That is the route this site sells through: brief, written configuration, quote, and serial numbers available before shipment. It is slower than clicking a price by perhaps a day, and it is how server estates avoid the purchases they regret for five years.

Second-hand lessons: what estates standardise after the first purchase

Talk to an estate on its second fleet purchase and the standardisation list is always longer than the first time. One rail type. One power supply rating per height. One management credential scheme. Memory modules of a single size, so any host can lend to any other. None of these decisions is technical; all of them are the difference between a fleet and a collection, and every one is free at configuration time and expensive forever after.

That is the deepest reason to buy servers as written configurations rather than as prices: the configuration document is where an estate's standards live. Keep it, repeat it, amend it deliberately — and the second purchase is the calmest procurement of the year instead of a fresh negotiation with entropy.