Cluster - Corosync - nur 1 nic - VLAN nutzen?

[dekiesel]

Hi,

Ich bin dabei einen 3-node-cluster für mein Homelab zu bauen. Zwei der Maschinen haben nur ein NIC (2 Mini PCs), aber alle 3 nodes sind am selben (switch (mikrotik).

Hier eine beispielhafte /etc/network/interfaces

auto lo
iface lo inet loopback

iface eno1 inet manual

auto vmbr0.100
iface vmbr0.100 inet static
        address  10.1.100.12/24
        gateway  10.1.100.1

auto vmbr0
iface vmbr0 inet manual
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

iface vmbr0 inet6 dhcp
    gateway fd00::1
    accept_ra 2

Der host ist bereits in einem low traffic VLAN (100), da wird nur ein bisschen gestreamt, aber ich nehme an VMs werden über das gleiche VLAN migriert in dem auch der Host sitzt?

Folgende Fragen kamen mir und ich hoffe, jemand kann ein paar beantworten
1) Machen VLANs hier überhaupt einen Unterschied?
2) Falls ja, sollte ich ein eigenes "Corosync"-VLAN erstellen
3) Gibt es andere Einstellungen die die Latenz für Corosync verbessern könnten?

Vielen Dank!

 

[Johannes S]

Der host ist bereits in einem low traffic VLAN (100), da wird nur ein bisschen gestreamt, aber ich nehme an VMs werden über das gleiche VLAN migriert in dem auch der Host sitzt?

Jein, standardmäß ist das VLAN nicht relevant (solange man nichts ändert), es wird für die Migration immer das gleiche Netzwerk genommen, wie corosync, was nicht ganz optimal ist (mehr dazu gleich).

Folgende Fragen kamen mir und ich hoffe, jemand kann ein paar beantworten
1) Machen VLANs hier überhaupt einen Unterschied?

Nein, der Grund für die Empfehlung für corosync ein eigenes Netzwerk zu haben ist, dass corosync sehr empfindlich auf Latenzen reagiert. Wenn also z.B. das Netzwerk durch Streaming, Migrationen oder anderen Datenverkehr komplett dicht ist, wie soll dann das VLAN bei Latenzen helfen?

Meine Empfehlung wäre (so habe ich das bei meinen Mini-PCs gemacht), für die Mini-PCs USB-Ethernet-Adapter zu kaufen und damit dann das Corosync-Netzwerk zu realisieren. Braucht dann halt noch einen dezidierten Switch, aber das muss ja alles keine teure Hardware sein, im Clusternetz hängen ja eh nur die Clusterknoten (braucht also keinen Support für VLANs o.ä.). Zusätzlich richtest dein normales Netzwerk dann als Fallback für Redundanz ein:
https://pve.proxmox.com/wiki/Cluster_Manager#pvecm_redundancy

Achtung: Standardmäßig wird das corosync-netzwerk auch für Migrations- (und wenn man das nutzt) den Traffic der Storage-Replication genutzt, sobald man zwei Netzwerke hat, sollte man das auftrennen, damit wenigstens ein Netzwerk exklusiv von corosync genutzt wird: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_guest_migration

Generell stelle ich mir aber auch die Frage, wozu du einen Cluster brauchst? Willst du die High-Availability-Features nutzen? Dann brauchst du auch shared Storage, also eine NAS o.ä., Ceph oder ZFS Storage-Replication. Ceph macht mit der typischen Netzwerk- und Storage hardware von Mini-PCs keinen Spaß, da man dafür mindestens 10GB und mehrere SSDs haben sollte: https://forum.proxmox.com/threads/fabu-can-i-use-ceph-in-a-_very_-small-cluster.159671/

Für ZFS Storage-Replication oder die Nutzung einer NAS ist das natürlich nicht nötig, eine NAS wird aber auch relativ lahm im Zugriff sein, wenn du darauf die VMs hostest.
Wenn du dagegen die High-Availability-Features nicht nutzen willst, brauchst du auch nicht unbedingt einen Cluster, eine Migration zwischen den Knoten geht auch ohne Cluster mit den ProxmoxDatacenterManager (den man auch gut in einer VM betreiben kann).
Hast du dir Gedanken um ein Backup gemacht? Mini-PCs sind sehr dankbare (weil wenig Strom verbrauchende) Optionen für einen ProxmoxBackupServer.

3) Gibt es andere Einstellungen die die Latenz für Corosync verbessern könnten?

Bei den Standardeinstellungen für corosync sollte man nur was anpassen, wenn man weiß, was man tut (ich tue es nicht). Dafür gibt es im Regelfall keinen Grund. Auf Reddit hat mal jemand geschrieben, dass er einen Cluster mit 30 Knoten betrieb und der mit den Standardeinstlellungen nicht sehr stabil war. Er hat also den Proxmoxsupport eingeschaltet (praktisch wenn man zahlender Kunde ist). Der hat ihn dann erklärt, dass die Standardeinstellungen für Cluster bis 19 Knoten einen stabilen Betrieb garantieren sollten. Hat man mehr Knoten, ist die Empfehlung entweder den Cluster in mehrere aufzuspalten oder bestimmte Einstellungen anzupassen. Der Support hat dann einen ähnlichen Cluster in ihren Labor nachgebaut und damit mehrere Einstellungen getestet und dann dem Kunden (also den Redditer) mitgegeben. Damit hat das dann nach dem finalen Tuning in der Produktion auch geklappt. Aber: Die entsprechende Einstellung sorgte dafür, dass er mehr Knoten benutzen konnte, aber corosync auf Latenzen noch empfindlicher reagierte und das Cluster-Netzwerk auch entsprechend dazu passen musste. Das war da kein Problem, aber davon kann eben nicht bei jeder Umgebung ausgegangen werden, darum sind die Standardeinstellungen wie sie sind. Diese Anekdote sollte verdeutlichen, warum wir Heimuser nichts daran "verbessern" sollten.

 

[dekiesel]

Wow, vielen lieben Dank für deine ausführliche Antwort!

Ich erzähle wohl besser kurz wie mein bisheriger Plan ist, ich hoffe dann macht der Rest des Textes mehr Sinn.

Ich möchte ein NAS haben (befindet sich im Bau). Auf diesem Nas sollen "ein paar" HDDs als mirrored pool laufen und Daten bereitstellen für user (samba) und an VMs und LXCs (ich denke hier ist NFS am besten?).
Auf dem NAS soll auch eine VM laufen da sie am meisten auf den Speicher zugreifen wird.
NAS-root und die VM sollen auf einer SSD sein.

Alles andere soll auf einem von zwei MiniPCs laufen. Wenn einer dieser MiniPCs ausfällt sollen die wichtigen Services "automatisch" auf dem jeweils anderen MiniPC weiter laufen. Root disks der VMs und LXCs sind auf den MiniPCs und sollen nächtlich synchronisiert werden. Ich habe gelesen das wäre möglich, finde aber jetzt natürlich nichts dazu.
Grösserer Platzbedarf (alles was unter Datengrab fällt) soll von den MiniPCs auf dem NAS abgelegt werden und im Failover Szenario soll der ersetzende MiniPC da weiter machen wo der andere aufgehört hat.

Wenn ich dafür keinen Cluster brauche ist das auch absolut ok für mich, ich dachte nur das wäre unabdingbar?

Die USB-Ethernet-Adapter Idee finde ich fantastisch, vielen Dank!

Braucht dann halt noch einen dezidierten Switch, aber das muss ja alles keine teure Hardware sein, im Clusternetz hängen ja eh nur die Clusterknoten (braucht also keinen Support für VLANs o.ä.).

Wieso bräuchte ich einen dedizierten Switch? Hat das was mit der Latenz zu tun oder mit den Bandbreiten-Spikes?

Vielen Dank nochmal!!

 

[Johannes S]

Ich möchte ein NAS haben (befindet sich im Bau). Auf diesem Nas sollen "ein paar" HDDs als mirrored pool laufen und Daten bereitstellen für user (samba) und an VMs und LXCs (ich denke hier ist NFS am besten?).
Auf dem NAS soll auch eine VM laufen da sie am meisten auf den Speicher zugreifen wird.
NAS-root und die VM sollen auf einer SSD sein.

Warum dann überhaupt ProxmoxVE, wenn der Hauptsinn eine NAS + 1-3 VM ist? Die gängigen NAS-Betriebssysteme (UnRaid,TrueNAS, OpenMediaVault) können auch alle VMs hosten. Wenn der Hauptsinn des entsprechenden Systems ist, eine NAS bereitzustellen, wozu dann noch ProxmoxVE und dessen steilere Lernkurve und Komplexität? Was für eine VM und NAS_Software willst du denn einsetzen?

Zu den Daten: Kann man so machen.

Alles andere soll auf einem von zwei MiniPCs laufen. Wenn einer dieser MiniPCs ausfällt sollen die wichtigen Services "automatisch" auf dem jeweils anderen MiniPC weiter laufen. Root disks der VMs und LXCs sind auf den MiniPCs und sollen nächtlich synchronisiert werden. Ich habe gelesen das wäre möglich, finde aber jetzt natürlich nichts dazu.

Ja, das funktioniert so. Relevante Lektüre:
https://pve.proxmox.com/wiki/Storage_Replication
https://pve.proxmox.com/wiki/High_Availability

Für HA braucht man aber zwingend einen dritten Knoten, da man sonst ein Splitbrain-Szenario riskiert (sehr grob erklärt: Knoten im Cluster müssen regelmäßig ein Quorum bestimmen, dafür braucht es Mehrheiten, die ein Zwei-Knoten-Cluster nicht haben kann).
Glücklicherweise braucht es dafür aber nicht zwingend einen dritten ProxmoxVE-Knoten, man kann auch ein Device außerhalb des Clusters dafür nehmen, z.B. einen PI oder eine VM auf einen Server, der NICHT Teil des Cluster ist:
https://pve.proxmox.com/wiki/Cluster_Manager#_corosync_external_vote_support

Selbst als docker-container geht: https://forum.proxmox.com/threads/how-to-run-a-qdevice-in-docker.141679/

Man könnte also das auch in einen schlanken Container oder kleine VM (meine qdevice-VM hat aktuell 512 MB RAM und vermutlich auch weniger gehen) auf dem NAS-Knoten laufen lassen. So ein qdevice braucht auch nicht die gleiche Latenz wie die normalen corosync-Knoten, braucht also auch kein extra Netzwerk, solange die corosync-Knoten nur überhaupt darauf zugreifen können.

Grösserer Platzbedarf (alles was unter Datengrab fällt) soll von den MiniPCs auf dem NAS abgelegt werden und im Failover Szenario soll der ersetzende MiniPC da weiter machen wo der andere aufgehört hat.

Wenn ich dafür keinen Cluster brauche ist das auch absolut ok für mich, ich dachte nur das wäre unabdingbar?

Die USB-Ethernet-Adapter Idee finde ich fantastisch, vielen Dank!

Braucht dann halt noch einen dezidierten Switch, aber das muss ja alles keine teure Hardware sein, im Clusternetz hängen ja eh nur die Clusterknoten (braucht also keinen Support für VLANs o.ä.).

Wieso bräuchte ich einen dedizierten Switch? Hat das was mit der Latenz zu tun oder mit den Bandbreiten-Spikes?

Naja, wie verbindest du drei Knoten, sodass sich alle erreichen können, wenn du keinen Switch hast? Für ein mesh-Netzwerk bräuchtest du ja pro Knoten zwei Netzwerkkarten (siehe: https://pve.proxmox.com/wiki/Full_Mesh_Network_for_Ceph_Server das beschreibt so ein Setup für Ceph, gilt so aber auch für corosync). Wenn du dagegen nur zwei Knoten im corosync-netzwerk hast, dann braucht es auch keinen Switch

Was mir noch unklar ist, wie du deine NAS und VMs/LXCs sicherst. Ich selbst fahre da zweigleisig (näheres ist hier beschrieben: https://forum.proxmox.com/threads/o...upt-ihr-eure-vms-und-files.174054/post-809135 ), indem ich die Daten auf der NAS unabhängig von den VMs und lxcs sichere. Genauer gesagt backupe ich die VMs und lxcs in einen lokalen ProxmoxBackupServer, dessen Backups wiederum auf einen PBS auf einen vserver gesichert werden. Für die Daten auf der NAS und Notebook nutze ich restic.

In deinen Fall wäre es eine Überlegung, deinen NAS-Knoten auch für den ProxmoxBackupServer zu nutzen. Entweder indem du ihn als VM einrichtest oder (falls du trotzdem ProxmoxVE als Basis nutzen möchtest) parallel zum PVE. Letzteres hätte den Vorteil, dass man (bei knappen Ressourcen) das qdevice auch in einen Debian-Container laufen lassen könnte. Die Idee habe ich vom Proxmox-Entwickler Aaron, der beschreibt sein Setup hier:
https://forum.proxmox.com/threads/planning-advice.169434/#post-791732

So oder so würde ich den NAS-Knoten dann nicht in den Cluster aufnehmen.

Ich würde dann den NAS-Knoten aber trotzdem nicht in den Cluster aufnehmen. Mit den DatacenterManager (der läuft im Cluster) kann man ja im Bedarfsfall auch zwischen dem Cluster und NAS-PVE VMs/Container hin- und herschieben.