What can you run on an OpenSFF cluster?

Introduction

In a previous article, we recommended operating systems for Compute Nodes to demonstrate the module’s flexibility. While we already touched on hypervisors and container orchestrators in that article, we want to take a closer look at what it would be like to use an OpenSFF-compatible system at a chassis level. We will go over our recommendations for cluster platforms as well as your networking and storage options.

Why use a cluster platform?

Few applications these days are built to cluster themselves. A typical service cannot detect a dead peer, reschedule itself onto a healthy node, then keep serving traffic through the failure. Container orchestrators, hypervisors, and hyperconverged infrastructure (HCI) platforms provide resilience for their respective packages. But rescheduling a stateless workload is just one part of the task. Storage is trickier and requires constant attention. As with the OS and the cluster platform, our open hardware standard also lets you decide your storage architecture.

Our recommended cluster platforms

Kubernetes

The default choice for container orchestration. If your workloads are already containerized, this will likely be your starting point.

Hypervisors

For VM-based workloads, Proxmox VE and XCP-ng would be our recommendations. These open-source hypervisors are designed to be lightweight. Given our 120W maximum power target per Compute Node, every watt you can spare matters.

Hyper-V on Windows Server might be your best option if you are running Windows-based applications and servers, though you may end up with a licensing model that is more expensive than the enterprise offerings of Proxmox and XCP-ng.

HCI platforms

If you want a turnkey deployment that you can hand over to a managed service provider, we suggest looking into HCI providers. Their service pools compute and storage into one appliance, and they typically let you choose between an on-site or a cloud-hosted arrangement. Our recommendations are Scale Computing for VM-focused workloads, and Tekkio for light deployments that require a mix of VMs and containers.

Networking options with OpenSFF

The Compute Node Specification defines two variants of the module. The Core Compute Node has a Core Connector that provides, among other things, two Ethernet interfaces that must be at least 2.5Gbps. The Enterprise Compute Node has both a Core Connector and an Enterprise Connector, which provides two more Ethernet interfaces that are also rated for at least 2.5Gbps.

Meanwhile, the Enclosure Specification defines a general purpose data network called the Node Network (NN). Compute Nodes use the NN for workload traffic, application communication, external connectivity, and clustering. The specification also defines two Enclosure variants. The Enterprise Enclosure must have a redundant internal switch fabric for the NN, while it is optional in Core Enclosures.

The node’s array of Ethernet interfaces and the Enclosure NN switches give you the option to route client and API traffic through one of the fabrics while dedicating the other to internal traffic, such as failover signaling and storage replication.

Storage options with OpenSFF

As we just mentioned, the physically separate interfaces and switches that our standard defines also provides a path for storage traffic that is isolated from application or user traffic.

Hyperconverged storage

If you want the cluster to manage its own storage, hyperconverged setups pool disks across nodes into a single logical volume, replicating data as it goes. LINBIT’s DRBD is best for small clusters as it is relatively lightweight. Ceph scales further but needs more nodes, RAM, and network bandwidth to rebuild quickly after a failure.

As for the hardware, the Compute Node Specification explicitly states that vendors can choose their implementation’s components, provided they adhere to the stated requirements. Besides 3.5”, 2.5”, and M.2, vendors can also use U.2, U.3, or EDSFF drives as long as their configuration fits within the node’s mechanical envelope and power budget.

In addition, an OpenSFF-compatible Enclosure can also provide its own drive bays. These would connect to Compute Nodes through a SATA or SAS controller attached to the PCIe 4.0 x1 lane on the Core Connector. You will be able to rely on the onboard node storage, the Enclosure-provided bays, or use both as you see fit.

External NAS

If you would rather let a separate appliance handle data replication and resilience, you do have the option to connect an external NAS device to an OpenSFF-compatible system. The nodes would reach the NAS over the Enclosure’s uplinks and use the backend fabric that you would have used for hyperconverged data traffic.

Why use OpenSFF for your cluster

You may be wondering why we are discussing clustering options that you can already do on existing hardware. That is exactly our point: our standard enables you to migrate your software stack from proprietary units to one backed by an open standard. Our modular, interoperable approach means any Compute Node will work with any Enclosure, regardless of their vendors.

If you run your own hardware, this means you will be able to go from a shelf of standalone mini PCs, each with their own power brick, cabling run, and KVM device, to a space-efficient Enclosure where nodes share power, cooling, and networking. We also define the Management Module, an optional, equally vendor-agnostic component that provides KVM redirection and power control for all nodes in an Enclosure.

For HCI providers, our interoperability will allow them to support a wider range of hardware. This is a significant advantage over their typical practice of certifying hardware from only a handful of vendors to ensure that their service runs well on those machines. Our upcoming certification program will instead provide that assurance. By adopting OpenSFF-compatible hardware, providers can simplify their sourcing and inventory rather than being locked into what they can test on their own. We are also developing a fleet management solution to help operators manage OpenSFF-compatible deployments across many sites.

Build with OpenSFF

An OpenSFF-compatible cluster is just as flexible as the nodes within it. Whether you are deploying K8s, a virtualization cluster, or a hyperconverged appliance, OpenSFF provides a common hardware foundation that is more streamlined, scalable, and serviceable than existing options.

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