Rack units, server chassis, and what fits where

Why this matters

Installing server hardware starts before anything is unboxed. Most of the expensive mistakes in this objective are made at the ordering stage: a server that is deeper than the rack, rails that do not fit the rack's mounting holes, a storage shelf too heavy for the top of the cabinet, or a part the operating system does not support. None of these are hard to avoid, and all of them turn up on the exam as scenarios that ask what should have been checked first.

This lesson covers the physical form of servers and the rack they live in. The next two lessons deal with the power feeding them and the air and cables around them.

The lesson

Tower, rack-mount and blade chassis, and when each earns its space

Servers come in three physical forms, and each suits a different situation.

A tower server looks like a large desktop PC and stands on the floor or a shelf. It needs no rack, runs quietly enough for an office, and usually has room for plenty of internal drives and expansion cards. It is the natural choice for a small business with one or two servers and no server room. Its weakness is density: towers take up a lot of floor space per server and are awkward to manage in any number.

A rack-mount server is built to bolt into a standard 19-inch rack. It is flat and wide, trades internal space for density, and is designed to be serviced from the front and back while its neighbours keep running. This is the default in any server room or data centre, because a single rack holds many servers, their switches, storage and power distribution in an organised stack.

A blade server takes density further. The individual servers, the blades, slide into a blade enclosure (chassis) that provides shared power supplies, cooling fans and network and storage connections. Many blades fit in the space of a few rack-mount servers, with far fewer cables. The trade-offs are that the enclosure itself becomes a shared dependency, blades generally only fit one vendor's enclosure, and the upfront cost is high until the enclosure is well populated. Blades earn their space when an organisation runs many similar servers and wants to manage them as one system.

Rack units, rack depth, and measuring before anything is ordered

Rack equipment is measured in rack units, written U. One rack unit is 1.75 inches (44.45 mm) of vertical space. A server described as 1U is 1.75 inches tall, a 2U server is 3.5 inches, and so on. A full-height rack is commonly 42U, a little over six feet of usable space, and smaller racks of 12U to 24U are common in offices and network closets.

The width is standardised: a 19-inch rack has mounting rails 19 inches apart, and almost all rack-mount equipment is built to that width.

The depth is not standardised, and it is where orders go wrong. Racks range from shallow network cabinets around 600 mm deep to server racks of 1,000 mm or more, and modern servers can be deep enough that they do not fit a shallow cabinet with the door closed. Before buying, check three numbers against each other: the depth of the rack between its front and rear mounting rails, the depth of the equipment including its rails and any cable management arm, and the clearance needed behind it for power and network cables.

Measure the height budget too. Plan the rack as a drawing, called a rack elevation, that assigns every device a position by U number. It shows at a glance whether everything fits, where the gaps are, and what is left for growth.

Rail kits, weight and loading the heaviest equipment at the bottom

Rack-mount equipment attaches to the rack with rails. Sliding rails let a server slide forward out of the rack on extending runners so it can be serviced without being removed, which is the norm for servers. Fixed rails or shelves simply support equipment that rarely needs opening. Rails must match the rack's mounting holes: most modern racks have square holes that take clip-in cage nuts or tool-less rails, while older racks have round or threaded holes. Check which your rack has before ordering rail kits, and check the rails' supported depth range against the rack.

Weight dictates layout. Load the heaviest equipment, such as UPS units and storage shelves, at the bottom of the rack, and lighter equipment above it. This keeps the centre of gravity low. A top-heavy rack can tip when a heavy server is slid out on its rails, and a falling rack is a genuine injury risk. For the same reason, fit the rack's stabiliser feet or anchor it to the floor, and pull out only one device at a time. Two servers extended at once can be enough to overbalance a rack that is not anchored.

Heavy equipment also needs two people and proper lifting technique: lift with your legs, not your back, and use a server lift for the heaviest units. Finally, check the floor load: a fully populated rack can weigh well over half a tonne, and raised floors and older buildings have rated limits.

KVM and console access, and where they sit in the rack

Servers usually run without their own keyboard and screen, but an administrator still needs a way in when the network or remote management is not available. A KVM switch (keyboard, video and mouse) connects one console to many servers and switches between them. In a rack, this is often a 1U console drawer: a fold-out screen and keyboard on sliding rails.

Place the KVM console at a comfortable working height, roughly the middle of the rack, not at the top or the floor. An administrator standing at it during an outage should be able to see and type without crouching.

Some equipment, particularly network gear, is managed through a serial console rather than a screen. A console server (terminal server) collects many serial connections and makes them reachable over the network. For servers, out-of-band management controllers provide remote console access over their own network port; the out-of-band management lesson later in this domain covers them in detail, and they reduce but do not remove the need for local console access.

The hardware compatibility list, checked before a part is bought

A hardware compatibility list (HCL) is a vendor's record of the hardware that has been tested and is supported with its software. Operating system vendors publish them, hypervisor vendors publish them, and server manufacturers publish lists of the memory, drives and expansion cards that are supported in each model.

Check the HCL before buying, not after something fails. The questions to ask are: is this server model supported by the operating system or hypervisor I intend to run, at the version I intend to run; are the specific components, such as the RAID controller and network cards, on the list with a supported driver; and does the server vendor support the memory and drives I plan to add? Many server vendors only support drives and memory they have qualified, and third-party parts can void support or simply not be recognised.

A part missing from the HCL may still work, but "it works" and "it is supported" are different promises. When something goes wrong in production, the vendor's first question will be whether the configuration was supported.