KVM + DRBD wurde zwischen zwei Aktiv-Passiv-Servern mit manueller Umschaltung repliziert

Ich muss eine 2-Knoten-Cluster-Lösung (ähnlich?) Im Aktiv-Passiv-Modus erstellen, dh ein Server ist aktiv, während der andere passiv (Standby) ist, wodurch die Daten kontinuierlich von aktiv repliziert werden. KVM-basierte virtuelle Maschinen würden auf einem aktiven Knoten ausgeführt.

Falls der aktive Knoten aus irgendeinem Grund nicht verfügbar ist, möchte ich manuell zum zweiten Knoten wechseln (aktiv und der andere passiv werden).

Ich habe dieses Tutorial gesehen: https://www.alteeve.com/w/AN!Cluster_Tutorial_2#Technologies_We_Will_Use

Ich bin jedoch nicht mutig genug, vollautomatischem Failover zu vertrauen und etwas so Komplexes zu erstellen und darauf zu vertrauen, dass es richtig funktioniert. Zu hohes Risiko für Split-Brain-Situationen, irgendwie fehlgeschlagene Komplexität, Datenkorruption usw., während meine maximale Ausfallzeit nicht so hoch ist, dass ein sofortiges automatisches Failover erforderlich ist.

Ich habe Probleme, Informationen zum Erstellen dieser Art von Konfiguration zu finden. Wenn Sie dies getan haben, teilen Sie bitte die Info / HOWTO in einer Antwort.

Oder ist es vielleicht möglich, mit Linux-Knoten ein hochzuverlässiges automatisches Failover zu erstellen? Das Problem mit der Hochverfügbarkeit von Linux ist, dass das Interesse an dem Konzept wie vor 8 Jahren stark zugenommen zu haben scheint und viele Tutorials mittlerweile ziemlich alt sind. Dies deutet darauf hin, dass es in der Praxis möglicherweise erhebliche Probleme mit HA gegeben hat und einige / viele Sysadmins es einfach fallen ließen.

Wenn dies möglich ist, teilen Sie uns bitte die Informationen zum Erstellen und Ihre Erfahrungen mit Clustern mit, die in der Produktion ausgeführt werden .

Ich habe eine sehr ähnliche Installation mit dem von Ihnen beschriebenen Setup: einen KVM-Server mit einem Standard-Replikat über DRBD aktiv / passiv. Um ein System so einfach wie möglich zu haben (und um ein automatisches Split-Brain zu vermeiden, dh weil mein Kunde mit dem Clusternetzwerk in Konflikt gerät), habe ich auch das automatische Cluster-Failover eingestellt.

Das System ist mindestens 5 Jahre alt und hat mir nie Probleme bereitet. Mein Volume-Setup ist wie folgt:

• ein dediziertes RAID-Volume für VM-Speicher;
• ein kleines Overlay-Volume mit QEMU / KVM-Konfigurationsdateien;
• größere Volumes für virtuelle Festplatten;
• DRBD-Ressourcen, die das gesamte dedizierte Array-Blockgerät verwalten.

Ich habe einige Shell-Skripte geschrieben, um mir im Falle eines Failovers zu helfen. Sie finden sie hier

Bitte beachten Sie, dass das System für maximale Leistung ausgelegt wurde, auch auf Kosten von Funktionen wie schnellen Snapshots und dateibasierten (anstatt volumenbasierten) virtuellen Festplatten.

Wenn ich jetzt ein ähnliches Aktiv / Passiv-Setup neu aufbaue, würde ich mich stark auf die Verwendung von ZFS und die kontinuierliche asynchrone Replikation über konzentrieren send/recv. Es ist keine blockbasierte Echtzeitreplikation, aber für mehr als 90% mehr als ausreichend.

Wenn eine Echtzeitreplikation wirklich benötigt wird, würde ich DRBD zusätzlich zu einem ZVOL + XFS verwenden. Ich habe ein solches Setup + einen automatischen Schrittmacherschalter in meinem Labor mit großer Zufriedenheit getestet. Wenn die Verwendung von 3rdy-Teilemodulen (wie ZoL) nicht möglich ist, würde ich DRBD-Ressourcen zusätzlich zu einem lvmthinVolume + XFS verwenden.

Warum nicht Dinge verwenden, die von Tausenden von Benutzern überprüft wurden und deren Zuverlässigkeit bewiesen haben? Sie können einfach einen kostenlosen Hyper-V-Server mit beispielsweise StarWind VSAN Free bereitstellen und ohne Probleme echte HA erhalten. Lesen Sie dieses Handbuch: https://www.starwindsoftware.com/resource-library/starwind-virtual-san-hyperconverged-2-node-scenario-with-hyper-v-server-2016

Sie können DRBD vollständig einrichten und rein manuell verwenden. Der Prozess sollte überhaupt nicht komplex sein. Sie würden einfach das tun, was ein Schrittmacher- oder Rgmanager-Cluster tut, aber von Hand. Im Wesentlichen:

• Stoppen Sie die VM auf dem aktiven Knoten
• DRBD auf dem aktiven Knoten herabstufen
• Heraufstufen von DRBD auf dem Peer-Knoten
• Starten Sie die VM auf dem Peer-Knoten

Dies setzt natürlich voraus, dass auf beiden Knoten die richtigen Pakete installiert sind und die Konfigurationen und Definitionen der VM auf beiden Knoten vorhanden sind.

Ich kann versichern, dass der Linux HA-Stack (Corosync und Schrittmacher) noch aktiv entwickelt und unterstützt wird. Viele Anleitungen sind alt, die Software gibt es schon seit 10 Jahren. Wenn es richtig gemacht wird, gibt es keine größeren Probleme oder Probleme. Es wird nicht aufgegeben, aber es ist nicht mehr "neu und aufregend".

Aktiv / Passiv-Cluster werden an vielen Orten immer noch häufig verwendet und laufen in der Produktion. Nachfolgend finden Sie unser Produktionssetup . Es funktioniert einwandfrei. Sie können es entweder im manuellen Modus ( orchestrate=start) laufen lassen oder das automatische Failover aktivieren ( orchestrate=ha). Wir verwenden zfs, um von zfs Sende- / Empfangs- und zfs-Snapshots zu profitieren. Es ist jedoch auch möglich, drbd zu verwenden, wenn Sie eine synchrone Replikation bevorzugen.

Voraussetzungen:

• 2 Knoten (in meinem Setup 2 physische Knoten 400 Kilometer Entfernung)
• interne Festplatten
• 1 zfs-Pool auf jedem Knoten
• Stretched VLAN (in meinem Setup verwenden wir "Vrack" bei OVH Hosting Provider)

Schritte :

• Installieren Sie den opensvc-Agenten auf beiden Knoten ( https://repo.opensvc.com ).
• Formular opensvc cluster (3 Befehle erforderlich, beschrieben im Screencast unter https://www.opensvc.com )
• Erstellen Sie eine Root-SSH-Vertrauensstellung zwischen beiden Knoten
• Erstellen Sie 1 opensvc-Dienst pro kvm-Gast [Dienstkonfigurationsdatei unten]

root @ node1: ~ $ svcmgr -s win1 print config

[DEFAULT]
env = PRD
nodes = node1.acme.com node2.acme.com
id = 7a10881d-e5d5-4817-a8fe-e7a2004c5520
orchestrate = start

[fs#1]
mnt_opt = rw,xattr,acl
mnt = /srv/{svcname}
dev = data/{svcname}
type = zfs

[container#0]
type = kvm
name = {svcname}
guestos = windows
shared = true

[sync#1]
src = data/{svcname}
dst = data/{svcname}
type = zfs
target = nodes
recursive = true
schedule = @12h

Einige Erklärungen:

• Der Dienst heißt "win1" und jeder {svcname}in der Dienstkonfigurationsdatei ist eine Referenz, die auf den tatsächlichen Dienstnamen (win1) verweist.
• Service-Start Gehen Sie wie folgt vor:
  • Mount-ZFS-Dataset data/win1auf Mountpoint/srv/win1
  • Starten Sie den KVM-Container win1
• ressource sync#1wird verwendet, um eine asynchrone zfs-Dataset-Replikation an den Slave-Knoten zu deklarieren (data / win1 auf Knoten1 wird an data / win1 auf Knoten2 gesendet), einmal pro 12 Stunden im Beispiel (zfs-Senden / Empfangen wird vom opensvc-Agenten verwaltet).
• Der opensvc-Agent befasst sich auch mit der Replikation von kvm qemu config und definiert diese, wenn der Dienst auf den Slave-Knoten verlagert wird

Einige Verwaltungsbefehle:

• svcmgr -s win1 start Starten Sie den Dienst
• svcmgr -s win1 stop Beenden Sie den Dienst
• svcmgr -s win1 stop --rid container#0 Stoppen Sie den Container-referenzierten Container # 0 in der Konfigurationsdatei
• svcmgr -s win1 switch Verschieben Sie den Dienst auf den anderen Knoten
• svcmgr -s win1 sync update Lösen Sie eine inkrementelle Kopie des zfs-Datasets aus
• svcmgr -s win1 sync full Lösen Sie eine vollständige Kopie des zfs-Datasets aus

Einige von mir verwaltete Dienste benötigen außerdem regelmäßig (täglich / wöchentlich / monatlich) zfs-Snapshots mit Aufbewahrung. In diesem Fall füge ich der Dienstkonfigurationsdatei das folgende Konfigurations-Snippet hinzu, und der opensvc-Agent erledigt den Job.

[sync#1sd]
type = zfssnap
dataset = data/{svcname}
schedule = 23:00-23:59@61
keep = 7
name = daily
recursive = true
sync_max_delay = 1d

[sync#1sw]
type = zfssnap
dataset = data/{svcname}
schedule = 23:00-23:59@61 sun
keep = 4
name = weekly
recursive = true
sync_max_delay = 7d

[sync#1sm]
type = zfssnap
dataset = data/{svcname}
schedule = 23:00-23:59@61 * *:first
keep = 6
name = monthly
recursive = true
sync_max_delay = 31d

Wie gewünscht füge ich auch eine lvm / drbd / kvm-Konfiguration hinzu:

drbd resource config /etc/drbd.d/kvmdrbd.res:

resource kvmdrbd {
    device /dev/drbd10;
    disk /dev/drbdvg/drbdlv;
    on node1 {
        address 1.2.3.4:12345;
        meta-disk internal;
    }
    on node2 {
        address 4.3.2.1:12345;
        meta-disk internal;
    }
}

opensvc service config file /etc/opensvc/kvmdrbd.conf:

root@node1# svcmgr -s kvmdrbd print config
[DEFAULT]
env = PRD
nodes = node1.acme.com node2.acme.com
id = 7a10881d-f4d3-1234-a2cd-e7a2018c4321
orchestrate = start

[disk#1]
type = lvm
vgname = {env.drbdvgname}
standby = true

[disk#2]
type = drbd
standby = true
shared = true
res = {svcname}

[fs#0]
mnt = {env.basedir}/{svcname}
type = ext4
dev = /dev/{env.drbddev}
shared = true

[container#0]
type = kvm
name = {svcname}
shared = true

[sync#i0]
schedule = @1440

[env]
basedir = /srv
drbddev = drbd10
drbdvgname = drbdvg

Einige Erklärungen :

• In meinem Setup repliziere ich lvm lv mit drbd. Ich erstelle ein Dateisystem auf dem drbd-Blockgerät. In diesem Dateisystem erstelle ich 1 Flatfile pro Festplatte, die ich dem kvm-Gast präsentieren möchte.
• disk#1: ist die lvm vg, die das große logische Volume hostet. sollte mindestens 5 GB betragen.
• disk#2: ist die drbd-Festplatte, auf die der drbd-Ressourcenname verweist. Wenn der opensvc-Dienst "foo" heißt, sollten Sie /etc/drbd.d/foo.res haben. Oder ändern Sie den Parameter disk # 2.res in der Servicekonfigurationsdatei.
• fs#0 : Das Hauptdateisystem, in dem alle Festplattendateien für kvm guest gehostet werden
• container#0: der kvm-Gast, gleicher Name wie der opensvc-Dienst im Beispiel. Der Agent muss in der Lage sein, den kvm-Gast mit DNS aufzulösen und eine Ping-Prüfung durchzuführen, bevor er den Start des Dienstes akzeptiert (wenn eine Ping-Antwort vorliegt, wird der kvm-Gast bereits irgendwo ausgeführt, und es ist keine gute Idee, ihn zu starten. Der doppelte Startschutz ist gewährleistet von opensvc agent)
• standby = true: bedeutet, dass diese Ressource aktiv bleiben muss, wenn der Dienst auf dem anderen Knoten ausgeführt wird. In unserem Beispiel ist es erforderlich, dass drbd weiterhin einwandfrei funktioniert
• shared = true: https://docs.opensvc.com/latest/agent.service.provisioning.html#shared-resources

Ich bin derzeit mit einem extrem ähnlichen System beschäftigt. 2 Server, einer aktiv, ein Backup und beide haben ein paar VMs in sich. Die Datenbank wird repliziert und die Dateiserver sind ständig mit rsync synchronisiert (aber nur in eine Richtung). Im Notfall wird der sekundäre Server bedient. Es gab die Idee, Pacemaker und Corosync zu verwenden, aber da dies 100% sein muss, hatte ich nicht den Mut zu experimentieren. Meine Idee ist, dass NginX über die Server wacht. Dies könnte geschehen, weil ich eine Webanwendung verwende, aber in Ihrem Fall weiß ich nicht, ob Sie sie verwenden könnten. DRBD ist ein Chaos für mich. Die vorherigen Server verwendeten es und während es anscheinend funktionierte, fühlte es sich an, als würde ich versuchen, einen menschlichen Körper zu sezieren.

Überprüfen Sie dies, es könnte Ihnen helfen: http://jensd.be/156/linux/building-a-high-available-failover-cluster-with-pacemaker-corosync-pcs

In einer kleinen Umgebung, in der ich es bereits ausprobiert und gearbeitet habe, sieht es nicht schwer aus. Leicht zu erlernen, leicht herzustellen, leicht zu warten. Eigentlich denke ich, dass Sie danach suchen.