Storage-Reise, Teil 3: Angekommen bei DRBD & LINSTOR

Nach Ceph (Teil 1) und Vitastor (Teil 2) sind wir bei DRBD und LINSTOR angekommen — und geblieben.

Was DRBD ist

DRBD ist eine shared-nothing, replizierte Storage-Lösung: Sie spiegelt den Inhalt von Block-Devices in Echtzeit zwischen Hosts. Technisch sitzt DRBD als Kernel-Modul ganz unten im I/O-Stack — direkt über dem Backing-Device, transparent für die darüberliegenden Schichten.

• Echtzeit & synchron: Schreibvorgänge gelten erst als abgeschlossen, wenn sie auf allen verbundenen Knoten liegen (synchroner Modus) — oder lokal, bei asynchroner Replikation über Distanz.
• Shared-nothing: kein zentrales SAN, kein Single Point of Failure.
• Quorum & Split-Brain-Handling: definierte Strategien gegen die klassischen HA-Fallen.

LINSTOR als Orchestrierung

Einzelne DRBD-Ressourcen von Hand zu pflegen skaliert nicht. LINSTOR verwaltet die Volumes clusterweit, und das LINSTOR-Proxmox-Plugin bindet das Ganze direkt in Proxmox ein:

drbd: drbdstorage
    resourcegroup defaultpool
    content images,rootdir
    controller 10.11.12.13

Damit lassen sich aktive VMs in Sekunden live migrieren — ohne Downtime und ohne zentrales SAN. Über Resource-Groups wird die Replikat-Anzahl zentral gesetzt.

Betriebs-Tipp

Wenn LVM, DRBD und LINSTOR zusammenspielen, gehört der global_filter in die lvm.conf:

global_filter = [ "r|^/dev/drbd|", "r|^/dev/mapper/[lL]instor|" ]

Sonst drohen hohe CPU-Last oder hängende LVM-Operationen, weil LVM die DRBD-Devices mitscannt.

Warum es bleibt

DRBD/LINSTOR verbindet für uns das Beste: niedrige Latenz auf eigener Hardware, echte Hochverfügbarkeit, saubere Proxmox-Integration und einen kommerziellen Support-Pfad über LINBIT. Genau diese Mischung suchten wir nach der Reise durch Ceph und Vitastor.