Blockstor speaks the LINSTOR REST API, so the clients you already run keep working unchanged: linstor-csi, piraeus-operator, ha-controller, golinstor and the linstor command. What changes is underneath. There is no database to back up, no in-memory state to lose on a restart, and no controller polling nodes.
From a pool to a replicated volume
Register the storage once, describe the placement policy once, and every volume spawned from the group gets the same replication.
# a thin pool on each node becomes a storage pool named "data"
$ blockstor storage-pool create lvmthin worker-1 data my_vg/my_thinpool
# the group holds the policy: two replicas, placed from “data”
$ blockstor resource-group create replicated –place-count 2 –storage-pool data
$ blockstor volume-group create replicated
# one line per volume
$ blockstor resource-group spawn replicated my-volume 10G
$ blockstor resource list
- Register the storageA storage pool points at an LVM volume group, a thin pool or a ZFS pool on a node. Blockstor can also build one from a raw disk.
- Describe the policyA resource group says how many replicas a volume gets, from which pools, and how they spread across nodes and zones.
- Spawn volumes, or let CSI do itEach spawn creates a definition that the controller places and the satellites bring up as DRBD replicas. A StorageClass does the same for every PersistentVolumeClaim.
Why blockstor
The same storage stack as LINSTOR and Piraeus, with the control plane rebuilt on Kubernetes primitives.
Kubernetes-native state
Nodes, pools, definitions, replicas and snapshots are custom resources with printer columns. Each satellite watches the slice for its own node and reports what it sees through Status. Back it up, diff it and drive it from GitOps like any other object.
Drop-in for the LINSTOR ecosystem
The REST API matches the LINSTOR wire shape, verified against golinstor. CSI, the HA controller and existing runbooks carry over. A running LINSTOR cluster can be taken over in place, without copying data.
Small footprint
Three statically linked Go services and a kernel module. No JVM, no external database, no controller-to-node protocol. Multi-arch images for linux/amd64 and linux/arm64 fit edge clusters and small ARM nodes.
The features you expect
Replicas on LVM, LVM-thin, ZFS and file backends. Automatic placement with zones and node constraints, tiebreakers and quorum, LUKS encryption, online resize, snapshots, clones and restores, and mutual TLS on the API.
Find your way
Pick the page that matches what you are doing.
Quickstart
From an empty cluster to a replicated PersistentVolumeClaim.
Start hereInstallation
Requirements, the manifests, registering nodes and storage pools.
InstallArchitecture
How the apiserver, the controller and the satellites share the work.
UnderstandComing from LINSTOR
Take over an existing cluster in place and what differs afterwards.
MigrateUsing the CLI
Nodes, pools, volumes and snapshots from the blockstor command.
Developer guide
Build it, run the test tiers, and find your way around the code.
ContributeBlockstor is built to become an independent project, but today it is developed as part of Cozystack.
Cozystack is a Cloud Native Computing Foundation Sandbox project
Acknowledgements
Blockstor was inspired by LINBIT's LINSTOR, and it operates DRBD to provide block-level replication. It deliberately speaks LINSTOR's API so that the ecosystem the LINSTOR community has built keeps working unchanged. Heartfelt thanks to LINBIT and to the wider DRBD, LINSTOR and Piraeus community.
Blockstor is licensed under Apache 2.0. LINSTOR, LINBIT and DRBD are trademarks or registered trademarks of LINBIT. Blockstor is an independent project and is not affiliated with, endorsed by, or sponsored by LINBIT.