Die bevorzugte Methode, um verteilten Storage in Proxmox-Clustern zu verwenden, ist aktuell CEPH. CEPH ist ein grossartiger Ansatz, jedoch auch nicht ganz einfach in Betrieb zu nehmen und für einen kleinen Cluster eigentlich überdimensioniert.

DRBD hingegen ist recht schnell in Betrieb genommen, und fügt sich problemlos in eine Serverinstallation mit LVM ein.

Der Storage-Treiber basierend auf DRBD-Manager wird zwar mit Proxmox noch mitgeliefert, aber ist nicht mehr wirklich unterstützt, seit es um DRBD-Manager einiges Hin- und Her um dessen Lizenzierung gab.

Die im Moment im Proxmox-Wiki empfohlene Variante, zwei DRBD-Volumes zu verwenden, ist unflexibel, funktioniert eigentlich nur mit zwei Knoten, und bietet ein hohes Risiko.

DRBD mit LVM ohne DRBD-Manager

Wir haben uns deshalb entschieden, DRBD mit einem eigenen Storage-Plugin für uns wieder auf eine Weise verfügbar zu machen, wie sie uns gut passt: Mit DRBD-Volumes aufsetzend auf LVM, aber ohne den DRBD-Manager zu verwenden. In diesem Modell wird eine LVM-Volumegroup benötigt (die aber z.B. mit einer lokalen Storage-Volumegroup identisch sein kann). Jede virtuelle Disk erhält zwei LVM-Volumes: Eines für die Metadaten, eines für die Daten. Darauf aufsetzend wird ein DRBD-Volume konfiguriert mit Synchronisation gegen einen Partnerknoten. Die virtuelle Maschine kann also jederzeit auf einem der beiden Partnerknoten laufen. Gibt es mehr als zwei Knoten im Netz, so wird jede VM (und Disk) jeweils auf zwei Knoten lauffähig sein – auf Mehrfachspiegel via DRBD verzichten wir aus Performance- und Komplexitätsgründen.

Bitte beachten Sie: Dieses Storage-Plugin basiert auf bestehenden Storage-Plugins von Proxmox und steht deshalb unter der AGP-Lizenz. Wir verwenden dieses Plugin selbst und stellen es so zur Verfügung, wie es für unsere Zwecke taugt. Wir übernehmen keinerlei Garantie dafür, dass es Ihren Anforderungen entspricht.

Installation und Inbetriebnahme

Bevor Sie DRBD in Betrieb nehmen sollten Sie dafür sorgen, dass auf Ihrem System LVM aufgesetzt ist und mindestens eine Volumegroup existiert. Eine bereits bestehende Volumegroup ist in Ordnung, wenn es Sie nicht stört, dass Sie dann evtl. die DRBD-Volumes dann auch in dieser als Inhalt auftauchen.

Unser DRBD-Storage-Plugin finden Sie unter Downloads als Debian-Paket. Laden Sie es herunter und installieren es auf allen Knoten mit

apt install ./pvedrbd-*.deb

Unter /etc/pve/storage.cfg wird automatisch eine Standardkonfiguration eingerichtet. Für ganz einfache Fälle sollte dies bereits genügen, aber es lohnt sich vielleicht, an dieser Stelle kurz ein bisschen nachzudenken, wie der Cluster aussehen soll. In der Konfigurationsdatei:

voldrbd: drbdstor
    vgname sys
    shared
    #peers 
    #peerips

Lässt sich mit der Option vgname die zu verwendende Volume Group konfigurieren. Standardmässig wird einfach die erste gefundene verwendet. Die auskommentierten Optionen peers und peerips sollten eine Liste der Knoten, auf denen DRBD Volumes anlegen soll sowie deren IP-Adressen eingetragen werden. Wir hier nichts angegeben, so werden alle Proxmox-Knoten im Cluster mit der IP verwendet, auf die deren Namen auflöst.

In allen nicht trivialen Clustern ist es anzuraten, auf jedem Rechner ein separates Interface für die DRBD-Synchronisation zu verwenden. Dessen IP-Adresse wird unter peerips eingetragen. Für einen einfachen Zwei-Knoten-Cluster mit den Knoten pve1 und pve2 und den IP-Adressen im Synchronisationsnetz 192.168.33.1 und 192.168.33.2 tragen Sie also in storage.cfg folgendes ein:

  peers pve1 pve2
  peerips 192.168.33.1 192.168.33.2

Nach einem Nuestart des pvedaemon sollte nun das Storage drbdstore auftauchen und verwendet werden können.

Verwendung mit nur einem Knoten

Beim Aufsetzen eines Clusters kann es notwendig sein, die VMs schon mal aufzusetzen, obwohl noch kein zweiter Knoten vorhanden ist. Verwenden Sie dann als zweiten Knoten (peers) den Namen none und seine künftige IP-Adresse unter peerips. So lassen sich die DRBD-Volumes noch ohne Synchronisationspartner aufsetzen.

Zur Zeit ist ein späteres Aufsetzen der Synchronisation noch mit Handarbeit verbunden. Dazu in einem späteren Artikel mehr.

Verwendung mit mehr als zwei Knoten

Die aufgesetzten DRBD-Volumes werden – falls mehr als ein Knoten vorhanden ist – immer paarweise synchronisiert. Mehrfachspiegel werden in dieser einfachen Konfiguration nicht unterstützt. Sie können steuern, auf welchen Knoten Spiegel eingerichtet werden: Wenn Sie eine virtuelle Disk auf einem Knoten einrichten, dann wird der Synchronisationspartner auf dem nächsten Knoten in der peer-Liste eingerichtet.

Ein späterer Umzug des Synchronisationspartners ist zur Zeit noch Handarbeit. Dazu in einem späteren Artikel mehr.

Live-Migration

In der Standardkonfiguration von DRBD nach der Installation ist kein Dual-Primary-Modus konfiguriert und folgerichtig muss eine VM zur Migration zuerst heruntergefahren werden, bevor die VM auf dem Partnerknoten hochgefahren werden kann.

Möchten Sie zwingend Live-Migration nutzen, dann müssen Sie in DRBD den Dual-Primary-Modus konfigurieren.

Dies bietet jedoch auch Risiken!

Das Problem haben wir nicht erschöpfend untersucht, sondern relativ schnell festgestellt, dass bei Ausschalten von oplocks durch

[global]
oplocks = no

in smb.conf die Transfers zwar nur noch mit Disk-Geschwindigkeit stattfinden, aber dafür der Speicherverbrauch der Samba-Prozesse im normalen Rahmen bleiben. Wir vermuten, dass ein serverseitiger Cache ins Spiel kommt, den man auch mit sanfteren Eingriffen ausschalten könnte.

Im Prinzip ist die vorgesehene Einsatzweise von CEPH die, direkt "rohe" Disks als CEPH-OSD einzusetzen. CEPH selber kennt Spiegelung und Redundanz – es ist also beispielsweise unnötig, ein RAID-Volume einzusetzen, wenn CEPH ins Spiel kommt.

Nichtsdestotrotz gibt es durchaus Szenarien, in denen CEPH nur eine Partition einer Disk oder eines RAID-Volumes erhalten kann, z.B.

• Wenn (z.B. aus Performancegründen) ein grosses RAID-Volume vorgezogen wird, um auf demselben Volume System, CEPH-OSD und eventuell weiteren lokalen Storage-Partitionen vorzuhalten
• wenn auf einer kleinen Installation System und CEPH-OSD auf derselben Disk Platz finden müssen
• wenn CEPH auf einer bestehenden Installation eingesetzt wird und keine Disks extra für CEPH freigeschaufelt werden können

Tatsächlich ist eine solche Installation machbar, auch wenn sowohl CEPH als auch Proxmox den einen oder anderen Stein in den Weg legen:

1. Partition CEPH-OSD-tauglich machen. Beispiel: Freier Platz auf /dev/sda soll für ein CEPH-OSD auf /dev/sda3 verwendet werden:

   PTYPE_UUID=4fbd7e29-9d25-41b8-afd0-062c0ceff05d
   disk=/dev/sda
   part=3
   OSD_UUID=`uuidgen -r`
   sgdisk --largest-new=$part --change-name="${part}:ceph data" \
      --partition-guid=${part}:$OSD_UUID   --typecode=${part}:$PTYPE_UUID \
      -- $disk
   

   wir verwenden sgdisk, um eine Partition /dev/sda3 anzulegen, die den freien Platz auf sda füllt und die richtigen Bezeichnungen erhält, um von CEPH genutzt werden zu können.

2. Proxmox erlaubt normalerweise nicht die Angabe einer Partitionsnummer für OSD. Damit dies möglich wird, editieren Sie die Datei /usr/share/perl5/PVE/API2/Ceph.pm. Suchen Sie nach der Zeile

   $devname =~ s|/dev/||;

   und kommentieren diese und die folgenden Zeilen bis und mit 

   my $devpath = $diskinfo->{devpath};

   aus. Die letztere ergänzen Sie um

   my $devpath = $devname;
   

   Nun suchen Sie nach der Zeile

   my $cmd = ['ceph-disk', 'prepare', '--zap-disk',

   und entfernen das Argument –zap-disk, so dass die Zeile so aussieht:

   my $cmd = ['ceph-disk', 'prepare', 

   [Diese Anleitung wurde getestet an Proxmox 5.0]

Nach Neustart des pvedaemon können Sie nun mit

pveceph create-osd /dev/sda3
ceph-disk activate /dev/sda3

Die Partition auf die gewohnte Weise als CEPH OSD hinzufügen.

Zuerst richten Sie wie unter oben erwähntem Beitrag bereits beschrieben mittels z.B. sgdisk eine Ceph-fähige Partition ein.

Der für Ceph-OSDs zuständige Code in Proxmox findet sich mittlerweile an etwas anderer Stelle, nämlich /usr/share/perl5/PVE/API2/Ceph/OSD.pm. Eine Patchdatei mit unseren vorgeschlagenen Modifikationen finden Sie hier. In OSD.pm suchen Sie nach der Zeile

die "unable to get device info for '$d...

diese und das nachfolgende Zeile kommentieren Sie mit "#" aus, damit der Code nicht abbricht, wenn keine Disk gefunden wird, die dem angegebenen Device-Namen entspricht. Ersetzen Sie nun die Zeile

my $devpath = $disklist->{$devname}->{devpath};

mit

my $devpath = "/dev/".$devname;

Als Partitionsname, der für OSD verwendet werden soll, muss also ein Name sein, der in /dev direkt als Gerät zu finden ist. Um eine unschöne Warnung zu vermeiden ersetzen wir ausserdem

my $osd_size = $disklist->{$devname}->{size};

ein paar Zeilen weiter unten mit

my $osd_size = `sfdisk -s $devpath`;
($osd_size *= 1024) if( $osd_size );

so kann pveceph die Grösse der verwendeten Partition erkennen – sofern das Utility sfdisk installiert ist.

Nun kann wie gewohnt mit

pveceph osd create /dev/sda3

(als Beispiel verwenden wir hier die Partition sda3) ein OSD erstellt werden.