Bislang habe ich EINE NIC pro Node für beides konfiguriert. Aber ich verstehe ... und werde das noch entsprechend erweitern/umbauen. Danke!
Datacenter und/oder Cluster mit local storage only
- Thread starter sgw
- Start date
Frage vorab zum weiteren Umbau des Clusters:
irgendwann wollen wir voraussichtlich die Nodes entfernen, die keine Controller für die Anbindung ans MSA-Storage haben ... die 3 temporären Nodes kommen also evtl. wieder weg (man wird sehen ...).
Darunter ist auch der Node, auf dem ich den Cluster ursprünglich angelegt habe. Hat der irgendeine besondere Rolle/Eigenschaft, die ich vor Entfernen evtl auf einen anderen Node übertragen muss? Oder kann ich den auch einfach so entfernen? Ich vermute Letzteres, frage aber lieber nach, bevor was kaputt geht ;-) (ich komme auf den Gedanken, weil ich gestern beim Testen eines Packer-Setups die URL des ersten Nodes verwenden musste für den Zugriff auf die API ... kann das sein? Muss ich noch mal in Ruhe testen.)
irgendwann wollen wir voraussichtlich die Nodes entfernen, die keine Controller für die Anbindung ans MSA-Storage haben ... die 3 temporären Nodes kommen also evtl. wieder weg (man wird sehen ...).
Darunter ist auch der Node, auf dem ich den Cluster ursprünglich angelegt habe. Hat der irgendeine besondere Rolle/Eigenschaft, die ich vor Entfernen evtl auf einen anderen Node übertragen muss? Oder kann ich den auch einfach so entfernen? Ich vermute Letzteres, frage aber lieber nach, bevor was kaputt geht ;-) (ich komme auf den Gedanken, weil ich gestern beim Testen eines Packer-Setups die URL des ersten Nodes verwenden musste für den Zugriff auf die API ... kann das sein? Muss ich noch mal in Ruhe testen.)
hier bin ich noch unschlüssig. Das Setzen auf "threads" wäre beim nun anstehenden Migrieren der VMs für alle Disks zu machen.
Gewinnt man mehr durch Einsatz von 6.8, und verliert evtl Performance durch "threads" ?
Oder lieber Pinnen von 6.2 (really? Nicht 6.5.x?) und nichts anfassen müssen ... dafür aber älterer Kernel.
Habe gestern testweise ein Packer-Script ausgeführt (proxmox-iso), für die Disk kann ich den aio-Parameter setzen, aber nicht für das ISO, ergo scheiterte das Script gleich mal. Ist nicht *wichtig* für mich, aber Test für zukünftige Dinge. Und ein anderer Thread, ja
OK; ich besorge Switch 2 und Kabel.
Ich lasse mal ein, zwei Test-VMs auf einem Node zu (der Kunde ist schon neugierig), vermutlich ist das nicht gleich riskant.
Ich hab ja eine NIC für den Upstream-Traffic und bereits eine separate NIC für OCFS2 und Corosync ("Loop1").
So wie ich das verstehe, geht es um den Fall, dass Corosync wegen zu viel anderem Traffic verzögert wird. Das dürfte ja nicht der Fall sein bei wenigen VMs mit wenig IO.
Ich war unpräzise: ich meinte den Traffic des OCFS2-Clusters. Das ist wohl kein tatsächlicher Inhalt von Files, aber Meta-Daten oä, richtig?
Mein Loop2 kommt heute so gegen 13:15h dran ;-)
Bin kurz vor dem Hinzufügen ... habe allerdings das nächste Verständnis-Problem:
ich wollte nur 3 von 6 Nodes mit einem 2. Loop versehen (die mit dem OCFS2-Storage). Da bin ich mir aber nicht so sicher, ob das klappt bzw. unterstützt wird ... Geht also vermutlich eher in die Richtung "6 Kabel an 2. Switch" ... bringt klarerweise noch mehr Redundanz und schadet nicht.
EDIT: bereits erledigt. 6 Nodes mit je 2 Links im Cluster: fein.
Last edited:
Ich hab jetzt erstmal auf 6.2.16-20-pve gepinnt (auf den 3 Nodes mit OCFS2). Wenn man das AIO-Setting vergisst, wird es sonst unschön.
Alter Thread hier, aber nachdem ich in genau diesem Cluster ein Problem habe, verweise ich mal auf das hier: https://forum.proxmox.com/threads/inplace-upgrade-8to9-unsupported-ocfs2-issues.171693/
Kurz: irgendwas startet zu früh, während was anderes noch nicht online ist ... zumindest ist das mein aktuelles Verständnis.
In dem pdf https://www.heinlein-support.de/sit...ments/2022-03/Proxmox und Storage vom SAN.pdf sind ja einige overrides erwähnt, die auf derlei Abhängigkeiten abzielen. Hat da wer von Euch ein hilfreiches Update dazu? Danke ...
Kurz: irgendwas startet zu früh, während was anderes noch nicht online ist ... zumindest ist das mein aktuelles Verständnis.
In dem pdf https://www.heinlein-support.de/sit...ments/2022-03/Proxmox und Storage vom SAN.pdf sind ja einige overrides erwähnt, die auf derlei Abhängigkeiten abzielen. Hat da wer von Euch ein hilfreiches Update dazu? Danke ...
Peinlich, aber wahr: es dürfte nur daran gelegen haben, dass der Service `ocfs2.service` aus irgendeinem Grund disabled war.
Manuell hab ich das definitiv nicht gemacht, dürfte irgendwie im Rahmen des Upgrades passiert sein. Und ich hab das wochenlang übersehen (hatte das Thema auch mittlerweile liegen gelassen ...).
Manuell hab ich das definitiv nicht gemacht, dürfte irgendwie im Rahmen des Upgrades passiert sein. Und ich hab das wochenlang übersehen (hatte das Thema auch mittlerweile liegen gelassen ...).
Hallo @sgw,
danke für die Rückmeldung. Gut zu wissen, dass das Upgrade auf PVE 9 die Services o2cb und ocfs2 deaktiviert.
Da du das Problem nun gelöst hast, könntest du dir das Kernel-Pinning noch einmal ansehen. Wie von @gurubert in Post #31 erwähnt, könntest du mit dem aktuellen Kernel arbeiten, wenn du für die VMs auf dem OCFS2-Storage die Option aio=threads setzt. Das würde das Pinning auf die ältere Version überflüssig machen.
danke für die Rückmeldung. Gut zu wissen, dass das Upgrade auf PVE 9 die Services o2cb und ocfs2 deaktiviert.
Da du das Problem nun gelöst hast, könntest du dir das Kernel-Pinning noch einmal ansehen. Wie von @gurubert in Post #31 erwähnt, könntest du mit dem aktuellen Kernel arbeiten, wenn du für die VMs auf dem OCFS2-Storage die Option aio=threads setzt. Das würde das Pinning auf die ältere Version überflüssig machen.
Das ist mir für ~50 VMs etwas zu viel Action, das manuell durchzugehen. Und was, wenn der Kunde eine neue VM ohne diese Optionen anlegt?
Natürlich wäre der aktuellere Kernel zu bevorzugen. Danke für den Reminder.
OK, ich nehme den Impuls ernst ;-) und hab das grade mit dem Kunden abgesprochen.
Vielleicht muss ich in den anderen Thread mit meinen Fragen, ich stelle sie mal, auch weil ich vorsichtig bin:
Das Setting betrifft die Storage-Settings der VM, richtig? (ich suche mir das gleich noch mal konkreter raus)
Wenn ich in meinem Cluster 3 Nodes habe, und aktuell fahren alle Kernel-6.2.12 ... wenn ich dieses Setting in einer VM ändere, klappt das auch mit 6.2.12, korrekt?
Und wenn ich einen von 3 Nodes mit 6.14 boote, hat das keinerlei Auswirkungen auf das gemeinsame Filesystem, sondern betrifft nur das Verhalten der VMs? Also bootet die angepasste VM dann am Node mit 6.14 und fertig.
Verstehe ich das richtig, in etwa?
Ich will jetzt nicht durch irgendein Mißverständnis irgendwas schreddern
Evtl räumen wir morgen einen Node leer und probieren mit einer Handvoll VMs auf diesem Node das Setting mit 6.14 ... außer Ihr haltet mich davon ab ;-)
Danke für Feedback dazu, wir werden gerne diese alten Kernel los, aber eben Schritt für Schritt.
Dein Verständnis ist absolut korrekt.
Die Einstellung
Der von dir beschriebene Plan, zunächst einen Node zu aktualisieren und dann einige wenige VMs mit der geänderten Konfiguration zum Testen dorthin zu migrieren, ist genau der richtige und sichere Weg.
Für die Anpassung deiner bestehenden VMs könntest du ein Skript nutzen, das über alle betreffenden VMs iteriert und die Option per
Die Einstellung
aio=threads ist eine Option pro virtueller Festplatte in der jeweiligen VM-Konfiguration (z.B. scsi0: dein-storage:100,aio=threads). Du kannst diese Option auch auf den Nodes mit dem alten Kernel schon setzen, sie ist dort ebenfalls gültig.Der von dir beschriebene Plan, zunächst einen Node zu aktualisieren und dann einige wenige VMs mit der geänderten Konfiguration zum Testen dorthin zu migrieren, ist genau der richtige und sichere Weg.
Für die Anpassung deiner bestehenden VMs könntest du ein Skript nutzen, das über alle betreffenden VMs iteriert und die Option per
qm set hinzufügt. Das erspart dir die manuelle Arbeit.