Longhorn vs Rook-Ceph: Kubernetes-storage vergeleken

TL;DR Longhorn en Rook-Ceph geven je allebei gerepliceerde block storage die een dode node overleeft. Longhorn is één Helm-install en een UI waarin je ziet wat een volume doet. Rook-Ceph is Ceph met een Kubernetes-operator eromheen, dus je krijgt block, object én filesystem, en het beheer dat daarbij hoort. Ik draai Longhorn op drie nodes. Hieronder waarom, en wanneer ik zou overstappen.

Draai je eerste stateful workload op een self-hosted cluster en je merkt al snel dat niemand je zomaar een PersistentVolume geeft. Geen storage class van een cloudprovider om op te leunen. Alleen je nodes, hun disks en een Postgres-pod die niet wil schedulen. Een uur lezen verder heb je twee namen over die steeds terugkomen. Longhorn en Rook-Ceph .

Ik heb ze allebei in productie gedraaid, en ik zeg maar meteen dat ik op kleine clusters standaard Longhorn kies. Waarom komt verderop, maar je mag het alvast weten terwijl je leest. Beide zijn CNCF -projecten, beide repliceren block storage over je nodes zodat een dode node je data niet meeneemt, en beide zijn goede software. Waar ze het over oneens zijn is hoeveel complexiteit je erbij moet nemen.

Waar je tussen kiest

Longhorn is gedistribueerde block storage die vanaf dag één voor Kubernetes is geschreven. Elk volume wordt over je nodes gerepliceerd met gewone Linux-storageprimitieven, en er zit geen apart storagesysteem onder dat je eerst zou moeten leren.

Rook-Ceph is een Kubernetes-operator om Ceph heen. Ceph is een gedistribueerd storagesysteem dat jaren ouder is dan Kubernetes, bij CERN petabytes draait en z’n hele featureset meebrengt. Block, object, filesystem, erasure coding, alles. Rook leert Kubernetes hoe je dat bestuurt.

Het meeste van wat volgt komt uit dat leeftijdsverschil. Longhorn is in je cluster geboren. Ceph is ergens anders vandaan komen inwonen en heeft alles meegenomen wat het bezat. Een deel daarvan ga je gebruiken. De rest moet je toch draaien.

Vier dingen die de doorslag geven

Een featurelijst helpt je hier niet, want beide tools vinken de meeste vakjes af. Wat telt is hoe het is om het te draaien. Ik weeg vier dingen. Hoeveel beheer ik erbij krijg. Hoe het zich gedraagt als een node sterft, want dit is storage en dat is het hele werk. Hoeveel RAM en CPU het van me wil. En hoe ver het schaalt voordat het lastig wordt. Performance telt ook, maar voor de meeste homelab- en kleine-productieworkloads geeft het niet de doorslag, dus dat komt later.

Longhorn: degene die in je cluster woont

Hoe Longhorn werkt

Het model past in je hoofd, en dat is het grootste deel van de charme. Elke PVC krijgt z’n eigen Longhorn-engine, die als pod draait. Die engine schrijft je data naar replica’s op de lokale disks van meerdere nodes, en hij schrijft synchroon, dus er wordt niks bevestigd tot elke replica het heeft. De workload praat met z’n volume over iSCSI, dat de engine aanbiedt.

Wil ik weten wat een volume doet, dan open ik de Longhorn-UI en kijk ik. Welke replica’s gezond zijn, waar ze staan, of er een rebuild loopt. Geen black box. Zo wil ik infrastructuur draaien, zoals ik in Sovereign Infrastructure schreef. Ik moet snappen wat ik draai, en bij Longhorn kan dat.

Longhorn installeren

helm repo add longhorn https://charts.longhorn.io
helm repo update

helm install longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --create-namespace

Basisconfiguratie:

# longhorn-values.yaml
defaultSettings:
  defaultReplicaCount: 3
  defaultDataPath: /var/lib/longhorn
  storageMinimalAvailablePercentage: 15
  defaultLonghornStaticStorageClass: longhorn

persistence:
  defaultClass: true
  defaultClassReplicaCount: 3

Wat Longhorn goed doet

Helm install, en je hebt storage. Geen dedicated storage-nodes, geen pooltopologie die je eerst moet ontwerpen. De ingebouwde web-UI laat volumes, backupstatus en node-health zien zonder dat je iets hoeft aan te sluiten. Backups gaan rechtstreeks naar S3-compatible storage als incrementele snapshots, wat bij mij betekent dat ik hem op m’n eigen MinIO richt en er niet meer aan denk. En er zit geen ouder systeem onder dat is aangepast, dus niks wat je tegenkomt is er om historische redenen.

Waar Longhorn tekortschiet

De grenzen zijn makkelijk op te noemen. Longhorn is prima voor de workloads die de meesten van ons draaien, maar het is niet gebouwd voor extreme IOPS, want al het verkeer van een volume gaat door z’n eigen engine-pod en die pod is het plafond. Tot ongeveer 100 nodes werkt het goed, daarboven wordt het lastig. En elke replica is een volledige kopie, dus drie replica’s is drie keer de ruwe capaciteit. Erasure coding om dat te verzachten is er niet.

Rook-Ceph: degene die is komen inwonen

Hoe Rook-Ceph werkt

Het model van Ceph is slim, en die slimheid is precies waarom er meer te leren valt. Elke disk wordt een OSD, een Object Storage Daemon. Data spreidt over die OSD’s via het CRUSH-algoritme en placement rules die jij schrijft, dus Ceph bepaalt op basis van je failure domains waar elk stuk data staat, in plaats van round-robin. Daarbovenop krijg je drie ingangen. Block via RBD, S3-compatible object storage via RGW en een echt filesystem via CephFS. Wat het geheel bij elkaar houdt is een quorum van monitor-daemons dat de cluster-state bijhoudt.

Elk van die onderdelen kun je inspecteren, en dat vind ik fijn. Elk ervan moet je ook snappen, de eerste keer dat het zich misdraagt.

Rook-Ceph installeren

helm repo add rook-release https://charts.rook.io/release
helm repo update

# Installeer Rook operator
helm install rook-ceph rook-release/rook-ceph \
  --namespace rook-ceph \
  --create-namespace

# Maak Ceph cluster
kubectl apply -f ceph-cluster.yaml

Clusterconfiguratie:

# ceph-cluster.yaml
apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
  name: rook-ceph
  namespace: rook-ceph
spec:
  cephVersion:
    image: quay.io/ceph/ceph:v18.2.0

  mon:
    count: 3
    allowMultiplePerNode: false

  mgr:
    count: 2

  storage:
    useAllNodes: true
    useAllDevices: false
    deviceFilter: "^sd[b-z]"  # Gebruik sdb, sdc, etc.

  resources:
    mon:
      requests:
        cpu: 500m
        memory: 1Gi
    osd:
      requests:
        cpu: 500m
        memory: 2Gi

Wat Ceph goed doet

Hier betaalt het extra gewicht zich terug. Ceph draait petabytes, de schaal waarop CERN en Bloomberg het gebruiken, dus je groeit er niet uit. Block, object en filesystem uit één systeem, plus erasure coding, snapshots en cross-cluster mirroring. Er valt enorm veel te tunen, dus een team dat Ceph kent kan het naar een workload vormen. En erasure coding snijdt in de overhead. In plaats van 3x te betalen voor replicatie kom je dichter bij 1.5x, en op grote capaciteit is dat echt geld.

Wat Ceph je kost

Dezelfde kracht kost dezelfde moeite. Veel meer bewegende delen, en monitors, managers en OSD’s willen allemaal resources en aandacht. Voordat je één byte hebt opgeslagen draai je al drie monitors, twee managers en je OSD’s, en het geheugen dat die pakken is niet niks. Ceph draagt decennia aan features en configuratie mee, dus de leercurve is steil en vlakt niet snel af. Voor echte performance eindig je vaak met nodes die alleen OSD’s draaien, hardware die je apart hebt gezet voor storage en verder niks. Een fout vind ik dat allemaal niet. Dat is wat Ceph rekent voor wat het je geeft, en die prijs is alleen zinnig als je gebruikt wat je hebt gekocht.

Naast elkaar

De tabel is handig voor een snelle blik, maar de beslissing zit in de rijen die je voelt. Voor mij zijn dat resource overhead en complexiteit, want die betaal ik elke dag dat het cluster draait, en setuptijd maar één keer.

Wanneer Longhorn de juiste keuze is

Pak Longhorn als je situatie er zo uitziet:

1. Kleine tot middelgrote clusters (onder 100 nodes)
2. Eenvoud telt en je storage wilt die gewoon werkt
3. Beperkte ops-capaciteit, een klein team dat z’n tijd niet kwijt kan aan het babysitten van storage
4. Algemene workloads zoals databases en stateful apps met gematigde I/O
5. Homelab of edge waar resources krap zijn

# Typische Longhorn workload
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-data
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn
  resources:
    requests:
      storage: 100Gi

Wanneer Rook-Ceph de moeite waard is

Pak Rook-Ceph wanneer:

1. Grote clusters (100+ nodes)
2. Meerdere storagetypes nodig, block EN object EN filesystem uit één systeem
3. Performance kritiek en je voor specifieke workloads moet tunen
4. Storage-efficiëntie telt en erasure coding je echt capaciteit bespaart
5. Dedicated storageteam, mensen die Ceph kunnen leren en goed kunnen draaien

Dat laatste punt slaan mensen over. Ceph beloont een team dat het kent en straft een team dat het niet kent, en als niemand in het team de storage bezit, leert de eerste die Ceph echt gaat snappen dat tijdens een storing.

# Rook-Ceph met erasure coding
apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
  name: replicated-pool
  namespace: rook-ceph
spec:
  failureDomain: host
  replicated:
    size: 3
---
apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
  name: erasure-coded-pool
  namespace: rook-ceph
spec:
  failureDomain: host
  erasureCoded:
    dataChunks: 2
    codingChunks: 1

Performance, het criterium dat ik parkeerde

Die had ik eerder geparkeerd, en dit is waarom het zelden iets beslist. Voor de workloads die de meeste mensen draaien zijn beide snel genoeg. Het verschil zie je pas aan de randen.

Longhorn onder belasting

# Tune replica count voor performance vs durability
defaultSettings:
  defaultReplicaCount: 2  # Sneller dan 3, minder durable

# Gebruik dedicated disk pad
defaultDataPath: /mnt/fast-ssd/longhorn

Longhorn is I/O-bound door die engine-pod per volume. Duw er een high-IOPS-workload doorheen en de engine is je bottleneck. Dat is de ruil die je doet voor de simpele architectuur.

Rook-Ceph onder belasting

# Dedicated OSD nodes
spec:
  placement:
    osd:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
            - matchExpressions:
                - key: storage-node
                  operator: In
                  values:
                    - "true"

# NVMe optimalisatie
storage:
  config:
    osdsPerDevice: "1"
    storeType: bluestore

Ceph kan moderne NVMe-drives volledig benutten als het goed geconfigureerd is. “Als het goed geconfigureerd is” doet in die zin veel werk, en daar komen is precies het werk waarvoor je hebt getekend.

Backups

Backups wegen bij mij zwaarder dan ruwe throughput, want storage waar je niet van kunt restoren raakt ooit data kwijt en je weet niet wanneer.

Longhorn-backups

Ingebouwd. Configureer een S3-target:

defaultSettings:
  backupTarget: s3://longhorn-backups@us-east-1/
  backupTargetCredentialSecret: longhorn-s3-credentials

Plan backups per volume:

apiVersion: longhorn.io/v1beta1
kind: RecurringJob
metadata:
  name: daily-backup
spec:
  cron: "0 2 * * *"
  task: backup
  groups:
    - default
  retain: 7

Rook-Ceph-backups

Een ingebouwd equivalent is er niet, dus je grijpt naar Velero met Ceph CSI -snapshots:

velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-csi \
  --features=EnableCSI

Of native Ceph-mirroring voor disaster recovery tussen clusters, wat fijn is zodra je op de schaal zit waar een tweede cluster bestaat.

Drie nodes, dus Longhorn

Bovenaan zei ik dat ik standaard Longhorn kies. Ik draai Longhorn in m’n homelab, en dit is de configuratie:

# Mijn Longhorn configuratie
defaultSettings:
  defaultReplicaCount: 2  # 3 nodes, 2 replica's
  defaultDataPath: /mnt/storage/longhorn
  backupTarget: s3://backups@minio/longhorn/
  backupTargetCredentialSecret: minio-credentials
  storageMinimalAvailablePercentage: 20

persistence:
  defaultClass: true

Drie nodes, dat is het beslissende feit. Te klein om de overhead van Ceph te dragen, want de monitors en managers alleen al zouden capaciteit opeten die ik niet kan missen. Misdraagt een volume zich, dan open ik de Longhorn-UI en lees ik wat er mis is. Bij Ceph zou ik door de internals bladeren om te bedenken welke daemon wat doet, en dat heb ik al vaak genoeg gedaan. Backups landen in m’n eigen MinIO over S3, en op kleine nodes blijft elke vrije MB vrij.

De dag dat ik 50-plus nodes draai, of object storage naast block nodig heb, stap ik over naar Ceph en betaal ik de complexiteit met plezier, want dan gebruik ik waar ik voor betaal. Die dag is er nog niet. Bij jou kan hij een stuk dichterbij liggen. Heb je het team en de schaal, kies dan Ceph en laat je niet door m’n drie nodes ompraten.

Later migreren als je Longhorn ontgroeit

Begin je op Longhorn en ben je bang dat je jezelf klemzet? Dat doe je niet. De weg eruit is saai, en saaier kun je een migratie niet wensen:

1. Backup de data van het Longhorn-volume
2. Deploy Rook-Ceph ernaast
3. Restore naar Ceph-volumes
4. Update workloads naar de nieuwe StorageClass
5. Retire Longhorn zodra alles verhuisd is

Beide spreken CSI, dus je workloads zien hoe dan ook dezelfde interface. Je verandert een StorageClass en je bent klaar.

Kies de complexiteit die je kunt dragen

Storage is het deel van Kubernetes dat fouten het hardst afstraft. Doe je het verkeerd, dan verlies je data, en dat is de ene fout die je niet kunt terugdraaien. Bouw je te groot, dan besteed je je weken aan complexiteit die je nooit nodig had.

Zet het naast je schaal en het antwoord rolt er meestal vanzelf uit. Homelab en kleine clusters wijzen naar Longhorn. Middelgrote productie kan beide kanten op, afhankelijk van of je die extra Ceph-features zou gebruiken. Grote schaal wijst naar Ceph. Allebei solide software. Wat ze scheidt is hoeveel beheer je wilt dragen, en dat weet alleen jij voor je eigen cluster.

Bij mij is het drie nodes en Longhorn, en het overleeft een dode node, want daar heb ik het voor gebouwd. Groeit het daar overheen, dan zijn de vijf stappen hierboven het hele plan.

• Infrastructure
• Architecture