Servers: Rack, Blade and Hyperconverged

What makes a server a server

A server is a computer that provides services to other computers over a network and is built to do so continuously, unattended and remotely managed. The word describes a role (a file server, a database server, a virtualization host) as much as a type of hardware. You can run a web server on a laptop, but a data center server differs from a desktop PC in what it is designed to survive.

The components are the same kinds you know from What's Inside a Computer: processors, memory, storage, network cards and a power supply. The differences lie in quantity, quality and redundancy:

• Memory with error correction. Servers use ECC memory, usually as registered DIMMs (RDIMMs), and often hundreds of gigabytes or terabytes of it. A single flipped bit in a database server's memory is an outage or silent corruption; ECC corrects it and logs it.
• Several processors. Two-socket servers are common, with many cores each. Software licensing is often counted per core, which makes the processor choice a cost decision as well (see Data Center Virtualization in Practice).
• Redundant, replaceable parts. Two or more redundant power supplies, several fans, drives in front-loading bays, often RAID (see RAID), all replaceable without opening the case or, ideally, without switching the server off.
• Fast networking. As of 2026, typically 25 GbE in general-purpose racks, 100 GbE increasingly for virtualization and storage hosts, and 200 or 400 GbE for AI and GPU nodes, usually two ports or more for redundancy.
• A management controller. A small, separate computer on the motherboard lets administrators power the server on and off, see its console and read its sensors over the network, even when the operating system has crashed. That is the subject of Out-of-Band Management.
• Validated combinations. Vendors publish a hardware compatibility list (HCL): the combinations of components, firmware and operating systems or hypervisors they have tested and will support. Staying on the HCL is what keeps the support contract valid.

Form factors

The form factor is the physical shape of the server, and it decides where and how it is installed. Server+ names three chassis types: tower, rack mount and blade enclosure.

Tower servers

A tower server looks like a large desktop PC and stands on the floor. It needs no rack and is relatively quiet, which makes it a fit for a small office or a branch site with one or two servers. In a data center it wastes floor space, so you rarely see one there.

Rack servers

A rack server is a flat, self-contained server that mounts horizontally in a 19-inch rack on sliding rails, with its height expressed in rack units (1U = 44.45 mm; see Racks, Rack Units and Cabling). Each one has its own power supplies, fans and network ports. It is the standard building block of most data centers.

Blade servers

A blade server is a stripped-down server board, with processors, memory and sometimes drives, that slides into a shared enclosure and has no power supplies or fans of its own. That enclosure is the blade chassis: a rack-mounted frame that provides power supplies, fans, network and storage connectivity (interconnect modules) and a management module for all the blades inside, connected to them through a shared backplane or midplane. A chassis typically holds 8 to 16 blades in 6U to 10U, depending on the model.

The appeal is density and simplicity: sixteen servers with a handful of power cords and uplinks instead of thirty-two power cords and dozens of network cables, and one management interface for the lot. The costs are less visible:

• Shared failure domain. The chassis, its midplane and its firmware are shared by every blade. A chassis-level fault or a botched chassis firmware update can affect all blades at once, so clusters should spread across chassis.
• Lock-in. Blades only fit the chassis of their vendor and generation; the chassis is an investment that ties you to both.
• Power density. A full chassis can draw far more per rack unit than rack servers, which pushes the rack's power and cooling limits (see rack density).

Many organizations now prefer rack servers combined with hyperconverged software over blades, but blade and modular systems remain common in larger enterprise environments.

Hyperconverged nodes

A hyperconverged node is, physically, a 2U rack server (or a quarter of a 2U chassis that holds four nodes) with processors, memory and a set of local SSDs. What makes it hyperconverged is the software: every node runs a hypervisor plus a storage service, and the storage services of all nodes join their local disks into one shared, replicated pool that every virtual machine in the cluster can use. No separate storage array or storage network is needed.

Adding capacity means adding a node: compute and storage grow together. That simplicity is the selling point; the catch is that you cannot grow storage without also buying compute, and the other way round. How the shared pool works, and the trade-offs of replication versus erasure coding, is on Software-Defined Storage and Hyperconverged Infrastructure.

GPU servers

A GPU server is a server built around several graphics processing units used as accelerators for AI training and inference, simulation or rendering, rather than for display output. Typical AI training servers carry eight GPUs on a shared board, connected to each other by a fast GPU-to-GPU interconnect and to the network by several high-speed NICs, often one per GPU.

What sets them apart for data center staff is power and heat. An air-cooled eight-GPU server can draw on the order of 10 kW on its own, about as much as an entire rack of ordinary servers. The newest systems are designed as whole liquid-cooled racks that act as one machine, drawing 100 kW and more per rack (as of 2026). Accommodating them is as much a facilities project as an IT one: see liquid cooling and power. For the GPU itself, see Expansion Cards and Graphics.

Redundancy and hot-swap

A server part is hot-swappable when it can be removed and replaced while the server keeps running, without shutting it down. On a typical server this applies to drives (and sometimes whole drive cages), power supplies, fans and, on some models, expansion cards. Hot-swap only makes sense together with redundancy: you can only pull a power supply without an outage if another one carries the load in the meantime, and only pull a drive if RAID or the storage software has the data elsewhere.

Two levels of redundancy are worth separating, because the exam does and so does real design:

• Component redundancy inside one server: two power supplies, mirrored boot drives, two network ports in a team, several fans. It protects against a part failing.
• Server-level redundancy: two or more servers in a cluster, so the service continues when a whole server fails, or is taken down for maintenance. It protects against everything component redundancy cannot, such as a failed motherboard, a bad firmware update or human error.

Redundant power supplies are a classic place where redundancy exists on paper only. Each server's supplies are connected to the rack's A and B power feeds; for the server to survive, the remaining supplies, and the remaining feed, must carry the full peak load. The check below shows why that is not automatic.

# (server, peak draw in W, number of PSUs, rating per PSU in W, PSUs on feed A)
servers = [
    ("db01", 1100, 2, 1400, 1),
    ("web01", 420, 2, 800, 1),
    ("vmhost03", 1650, 2, 1400, 1),
    ("gpu01", 10200, 6, 3200, 3),
]

for name, peak, count, rating, on_a in servers:
    one_failed = (count - 1) * rating            # one PSU breaks
    feed_lost = min(on_a, count - on_a) * rating  # feed A or feed B goes down
    psu_ok = "yes" if one_failed >= peak else "NO"
    feed_ok = "yes" if feed_lost >= peak else "NO"
    print(f"{name:9} peak {peak:6,} W | survives a PSU failure: {psu_ok:3}"
          f" | survives losing one feed: {feed_ok}")

db01      peak  1,100 W | survives a PSU failure: yes | survives losing one feed: yes
web01     peak    420 W | survives a PSU failure: yes | survives losing one feed: yes
vmhost03  peak  1,650 W | survives a PSU failure: NO  | survives losing one feed: NO
gpu01     peak 10,200 W | survives a PSU failure: yes | survives losing one feed: NO

vmhost03 was upgraded with more memory and processors over the years, and its peak draw grew past what one supply can deliver; it has two supplies, but no redundancy left. gpu01 survives any single supply failure, but if feed A drops, the three supplies on feed B cannot carry it. Large GPU servers often need more supplies or a specific redundancy setting to be feed-redundant; check the vendor's power configurator rather than assuming.

Swapping a part safely

1. Confirm the failed part from the management controller or the server's own logs, not from memory or a ticket alone.
2. Check that redundancy is intact for everything else: the other supply is healthy, the RAID set is not already degraded by a second disk.
3. Find the right server and the right slot: switch on the locator LED from the management interface and check the label and serial number.
4. Use ESD protection (see Safety and Handling), swap the part, and verify in the management interface that the new part is recognized and, for a drive, that the rebuild has started.

Installing servers in a rack

Racking a server is physical work with real risks. A 2U server weighs 20–30 kg, a GPU server considerably more, and a rack that tips over can crush a person. The basics, which Server+ also lists under racking:

• Lift safely: two people (or a server lift) for anything heavy, and never lift a server above shoulder height alone (see Safety and Handling).
• Rack balancing: heaviest equipment at the bottom, and extend the anti-tip feet or stabilizer before you slide a server out on its rails. Never pull out more than one server at a time.
• Floor load limitations: a full rack can weigh well over a ton. Raised floors and older buildings have a maximum load per square meter and per tile; check it before placing heavy racks.
• Rails and cable management arms so that the server slides out for maintenance without unplugging anything, while cables stay clear of the exhaust (see Cooling and Airflow).

Before any of that comes planning. Space is rarely the limit anymore; power usually is. The sketch below fills a 42U rack, with four units reserved for networking, against a power budget of 12 kW.

USABLE_U = 42 - 4      # 4U reserved for top-of-rack switches and a patch panel
RACK_KW = 12.0         # power the rack's two feeds are designed to deliver

# (form factor, height in U, typical draw in kW per unit)
options = [
    ("1U server", 1, 0.45),
    ("2U server", 2, 0.75),
    ("2U four-node chassis", 2, 2.2),
    ("8-GPU server", 6, 10.2),
]

for name, height, kw in options:
    by_space = USABLE_U // height
    by_power = int(RACK_KW // kw)
    fit = min(by_space, by_power)
    limit = "space" if by_space < by_power else "power"
    print(f"{name:21} fits {fit:2} (space allows {by_space:2}, power {by_power:2})"
          f" -> limited by {limit}, {fit * height:2}U used")

1U server             fits 26 (space allows 38, power 26) -> limited by power, 26U used
2U server             fits 16 (space allows 19, power 16) -> limited by power, 32U used
2U four-node chassis  fits  5 (space allows 19, power  5) -> limited by power, 10U used
8-GPU server          fits  1 (space allows  6, power  1) -> limited by power,  6U used

In every case the rack runs out of power first and is left partly empty. That is normal: half-empty racks with blanking panels are a sign of good capacity planning, not of waste. Use the measured peak draw from the management controller or the rack PDU, not the nameplate rating of the power supplies, which is usually far higher than what the server really draws.