Shared LVM gewünscht: FC-SAN?

  • Like
Reactions: Johannes S
Mein Projekt wurde beauftragt, die Hardware bestellt, ich habe jetzt mal etwas verschnauft und warte ohnehin auf Elektriker und die Lieferungen ;)

Irgendwann muss ich mich dann aber einlesen in Sachen ZFS-Replication (plus dem HA-Part für PVE), ein Start dazu erscheint mir das hier zu sein:

https://pve.proxmox.com/wiki/PVE-zsync

Dann hat mir noch jemand das hier gemailt: https://gitlab.bashclub.org/bashclub/zsync/

Darf ich Euch noch um den Hinweis bitten, wo ich am Besten zum Thema weiterlese?

ZFS ist mir geläufig soweit, allerdings habe ich es bislang noch nicht auf einem PVE eingesetzt.
HA hab ich bei dem Kunden mit dem FC-SAN am Laufen.

Selbstverständlich durchsuche ich das Forum, bislang bin ich aber von der Vielzahl der gefundenen Einträge (zu "ZFS Repliaction") überfordert.

Danke im Voraus!
 
Mein Projekt wurde beauftragt, die Hardware bestellt, ich habe jetzt mal etwas verschnauft und warte ohnehin auf Elektriker und die Lieferungen ;)

Irgendwann muss ich mich dann aber einlesen in Sachen ZFS-Replication (plus dem HA-Part für PVE), ein Start dazu erscheint mir das hier zu sein:

https://pve.proxmox.com/wiki/PVE-zsync

Dann hat mir noch jemand das hier gemailt: https://gitlab.bashclub.org/bashclub/zsync/

Darf ich Euch noch um den Hinweis bitten, wo ich am Besten zum Thema weiterlese?

ZFS ist mir geläufig soweit, allerdings habe ich es bislang noch nicht auf einem PVE eingesetzt.
HA hab ich bei dem Kunden mit dem FC-SAN am Laufen.

Selbstverständlich durchsuche ich das Forum, bislang bin ich aber von der Vielzahl der gefundenen Einträge (zu "ZFS Repliaction") überfordert.

Danke im Voraus!
Hi, wenn du nicht so Fit damit bist, lass das lieber mit den Scripten.
Du kannst ganz Simpel in der GUI bei jeder VM die Replikation aktivieren und bei jeder VM einen eigenen Intervall einstellen.
Wenn der Sync gelaufen ist, einfach HA aktivieren für die VM.

Das ist Simpel und für jeden nachvollziehbar. Wenn du mit Scripten arbeitest wie die vom BashClub dann bitte gut Dokumentieren und gut ins Thema ZFS einlesen.
Ich mache immer die Simple Methode bei meinen Kunden, da die Einstellungen in der GUI für jeden Nachvollziehbar sind und das ganze Rocksolid funktioniert.
 
  • Like
Reactions: sgw
Irgendwann muss ich mich dann aber einlesen in Sachen ZFS-Replication (plus dem HA-Part für PVE), ein Start dazu erscheint mir das hier zu sein:

https://pve.proxmox.com/wiki/PVE-zsync

Nein, wie auf der Seite auch erklärt ist das ein anderes PVE-Feature mit anderen Usecase ( https://pve.proxmox.com/wiki/PVE-zsync#PVE_Storage_Replication_and_PVE-zsync )

Für deinen Zweck ist https://pve.proxmox.com/wiki/Storage_Replication relevant und dazu hat Falk ja schon das Wesentliche geschrieben, solange du keine besonderen Anforderungen hast, lässt sich das vollständig über die GUI abbilden.

pve-zsync ist tatsächlich ein älteres Feature, was dazu auch clusterübergreifend funktioniert und auf den gleichen Features von zfs basiert, lässt sich aber NICHT für die HA-Funktion in PVE verwenden, Storage Replication schon.
 
  • Like
Reactions: sgw
Danke @Johannes S und @Falk R.

Das Script hat mich ohnehin nicht sonderlich angezogen ;)

https://pve.proxmox.com/wiki/Storage_Replication hab ich mal überflogen, bin aber noch nicht sicher, wie ich den Beginn gestalte:

ich denke in der Richtung:

* Beide PVEs installieren, mit gleichnamigen(?) ZFS-Pools als local storage
* Drittes Device (separate Debian-Kiste) als Quorum-Device vorbereiten .. https://pve.proxmox.com/wiki/Cluster_Manager#_corosync_external_vote_support // EDIT: besser: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_corosync_external_vote_support

* HA / Corosync einrichten = "Cluster aufbauen"
* und dann ZFS-Replication einrichten, im GUI? Für einzelne VMs optional.

Ich warte gerne noch ab, bis ich die 2 Nodes habe, und versuche das dann selbst ... / Nur mal vorab als gedankliche Stütze für mich.
 
Last edited:
* Beide PVEs installieren, mit gleichnamigen(?) ZFS-Pools als local storage
* Drittes Device (separate Debian-Kiste) als Quorum-Device vorbereiten
* HA / Corosync einrichten = "Cluster aufbauen"
* und dann ZFS-Replication einrichten, im GUI? Für einzelne VMs optional.

Genauso, im Idealfall vor den Zusammenschalten zum Cluster auch schon die verschiedenenen Netzwerkkarten je nach Funktion vorkonfigurieren und verkabeln. Wichtig ist dabei dass der ZFS- und Corosync-Traffic vom Rest des Traffics (VM untereinander, Clients, Management) getrennt sind getrennt sind, ZFS und corosync kriegen jeweils einen dezidierten Link, damit zuviel Traffic in einen dir nicht den Rest zerschießt, der ZFS-Traffic kommt dann auf eine 10Gbit-Karte, corosync kommt auch mit 1Gbit zurecht:
https://pve.proxmox.com/wiki/Cluster_Manager#pvecm_cluster_network
https://pve.proxmox.com/wiki/Storage_Replication#_network

Beim Storagenetz kann man auch per Konfigdatei konfigurieren, dass der Datenverkehr nicht verschlüsselt wird. Wenn die beiden hosts direkt miteinander reden, ist das ja kein Sicherheitsproblem und macht das ganze noch mal deutlich schneller.


Da du ja erwähnt hast, insgesamt viermal 1Gbit in den Kisten zu haben, sind dann noch zwei Ports offen, wovon eins dann für ein Management-Netzwerk genutzt werden können (damit von außen niemand an das Webinterface/die ssh-Konsole der Hosts kommt). Außerdem bietet sich natürlich an sämtliche Netzwerkkarten auch als Fallback für corosync zu hinterlegen, idealerweise direkt beim Anlegen des Clusters:
https://pve.proxmox.com/wiki/Cluster_Manager#pvecm_redundancy

Dafür kann dann auch das Storage-Netzwerk und ggf. (du hattest ja erwähnt dass für den Traffic der VM envtl. eine weitere 10G oder 25G Karte reinkommt) eine weitere eingebaute Karte genutzt werden, ist ja nur als Fallback ;)

Bevor das ganze in Produktion gibt, würde es sich natürlich auch anbieten zusammen mit den Kunden einmal ein paar Notfall- und Wartungsszenarien (ein Knoten fällt aus, Backups müssen zurückgespielt werden, Neustart eines Knotens nach Systemupdates etc) durchzuspielen. Im Idealfall freut der Kunde sich dann schon über die erhöhte Verfügbarkeit und falls was doch schieflaufen sollte, kann man das noch glattziehen, bevor daran tatsächlich wichtige Sachen darauf laufen.
 
Last edited:
@Johannes S Danke mal ganz schnell für den guten Überblick. Teils war es mir schon klar so, teils hilft es mir super weiter ;-)
Ich melde mich wieder, sobald ich neue Fragen habe ;-) Danke Euch!

EDIT: Genau so habe ich das auch vor: der neue Cluster steht erst mal testweise separat nebendran, und erst wenn ich alles so habe, dass ich es (a) verstehe und (b) getestet habe, kommen VMs für die Mitarbeiter drauf etc / ich hab das ganze Projekt mit ausreichend Zeit "verkauft" und habe noch keinen besonderen Druck drauf.

Ich habe erst mal mehr NICs drin, als ich ad hoc brauche, das wird eine der ersten Tätigkeiten, dass ich die ganze Netzwerk-Config aufbaue und möglichst sinnvoll gestalte. Da befasse ich mich dann konkret, wenn die Kisten da sind und laufen. Ich habe ja von anderen Kunden-Setups schon ganz gute Vorlagen, von denen ich ausgehen kann (zB Bonding ...).

Das dritte Quorum-Device stelle ich mir als corosync-Daemon auf einem separaten Debian-Server vor, bin ich da zu naiv?

Ich will vermeiden, etwaige Fehler zu machen, die dann nicht mehr zu korrigieren sind: ich denke an irgendwelche Blocksizes rund um die NVMes und ZFS, soll ich da auf irgendwas achten? Sowas kriegt man ja dann nicht mehr weg. Generell befürche ich da aber keine schlechte Performance.
 
Last edited:
  • Like
Reactions: Johannes S
Das dritte Quorum-Device stelle ich mir als corosync-Daemon auf einem separaten Debian-Server vor, bin ich da zu naiv?
Korrekt, auf den Knoten muss aber auch ein Dienst laufen, das steht aber auch alles in der Doku erklärt: https://pve.proxmox.com/wiki/Cluster_Manager#_corosync_external_vote_support

Anders als bei den Knoten braucht der NICHT eine dezidierte Karte für das Cluster-Netzwerk. Ich finde es aber fast Verschwendung, einen Server nur als qdevice zu verwenden, es gibt ja Leute die dafür (allerdings im Heimbereich) einen Raspberry-PI nutzen.
Insofern würde ich mir überlegen, ob man darauf nicht noch andere Dienste laufen lässt, etwa eine Monitoring-Software, den Bacula-Server (du hattest ja erwähnt, dass ihr das als Backupsoftware nutzt) oder PBS. Für eine saubere Isolierung würde es sich dabei anbieten, dafür auf diesen Server PVE als single-node-Instanz (also NICHT Teil eines Clusters!) einzurichten und dort dann die verschiedenen Dienste (qdevice, bacula, Monitoring, envtl. Jumphost zu den PVE-Hosts im Management-netzwerk) als dezidierte VMs oder lxcs. Lediglich einen PBS würde ich bare-metal paarlael installieren, damit der auch bei nicht funktionierenden PVE noch erreichbar ist.
 
  • Like
Reactions: UdoB
Korrekt, auf den Knoten muss aber auch ein Dienst laufen, das steht aber auch alles in der Doku erklärt: https://pve.proxmox.com/wiki/Cluster_Manager#_corosync_external_vote_support

Anders als bei den Knoten braucht der NICHT eine dezidierte Karte für das Cluster-Netzwerk. Ich finde es aber fast Verschwendung, einen Server nur als qdevice zu verwenden, es gibt ja Leute die dafür (allerdings im Heimbereich) einen Raspberry-PI nutzen.
Insofern würde ich mir überlegen, ob man darauf nicht noch andere Dienste laufen lässt, etwa eine Monitoring-Software, den Bacula-Server (du hattest ja erwähnt, dass ihr das als Backupsoftware nutzt) oder PBS. Für eine saubere Isolierung würde es sich dabei anbieten, dafür auf diesen Server PVE als single-node-Instanz (also NICHT Teil eines Clusters!) einzurichten und dort dann die verschiedenen Dienste (qdevice, bacula, Monitoring, envtl. Jumphost zu den PVE-Hosts im Management-netzwerk) als dezidierte VMs oder lxcs. Lediglich einen PBS würde ich bare-metal paarlael installieren, damit der auch bei nicht funktionierenden PVE noch erreichbar ist.

Ich wollte das auf einen der beiden vorhandenen Samba-AD-DCs dazu packen ... die haben sonst nicht viel zu tun. Die machen AD-DC und ISC-Kea-Cluster, da würde mir das thematisch gut dazu passen ...

* Bacula wird in Phase 1 eine VM auf dem Cluster sein, also nicht geeignet
* PI: nein

Ich will es auf einen der Debian-Server dazu packen, das ist der Wunsch. Ideal isoliert etc ist das aber vermutlich eher nicht (und damit würde ich leben, denke ich). Einen Samba-File-Server löse ich auch ab im Laufe der Monate, aber das scheint mir Overkill, so eine fette Hardware dafür laufen zu lassen.

Ein QNAP-NAS deploye ich auch ... da hab ich auch schon davon gelesen, dass manche das als Quorum-Device nutzen.
 
  • Like
Reactions: Johannes S
Ich will es auf einen der Debian-Server dazu packen, das ist der Wunsch. Ideal isoliert etc ist das aber vermutlich eher nicht (und damit würde ich leben, denke ich). Einen Samba-File-Server löse ich auch ab im Laufe der Monate, aber das scheint mir Overkill, so eine fette Hardware dafür laufen zu lassen.
Das ist insofern problematisch, weil man dann vom qdevice per root und ssh auf die Cluster-Knoten kann und umgekehrt.

@UdoB hat beschrieben, wie sich das absichern lässt:


Sauberer wäre es aber das in einer eigenen kleinen vm, lxc oder docker-container laufen zu lassen, dafür kann man natürlich den vorhandenen devian-server oder das nas nehmen.
 
  • Like
Reactions: UdoB