Really? Das ist ja ein interessantes Konzept!BTW: Wir verkaufen unser Know-How auch.
Danke, ich behalte das im Hinterkopf Datacenter und/oder Cluster mit local storage only
- Thread starter sgw
- Start date
Danke, ich behalte das im Hinterkopf Der Kunde ist willig .. wir haben bereits einen der ESXIs durch proxmox-8.2 ersetzt.
Ich bin nun am Starten mit OCFS2. Service läuft, vor dem Formatieren habe ich noch eine Verständnisfrage:
In `/dev/mapper` sehe ich nichts, was dem Shared Storage entspricht.
Ich sehe die LUN als `/dev/sda` und `/dev/sdb` ... ist es OK, dieses Device mit OCFS2 zu formatieren und zu verwenden? (soweit ich verstehe, ist das die Sicht per multipath-Anbindung?)
Weiters nehme ich an, den OCFS-Cluster lieber per extra Netzwerk zu etablieren, also extra-NICs, extra-Subnet, extra-Switch? Dazu bräuchte ich dann Eingriff vor Ort wegen Verkabelung. Machbar per Admin dort, aber nicht jetzt sofort. Kann ich die IPs des OCFS-Clusters dann noch mal ändern?
Wie erwähnt: das ist grade roh und Test-Umgebung. Bislang kann ich noch alles von vorn beginnen ;-)
Danke Euch, Stefan
EDIT:
habe sda mit OCFS2 formatiert ... sehe das Storage bereits in der WebGUI. Auch nach einem Reboot: super.
Ein Teil der Systemd-specifics hatte einen Fehler geworfen:
Ich prüfe das alles definitiv noch nach, erstmal Essen!
Ich bin nun am Starten mit OCFS2. Service läuft, vor dem Formatieren habe ich noch eine Verständnisfrage:
In `/dev/mapper` sehe ich nichts, was dem Shared Storage entspricht.
Ich sehe die LUN als `/dev/sda` und `/dev/sdb` ... ist es OK, dieses Device mit OCFS2 zu formatieren und zu verwenden? (soweit ich verstehe, ist das die Sicht per multipath-Anbindung?)
Weiters nehme ich an, den OCFS-Cluster lieber per extra Netzwerk zu etablieren, also extra-NICs, extra-Subnet, extra-Switch? Dazu bräuchte ich dann Eingriff vor Ort wegen Verkabelung. Machbar per Admin dort, aber nicht jetzt sofort. Kann ich die IPs des OCFS-Clusters dann noch mal ändern?
Wie erwähnt: das ist grade roh und Test-Umgebung. Bislang kann ich noch alles von vorn beginnen ;-)
Danke Euch, Stefan
EDIT:
habe sda mit OCFS2 formatiert ... sehe das Storage bereits in der WebGUI. Auch nach einem Reboot: super.
Ein Teil der Systemd-specifics hatte einen Fehler geworfen:
Bash:
# systemctl add-requires remote-fs-pre.target ocfs2.service
Failed to add dependency: Unit /run/systemd/generator.late/ocfs2.service is transient or generated.Ich prüfe das alles definitiv noch nach, erstmal Essen!
Last edited:
Wenn das Storage per Multipath angebunden ist, müsst Ihr noch den multipathd installieren und einrichten. Dann gibt es entsprechende Devices unter /dev/mapper, die dann auch genutzt werden müssen.
Sehr gute Anleitung zu OCFS2 https://www.heinlein-support.de/sit...ments/2022-03/Proxmox und Storage vom SAN.pdf
Aber das beachten: https://forum.proxmox.com/threads/proxmox-8-2-welsche-kernel-möglich.145833/
Danke, das HOWTO habe ich bereits befolgt, das mit den Kernel-Versionen prüfe ich gleich. Betrifft mich vermutlich, da ich ja mit einem 8.2er ISO installiert habe. Das System fährt grad den Kernel 6.8.4-2-pve
Davor brauche ich grad noch die multipath-config, dazu lese ich mich nun umgehend ein.
multipath.conf von hier weitgehend abgekupfert ... WWIDs rausgefunden und eingetragen ... LUN nun als Device in "/dev/mapper" sichtbar, neu formatiert.
Auf Kernel "6.2.16-5-pve" gepinnt, rebootet. Erste Test-VM nach einem Kaffee.
EDIT: die multipath-Parameter sind vermutlich noch schwer zu hinterfragen und essentiell für Performance und Stabilität.
EDIT2: found https://pve.proxmox.com/wiki/ISCSI_Multipath ... sry
Auf Kernel "6.2.16-5-pve" gepinnt, rebootet. Erste Test-VM nach einem Kaffee.
EDIT: die multipath-Parameter sind vermutlich noch schwer zu hinterfragen und essentiell für Performance und Stabilität.
EDIT2: found https://pve.proxmox.com/wiki/ISCSI_Multipath ... sry
Last edited:
Ist den Snapshot ein Muss Kriterium? Meine Kunden habe ich alle überzeugen können, dass Backup statt Snapshot ausreichend ist.
Dann kannst du ja einiges Parallel migrieren.
Ich würde nicht mehr in das alte Storage investieren, sondern lieber Disks in die Hosts und eventuell einen Ceph Pool Parallel aufbauen und den mit der Zeit wachsen lassen.
ODer in den Nodes benutzen.
Es gibt keine Pauschal immer passende Entscheidung, ich beurteile das bei Jedem Projekt individuell anders. Immer je nach gegebenheiten. Angefangen beim alter der Hardware, Typ der Hardware und ganz wichtig, das Netzwerk und die Verkabelung (Ausbaufähigkeit des Netzwerks).
Ich habe die conf mittlerweile stark eingedampft. Ich werde dazu noch HPE-seitig suchen. Danke!
Oder aio=threads setzen: https://forum.proxmox.com/threads/p...nd-ocfs2-shared-storage-with-io_uring.140273/
Machen wir! danke
OCFS2 über 2 neue Nodes in Betrieb, jeweils per multipath. Sieht schon sehr gut aus.
Demnächst Umbau auf separate NICs für die Cluster-Kommunikation.
Danach will ich die 3 OCFS2-Nodes in den bereits existierenden PVE-Cluster joinen, für komfortables Migrieren der VMs.
Danke Euch für die Hilfe!
Detailfragen sammle ich noch ...
Nein, eher ein nice-to-have. Wird vielleicht für einzelne Entwicklungs-VM Sinn machen, aber nicht für den größeren Anteil der Service-VMs in Richtung deren Kunden.
Dann kannst du ja einiges Parallel migrieren.
Ich würde nicht mehr in das alte Storage investieren, sondern lieber Disks in die Hosts und eventuell einen Ceph Pool Parallel aufbauen und den mit der Zeit wachsen lassen.
ODer in den Nodes benutzen.
OK, danke für die Einschätzung. Das ist hier noch Zukunftsmusik.
Verstehe ich völlig, ja.
Fürs Erste bin ich mal zufrieden mit dem Tages-Ergebnis. 2 Nodes neu installiert, OCFS2 per Multipath realisiert, die Basis steht und sieht gut aus.
Im nächsten Anlauf dann das extra "Heartbeat-Netzwerk" auf separaten NICs (da fehlte mir heute jemand vor Ort zum Stöpseln), dritter Node, alles testen und abrunden ... danach dann VMs noch mal weg von den 3 und Joinen der 3 zum bereits laufenden PVE-Cluster.
Und dann Migrieren der VMs.
Klingt doch nach einem Plan. thanks all!
EIn paar offene Fragen noch:
* das mit dem dlm.service muss ich noch checken, dieser Dienst liefert Fehler, siehe hier
* ist es OK und ausreichend, pro Node eine NIC für sowohl den Heartbeat des PVE-Clusters als auch für OCFS2 zu verwenden? Reicht das für die Synchronisation aus oder baue ich mir da ein potentielles Problem ein? Aktuell haben wir dafür einen kleinen Switch gedacht (Gigabit). Also ich meine: eine NIC pro Node für BEIDE Heartbeats. Ist sicherlich abhängig von der Aktivität am Filesystem, korrekt?
und betreffend Thread hier : soll ich den Thread umbenennen? Stimmt ja nicht mehr so ganz.
Guten Morgen allen
* das mit dem dlm.service muss ich noch checken, dieser Dienst liefert Fehler, siehe hier
* ist es OK und ausreichend, pro Node eine NIC für sowohl den Heartbeat des PVE-Clusters als auch für OCFS2 zu verwenden? Reicht das für die Synchronisation aus oder baue ich mir da ein potentielles Problem ein? Aktuell haben wir dafür einen kleinen Switch gedacht (Gigabit). Also ich meine: eine NIC pro Node für BEIDE Heartbeats. Ist sicherlich abhängig von der Aktivität am Filesystem, korrekt?
und betreffend Thread hier
: soll ich den Thread umbenennen? Stimmt ja nicht mehr so ganz.Guten Morgen allen
Last edited:
Das Verzeichnis `/dlm` habe ich laut Anleitung. Meine Vermutung geht in Richtung
Sollte
Der Status:
Ich komme dann am frühen Nachmittag dazu, den dritten Server zu konfigurieren.
Soweit ich verstehe, ist der Betrieb von OCFS2 ohne funktionierendem DLM eher gefährlich (?) bzw. schlicht falsch (?).
corosync.conf , kann das sein, dass mir die fehlt? (stand auch nicht im HOWTO ... ). Mein obiger Link zur Fehlermeldung geht in eine privat-Nachricht, sorry, ich reiche die Meldung hier nach.Sollte
dlm.service auch bereits mit 2 Nodes starten und laufen? @garfield2008 vermutete im private thread, dass evtl ein 3. Node noch fehlt.Der Status:
Code:
# cat /etc/dlm/dlm.conf
# Enable debugging
log_debug=1
# Use tcp as protocol
protocol=tcp
# Delay at join
post_join_delay=10
# Disable fencing (for now)
enable_fencing=0
Bash:
# systemctl status dlm
× dlm.service - dlm control daemon
Loaded: loaded (/lib/systemd/system/dlm.service; enabled; preset: enabled)
Active: failed (Result: exit-code) since Tue 2024-04-30 04:00:24 CEST; 2s ago
Docs: man:dlm_controld
man:dlm.conf
man:dlm_stonith
Process: 325848 ExecStartPre=/sbin/modprobe dlm (code=exited, status=0/SUCCESS)
Process: 325849 ExecStart=/usr/sbin/dlm_controld --foreground $DLM_CONTROLD_OPTS (code=exited, status=1/FAILURE)
Main PID: 325849 (code=exited, status=1/FAILURE)
CPU: 5ms
Apr 30 04:00:24 srv3 systemd[1]: Starting dlm.service - dlm control daemon...
Apr 30 04:00:24 srv3 dlm_controld[325849]: 42593 dlm_controld 4.2.0 started
Apr 30 04:00:24 srv3 dlm_controld[325849]: 42593 corosync cfg init error 2
Apr 30 04:00:24 srv3 systemd[1]: dlm.service: Main process exited, code=exited, status=1/FAILURE
Apr 30 04:00:24 srv3 systemd[1]: dlm.service: Failed with result 'exit-code'.
Apr 30 04:00:24 srv3 systemd[1]: Failed to start dlm.service - dlm control daemon.Ich komme dann am frühen Nachmittag dazu, den dritten Server zu konfigurieren.
Soweit ich verstehe, ist der Betrieb von OCFS2 ohne funktionierendem DLM eher gefährlich (?) bzw. schlicht falsch (?).
Last edited:
Ich denke, ich verstehe besser.
Die corosync.conf entsteht, wenn ich den PVE-Cluster erstelle, korrekt? Das ist bislang mit den 3 Nodes noch nicht erfolgt.
Ich mache mal den 3. Node fertig in Sachen multipath und OCFS2 ... dann kann ich die 3 leeren Nodes dem bestehenden Datacenter hinzufügen. Durch diesen Schritt erwarte ich die corosync.conf, korrekt? danke
EDIT: ja, ist durchs Joinen gelöst ...
Die corosync.conf entsteht, wenn ich den PVE-Cluster erstelle, korrekt? Das ist bislang mit den 3 Nodes noch nicht erfolgt.
Ich mache mal den 3. Node fertig in Sachen multipath und OCFS2 ... dann kann ich die 3 leeren Nodes dem bestehenden Datacenter hinzufügen. Durch diesen Schritt erwarte ich die corosync.conf, korrekt? danke
EDIT: ja, ist durchs Joinen gelöst ...
Last edited:
STATUS:
ich denke, ich hab's soweit.
3 Nodes mit local storage plus 3 Nodes mit dem OCFS2-Storage im Cluster.
Hin- und Her-Schieben klappt, alle reden mit dem PBS ... sieht schon sehr fein aus!
Sogar bereits erste Steps mit HA gemacht.
Jetzt geht es ans Aufräumen und die Fein-Config... bzw. ein Backup derselben (kann der PBS eigtl auch die Hosts selber sichern? okay, vermutlich RTFM ...)
Danke Euch allen, ist bislang eine super Experience. Der Kunde will schon Produktiv-VMs hin schieben.
* Passt das mit der einen Gigabit-NIC für OCFS2 und Corosync?
* Bei den 3 "OCFS-Nodes" bin ich noch unschlüssig, ob wir den Kernel auf alt pinnen ...
Schönen Abend, schönen Tag der Arbeit den Österreichern morgen. Stefan
ich denke, ich hab's soweit.
3 Nodes mit local storage plus 3 Nodes mit dem OCFS2-Storage im Cluster.
Hin- und Her-Schieben klappt, alle reden mit dem PBS ... sieht schon sehr fein aus!
Sogar bereits erste Steps mit HA gemacht.
Jetzt geht es ans Aufräumen und die Fein-Config... bzw. ein Backup derselben (kann der PBS eigtl auch die Hosts selber sichern? okay, vermutlich RTFM
...)Danke Euch allen, ist bislang eine super Experience. Der Kunde will schon Produktiv-VMs hin schieben.
* Passt das mit der einen Gigabit-NIC für OCFS2 und Corosync?
* Bei den 3 "OCFS-Nodes" bin ich noch unschlüssig, ob wir den Kernel auf alt pinnen ...
Schönen Abend, schönen Tag der Arbeit den Österreichern morgen. Stefan
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.