Datacenter und/oder Cluster mit local storage only

[sgw]

Bislang habe ich EINE NIC pro Node für beides konfiguriert. Aber ich verstehe ... und werde das noch entsprechend erweitern/umbauen. Danke!

 

[sgw]

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

 

[sgw]

Oder aio=threads setzen: https://forum.proxmox.com/threads/p...nd-ocfs2-shared-storage-with-io_uring.140273/

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

 

[UdoB]

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?

Nein.

Der Umstand, dass dort der Cluster initiiert wurde, ist irrelevant. Genau, wie es keinen Master oder ähnliches gibt. Alle Nodes sind hinsichtlich der Clusterfunktionen gleichwertig.

 

[sgw]

Nein.

Der Umstand, dass dort der Cluster initiiert wurde, ist irrelevant. Genau, wie es keinen Master oder ähnliches gibt. Alle Nodes sind hinsichtlich der Clusterfunktionen gleichwertig.

Hatte ich so vermutet, danke für die Bestätigung!

 

[gurubert]

Passt das mit der einen Gigabit-NIC für OCFS2 und Corosync?

Grundsätzlich ja, denn da entsteht nicht viel Traffic.
Für Corosync ist immer noch eine zweite unabhängige Netzwerkverbindung empfehlenswert.

 

[sgw]

Grundsätzlich ja, denn da entsteht nicht viel Traffic.
Für Corosync ist immer noch eine zweite unabhängige Netzwerkverbindung empfehlenswert.

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.

 

[gurubert]

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.

Auf der separaten NIC ("Loop1") gibt es keinen Traffic von VMs. Der Storage-Traffic geht über SAS und der IP-Traffic geht über die andere NIC.

 

[sgw]

Auf der separaten NIC ("Loop1") gibt es keinen Traffic von VMs. Der Storage-Traffic geht über SAS und der IP-Traffic geht über die andere NIC.

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 ;-)

 

[gurubert]

ich meinte den Traffic des OCFS2-Clusters. Das ist wohl kein tatsächlicher Inhalt von Files, aber Meta-Daten oä, richtig?

Da sind nur die Lock-Infos, die da rübergehen, und ob die Knoten alle noch da sind. Trafficseitig vernachlässigbar.

 

[sgw]

Ein NIC, oder jeweils ein NIC?

Corosync sollte nicht auf einem Kabel leben, auf dem der Storage massiven Datenverkehr verursacht. For Corosync sollten zwei "Links" konfiguriert sein, und der Primäre sollte am besten exklusiv dafür vorgesehen sein. Und ich meine damit ausdrücklich kein "separates VLAN", sondern echtes Kupfer.

• https://pve.proxmox.com/pve-docs/pve-admin-guide.html#pvecm_redundancy

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.

 

[sgw]

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.