Wahrscheinlich hat jeder, der mindestens einmal von der Suche nach hochleistungsfähigem, softwaredefiniertem Speicher verwirrt war, früher oder später von DRBD gehört oder sich vielleicht sogar damit befasst.
Auf dem Höhepunkt der Popularität von Ceph und GlusterFS , die im Prinzip ziemlich gut funktionieren und vor allem sofort einsatzbereit sind, haben alle nur ein wenig vergessen. Darüber hinaus unterstützte die vorherige Version die Replikation auf mehr als zwei Knoten nicht, und aus diesem Grund traten häufig Probleme mit dem geteilten Gehirn auf, was eindeutig nicht zu seiner Popularität beitrug.
Die Lösung ist wirklich nicht neu, aber ziemlich wettbewerbsfähig. Mit relativ geringen Kosten für CPU und RAM bietet DRBD eine sehr schnelle und sichere Synchronisation auf Blockgeräteebene . Während dieser ganzen Zeit stehen LINBIT-DRBD-Entwickler nicht still und entwickeln sie ständig weiter. Ab der DRBD9- Version ist es nicht mehr nur ein Netzwerkspiegel und wird zu etwas mehr.
Erstens ist die Idee, ein einzelnes verteiltes Blockgerät für mehrere Server zu erstellen, in den Hintergrund getreten, und jetzt versucht LINBIT, Tools zum Orchestrieren und Verwalten vieler drbd-Geräte in einem Cluster bereitzustellen, die auf LVM- und ZFS-Partitionen erstellt werden .
DRBD9 unterstützt beispielsweise bis zu 32 Replikate, RDMA, plattenlose Knoten und neue Orchestrierungswerkzeuge, mit denen Sie Snapshots, Online-Migration und vieles mehr verwenden können.
Trotz der Tatsache, dass DRBD9 über Integrationstools mit Proxmox , Kubernetes , OpenStack und OpenNebula verfügt , befinden sie sich derzeit in einem Übergangsmodus, in dem neue Tools noch nicht überall unterstützt werden und alte sehr bald als veraltet angekündigt werden. Dies sind DRBDmanage und Linstor .
Ich werde diesen Moment nutzen, um nicht viel auf die Details eines jeden von ihnen einzugehen , sondern um die Konfiguration und die Prinzipien der Arbeit mit DRBD9 selbst genauer zu untersuchen. Sie müssen es noch herausfinden, schon allein deshalb, weil die fehlertolerante Konfiguration des Linstor-Controllers die Installation auf einem dieser Geräte impliziert.
In diesem Artikel möchte ich Sie über DRBD9 und die Möglichkeit seiner Verwendung in Proxmox ohne Plug-Ins von Drittanbietern informieren .
DRBDmanage und Linstor
Zunächst ist noch einmal DRBDmanage zu erwähnen, das sich sehr gut in Proxmox integriert . LINBIT bietet ein vorgefertigtes DRBDmanage-Plugin für Proxmox, mit dem Sie alle Funktionen direkt über die Proxmox- Oberfläche nutzen können.
Es sieht wirklich toll aus, hat aber leider einige Nachteile.
- Zunächst müssen die markierten Datenträgernamen, die LVM-Gruppe oder der ZFS-Pool den Namen
drbdpool . - Unfähigkeit, mehr als einen Pool pro Knoten zu verwenden
- Aufgrund der Besonderheiten der Lösung kann das Controller-Volume nur auf einem normalen LVM und nicht anders sein
- Periodische dbus- Störungen, die von DRBDmanage eng zur Interaktion mit Knoten verwendet werden.
Infolgedessen entschied sich LINBIT, die gesamte komplexe DRBDmanage-Logik durch eine einfache Anwendung zu ersetzen, die über eine reguläre TCP-Verbindung mit Knoten kommuniziert und dort ohne Magie funktioniert. Da war also Linstor .
Linstor funktioniert wirklich sehr gut. Leider haben die Entwickler Java als Hauptsprache für das Schreiben des Linstor-Servers gewählt, aber lassen Sie sich davon nicht abschrecken, da Linstor sich nur mit der Verteilung von DRBD- Konfigurationen und dem Aufteilen von LVM / ZFS-Partitionen auf Knoten befasst.
Beide Lösungen sind kostenlos und werden unter der kostenlosen GPL3- Lizenz vertrieben .
Sie können über jeden von ihnen und über das Einrichten des oben genannten Plug- Ins für Proxmox im offiziellen Proxmox-Wiki lesen
Failover-NFS-Server
Leider ist Linstor zum Zeitpunkt des Schreibens nur in Kubernetes integriert. Ende des Jahres werden jedoch Treiber für die übrigen Proxmox- , OpenNebula- und OpenStack- Systeme erwartet.
Bisher gibt es jedoch keine vorgefertigte Lösung, aber wir mögen die alte auf die eine oder andere Weise nicht. Versuchen wir, DRBD9 auf die altmodische Weise zu verwenden, um den NFS-Zugriff auf eine gemeinsam genutzte Partition zu organisieren.
Diese Lösung wird sich jedoch auch als nicht ohne Vorteile erweisen, da Sie mit dem NFS-Server den wettbewerbsfähigen Zugriff auf das Speicherdateisystem von mehreren Servern aus organisieren können, ohne komplexe Cluster-Dateisysteme mit DLM wie OCFS und GFS2 zu benötigen.
In diesem Fall können Sie die Rollen des primären / sekundären Knotens einfach durch Migrieren des Containers mit dem NFS-Server in der Proxmox-Schnittstelle wechseln.
Sie können auch alle Dateien in diesem Dateisystem sowie virtuelle Festplatten und Sicherungen speichern.
Wenn Sie Kubernetes verwenden , können Sie den ReadWriteMany- Zugriff für Ihre PersistentVolumes arrangieren.
Proxmox- und LXC-Container
Die Frage ist nun: Warum Proxmox?
Um ein solches Schema zu erstellen, könnten wir im Prinzip Kubernetes sowie das übliche Schema mit einem Cluster-Manager verwenden. Proxmox bietet jedoch eine vorgefertigte, sehr multifunktionale und gleichzeitig einfache und intuitive Benutzeroberfläche für fast alles, was Sie benötigen. Es ist sofort einsatzbereit und unterstützt den auf Softdog basierenden Fencing- Mechanismus. Wenn Sie LXC-Container verwenden, können Sie beim Umschalten minimale Zeitüberschreitungen erzielen.
Die resultierende Lösung weist keinen einzigen Fehlerpunkt auf .
Tatsächlich werden wir Proxmox hauptsächlich als Cluster-Manager verwenden , wobei wir einen separaten LXC-Container als Dienst betrachten können, der in einem klassischen HA-Cluster ausgeführt wird, nur mit dem Unterschied, dass das Root-System auch mit dem Container geliefert wird . Das heißt, Sie müssen nicht mehrere Dienstinstanzen auf jedem Server separat installieren, sondern können dies nur einmal im Container tun.
Wenn Sie jemals mit Cluster-Manager-Software gearbeitet und HA für Anwendungen bereitgestellt haben, werden Sie verstehen, was ich meine.
Allgemeines Schema
Unsere Lösung ähnelt dem Standardreplikationsschema einer Datenbank.
- Wir haben drei Knoten
- Jeder Knoten verfügt über ein verteiltes drbd-Gerät .
- Das Gerät verfügt über ein reguläres Dateisystem ( ext4 )
- Nur ein Server kann ein Master sein
- Der NFS-Server im LXC-Container wird im Assistenten gestartet.
- Alle Knoten greifen ausschließlich über NFS auf das Gerät zu .
- Bei Bedarf kann der Assistent zusammen mit dem NFS-Server auf einen anderen Knoten wechseln
DRBD9 hat eine sehr coole Funktion, die alles stark vereinfacht:
Das drbd-Gerät wird automatisch primär , sobald es auf einem Knoten gemountet ist. Wenn das Gerät als primär markiert ist, führt jeder Versuch, es auf einem anderen Knoten bereitzustellen, zu einem Zugriffsfehler. Dies gewährleistet eine Blockierung und einen garantierten Schutz gegen gleichzeitigen Zugriff auf das Gerät.
Warum vereinfacht sich das alles stark? Denn wenn der Container gestartet wird, stellt Proxmox dieses Gerät automatisch bereit und es wird auf diesem Knoten primär. Wenn der Container stoppt, wird es im Gegenteil aufgehoben und das Gerät wird wieder sekundär .
Somit müssen wir uns nicht mehr um das Wechseln von Primär- / Sekundärgeräten kümmern, Proxmox erledigt dies automatisch , Hurra!
DRBD-Setup
Nun, wir haben die Idee herausgefunden. Nun gehen wir zur Implementierung über.
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
Nach der Installation des Moduls prüfen wir , 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 nfs1 drbdadm secondary nfs1
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, arbeitet unser NFS-Server 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=nfs1 \ --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 Sie einen NFS-Server.
Standardmäßig lässt Proxmox nicht zu, dass der NFS-Server im Container ausgeführt wird. Es gibt jedoch verschiedene Möglichkeiten, ihn zu aktivieren.
Eine davon ist das Hinzufügen von lxc.apparmor.profile: unconfined zur /etc/pve/lxc/100.conf unseres Containers.
Oder wir können NFS für alle Container fortlaufend aktivieren. Dazu müssen wir die Standardvorlage für LXC auf allen Knoten aktualisieren und die folgenden Zeilen zu /etc/apparmor.d/lxc/lxc-default-cgns :
mount fstype=nfs, mount fstype=nfs4, mount fstype=nfsd, mount fstype=rpc_pipefs,
Starten Sie den Container nach den Änderungen neu:
pct shutdown 101 pct start 101
Jetzt melden wir uns an:
pct exec 101 bash
Installieren Sie Updates und NFS-Server :
apt-get update apt-get -y upgrade apt-get -y install nfs-kernel-server
Export erstellen:
echo '/data *(rw,no_root_squash,no_subtree_check)' >> /etc/exports mkdir /data exportfs -a
HA-Setup
Zum Zeitpunkt des Schreibens weist der HA-Manager von proxmox einen Fehler auf , der verhindert, dass der HA-Container seine Arbeit erfolgreich abschließt. Infolgedessen verhindern die Kernel-Space- Prozesse des NFS-Servers , die nicht vollständig beendet wurden, dass das drbd-Gerät Secondary verlässt. Wenn Sie bereits auf eine solche Situation gestoßen sind, sollten Sie nicht in Panik geraten und einfach killall -9 nfsd auf dem Knoten ausführen, auf dem der Container gestartet wurde. Dann sollte das drbd-Gerät "freigeben" und es geht zu Secondary .
Führen Sie die folgenden Befehle auf allen Knoten aus, um diesen Fehler zu beheben:
sed -i 's/forceStop => 1,/forceStop => 0,/' /usr/share/perl5/PVE/HA/Resources/PVECT.pm systemctl restart pve-ha-lrm.service
Jetzt können wir mit der HA-Manager- Konfiguration fortfahren. Erstellen wir eine separate HA-Gruppe für unser Gerät:
ha-manager groupadd nfs1 --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=nfs1 --max_relocate=3 --max_restart=3
Das ist alles. Einfach, richtig?
Der resultierende NFS-Ball kann sofort mit Proxmox verbunden werden, um andere virtuelle Maschinen und Container zu speichern und auszuführen.
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.
NFS-Server
Um den Betrieb des NFS-Servers zu beschleunigen , kann es hilfreich sein, die Gesamtzahl der ausgeführten Instanzen des NFS-Servers zu erhöhen. Standardmäßig - 8 , persönlich hat es mir geholfen, diese Zahl auf 64 zu erhöhen.
Aktualisieren Sie dazu den Parameter RPCNFSDCOUNT=64 in /etc/default/nfs-kernel-server .
Und starte die Dämonen neu:
systemctl restart nfs-utils systemctl restart nfs-server
NFSv3 gegen NFSv4
Kennen Sie den Unterschied zwischen NFSv3 und NFSv4 ?
- NFSv3 ist ein zustandsloses Protokoll, das Fehler in der Regel besser toleriert und schneller wiederherstellt .
- NFSv4 ist ein Stateful-Protokoll , es arbeitet schneller und kann an bestimmte TCP-Ports gebunden werden. Aufgrund des vorhandenen Status ist es jedoch empfindlicher gegenüber Fehlern. Es hat auch die Möglichkeit, die Authentifizierung mit Kerberos und einer Reihe anderer interessanter Funktionen zu verwenden.
Wenn Sie jedoch showmount -e nfs_server , wird das NFSv3-Protokoll verwendet. Proxmox verwendet auch NFSv3. NFSv3 wird auch häufig zum Organisieren von Netzwerkstartmaschinen verwendet.
Wenn Sie keinen besonderen Grund für die Verwendung von NFSv4 haben, versuchen Sie im Allgemeinen, NFSv3 zu verwenden, da es bei Fehlern aufgrund des Fehlens eines Status als solchen weniger schmerzhaft ist.
Sie können den Ball mit NFSv3 mounten, indem Sie den Parameter -o vers=3 für den Befehl mount angeben:
mount -o vers=3 nfs_server:/share /mnt
Wenn Sie möchten, können Sie NFSv4 für den Server im Allgemeinen deaktivieren. --no-nfs-version 4 Variablen --no-nfs-version 4 Option --no-nfs-version 4 und starten Sie den Server neu. Beispiel:
RPCNFSDCOUNT="64 --no-nfs-version 4"
iSCSI und LVM
In ähnlicher Weise kann ein regulärer tgt-Daemon im Container konfiguriert werden, iSCSI bietet eine deutlich höhere Leistung für E / A-Vorgänge und der Container funktioniert reibungsloser, da der tgt-Server vollständig im Benutzerbereich arbeitet.
In der Regel wird eine exportierte LUN mithilfe von LVM in viele Teile geschnitten. Es sind jedoch mehrere Nuancen zu berücksichtigen, z. B. wie LVM- Sperren für die gemeinsame Nutzung einer exportierten Gruppe auf mehreren Hosts bereitgestellt werden.
Vielleicht werde ich diese und andere Nuancen im nächsten Artikel beschreiben .