Shared LVM gewünscht: FC-SAN?

[aaron]

Zwei Stück 10G NICs und ein (DAC) Kabel dazwischen kosten zum glück auch nicht die Welt. ZB die Aquantia Chipsätze sind recht günstig. Man muss nur aufpassen, dass die NIC einen Chipsatz hat der vom Kernel supported wird:
https://www.kernel.org/doc/html/v7.0/networking/device_drivers/ethernet/aquantia/atlantic.html
Steht gleich zu Beginn welche das sind.

 

[sgw]

Zwei Stück 10G NICs und ein (DAC) Kabel dazwischen kosten zum glück auch nicht die Welt. ZB die Aquantia Chipsätze sind recht günstig. Man muss nur aufpassen, dass die NIC einen Chipsatz hat der vom Kernel supported wird:
https://www.kernel.org/doc/html/v7.0/networking/device_drivers/ethernet/aquantia/atlantic.html
Steht gleich zu Beginn welche das sind.

Ahja, Aquantia war mir kein Begriff (Marvell aber schon). Danke für den Hinweis.

 

[sgw]

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!

 

[Falk R.]

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.

 

[Johannes S]

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.

 

[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.

 

[Johannes S]

* 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.

 

[sgw]

@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.

 

[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.

 

[sgw]

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.

 

[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 mit ssh als Root auf die Cluster-Knoten kann und umgekehrt.

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

[TUTORIAL] Thread 'FabU: How to setup a Quorum Device and secure it by disabling root access.'

Mar 10, 2026

Statement: it is not required to allow root@cluster to login to a separate “Quorum Device”-machine after installation.

The “tl;dr” boils down to a single line:

~$ echo "PermitRootLogin no" | sudo tee /etc/ssh/sshd_config.d/permitrootlogin.conf

(( This is Debian, and it comes without “sudo” by default. I am still trying to convince myself that “passwordless sudo” actually is a great idea... ))

This post is definitely much longer than required. (Perhaps I have too much spare time...) I prefer to leave it in this state as I believe too few details are worse than too many...

• UdoB
• quorum quorum device quorum node
• Replies: 4
• Forum: Proxmox VE: Networking and Firewall

• 

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 Debian-server oder das nas nehmen.

 

[sgw]

Danke! Das verlinkte Howto von @UdoB notiere ich mir gleich für später. Ob NAS oder Debian-Server, mal sehen. Einer der Debian-Server hat bereits QEMU/KVM drauf, allerdings bin ich noch nicht sicher, ob der in Betrieb bleibt usw. / Ich drehe dort gefühlt jeden Stein um, während zugleich der Betrieb ungestört weiter läuft, quasi Guten Morgen allen

VM oä auf QNAP: Muss ich mir ansehen, sobald das NAS vor Ort läuft, das dauert noch etwas.

 

[Johannes S]

VM oä auf QNAP: Muss ich mir ansehen, sobald das NAS vor Ort läuft, das dauert noch etwas.

Dann bleibt ja nur der Server, wenn der Cluster vor Inbetriebnahme des BAS laufen soll. Ohne qdevice würde ich keinen zwei-Knoten-Cluster betreiben.

 

[sgw]

Dann bleibt ja nur der Server, wenn der Cluster vor Inbetriebnahme des BAS laufen soll. Ohne qdevice würde ich keinen zwei-Knoten-Cluster betreiben.

Nein: Das NAS ist bereits bei mir, wird noch vor den PVEs online sein dort.

 

[Johannes S]

Nein: Das NAS ist bereits bei mir, wird noch vor den PVEs online sein dort.

Dann gucken, ob das vms oder docker-Container kann, das wäre dann die beste Variante. Die VM kann sehr schlank sein ( eine vCPU und 512 mb bis 1gb RAM bei 5 gb storage reichen völlig aus) und mit aktivierten unattended-upgrades ( inklusive automatiscgen reboot, das muss händisch aktiviert werden!) hat es minimalen Wartungsaufwand.

 

[sgw]

Dann gucken, ob das vms oder docker-Container kann, das wäre dann die beste Variante. Die VM kann sehr schlank sein ( eine vCPU und 512 mb bis 1gb RAM bei 5 gb storage reichen völlig aus) und mit aktivierten unattended-upgrades ( inklusive automatiscgen reboot, das muss händisch aktiviert werden!) hat es minimalen Wartungsaufwand.

Das QNAP kann virtualisieren, ja. Zum Anlegen einer solchen VM komme ich aber erst kommende Woche (mit genügend Vorlauf, Rack und Server sind noch nicht eingetroffen). Danke!

 

[sgw]

Vielleicht sollte (und dürfte) ich einen neuen Thread dazu anlegen, mittlerweile bin ich ja deutlich weg von "FC-SAN" ...

Ich hab das NAS am Start, und installiere heute die kleine VM für mein Quorum. Dazu natürlich gleich wieder Fragen:

Soweit ich verstehe, wird der Corosync-Traffic auf den PVEs auf einer gesonderten NIC laufen. Ich werde dafür ein VLAN anlegen, und am Switch 2 Ports nativ in das VLAN stellen und dort die 2 NICs connecten. Die Quorum-VM bekommt dann auch eine IP in diesem VLAN ... dieses will ich nun per Virtual Switch am NAS für die VM da drauf bereitstellen. Korrekt so? Schon klar, es gibt immer mehrere Wege ..

Was passiert im Betrieb des PVE-Clusters, wenn zB das NAS (upgrades?) mit der Quorum-VM kurz weg ist? Baue ich mir so eine Situation ala "never touch that NAS" ?

 

[Falk R.]

Vielleicht sollte (und dürfte) ich einen neuen Thread dazu anlegen, mittlerweile bin ich ja deutlich weg von "FC-SAN" ...

Ich hab das NAS am Start, und installiere heute die kleine VM für mein Quorum. Dazu natürlich gleich wieder Fragen:

Soweit ich verstehe, wird der Corosync-Traffic auf den PVEs auf einer gesonderten NIC laufen.

Richtig, es wird eine dedizierte NIC empfohlen.

Ich werde dafür ein VLAN anlegen, und am Switch 2 Ports nativ in das VLAN stellen und dort die 2 NICs connecten.

Empfehlen würde ich eine Single NIC auf einem Dedizierten Switch oder bei 2 Node Clustern direkt gesteckt zu nutzen.
Wenn dein Switch ausfällt, bringt die extra NIC sonst gar nichts.

Die Quorum-VM bekommt dann auch eine IP in diesem VLAN ... dieses will ich nun per Virtual Switch am NAS für die VM da drauf bereitstellen. Korrekt so? Schon klar, es gibt immer mehrere Wege ..

Die Quorum VM muss nicht im Corosync VLAN laufen, es reicht wenn das Quorum über das Management erreichbar ist.

Was passiert im Betrieb des PVE-Clusters, wenn zB das NAS (upgrades?) mit der Quorum-VM kurz weg ist? Baue ich mir so eine Situation ala "never touch that NAS" ?

Wenn das Quorum weg ist, passiert gar nichts, solange in dem Moment nicht einer der Hosts offline geht

 

[sgw]

Richtig, es wird eine dedizierte NIC empfohlen

Mache ich auf den PVEs so.

Empfehlen würde ich eine Single NIC auf einem Dedizierten Switch oder bei 2 Node Clustern direkt gesteckt zu nutzen.
Wenn dein Switch ausfällt, bringt die extra NIC sonst gar nichts.

OK ... Dann connecte ich die direkt, danke. Dann vergebe ich dort ein eigenes Subnetz, aber das braucht dann kein VLAN zu sein, das über alle Switches hinweg verfügbar ist (habe ich grade ausgerollt ;-) aber macht nix).

Die Quorum VM muss nicht im Corosync VLAN laufen, es reicht wenn das Quorum über das Management erreichbar ist.

OK, danke, das hilft mir, da denke ich noch mal neu drüber nach.
Ich habe soeben die neue Quorum-VM in einem VLAN online.

Security-theoretisch dachte ich, ich separiere den Corosync-Stuff komplett weg, aber das ist vielleicht overkill.
Vielleicht verwende ich das neu ausgerollte VLAN gleich mal für die Management-IPs des Clusters UND die Corosync-IPs ...

Wenn das Quorum weg ist, passiert gar nichts, solange in dem Moment nicht einer der Hosts offline geht

Das beruhigt mich sehr, gut, das so explizit zu lesen. thx!

 

[devaux]

Betreffend Backup:
Schaut Euch mal die NAS von UGREEN (z.B. DXP4800 Plus) an. Die sind offen und man kann direkt PBS darauf installieren (hat ein kleines 128GB SSD-Storage eingebaut).
Einmal 10Gbit und einmal 2.5Gbit NIC. Perfekt fuer einmal Management-Zugriff und einmal schnelle Verbindung fuer die Backups. Zusaetzlich haben sie zwei Slots fuer NVMe die man perfekt fuer Special vdev ZFS einsetzen kann. Hat man dann noch ein altes NAS mit spinning SATA-Platten rumliegen kann man diese wunderbar damit beschleunigen.
So hat man dann um 700 Euro einen dedizierten, schnellen und kostenguenstigen Backup-Server.