> ## Documentation Index
> Fetch the complete documentation index at: https://docs.akua.dev/llms.txt
> Use this file to discover all available pages before exploring further.
# Piraeus (LINSTOR)
> Replicated block storage across multiple nodes for production workloads
Piraeus is a production-grade storage solution built on LINSTOR and DRBD. It replicates data across multiple worker nodes, so if a node fails, your applications continue running on another node with a complete copy of their data.
## When to use
* **Production workloads**: databases, message queues, and any application where data loss is unacceptable
* **Multi-node clusters**: two or more worker nodes for meaningful replication
* **High availability**: applications that need to survive node failures without downtime
## How it works
Piraeus runs a storage controller and satellite agents on your worker nodes. When an application requests a volume:
1. LINSTOR creates a block device and replicates it across multiple nodes
2. DRBD keeps replicas synchronized in real time at the kernel level
3. If the primary node fails, Kubernetes reschedules the pod to a node with an up-to-date replica
4. The application resumes with all its data intact, with no manual recovery needed
**Key characteristics:**
* Configurable replication (synchronous by default, with asynchronous options for performance-sensitive workloads)
* Automatic failover: pods reschedule to healthy nodes with existing replicas
* Volume snapshots and cloning for backup and testing
* Thin provisioning: storage is allocated on demand, not reserved upfront
## Replication modes
DRBD supports three replication protocols that control when a write is considered complete:
| Protocol | Mode | Write confirmed when | Best for |
| -------------- | ---------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------------------------ |
| **Protocol C** | Synchronous | Local **and** remote disk writes complete | Most workloads; strongest data safety (default) |
| **Protocol B** | Semi-synchronous | Local disk write completes and data reaches the peer node's memory | Faster writes with near-synchronous safety |
| **Protocol A** | Asynchronous | Local disk write completes and data is placed in the send buffer | Maximum write performance, useful for long-distance replication or disaster recovery |
**Protocol C** (synchronous) is the default and the right choice for most production workloads. Every write is confirmed on both nodes before your application proceeds, so no data is lost if a node fails.
**Protocol A** (asynchronous) gives you significantly faster write performance because the application doesn't wait for the remote node to confirm. The trade-off is that a small window of recent writes could be lost if the primary node fails before the data reaches the replica. This mode is commonly used for disaster recovery across data centers where the network latency of synchronous replication would be too high.
## Deploy
Navigate to your cluster's **Storage** tab, click **Deploy Storage**, and select **Piraeus (LINSTOR)**. Deployment takes a few minutes as Piraeus installs its controller and satellite components on each worker node.
After deployment, a default StorageClass is created. Any application requesting a PersistentVolumeClaim will get a replicated volume distributed across your nodes.
## Worker node storage
Piraeus uses the local disks on your worker nodes for storage. When choosing servers for a cluster with Piraeus:
* **Disk space**: each node contributes its local disk to the storage pool. More disk space per node means more total storage capacity.
* **Disk type**: NVMe SSDs provide the best performance for database workloads. Standard SSDs work well for most applications.
* **Number of nodes**: at least two for meaningful replication, three for full redundancy (data survives any single node failure).
Using your worker nodes' local disks is the most straightforward and cost-effective approach. You avoid provisioning separate cloud volumes, and Piraeus handles replication automatically. This works well for most workloads: production-grade durability without extra infrastructure costs.
## Cloud provider CSI drivers
If your worker nodes run on a cloud provider with its own block storage (Hetzner Cloud Volumes, AWS EBS, etc.), you have a choice:
* **Piraeus with local disks**: simpler setup, no cloud-specific dependencies, replication handled by DRBD. Your data is replicated across nodes regardless of the underlying cloud provider.
* **Cloud CSI driver**: uses the cloud provider's managed block storage. The cloud provider handles durability and snapshots, but you pay per volume and are tied to that provider.
Both approaches are valid. Piraeus with local disks is provider-agnostic and keeps your infrastructure portable. A cloud CSI driver may be preferable if you want cloud-managed snapshots or your provider offers specialized storage tiers.
Akua's built-in Piraeus deployment works on any cluster: managed or imported, any cloud provider or bare metal. You don't need to choose a storage strategy based on your infrastructure provider.
## Related topics
Direct local disk storage for development and latency-sensitive workloads.
Compare storage providers and deploy to your cluster.
Connect compute capacity to provide local disk for Piraeus.
Project source and upstream documentation.