Distributed Replicated Block Device - Version 9 - mit Verwaltungstool LINSTOR

DRBD, das „Distributed Replicated Block Device" hat sich mit Version 9 weiterentwickelt. Seit 2018 gibt es nun mit LINSTOR auch ein komplett neues Verwaltungstool.

Seit seiner Einführung vor rund zwei Jahrzehnten hat sich DRBD als zuverlässige und einfache Lösung zur Replikation von Block Devices über das Netzwerk bewiesen – vereinfacht kann man sich DRBD als ein RAID-1 über das Netzwerk vorstellen. Da es bis zur Version 9 auf zwei Knoten beschränkt war, wurde es hauptsächlich als kleine Lösung für Master/Slave-Setups verwendet, vorzugsweise in Kombination mit dem Cluster-Resource-Manager Pacemaker.

Über Stacking waren zwar auch etwas größere Setups, wie etwa synchrone Replikation auf einen nahen Slave sowie zeitgleiche asynchrone Spiegelung auf ein zusätzliches Backup möglich, eine echte Skalierung in die Breite kam aber erst 2015 mit dem lange erwarteten Update auf Version 9, die bis zu 32 Knoten unterstützt – also einen Master mit bis zu 31 Secondaries.

Drei Jahre später (2018) folgte dann das neue Verwaltungstool LINSTOR als Nachfolger von DRBD Manager, welches dem Admin gegenüber der manuellen Verwaltung per "drbdadm" und "drbdsetup" eine Menge Arbeit abnimmt.

Kommerzielle Kunden mit gültiger Lizenz erhalten bei LINBIT, dem Hersteller von DRBD und LINSTOR, Zugriff auf das Paket-Repository für RHEL, SLES, Debian und Ubuntu.

Frei zugängliche LINSTOR-Pakete findet man bis zum jetzigen Zeitpunkt leider nur für Ubuntu 18.04 LTS in einem eigenen PPA. Wer ohne kommerzielle Lizenz LINSTOR auf einem anderen System testen will, kann sich den Quellcode der Software jedoch aus dem Github-Repository oder von der LINBIT Homepage beziehen und selbst bauen.

Am Beispiel eines 3-Knoten-Clusters mit den Namen tatooine, naboo und kamino wollen wir uns einmal die Funktionsweise von LINSTORE anschauen.

LINSTORE unterscheidet grundlegend die Knotentypen Controller und Satellite. Ein Controller beherbergt die Datenbank mit Konfigurationsinformationen für den gesamten Cluster. Ein Satellite ist jeder Knoten, der Storage bereitstellt. Es muss in einem Cluster mindestens einen Controller geben. Ein Controller kann auch gleichzeitig ein Satellite sein, er ist dann vom Typ Combined.

Installation DRBD & LINSTORE mit Satellite auf allen Clusterknoten – alle Knoten stellen Storage bereit:

sudo add-apt-repository ppa:linbit/linbit-drbd9-stack 
sudo apt-get update 
sudo apt-get install drbd-dkms drbd-utils lvm2 linstor-common linstor-satellite linstor-client 
sudo systemctl enable --now linstor-satellite  

Auf zwei der drei Knoten (tatooine & naboo) wird der Controller installiert und aktiviert:

sudo apt-get install linstor-controller 
sudo systemctl enable --now linstor-controller  

Die Knoten werden initialisiert:

sudo linstor node create --node-type Combined tatooine 10.0.100.1 
sudo linstor node create --node-type Combined naboo 10.0.100.2 
sudo linstor node create --node-type Satellite kamino 10.0.100.1 
sudo linstor node list 
╭─────────────────────────────────────────────────────────╮ 
┊ Node     ┊ NodeType  ┊ Addresses               ┊ State  ┊ 
╞═════════════════════════════════════════════════════════╡ 
┊ kamino   ┊ SATELLITE ┊ 10.0.100.3:3366 (PLAIN) ┊ Online ┊ 
┊ naboo    ┊ COMBINED  ┊ 10.0.100.2:3366 (PLAIN) ┊ Online ┊ 
┊ tatooine ┊ COMBINED  ┊ 10.0.100.1:3366 (PLAIN) ┊ Online ┊ 
╰─────────────────────────────────────────────────────────╯ 

Auf den einzelnen Knoten werden die Volume Groups angelegt – hier mit der bisher unbenutzten Disk sdb:

sudo vgcreate vg_sdb /dev/sdb 

Nun wird auf dem Controller der Storage Pool registriert – einer je Satellite:

for i in tatooine naboo kamino; do sudo linstor storage-pool create lvm $i pool_sdb vg_sdb; done 
sudo linstor storage-pool list 
╭───────────────────────────────────────────────────────────────────────────────────────────────────────╮ 
┊ StoragePool ┊ Node     ┊ Driver ┊ PoolName ┊ FreeCapacity ┊ TotalCapacity ┊ SupportsSnapshots ┊ State ┊ 
╞═══════════════════════════════════════════════════════════════════════════════════════════════════════╡ 
┊ pool_sdb    ┊ kamino   ┊ LVM    ┊ vg_sdb   ┊    20.00 GiB ┊     20.00 GiB ┊ false             ┊ Ok    ┊ 
┊ pool_sdb    ┊ naboo    ┊ LVM    ┊ vg_sdb   ┊    20.00 GiB ┊     20.00 GiB ┊ false             ┊ Ok    ┊ 
┊ pool_sdb    ┊ tatooine ┊ LVM    ┊ vg_sdb   ┊    20.00 GiB ┊     20.00 GiB ┊ false             ┊ Ok    ┊
╰───────────────────────────────────────────────────────────────────────────────────────────────────────╯  

LINSTOR verwaltet Volumes als Teil von Ressource-Gruppen. Diese müssen definiert werden:

sudo linstor resource-definition create r0 
sudo linstor resource-definition list 
╭─────────────────────────────────────────────╮ 
┊ ResourceName ┊ Port ┊ ResourceGroup ┊ State ┊ 
╞═════════════════════════════════════════════╡ 
┊ backups      ┊      ┊ DfltRscGrp    ┊ ok    ┊ 
╰─────────────────────────────────────────────╯ 

Wir definieren zwei Backup-Volumes – sie werden später über die Volumenummer unterschieden:

sudo linstor volume-definition create backups 8G 
sudo linstor volume-definition create backups 1G 
linstor volume-definition list 
╭───────────────────────────────────────────────────────╮ 
┊ ResourceName ┊ VolumeNr ┊ VolumeMinor ┊ Size  ┊ State ┊ 
╞═══════════════════════════════════════════════════════╡ 
┊ backups      ┊ 0        ┊             ┊ 8 GiB ┊ ok    ┊ 
┊ backups      ┊ 1        ┊             ┊ 1 GiB ┊ ok    ┊ 
╰───────────────────────────────────────────────────────╯  

Danach lassen wir LINSTORE diese auf den Knoten erzeugen:

for i in tatooine naboo kamino; do sudo linstor resource create $i backups --storage-pool pool_sdb; done 
sudo linstor resource list 
╭─────────────────────────────────────────────────────────────╮ 
┊ ResourceName ┊ Node     ┊ Port ┊ Usage  ┊             State ┊ 
╞═════════════════════════════════════════════════════════════╡ 
┊ backups      ┊ kamino   ┊ 7004 ┊ Unused ┊ SyncTarget(1,14%) ┊ 
┊ backups      ┊ naboo    ┊ 7004 ┊ Unused ┊ SyncTarget(1,02%) ┊ 
┊ backups      ┊ tatooine ┊ 7004 ┊ Unused ┊          UpToDate ┊
╰─────────────────────────────────────────────────────────────╯  

Die Volumes lassen sich jetzt verwenden:

sudo mkfs.xfs /dev/drbd/by-res/backups/0 
sudo mkdir -p /mnt/backups/0 
sudo mount /dev/drbd/by-res/backups/0 /mnt/backups/0 
sudo sh -c 'uname -a > /mnt/backups/0/testdata.txt' 
sudo linstor resource list 
╭────────────────────────────────────────────────────╮ 
┊ ResourceName ┊ Node     ┊ Port ┊ Usage  ┊    State ┊ 
╞════════════════════════════════════════════════════╡ 
┊ backups      ┊ kamino   ┊ 7004 ┊ Unused ┊ UpToDate ┊ 
┊ backups      ┊ naboo    ┊ 7004 ┊ Unused ┊ UpToDate ┊ 
┊ backups      ┊ tatooine ┊ 7004 ┊ InUse  ┊ UpToDate ┊
╰────────────────────────────────────────────────────╯  

Das Volume kann – sobald auf tatooine wieder ausgehängt – natürlich einfach auf einem anderen Knoten (hier kamino) eingehängt werden:

luke@tatooine:~$ sudo umount /mnt/backups/0 

luke@kamino:~$ sudo mount /dev/drbd/by-res/backups/0 /mnt/backups/0 
luke@kamino:~$ sudo linstor --controller tatooine resource list 
╭────────────────────────────────────────────────────╮ 
┊ ResourceName ┊ Node     ┊ Port ┊ Usage  ┊    State ┊ 
╞════════════════════════════════════════════════════╡ 
┊ backups      ┊ kamino   ┊ 7004 ┊ InUse  ┊ UpToDate ┊ 
┊ backups      ┊ naboo    ┊ 7004 ┊ Unused ┊ UpToDate ┊ 
┊ backups      ┊ tatooine ┊ 7004 ┊ Unused ┊ UpToDate ┊
╰────────────────────────────────────────────────────╯  

Fazit

Die Installation eines grundlegenden DRBD-Clusters ist mit LINSTOR in Kürze erledigt. LINSTOR vereinfacht die administrativen Aufgaben, die Syntax ist leicht verständlich.

Da LINBIT den DRBD Manager offiziell nicht mehr unterstützt, sind Anwender gut beraten, in absehbarer Zeit auf LINSTOR zu migrieren. Hierzu stellt der Hersteller neben einem Migrations-Skript auch eine ausführliche Anleitung zur Verfügung.