Why We Chose LINSTOR for Distributed Storage

Storage in Kubernetes is one of those things that sounds simple until you actually try to do it.

You need your data to survive pod restarts. You probably want it replicated across nodes so you don't lose everything when a disk dies. And you definitely want it to be fast.

Getting all three? That's where most teams start pulling their hair out.

A quick history of DRBD

Before we talk about LINSTOR, you need to know about DRBD. It stands for Distributed Replicated Block Device, and it's been around since 2000.

The concept is straightforward: take a block device on one machine and replicate it, byte for byte, to another machine over the network. Think of it like RAID 1 (disk mirroring), but across servers instead of disks in the same box.

DRBD was created by LINBIT, an Austrian company that's been doing distributed storage since before Kubernetes even existed. The project got merged into the Linux kernel mainline back in 2010 (kernel 2.6.33). That's a big deal. It means DRBD is literally part of Linux itself.

And because it operates at the kernel level, it's fast. Really fast. We're talking near-native disk performance. Your application reads and writes to what looks like a normal block device, and DRBD handles the replication behind the scenes with minimal overhead.

For over two decades, DRBD has been used in production by banks, hospitals, telecoms, and basically anyone who needed data replicated between machines without sacrificing speed. It's one of those technologies that quietly powers critical infrastructure everywhere.

So what's LINSTOR?

DRBD gives you the fast replication. But managing DRBD resources across a whole Kubernetes cluster? That used to require a lot of manual configuration.

LINSTOR is the management layer that LINBIT built on top of DRBD. It provides an API and a CSI (Container Storage Interface) driver that plugs directly into Kubernetes. You get all the speed of DRBD with proper orchestration, volume provisioning, snapshots, and the kind of storage management that Kubernetes expects.

In short: DRBD is the engine, LINSTOR is the dashboard and controls.

Why LINSTOR is faster than Longhorn

If you've been in the Kubernetes storage world, you've probably heard of Longhorn. It was the default distributed storage option in the Rancher ecosystem for years. It works. But it's slow compared to LINSTOR.

Here's why:

• Kernel vs. userspace: DRBD replicates at the kernel level. Longhorn runs entirely in userspace and uses iSCSI targets to expose volumes. That extra layer adds latency on every single I/O operation
• Protocol overhead: DRBD's replication protocol is purpose-built and has been optimized for 25+ years. It does one thing and does it incredibly well
• Lower CPU usage: Because DRBD runs in kernel space, it uses fewer CPU cycles per I/O operation. Longhorn's userspace architecture burns more compute on the same workload
• Proven at scale: DRBD has been running in production for over two decades. The edge cases have been found and fixed. Longhorn is newer and still maturing

For a database like PostgreSQL or ClickHouse where every millisecond of I/O latency matters, that difference is huge. We're not talking about marginal gains here. LINSTOR can deliver significantly lower latency and higher IOPS than Longhorn on the same hardware.

The Rancher ecosystem agrees

SUSE (the company behind Rancher) acquired LINBIT. So now DRBD, LINSTOR, and Rancher are all under the same roof.

And SUSE is putting its weight behind LINSTOR. It's becoming the primary distributed storage option in the Rancher ecosystem, and Longhorn is being phased out as the recommended choice for network-replicated storage.

That tells you something. When the company that built Longhorn decides to go all-in on LINSTOR instead, the performance difference is real.

How RunOS handles storage

We give you two storage options, each designed for a specific job:

• OpenEBS (local storage): When you need the absolute fastest performance possible. Your data lives on the same node as your workload. No network overhead. Maximum speed. Perfect for single-node databases or caches where raw performance matters most
• LINSTOR (distributed storage): When you need your data replicated across nodes. Your data survives node failures. DRBD handles the replication at kernel level, so you get distributed storage that's about as fast as distributed storage can get

You pick which one you want when deploying any stateful application. Database, message queue, object store, whatever it is. You choose the storage that fits your needs.

Storage groups: hot, cold, and everything in between

This is where it gets really useful.

Not all nodes in your cluster are the same. Maybe some have NVMe SSDs. Maybe others have large spinning disks. Maybe you've got a few machines with massive storage capacity that you keep around for archives and backups.

With RunOS, you can organize your nodes into storage groups. The management interface is built right into the RunOS console, tightly coupled with everything else.

For example:

• Hot storage: A group of nodes with fast NVMe drives. Your production databases go here. PostgreSQL, ClickHouse, Valkey, anything latency-sensitive
• Cold storage: A group of nodes with large, cheaper drives. Backups, logs, archives, data you access less frequently but still need available
• Local storage: Still an option when you want maximum single-node performance with no replication overhead at all

When you deploy an application or spin up a service, you just pick which storage group it should use. That's it. RunOS puts your data where you told it to go.

Want to move your analytics database to cold storage because it doesn't need NVMe speeds? Change the storage group. Want your primary PostgreSQL instance on the fastest drives you have? Put it in the hot group.

You're in control of where your data lives, without having to think about the underlying DRBD configuration, storage pools, or resource groups. RunOS handles that.

Why we went with LINSTOR

Speed and maturity. That's what it comes down to.

DRBD has been doing kernel-level block replication since before most of us were writing Kubernetes manifests. It's proven technology. LINSTOR puts a modern management layer on top of it. And with SUSE backing it as the future of distributed storage in the Rancher world, the ecosystem support is only going to get stronger.

For a platform like RunOS, where we want to give you real infrastructure that just works, LINSTOR was the obvious pick. The speed is there. The reliability is there. And the hard work of managing DRBD across a cluster? That's traditionally been a pain for smaller teams to handle. Resource definitions, storage pools, replication policies, failover configuration. It adds up fast.

RunOS does all of that in the background. You get the performance of DRBD without having to become a DRBD expert. Create your storage groups, pick your storage class when deploying, and let the platform handle the rest.

Storage shouldn't be the hard part

You've got apps to build. Services to ship. Users to keep happy.

Storage should be a decision you make once and then forget about. Pick local for raw speed. Pick distributed for resilience. Organize your nodes into groups that make sense for your workload. Deploy your stuff.

That's how it should work. And with LINSTOR and OpenEBS under the hood, that's exactly how it works on RunOS.

Fast storage. Smart replication. Your infrastructure, your rules.