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.