LINSTOR-Speicher und seine Integration mit OpenNebula

Vor nicht allzu langer Zeit haben die Leute von LINBIT ihre neue SDS-Lösung – Linstor – vorgestellt. Dies ist ein vollständig offenes Speichersystem, das auf bewährten Technologien basiert: DRBD, LVM, ZFS. Linstor kombiniert Benutzerfreundlichkeit mit einer durchdachten Architektur, die Stabilität und beeindruckende Ergebnisse ermöglicht.

Heute möchte ich etwas genauer darauf eingehen und zeigen, wie einfach es ist, es mit OpenNebula zu integrieren, indem ich linstor_un verwende – einen neuen Treiber, den ich speziell für diesen Zweck entwickelt habe.

Linstor in Kombination mit OpenNebula ermöglicht den Aufbau einer schnellen und zuverlässigen Cloud, die problemlos auf eigener Infrastruktur bereitgestellt werden kann.

Die Architektur von Linstor

Linstor selbst ist weder ein Dateisystem noch ein Blockspeicher. Linstor ist ein Orchestrator, der eine Abstraktionsschicht bereitstellt, um die Erstellung von Volumes in LVM oder ZFS zu automatisieren und diese mit DRBD9 zu replizieren.

Mythen brechen

Aber halt, DRBD? – Warum sollte man es automatisieren, und wie funktioniert das überhaupt?

Erinnern wir uns an die Zeit, als DRBD8 beliebt war. Seine Standardnutzung bestand darin, ein großes Blockgerät zu erstellen und dieses mithilfe von LVM in viele kleine Teile aufzuteilen. Eine Art mdadm RAID-1, aber mit Netzwerk-Replikation.

Dieser Ansatz hat einige Nachteile, weshalb mit der Einführung von DRBD9 die Prinzipien der Speicherkonzeption geändert wurden. Jetzt wird für jede virtuelle Maschine ein separates DRBD-Gerät erstellt.

Der Ansatz mit unabhängigen Blockgeräten ermöglicht eine bessere Ausnutzung des Raums im Cluster und bietet zudem eine Reihe zusätzlicher Möglichkeiten. Zum Beispiel kann für jedes dieser Geräte die Anzahl der Replikate, deren Standort und individuelle Einstellungen definiert werden. Sie lassen sich einfach erstellen/entfernen, Snapshots machen, die Größe ändern, Verschlüsselung aktivieren und vieles mehr. Es ist bemerkenswert, dass DRBD9 auch Quorum unterstützt, was Split-Brain-Situationen vermeiden hilft.

Ressourcen und Backends

Beim Erstellen eines neuen Blockgeräts platziert Linstor die erforderliche Anzahl von Replikaten auf verschiedenen Knoten im Cluster. Jede dieser Replikate nennen wir DRBD-Ressource.

Ressourcen gibt es in zwei Typen:

• Datenressource — sind DRBD-Geräte, die in einem LVM- oder ZFS-Pool auf einem Knoten bereitgestellt werden.
  Derzeit werden mehrere Backends unterstützt, und ihre Anzahl wächst kontinuierlich. Es gibt Unterstützung für LVM, ThinLVM und ZFS. Letztere ermöglichen das Erstellen und Verwenden von Snapshots.
• Diskless-Ressource — ist ein DRBD-Gerät, das auf einem Knoten ohne Backend bereitgestellt wird, es handelt sich jedoch um ein gewöhnliches Blockgerät, bei dem alle Lese-/Schreiboperationen auf die Datenressourcen umgeleitet werden. Der nächste Analog zu Diskless-Ressourcen ist ein iSCSI LUN.

Jede DRBD-Ressource kann bis zu 8 Replikate haben, und nur eines davon kann standardmäßig aktiv sein — Primary, alle anderen werden als Secondary eingestuft und können erst verwendet werden, wenn mindestens ein Primary vorhanden ist, das heißt, sie replizieren einfach die Daten untereinander.

Wenn das DRBD-Gerät im System gemountet wird, wird es automatisch zu Primary, sodass sogar eine Diskless-Ressource in der Terminologie von DRBD als Primary fungieren kann.

Warum ist Linstor notwendig?

Indem es alle ressourcenintensiven Aufgaben dem Kern anvertraut, ist Linstor im Wesentlichen eine herkömmliche Java-Anwendung, die es ermöglicht, die Erstellung von DRBD-Ressourcen mühelos zu automatisieren.
Jede erstellte Ressource wird ein unabhängiger DRBD-Cluster sein, der eigenständig funktioniert, unabhängig vom Zustand des Control-Plans und anderer DRBD-Ressourcen.

Linstor besteht aus zwei Komponenten:

• Linstor-Controller — Der Hauptcontroller, der eine API zur Erstellung und Verwaltung von Ressourcen bereitstellt. Er kommuniziert auch mit den Satelliten, um den verfügbaren Speicherplatz zu überprüfen, und gibt Aufträge zur Erstellung und Löschung neuer Ressourcen aus. Wird als Einzelinstanz gestartet und nutzt eine Datenbank, die sowohl intern (H2) als auch extern (PostgreSQL, MySQL, MariaDB) sein kann.
• Linstor-Satellite — Wird auf allen Storage-Nodes installiert und liefert dem Controller Informationen über den freien Speicherplatz. Außerdem führt er die vom Controller erhaltenen Aufgaben zur Erstellung und Löschung neuer Volumes und DRBD-Geräte durch.

Linstor operiert mit den folgenden Schlüsselbegriffen:

• Knoten — Ein physischer Server, auf dem DRBD-Ressourcen erstellt und genutzt werden.
• Storage-Pool — Ein LVM- oder ZFS-Pool, der auf dem Knoten erstellt wird, in dem DRBD-Ressourcen platziert werden. Auch ein diskless-Pool ist möglich – ein Pool, der nur diskless-Ressourcen enthält.
• Ressourcendefinition — Die Ressourcendefinition ist im Wesentlichen ein Prototyp, der den Namen und all seine Eigenschaften beschreibt.
• Volumendefinition — Die Volumendefinition. Jede Ressource kann aus mehreren Volumen bestehen, und jedes Volumen muss eine Größe haben.
• Ressource — Eine erstellte Instanz eines Blockgeräts, jede Ressource muss auf einem bestimmten Knoten und in einem Speicherpool platziert sein.

Installation von Linstor

Ich empfehle die Verwendung von Ubuntu, da es dafür ein fertiges PPA gibt.:

add-apt-repository ppa:linbit/linbit-drbd9-stack
apt-get update

Alternativ können Sie Debian verwenden, wo Linstor aus dem offiziellen Repository für Proxmox installiert werden kann:

wget -O- https://packages.linbit.com/package-signing-pubkey.asc | apt-key add -
PVERS=5 && echo "deb http://packages.linbit.com/proxmox/ proxmox-$PVERS drbd-9.0" > 
    /etc/apt/sources.list.d/linbit.list
apt-get update

Controller

Hier ist alles einfach:

apt-get install linstor-controller linstor-client
systemctl enable linstor-controller
systemctl start linstor-controller

Storage-Knoten

Der Linux-Kernel enthält derzeit ein in-tree Kernel-Modul DRBD8, leider ist es nicht geeignet, und wir müssen DRBD9 installieren.:

apt-get install drbd-dkms

Wie die Erfahrung zeigt, entstehen die meisten Schwierigkeiten genau dann, wenn das Modul DRBD8 und nicht DRBD9 in das System geladen werden. Glücklicherweise lässt sich das leicht überprüfen mit:

modprobe drbd
cat /proc/drbd

Wenn Sie sehen version: 9 — bedeutet alles ist in Ordnung, wenn Version: 8 — bedeutet, dass etwas schiefgelaufen ist und Sie weitere Maßnahmen zur Ursachenforschung ergreifen müssen.

Jetzt installieren wir linstor-satellite und drbd-utils:

apt-get install linstor-satellite drbd-utils
systemctl enable linstor-satellite
systemctl start linstor-satellite

Erstellung eines Clusters

Speicherpools und Knoten

Als Backend verwenden wir ThinLVM, da es am einfachsten ist und Snapshots unterstützt.
Installieren Sie lvm2, falls Sie das noch nicht gemacht haben, und lassen Sie uns einen ThinLVM-Pool auf allen unseren Storage-Knoten erstellen:

sudo vgcreate drbdpool /dev/sdb
sudo lvcreate -L 800G -T drbdpool/thinpool

Alle weiteren Schritte können direkt auf dem Controller durchgeführt werden:

Fügen wir unsere Knoten hinzu:

linstor node create node1 127.0.0.11
linstor node create node2 127.0.0.12
linstor node create node3 127.0.0.13

Erstellen wir Speicherpools:

linstor storage-pool create lvmthin node1 data drbdpool/thinpool
linstor storage-pool create lvmthin node2 data drbdpool/thinpool
linstor storage-pool create lvmthin node3 data drbdpool/thinpool

Jetzt überprüfen wir die erstellten Pools:

linstor storage-pool list

Wenn alles richtig gemacht wurde, sollten wir etwas wie Folgendes sehen:

+-------------------------------------------------------------------------------------------------------+
| Speicherpool  | Knoten | Treiber   | Poolname          | Freikapazität | Gesamtkapazität | UnterstütztSnapshots |
|-------------------------------------------------------------------------------------------------------|
| daten         | knoten1 | LVM_THIN | drbdpool/thinpool  |       64 GiB  |        64 GiB | true              |
| daten         | knoten2 | LVM_THIN | drbdpool/thinpool  |       64 GiB  |        64 GiB | true              |
| daten         | knoten3 | LVM_THIN | drbdpool/thinpool  |       64 GiB  |        64 GiB | true              |
+-------------------------------------------------------------------------------------------------------+

DRBD-Ressourcen

Lassen Sie uns jetzt versuchen, unsere neue DRBD-Ressource zu erstellen:

linstor resource-definition create myres
linstor volume-definition create myres 1G
linstor resource create myres --auto-place 2

Überprüfen wir die erstellten Ressourcen:

linstor resource list 

+------------------------------------------------------------------------------------------------------+
| Knoten | Ressource | Speicherpool | VolumenNr | MinorNr | GeräteName    | Zugewiesen  | InBenutzung |    Status |
|------------------------------------------------------------------------------------------------------|
| knoten1 | myres    | daten        | 0         | 1084    | /dev/drbd1084 | 52 KiB     | Unbenutzt | Aktuell |
| knoten2 | myres    | daten        | 0         | 1084    | /dev/drbd1084 | 52 KiB     | Unbenutzt | Aktuell |
+------------------------------------------------------------------------------------------------------+

Ausgezeichnet! — wir sehen, dass die Ressource auf den ersten beiden Knoten erstellt wurde. Wir können auch versuchen, eine diskless-Ressource auf dem dritten zu erstellen:

linstor resource create --diskless knoten3 myres

Auf den Knoten finden Sie immer dieses Gerät wie /dev/drbd1084 oder /dev/drbd/by-res/myres/0

So funktioniert Linstor, weitere Informationen können Sie aus offiziellen Dokumentation.

Jetzt werde ich erklären, wie man es mit OpenNebula integriert

Konfiguration von OpenNebula

Ich werde nicht tief in den Konfigurationsprozess von OpenNebula eintauchen, da alle Schritte detailliert in offiziellen Dokumentation, auf die ich Ihnen empfehle zuzugreifen, beschrieben sind. Ich werde nur über die Integration von OpenNebula mit Linstor sprechen.

linstor_un

Um diese Aufgabe zu lösen, habe ich einen eigenen Treiber geschrieben — linstor_un, der momentan als Plugin verfügbar ist und separat installiert werden muss.

Die gesamte Installation erfolgt auf den Frontend OpenNebula-Knoten und erfordert keine zusätzlichen Schritte auf den Compute-Knoten.

Zuerst müssen wir sicherstellen, dass wir jq und linstor-client:

apt-get install jq linstor-client

Der Befehl linstor node list sollte eine Liste der Knoten ausgeben. Alle Compute-Knoten von OpenNebula sollten dem Linstor-Cluster hinzugefügt werden.

Laden Sie das Plugin herunter und installieren Sie es:

curl -L https://github.com/OpenNebula/addon-linstor_un/archive/master.tar.gz | tar -xzvf - -C /tmp

mv /tmp/addon-linstor_un-master/vmm/kvm/* /var/lib/one/remotes/vmm/kvm/

mkdir -p /var/lib/one/remotes/etc/datastore/linstor_un
mv /tmp/addon-linstor_un-master/datastore/linstor_un/linstor_un.conf /var/lib/one/remotes/etc/datastore/linstor_un/linstor_un.conf

mv /tmp/addon-linstor_un-master/datastore/linstor_un /var/lib/one/remotes/datastore/linstor_un
mv /tmp/addon-linstor_un-master/tm/linstor_un /var/lib/one/remotes/tm/linstor_un

rm -rf /tmp/addon-linstor_un-master

Jetzt müssen wir es zur OpenNebula-Konfiguration hinzufügen. Dazu führen wir die beschriebenen einfachen Schritte aus. hier.

Anschließend starten wir OpenNebula neu:

systemctl restart opennebula

Und fügen unsere Datenspeicher hinzu, das System:

cat > system-ds.conf <<EOT
NAME="linstor-system"
TYPE="SYSTEM_DS"
STORAGE_POOL="data"
AUTO_PLACE="2"
CLONE_MODE="snapshot"
CHECKPOINT_AUTO_PLACE="1"
BRIDGE_LIST="node1 node2 node3"
TM_MAD="linstor_un"
EOT

onedatastore create system-ds.conf

Und den Speicher für Bilder:

cat > images-ds.conf <<EOT
NAME="linstor-images"
TYPE="IMAGE_DS"
STORAGE_POOL="data"
AUTO_PLACE="2"
BRIDGE_LIST="node1 node2 node3"
DISK_TYPE="BLOCK"
DS_MAD="linstor_un"
TM_MAD="linstor_un"
EOT

onedatastore create images-ds.conf

• Parameter AUTO_PLACE zeigt die Anzahl der Daten-Replikate an, die für jedes neue Abbild in OpenNebula erstellt werden.
• Parameter CLONE_MODE gibt an, wie die Abbilder beim Erstellen neuer virtueller Maschinen geklont werden. snapshot — erstellt einen Snapshot des Abbildes und entwickelt die virtuelle Maschine aus dem Snapshot. copy — erstellt ein vollständiges Abbild für jede virtuelle Maschine.
• In BRIDGE_LIST Es wird empfohlen, alle Knoten anzugeben, die für die Durchführung von Clone-Operationen verwendet werden.

Die vollständige Liste der unterstützten Parameter finden Sie in der README des Projekts bekanntgaben.

Damit ist die Konfiguration abgeschlossen, jetzt können Sie ein Appliance aus dem offiziellen OpenNebula Marketplace laden und virtuelle Maschinen daraus erstellen.

Link zum Projekt:
https://github.com/OpenNebula/addon-linstor_un

Quelle: habr.com