Exploring Cooling Configurations in OpenSFF Enclosures

Introduction

In our design recommendations for the Compute Node, we emphasized that nodes must have only passive cooling components. The Enclosure will be the one responsible for generating and directing airflow across the node’s thermal solution. This keeps nodes easily replaceable, interoperable, and free of moving parts, while giving Enclosure vendors the freedom to decide how they will provide the necessary airflow.

Since the Enclosure largely defines the purpose of an OpenSFF-compatible system, vendors must also align their implementation’s cooling solution with their Enclosure’s use case. An Enclosure’s size, shape, acceptable noise levels, and intended operating environment will help determine how it generates airflow. There is no single correct way to cool an OpenSFF-compatible system, which is why the Compute Node Specification prescribes cooling targets instead of specific assemblies.

What the Compute Node Specification requires

Enclosures must provide sufficient airflow through a node’s cooling path to satisfy the following thermal requirements, as defined in the Compute Node Specification:

Just as important, an Enclosure’s active cooling system must work with any OpenSFF-compatible Compute Node, regardless of the node’s power target (up to 120W), component layout, or passive thermal solution. Therefore, liquid cooling—including direct-to-chip designs—is a poor fit for our standards. It would generally involve a defined CPU layout, standardized mounting features, and interfaces beyond what the Compute Node Specification defines. A Compute Node that is compatible with a liquid-cooled Enclosure would need matching hardware, which would then make it incompatible with other Enclosure designs.

Beyond that, vendors are free to come up with their own air cooling configuration. As long as they hit the temperature, airflow, and static pressure targets we enumerated, vendors can choose an airflow topology or acoustic target that fits their Enclosure’s use case. Let us go over a few approaches used in existing hardware that can also work in OpenSFF-compatible systems.

Front-to-back

This is the airflow pattern most commonly used in servers. Air enters at the front of the Enclosure, sweeps across the Compute Nodes, and exits out the rear. It is the same layout we see in most NAS devices, rack servers, and other enterprise hardware. This configuration is predictable, familiar to datacenter operators, and easy to duct into existing hot/cold aisle setups. It also scales well with multi-node Enclosures, since the nodes are all in the same airflow path.

Bottom-to-top/rear/side

Apple popularized this approach with its 2012 Mac Pro and more recently with the M4 Mac Mini. A number of mini PCs also take this approach. The system’s fans draw air in from the bottom of the chassis and exhausts out the top or rear. Convection helps generate sufficient airflow even at lower fan speeds, making this approach a great fit for OpenSFF-compatible workstations and appliances that are meant to sit on a desktop rather than a rack.

Ducted blower

Commonly seen in reference-design GPUs, this approach uses a single centrifugal blower to pull air in from the top or bottom of the system. The air is then pushed through a fully enclosed duct across the Compute Node’s thermal solution before exiting through the I/O shield. Because the duct maintains the airflow path, this approach does not depend on the rest of the Enclosure’s internal layout to work correctly. This design also achieves relatively high static pressures compared to regular axial fans in more open layouts. The lone fan lends itself to a compact design, making this approach a good choice for OpenSFF-compatible mini PCs, industrial IoT systems, rugged devices, and any other system that benefits from a self-contained airflow path.

Multiple intakes and exhausts

The prevailing layout in full-sized gaming PC towers. This approach combines intake fans on two or more sides, with exhaust fans positioned on opposing planes accordingly. Beyond aesthetics, this configuration can spread the load across several smaller fans. This combination can be inexpensive, run quietly at lower speeds, and move a lot of air in aggregate. This distributed approach will fit mid-sized OpenSFF-compatible systems that do not have a single major source of heat to design around.

Solid-state active cooling

This is a purely conceptual example involving extremely thin or small coolers that generate airflow without using fans or any moving parts for that matter. Despite the technology’s infancy, we are including it here to demonstrate that the Enclosure Specification does not limit cooling systems to fans. It simply points to the Compute Node Specification’s thermal requirements.

Existing solid-state cooling solutions such as those being developed by Frore Systems, YPlasma, and Ventiva can cool only low-powered systems, mainly on the level of single-board computers. Whether these companies can scale their product or another solution emerges in the future, alternative forms of active cooling may be implemented on OpenSFF-compatible systems.

Build with OpenSFF

We define our thermal requirements to balance flexibility with interoperability. We firmly believe that this will result in significantly more cost-efficient, serviceable, and sustainable systems. An Enclosure designed for a datacenter may prioritize maximum airflow, while one built for industrial environments could focus on withstanding sustained heat amidst dust and other hazardous particles. Designed properly, both Enclosures will still reliably cool the same Compute Node.

We encourage you to read our specifications, and we would be grateful if you spread the word about our open hardware standard. For technical clarifications, partnerships, and other inquiries, reach out to our development team at [email protected].