Skip to content

Longhorn

Cloud-native distributed block storage for Kubernetes — CNCF Incubating, lightweight, Kubernetes-native.

Overview

Longhorn is a lightweight, Kubernetes-native distributed block storage system by SUSE/Rancher. It provides per-volume replicated storage using a microservices architecture where each volume gets its own dedicated storage controller. It integrates via CSI, supports incremental snapshots and S3 backups, and is the simplest distributed storage to deploy on K8s.

Key Facts

Attribute Detail
Repository github.com/longhorn/longhorn
Stars ~6k+ ⭐
Latest Version v1.11.1 (April 2026)
Language Go, C++ (engine)
License Apache 2.0
Governance CNCF Incubating
Company SUSE / Rancher

Evaluation

Pros Cons
Simplest K8s distributed storage Not suitable for large-scale (100+ node) clusters
Per-volume engine — fine-grained control Performance lower than Ceph for heavy workloads
Incremental snapshots + S3 backups V2 Data Engine (SPDK) still in tech preview
Non-disruptive upgrades No object or file storage (block only)
Intuitive dashboard UI Each volume runs its own engine process
CNCF Incubating, active community
Disaster recovery built-in

Architecture

flowchart TB
    subgraph K8sCluster["Kubernetes Cluster"]
        subgraph Node1["Node 1"]
            LM1["Longhorn Manager\n(DaemonSet)"]
            E1["Engine\n(volume controller)"]
            R1["Replica 1"]
        end
        subgraph Node2["Node 2"]
            LM2["Longhorn Manager"]
            R2["Replica 2"]
        end
        subgraph Node3["Node 3"]
            LM3["Longhorn Manager"]
            R3["Replica 3"]
        end
        CSI["CSI Driver"]
    end

    Pod["Pod + PVC"] --> CSI --> E1
    E1 -->|"sync replicate"| R1
    E1 -->|"sync replicate"| R2
    E1 -->|"sync replicate"| R3

    style K8sCluster fill:#2e7d32,color:#fff

Key Features

Feature Detail
Synchronous replication 2–3 replicas across nodes
Incremental snapshots Point-in-time recovery
Automated backups To S3 or NFS
Disaster recovery Standby volumes in remote cluster
Non-disruptive upgrades Upgrade without volume disconnection
V2 Data Engine SPDK-based for high-performance (tech preview)
Parallel replica rebuild v1.11: faster recovery

Notes

Sources

Questions

Answered

  • Q: Can Longhorn back up to S3? -- Yes -- native backup target for S3 and NFS.

  • Q: How does the Longhorn Engine differ from a traditional storage controller? -- Longhorn creates a dedicated Engine (storage controller) per volume, not per node. Each Engine is an isolated microservice that handles synchronous replication for exactly one volume. If one Engine fails, only that volume is affected. Traditional storage controllers serve many LUNs/volumes and represent a larger failure domain.

  • Q: What is the difference between V1 and V2 Data Engines? -- V1 uses iSCSI as the frontend and runs engines/replicas as Linux processes. V2 uses SPDK for user-space I/O, operating engines as SPDK RAID bdevs and replicas as SPDK logical volumes. V2 frontends are NVMe-TCP or UBLK. V2 is currently a Technical Preview and does not have full feature parity with V1.

  • Q: How does Longhorn handle replica failure? -- When the Engine detects a replica failure, it marks the replica in error state. The Longhorn Manager creates a blank replica on another node. The Engine pauses I/O, adds the blank replica in write-only mode, takes a system snapshot, resumes I/O, syncs historical data in the background, and finally sets the new replica to read-write mode. The faulty replica is then removed.

  • Q: Does Longhorn support volume encryption? -- Yes. Longhorn supports LUKS/dm-crypt encryption per volume via the CSI driver. Encryption keys are stored as Kubernetes Secrets and referenced by the StorageClass. Both Filesystem and Block volume modes are supported. Backups from encrypted volumes are also encrypted.

  • Q: How do Longhorn backups work? -- Each backup is created from a snapshot and stored as a flattened chain of 2 MB blocks in an external backupstore (S3 or NFS). Backups are incremental at the block level: only changed 2 MB blocks are transmitted. Blocks are shared across backups of the same volume using checksums for deduplication.

  • Q: What is a Disaster Recovery (DR) volume? -- A DR volume is a special volume in a backup cluster that incrementally restores data from a primary cluster's backups. It does not support snapshots, backups, or PVC binding until activated. When the primary cluster fails, the DR volume is activated and becomes a normal Longhorn volume, reducing RTO compared to a full restore.

  • Q: How does Longhorn provide ReadWriteMany (RWX) access? -- Longhorn deploys a Share Manager pod per RWX volume that runs an NFS server backed by the Longhorn volume. The NFS export is exposed via a Kubernetes Service, and the CSI driver mounts the NFS share into requesting Pods. RWX does not support Block mode.

  • Q: What is the read index and why does it matter? -- The read index is an in-memory byte array (one byte per 4 KB block) that tracks which snapshot layer holds the most recent data for each block of a replica. It avoids scanning the entire snapshot chain on every read. A 1 TB volume consumes approximately 256 MB of read index memory per replica.

  • Q: Is Longhorn crash-consistent or application-consistent? -- Longhorn is crash-consistent. It runs sync before creating snapshots, but OS-level caches may contain unflushed data at crash time. Application-consistent backups require application-level quiescing (for example, using pre/post snapshot hooks) before the snapshot is taken.

Open

  • Q: What are the scaling limits of Longhorn in practice (beyond 100 nodes)? -- Longhorn is described as not suitable for large-scale (100+ node) clusters. Need to identify the specific bottleneck (Instance Manager overhead, replica rebuild time, Manager API throughput) and whether V2 Data Engine changes the equation.

  • Q: When will V2 Data Engine reach GA? -- V2 (SPDK-based) is currently Technical Preview in v1.12. The feature parity gap with V1 needs to close first. Track the official feature parity wiki for updates.

  • Q: How does Longhorn performance compare to Ceph RBD for database workloads? -- The index notes that Longhorn has lower performance than Ceph for heavy workloads. Need specific benchmarks for PostgreSQL/MySQL on Longhorn V1 vs Ceph RBD with comparable hardware.