In einem früheren Artikel habe ich die Möglichkeit untersucht, einen fehlertoleranten NFS-Server mit DRBD und Proxmox zu erstellen. Es hat sich als ziemlich gut herausgestellt, aber wir werden uns nicht auf unseren Lorbeeren ausruhen und jetzt werden wir versuchen, "alle Säfte aus unserem Lager herauszupressen".
In diesem Artikel werde ich Ihnen erklären, wie Sie auf diese Weise ein fehlertolerantes iSCSI-Ziel erstellen, das wir mit LVM in kleine Stücke schneiden und für virtuelle Maschinen verwenden.
Dieser Ansatz reduziert die Last und erhöht die Geschwindigkeit des Zugriffs auf Daten um ein Vielfaches. Dies ist besonders dann von Vorteil, wenn kein wettbewerbsfähiger Zugriff auf Daten erforderlich ist, z. B. wenn Sie Speicher für virtuelle Maschinen organisieren müssen.
Ein paar Worte zu DRBD
DRBD ist eine ziemlich einfache und ausgereifte Lösung. Der Code der achten Version wird als Teil des Linux-Kernels übernommen. Tatsächlich handelt es sich um einen Netzwerkspiegel RAID1. In der neunten Version wurde die Unterstützung für Quorum und Replikation mit mehr als zwei Knoten eingeführt.
Tatsächlich können Sie Blockgeräte auf mehreren physischen Knoten in einem gemeinsamen Netzwerk kombinieren.
Mit DRBD können Sie sehr interessante Konfigurationen erzielen. Heute werden wir über iSCSI und LVM sprechen.
Sie können mehr darüber erfahren, indem Sie meinen vorherigen Artikel lesen, in dem ich diese Lösung ausführlich beschrieben habe.
Ein paar Worte zu iSCSI
iSCSI ist ein Block Device Delivery-Protokoll über ein Netzwerk.
Im Gegensatz zu NBD unterstützt es die Autorisierung, behebt Netzwerkfehler problemlos und unterstützt viele andere nützliche Funktionen. Vor allem zeigt es eine sehr gute Leistung.
Es gibt eine große Anzahl von Implementierungen, einige davon sind auch im Kernel enthalten und erfordern keine besonderen Schwierigkeiten bei der Konfiguration und Verbindung.
Ein paar Worte zu LVM
Es ist erwähnenswert, dass LINBIT eine eigene Lösung für Proxmox hat. Es sollte sofort funktionieren und ein ähnliches Ergebnis erzielen. In diesem Artikel möchte ich mich jedoch nicht nur auf Proxmox konzentrieren und eine universellere Lösung beschreiben, die sowohl für Proxmox als auch für Proxmox geeignet ist Alles andere, in diesem Beispiel, wird proxmox nur als Mittel zur Container-Orchestrierung verwendet. Sie können es sogar durch eine andere Lösung ersetzen, z. B. Container mit einem Ziel in Kubernetes starten.
Speziell für Proxmox funktioniert es gut mit gemeinsam genutzter LUN und LVM, wobei nur die eigenen Standardtreiber verwendet werden.
Zu den Vorteilen von LVM gehört die Tatsache, dass seine Verwendung nicht revolutionär neu und unzureichend eingefahren ist, sondern im Gegenteil eine Trockenstabilität aufweist, die normalerweise für die Lagerung erforderlich ist. Es ist erwähnenswert, dass LVM in anderen Umgebungen, beispielsweise in OpenNebula oder Kubernetes, sehr aktiv verwendet wird und dort recht gut unterstützt wird.
Auf diese Weise erhalten Sie universellen Speicher, der in verschiedenen Systemen (nicht nur in Proxmox) verwendet werden kann und nur vorgefertigte Treiber verwendet, ohne dass eine besondere Änderung mit einer Datei erforderlich ist.
Leider müssen Sie bei der Auswahl einer Speicherlösung immer einige Kompromisse eingehen. Diese Lösung bietet Ihnen also nicht die gleiche Flexibilität wie beispielsweise Ceph.
Die Größe der virtuellen Festplatte ist durch die Größe der LVM-Gruppe begrenzt, und der für eine bestimmte virtuelle Festplatte markierte Bereich wird notwendigerweise neu zugewiesen. Dies verbessert die Geschwindigkeit des Zugriffs auf Daten erheblich, ermöglicht jedoch keine Thin-Provisioning-Funktion (wenn die virtuelle Festplatte weniger Speicherplatz beansprucht als sie tatsächlich ist). Es ist erwähnenswert, dass die Leistung von LVM bei der Verwendung von Schnappschüssen stark nachlässt und daher die Möglichkeit ihrer freien Verwendung häufig ausgeschlossen ist.
Ja, LVM unterstützt Thin-Provision-Pools, die diesen Nachteil nicht aufweisen. Leider ist ihre Verwendung nur im Kontext eines Knotens möglich, und es gibt keine Möglichkeit, einen Thin-Provision-Pool für mehrere Knoten im Cluster freizugeben.
Trotz dieser Mängel erlaubt LVM aufgrund seiner Einfachheit den Wettbewerbern immer noch nicht, es zu umgehen und es vollständig vom Schlachtfeld zu verdrängen.
Mit einem relativ geringen Overhead bietet LVM immer noch eine sehr schnelle, stabile und ziemlich flexible Lösung.
Allgemeines Schema
- Wir haben drei Knoten
- Jeder Knoten verfügt über ein verteiltes drbd-Gerät .
- Über dem drbd-Gerät wird ein LXC-Container mit einem iSCSI-Ziel gestartet.
- Das Ziel ist mit allen drei Knoten verbunden.
- Auf dem verbundenen Ziel wurde eine LVM-Gruppe erstellt.
- Bei Bedarf kann der LXC-Container zusammen mit dem iSCSI-Ziel auf einen anderen Knoten verschoben werden
Anpassung
Wir haben die Idee jetzt herausgefunden und fahren mit der Implementierung fort.
Standardmäßig wird die achte Version von drbd mit dem Linux-Kernel geliefert. Leider passt sie nicht zu uns und wir müssen die neunte Version des Moduls installieren.
Verbinden Sie das LINBIT-Repository und installieren Sie alles, was Sie benötigen:
wget -O- https://packages.linbit.com/package-signing-pubkey.asc | apt-key add - echo "deb http://packages.linbit.com/proxmox/ proxmox-5 drbd-9.0" \ > /etc/apt/sources.list.d/linbit.list apt-get update && apt-get -y install pve-headers drbd-dkms drbd-utils drbdtop
pve-headers - Kernel-Header, die zum Erstellen des Moduls benötigt werdendrbd-dkms - Kernelmodul im DKMS-Formatdrbd-utils - grundlegende DRBD-Verwaltungsdienstprogrammedrbdtop ist ein interaktives Tool wie top nur für DRBD
Überprüfen Sie nach der Installation des Moduls, ob alles in Ordnung ist:
Wenn Sie die achte Version in der Ausgabe des Befehls sehen, ist ein Fehler aufgetreten und das Kernelmodul im Baum wird geladen. Überprüfen Sie den dkms status um herauszufinden, was der Grund ist.
Auf jedem Knoten, den wir haben, wird dasselbe drbd-Gerät auf regulären Partitionen ausgeführt. Zuerst müssen wir diesen Abschnitt für drbd auf jedem Knoten vorbereiten.
Eine solche Partition kann ein beliebiges Blockgerät sein , es kann sich um lvm, zvol, eine Festplattenpartition oder die gesamte Festplatte handeln. In diesem Artikel werde ich eine separate NVME-Festplatte mit einer Partition unter drbd verwenden: /dev/nvme1n1p1
Es ist erwähnenswert, dass sich Gerätenamen manchmal ändern. Es ist daher besser, sofort die Gewohnheit zu verwenden, einen konstanten Symlink zum Gerät zu verwenden.
Sie können einen solchen Symlink für /dev/nvme1n1p1 :
Wir beschreiben unsere Ressource auf allen drei Knoten:
Es wird empfohlen, ein separates Netzwerk für die drbd-Synchronisation zu verwenden.
Erstellen Sie nun die Metadaten für drbd und führen Sie sie aus:
Wiederholen Sie diese Schritte auf allen drei Knoten und überprüfen Sie den Status:
Jetzt befindet sich unsere inkonsistente Festplatte auf allen drei Knoten. Dies liegt daran, dass drbd nicht weiß, welche Festplatte als Original verwendet werden soll. Wir müssen einen von ihnen als primär markieren, damit sein Status mit den anderen Knoten synchronisiert wird:
drbdadm primary --force tgt1 drbdadm secondary tgt1
Unmittelbar danach beginnt die Synchronisation :
Wir müssen nicht warten, bis es fertig ist, und wir können parallel weitere Schritte ausführen. Sie können auf jedem Knoten ausgeführt werden , unabhängig vom aktuellen Status der lokalen Festplatte in DRBD. Alle Anforderungen werden automatisch mit dem Status UpToDate an das Gerät umgeleitet .
Vergessen Sie nicht, die automatische Ausführung des drbd-Dienstes auf den Knoten zu aktivieren:
systemctl enable drbd.service
Konfigurieren eines LXC-Containers
Wir werden den Konfigurationsteil des Proxmox-Clusters mit drei Knoten weglassen. Dieser Teil ist im offiziellen Wiki gut beschrieben
Wie ich bereits sagte, funktioniert unser iSCSI-Ziel in einem LXC-Container . Wir werden den Container auf dem Gerät /dev/drbd100 , das wir gerade erstellt haben.
Zuerst müssen wir ein Dateisystem darauf erstellen:
mkfs -t ext4 -O mmp -E mmp_update_interval=5 /dev/drbd100
Proxmox enthält standardmäßig einen Multimount-Schutz auf Dateisystemebene. Im Prinzip können wir darauf verzichten, da DRBD hat standardmäßig einen eigenen Schutz. Es verbietet lediglich die zweite Primärdatenbank für das Gerät, aber Vorsicht schadet uns nicht.
Laden Sie jetzt die Ubuntu-Vorlage herunter:
# wget http://download.proxmox.com/images/system/ubuntu-16.04-standard_16.04-1_amd64.tar.gz -P /var/lib/vz/template/cache/
Und erstellen Sie unseren Container daraus:
pct create 101 local:vztmpl/ubuntu-16.04-standard_16.04-1_amd64.tar.gz \ --hostname=tgt1 \ --net0=name=eth0,bridge=vmbr0,gw=192.168.1.1,ip=192.168.1.11/24 \ --rootfs=volume=/dev/drbd100,shared=1
In diesem Befehl geben wir an, dass sich das /dev/drbd100 unseres Containers auf dem Gerät /dev/drbd100 und fügen den Parameter shared=1 , um die Migration des Containers zwischen Knoten zu ermöglichen.
Wenn etwas schief gelaufen ist, können Sie es jederzeit über die Proxmox- Oberfläche oder in der Containerkonfiguration /etc/pve/lxc/101.conf
Proxmox entpackt die Vorlage und bereitet das Container- Root-System für uns vor. Danach können wir unseren Container starten:
pct start 101
Konfigurieren eines iSCSI-Ziels.
Aus der ganzen Reihe von Zielen habe ich istgt ausgewählt , da es die höchste Leistung aufweist und im Benutzerbereich funktioniert.
Melden wir uns jetzt in unserem Container an:
pct exec 101 bash
Installieren Sie Updates und istgt :
apt-get update apt-get -y upgrade apt-get -y install istgt
Erstellen Sie eine Datei, die wir über das Netzwerk weitergeben:
mkdir -p /data fallocate -l 740G /data/target1.img
Jetzt müssen wir eine Konfiguration für istgt /etc/istgt/istgt.conf schreiben:
[Global] Comment "Global section" NodeBase "iqn.2018-07.org.example.tgt1" PidFile /var/run/istgt.pid AuthFile /etc/istgt/auth.conf MediaDirectory /var/istgt LogFacility "local7" Timeout 30 NopInInterval 20 DiscoveryAuthMethod Auto MaxSessions 16 MaxConnections 4 MaxR2T 32 MaxOutstandingR2T 16 DefaultTime2Wait 2 DefaultTime2Retain 60 FirstBurstLength 262144 MaxBurstLength 1048576 MaxRecvDataSegmentLength 262144 InitialR2T Yes ImmediateData Yes DataPDUInOrder Yes DataSequenceInOrder Yes ErrorRecoveryLevel 0 [UnitControl] Comment "Internal Logical Unit Controller" AuthMethod CHAP Mutual AuthGroup AuthGroup10000 Portal UC1 127.0.0.1:3261 Netmask 127.0.0.1 [PortalGroup1] Comment "SINGLE PORT TEST" Portal DA1 192.168.1.11:3260 [InitiatorGroup1] Comment "Initiator Group1" InitiatorName "ALL" Netmask 192.168.1.0/24 [LogicalUnit1] Comment "Hard Disk Sample" TargetName disk1 TargetAlias "Data Disk1" Mapping PortalGroup1 InitiatorGroup1 AuthMethod Auto AuthGroup AuthGroup1 UseDigest Auto UnitType Disk LUN0 Storage /data/target1.img Auto
Neustart istgt:
systemctl restart istgt
Damit ist die Zieleinstellung abgeschlossen
HA-Setup
Jetzt können wir mit der HA-Manager- Konfiguration fortfahren. Erstellen wir eine separate HA-Gruppe für unser Gerät:
ha-manager groupadd tgt1 --nodes pve1,pve2,pve3 --nofailback=1 --restricted=1
Unsere Ressource funktioniert nur auf den für diese Gruppe angegebenen Knoten. Fügen Sie unseren Container dieser Gruppe hinzu:
ha-manager add ct:101 --group=tgt1 --max_relocate=3 --max_restart=3
Empfehlungen und Abstimmung
DRBD
Wie oben erwähnt, ist es immer ratsam, ein separates Netzwerk für die Replikation zu verwenden. Es wird dringend empfohlen, 10-Gigabit-Netzwerkadapter zu verwenden , da sonst die Portgeschwindigkeit beeinträchtigt wird.
Wenn die Replikation langsam genug erscheint, probieren Sie einige der Optionen für DRBD aus . Hier ist die Konfiguration, die meiner Meinung nach für mein 10G-Netzwerk optimal ist :
# cat /etc/drbd.d/global_common.conf global { usage-count yes; udev-always-use-vnr; } common { handlers { } startup { } options { } disk { c-fill-target 10M; c-max-rate 720M; c-plan-ahead 10; c-min-rate 20M; } net { max-buffers 36k; sndbuf-size 1024k; rcvbuf-size 2048k; } }
Weitere Informationen zu den einzelnen Parametern finden Sie in der offiziellen DRBD-Dokumentation.
Öffnen Sie iSCSI
Da wir kein Multipathing verwenden, wird in unserem Fall empfohlen, die regelmäßigen Verbindungsprüfungen auf Clients zu deaktivieren und die Wartezeiten für die Sitzungswiederherstellung in /etc/iscsi/iscsid.conf .
node.conn[0].timeo.noop_out_interval = 0 node.conn[0].timeo.noop_out_timeout = 0 node.session.timeo.replacement_timeout = 86400
Verwenden Sie
Proxmox
Das resultierende iSCSI-Ziel kann sofort mit Proxmox verbunden werden, ohne die Option " LUN direkt verwenden" zu deaktivieren.
Unmittelbar danach ist es möglich, LVM darüber zu erstellen. Vergessen Sie nicht, das freigegebene Kontrollkästchen zu aktivieren:
Andere Umgebungen
Wenn Sie diese Lösung in einer anderen Umgebung verwenden möchten, müssen Sie möglicherweise eine Clustererweiterung für LVM installieren, da zwei Implementierungen vorhanden sind. CLVM und lvmlockd .
Das Konfigurieren von CLVM ist nicht trivial und erfordert einen funktionierenden Cluster-Manager.
Als zweite Methode ist lvmlockd noch nicht vollständig getestet und erscheint gerade erst in stabilen Repositorys.
Ich empfehle, einen ausgezeichneten Artikel über das Blockieren in LVM zu lesen
Bei Verwendung von LVM mit Proxmox ist das Hinzufügen von Clustern nicht erforderlich , da die Datenträgerverwaltung von proxmox selbst bereitgestellt wird, das LVM-Metadaten unabhängig aktualisiert und überwacht. Gleiches gilt für OpenNebula , wie aus der offiziellen Dokumentation eindeutig hervorgeht.