Data Center Hardware

A data center turns electrical power, floor space, cooling, and network links into computing capacity. Its hardware is a system, not a pile of servers. A processor cannot serve an application without memory, storage, network paths, power conversion, heat removal, firmware, and a physical chassis.

Use this mental model:

facility power and cooling
          |
          v
rack -> server -> compute, memory, storage, and network
  |         |
  |         +-> firmware and out-of-band management
  +-> power distribution, cabling, and switches

Each layer constrains the next one. A rack can have empty slots yet lack enough power or cooling for another server. A server can have fast processors yet wait on memory, storage, or the network. Good hardware decisions therefore begin with the workload and include the whole operating environment.

Start with the workload

Translate an application need into resource requirements before comparing product names.

Workload need	Hardware question
More parallel computation	How many processor cores or accelerators can the software use?
Large active data set	How much memory capacity and bandwidth are required?
High transaction rate	What storage latency, endurance, and input or output rate are required?
Heavy east-west traffic	What network throughput, port speed, and path redundancy are required?
Strict availability target	Which components, paths, and power feeds must tolerate a failure?
Dense deployment	Can the rack deliver and remove the required power and heat?

Capacity is not one number. Record compute, memory, storage, network, power, cooling, rack space, and management requirements separately. Include growth and failure conditions. Peak demand, steady demand, and recovery demand can describe different hardware needs.

Read a server as a set of subsystems

A server chassis packages several cooperating subsystems.

The processor executes instructions. Socket count, core count, architecture, clock behavior, and supported memory shape the compute envelope.
Memory holds active code and data. Capacity, channel population, bandwidth, latency, and error protection matter.
Local storage holds persistent data or temporary working data. Media type, interface, endurance, capacity, and fault design matter.
Expansion slots connect network adapters, storage controllers, and accelerators through an I/O interconnect such as PCI Express.
Network interface controllers connect the host to data and management networks.
Power supply units convert incoming power for the server. Redundant units can preserve service after one supply or feed fails when the rest of the path is designed correctly.
Fans, heat sinks, and airflow paths move component heat to the room cooling system.
Platform firmware initializes hardware and starts the operating-system loader.
A baseboard management controller provides an independent path for monitoring and out-of-band management.

The motherboard joins these parts. It also fixes many limits. Processor sockets, memory slots, expansion lanes, drive bays, firmware support, and physical clearances cannot be evaluated independently.

Separate form factor from capability

Rack servers use rack units to describe chassis height. A one-unit server occupies less vertical space than a two-unit server, but density is only one tradeoff. More chassis volume can allow more drives, larger accelerators, larger heat sinks, or different airflow.

Blade and sled systems place multiple compute modules in a shared enclosure or rack architecture. Shared power, cooling, fabric, and management can reduce repeated components. They also create shared dependencies and platform-specific service procedures.

Open Compute Project designs show another approach: standard interfaces between racks, power systems, server sleds, storage, and management. These specifications are useful examples of hardware designed as a rack-level system.

Do not choose a form factor from rack-unit count alone. Check installed weight, rail compatibility, service clearance, cable space, power connectors, inlet conditions, and the exact configuration's heat output.

Treat the rack as an operating boundary

A rack provides mechanical support, power distribution, network attachment, airflow paths, grounding, and service access. Its usable capacity is the lowest remaining limit across those resources.

usable rack capacity = constrained by
space, weight, power, cooling, ports, cabling, and service access

Power distribution units deliver power inside the rack. Uninterruptible power systems and facility power equipment may support the upstream path. Redundancy only works when nominally redundant server supplies connect through independent paths where the design requires them.

Cooling depends on the full airflow path. Air-cooled equipment usually draws conditioned air at its inlet and rejects warmer air at its exhaust. Missing blanking panels, blocked intakes, cable obstructions, or mixed airflow directions can send hot exhaust back to an inlet. ASHRAE distinguishes recommended environmental ranges for efficient, reliable operation from wider allowable ranges used to describe functional limits.

High-density equipment can require liquid cooling at the rack or inside the equipment. Liquid cooling changes the interfaces, maintenance procedures, leak controls, and facility support that the deployment needs. It does not remove the need to account for heat.

Connect compute, storage, and network hardware

Data center storage can be local to a server or provided by dedicated storage systems. Local storage can reduce the number of external dependencies. Shared or networked storage can centralize capacity and data services. The correct choice depends on latency, availability, scaling, and operational requirements.

Network switches connect servers, storage, management controllers, and upstream networks. A top-of-rack switch commonly aggregates server connections inside a rack. The physical design must include port count, transceiver type, cable type, reach, airflow direction, power, and redundant paths. A fast switch does not fix an undersized server adapter or an oversubscribed upstream design.

PCI Express is a common internal expansion interconnect. Its generation, lane count, slot wiring, and processor attachment affect the bandwidth available to network adapters, storage devices, and accelerators. A card that physically fits may still receive fewer lanes, share bandwidth, or lack firmware support.

Manage hardware outside the operating system

Server management must work when the host operating system is absent or unhealthy. A baseboard management controller, or BMC, commonly monitors hardware and provides out-of-band control through a separate management path. DMTF Redfish defines a model-oriented, RESTful management standard that can represent systems, chassis, managers, sensors, power, and other resources.

Out-of-band access provides privileged administrative control. Isolate the management network, restrict identities, protect credentials, update firmware, and record changes. A management controller is a computer with its own firmware and network exposure, not a passive sensor.

UEFI defines an interface between platform firmware and the operating system. Firmware compatibility belongs in hardware planning because it affects initialization, boot, device discovery, and updates. Record the server model, board revision, device firmware, BMC firmware, and configuration baseline for each deployed system.

Design for failure and service

Redundant parts are useful only when they cover a defined failure and are tested as a system.

Design choice	Failure it may cover	Boundary to check
Two power supplies	One supply failure	Independent feeds and upstream distribution
Multiple network ports	One port, cable, or adapter path	Switches, routing, bonding, and application behavior
Mirrored local drives	One drive failure	Controller, backplane, rebuild load, and backup
Hot-swappable part	Replacement without powering down	Supported procedure and remaining redundancy
Spare server capacity	One host loss	Placement, orchestration, data access, and restart time

Redundancy is not backup. Mirrored drives can reproduce deletion or corruption. Redundant power supplies do not help when both connect to one failed power path. Hot-swap capability does not guarantee that an application remains available during the replacement.

Serviceability affects recovery time. Check whether technicians can identify, isolate, remove, and replace a failed part without disturbing nearby equipment. Labels, cable management, inventory, compatible spares, firmware baselines, and tested procedures are part of the hardware system.

Use a disciplined selection process

Describe the workload, service target, and growth horizon.
Set requirements for compute, memory, storage, network, acceleration, and management.
Identify facility constraints for rack space, weight, power, cooling, cabling, and service access.
Build a complete bill of materials, including rails, power cords, adapters, transceivers, cables, and licenses tied to hardware operation.
Validate component, firmware, operating-system, and rack compatibility.
Test a representative configuration under load and failure conditions.
Measure power, thermals, performance, and error behavior.
Document the accepted configuration and deployment procedure.
Monitor health and capacity after installation.
Plan replacement, secure data removal, and decommissioning before the equipment reaches end of service.

Know the limits of this course

This course gives you a system-level map. It does not replace electrical design, mechanical engineering, vendor service manuals, safety procedures, or workload benchmarking. Exact voltage, current, weight, temperature, torque, cable, and service limits come from the facility and equipment documentation for your configuration.