LINSTOR-Speicher und seine Integration mit OpenNebula

Vor nicht allzu langer Zeit präsentierten die Jungs von LINBIT ihre neue SDS-Lösung – Linstor. Es handelt sich um einen vollständig offenen Speicher, der auf bewährten Technologien basiert: DRBD, LVM, ZFS. Linstor vereint Einfachheit und eine gut durchdachte Architektur, die es ermöglicht, Stabilität und beeindruckende Ergebnisse zu erzielen.

Heute möchte ich ein wenig ausführlicher darüber sprechen und zeigen, wie einfach es ist, es mit OpenNebula unter Verwendung von linstor_un zu integrieren – einem 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 der eigenen Infrastruktur bereitgestellt werden kann.

Architektur von Linstor

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

Stereotype aufbrechen

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

Erinnern wir uns an die Vergangenheit, als DRBD8 weit verbreitet war. Seine Standardnutzung sah vor, ein großes Blockgerät zu erstellen und es mit LVM in viele kleine Stücke zu zerteilen. Eine Art mdadm RAID-1, aber mit Replikation über das Netzwerk.

Dieser Ansatz hat seine Nachteile, und daher haben sich mit der Einführung von DRBD9 die Prinzipien des Speichersystems geändert; jetzt wird für jede virtuelle Maschine ein separates DRBD-Gerät erstellt.

Der Ansatz mit unabhängigen Blockgeräten ermöglicht eine bessere Raumausnutzung im Cluster und bietet auch eine Reihe zusätzlicher Möglichkeiten. Zum Beispiel kann für jedes dieser Geräte die Anzahl der Replikate, deren Standort und individuelle Einstellungen festgelegt werden. Sie lassen sich leicht erstellen/löschen, Snapshots machen, die Größe ändern, Verschlüsselung aktivieren und vieles mehr. Es ist erwähnenswert, dass DRBD9 auch Quorum unterstützt, um Split-Brain-Situationen zu vermeiden.

Ressourcen und Backends

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

Ressourcen gibt es in zwei Typen:

• Datenressource – repräsentieren ein DRBD-Gerät, das auf einem Knoten im LVM- oder ZFS-Pool platziert ist.
  Derzeit gibt es Unterstützung für mehrere Backends, und ihre Anzahl wächst ständig. Es gibt Unterstützung für LVM, ThinLVM und ZFS. Letztere beiden ermöglichen es, Snapshots zu erstellen und zu verwenden.
• Diskless-Ressource — ist ein DRBD-Gerät, das auf einem Knoten ohne Backend platziert ist, aber wie ein gewöhnliches Blockgerät behandelt werden kann; alle Lese-/Schreibvorgänge werden an die Datenressourcen umgeleitet. Der nächstgelegene Vergleich zu diskless-Ressourcen ist ein iSCSI LUN.

Jede DRBD-Ressource kann bis zu 8 Replikate haben, von denen nur eines standardmäßig aktiv sein kann — Primär, alle anderen werden als Sekundär betrachtet, und ihre Nutzung ist nicht möglich, solange es mindestens einen Primär gibt, das heißt, sie replizieren einfach Daten untereinander.

Wenn ein DRBD-Gerät im System gemountet wird, wird es automatisch zu Primär, sodass sogar eine Diskless-Ressource in der Terminologie von DRBD primär sein kann.

Warum wird Linstor benötigt?

Indem es alle ressourcenintensiven Aufgaben dem Kern anvertraut, ist Linstor im Wesentlichen eine gewöhnliche Java-Anwendung, die die Erstellung von DRBD-Ressourcen problemlos automatisiert.
Jede erstellte Ressource stellt einen unabhängigen DRBD-Cluster dar, der eigenständig arbeitet, unabhängig vom Zustand des Control-Planes und anderer DRBD-Ressourcen.

Linstor besteht aus nur zwei Komponenten:

• Linstor-Controller — Der Hauptcontroller, der eine API zur Erstellung und Verwaltung von Ressourcen bereitstellt. Er kommuniziert auch mit den Satelliten, überprüft den verfügbaren Speicherplatz auf diesen und sendet Aufgaben zur Erstellung und Löschung neuer Ressourcen. Er läuft als Einzelinstanz und verwendet eine Datenbank, die intern (H2) oder extern (PostgreSQL, MySQL, MariaDB) sein kann.
• Linstor-Satellite — Wird auf allen Storage-Knoten installiert und stellt dem Controller Informationen über den verfügbaren Speicherplatz zur Verfügung und führt Aufgaben aus, die vom Controller erhalten wurden, um neue Volumes und DRBD-Geräte darauf zu erstellen und zu löschen.

Linstor arbeitet mit folgenden Schlüsselbegriffen:

• Node — Der physische Server, auf dem DRBD-Ressourcen erstellt und verwendet werden.
• Storage Pool — Ein LVM- oder ZFS-Pool, der auf dem Knoten erstellt wurde, in dem die DRBD-Ressourcen untergebracht werden. Ein diskless-Pool ist ebenfalls möglich — dies ist ein Pool, in dem nur diskless-Ressourcen untergebracht werden.
• Ressourcendefinition — Definition der Ressource, im Grunde genommen ist dies ein Prototyp, der den Namen und all seine Eigenschaften beschreibt.
• Volumes Definition — Definition des Volumes. Jede Ressource kann aus mehreren Volumes bestehen, jedes Volume muss eine Größe haben.
• Ressource — Erstellt durch eine Instanz des Blockgeräts, jede Ressource muss auf einem bestimmten Knoten und in einem bestimmten Storage-Pool platziert werden.

Installation von Linstor

Ich empfehle, das System Ubuntu zu verwenden, da es dafür existiert ein fertiges PPA:

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

Oder Debian, 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

Momentan wird im Linux-Kernel ein in-tree Kernel-Modul geliefert DRBD8, leider passt es uns nicht und wir müssen installieren DRBD9:

apt-get install drbd-dkms

Die Erfahrung zeigt, dass die meisten Schwierigkeiten genau dann auftreten, wenn das DRBD8-Modul in das System geladen ist, und nicht DRBD9. Glücklicherweise lässt sich dies leicht überprüfen, indem man ausführt:

modprobe drbd
cat /proc/drbd

Wenn Sie sehen version: 9 — dann ist alles in Ordnung, wenn version: 8 — dann ist etwas schiefgelaufen und Sie müssen zusätzliche Schritte unternehmen, um die Ursache herauszufinden.

Jetzt installieren wir linstor-satellite und drbd-utils:

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

Cluster erstellen

Storage-Pools und Knoten

Für das Backend wählen 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 am Controller durchgeführt werden:

Lassen Sie uns unsere Knoten hinzufügen:

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

Lassen Sie uns Storage-Pools erstellen:

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 sehen wie:

+-------------------------------------------------------------------------------------------------------+
| StoragePool | Node  | Driver   | PoolName          | FreeCapacity | TotalCapacity | SupportsSnapshots |
|-------------------------------------------------------------------------------------------------------|
| data        | node1 | LVM_THIN | drbdpool/thinpool |       64 GiB |        64 GiB | true              |
| data        | node2 | LVM_THIN | drbdpool/thinpool |       64 GiB |        64 GiB | true              |
| data        | node3 | LVM_THIN | drbdpool/thinpool |       64 GiB |        64 GiB | true              |
+-------------------------------------------------------------------------------------------------------+

DRBD-Ressourcen

Jetzt versuchen wir, 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 

+------------------------------------------------------------------------------------------------------+
| Node  | Resource | StoragePool | VolumeNr | MinorNr | DeviceName    | Allocated  | InUse  |    State |
|------------------------------------------------------------------------------------------------------|
| node1 | myres    | data        | 0        | 1084    | /dev/drbd1084 | 52 KiB     | Unused | UpToDate |
| node2 | myres    | data        | 0        | 1084    | /dev/drbd1084 | 52 KiB     | Unused | UpToDate |
+------------------------------------------------------------------------------------------------------+

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

linstor resource create --diskless node3 myres

Auf den Nodes werden Sie dieses Gerät immer als /dev/drbd1084 oder /dev/drbd/by-res/myres/0

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

Jetzt werde ich darüber sprechen, wie man es mit OpenNebula integriert

OpenNebula-Konfiguration

Ich werde nicht zu sehr in den Prozess der OpenNebula-Konfiguration eintauchen, da alle Schritte detailliert beschrieben sind in offiziellen Dokumentation, auf die ich Ihnen empfehle, sich zu beziehen, ich werde nur über die Integration von OpenNebula mit Linstor sprechen.

linstor_un

Um dieses Problem 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-Nodes von OpenNebula und erfordert keine zusätzlichen Aktionen auf den Compute-Nodes.

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

apt-get install jq linstor-client

Team linstor node list sollte die Liste der Nodes anzeigen. Alle Compute-Nodes von OpenNebula müssen dem Linstor-Cluster hinzugefügt werden.

Laden wir das Plugin herunter und installieren wir 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 ihn zur OpenNebula-Konfiguration hinzufügen. Dazu führen wir die beschriebenen einfachen Schritte aus hier.

Nachdem wir das gemacht haben, starten wir OpenNebula neu:

systemctl restart opennebula

Und fügen unsere Datenspeicher hinzu, den Systemspeicher:

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 das Image-Repository:

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 Data-Replikate an, die für jedes neue Image in OpenNebula erstellt werden.
• Parameter CLONE_MODE gibt an, wie die Images bei der Erstellung neuer virtueller Maschinen geklont werden sollen, Snapshot — es wird ein Snapshot des Images erstellt und dieser Snapshot wird für die virtuelle Maschine verwendet, copy — es wird eine vollständige Kopie des Images für jede virtuelle Maschine erstellt.
• Im BRIDGE_LIST Es wird empfohlen, alle Nodes anzugeben, die für das Klonen der Images verwendet werden.

Die vollständige Liste der unterstützten Parameter finden Sie in der README Projekt.

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

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

Quelle: habr.com