Datacenter und/oder Cluster mit local storage only

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:

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:
Ich bin nun am Starten mit OCFS2. Service läuft, vor dem Formatieren habe ich noch eine Verständnisfrage:

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.

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
 
Last edited:
PBS bereits produktiv, klappt soweit. Das war Bedingung, um etwaige VMs drauf zu ziehen.

Wenn keine Snapshots: dennoch OCFS2, oder was Anderes? Thin Provisioning ist für den Kunden derzeit eigtl auch keine Anforderung: die Platten im Storage sind nur etwa halb durch die produktive VMware-LUN in Verwendung.
Ist den Snapshot ein Muss Kriterium? Meine Kunden habe ich alle überzeugen können, dass Backup statt Snapshot ausreichend ist.
(a) da ist noch Platz auf den vorhandenen Platten im Storage
Dann kannst du ja einiges Parallel migrieren.
(b) da sind noch zig Slots frei im Storage (ob die alle auch einen Controller dran haben, weiß ich ad hoc nicht)
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.
(c) die SAS-SSDs, die ich aktuell lokal als RAID-1 (2 disks) in den 3 Temporär-PVEs betreibe, kann man dann später evtl ins Storage rein siedeln (Rahmen und Controller vorausgesetzt)
ODer in den Nodes benutzen. ;)
(d) es werden noch VMs dazu kommen, aber nicht Faktor 2 oder mehr

Ich denke, das ist jetzt eine sehr grundlegende und weitreichende Entscheidung, wie man dieses Storage aufbaut (no na), da höre ich gerne Eure Empfehlungen und pros and cons. Gerne immer das Beste, sofern ich es ausreichend verstehen und betreiben kann ;-)
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).
 
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
Die Multipath Konfiguration am besten immer beim Storagehersteller besorgen. Da gibts unterschiedliche Empfehlungen.
Um die WWIDs einzutragen einfach über ein Pfad-Device machen: multipath -a /dev/sdb wenn sdb ein Pfad zu deiner LUN ist.
 
Die Multipath Konfiguration am besten immer beim Storagehersteller besorgen. Da gibts unterschiedliche Empfehlungen.
Um die WWIDs einzutragen einfach über ein Pfad-Device machen: multipath -a /dev/sdb wenn sdb ein Pfad zu deiner LUN ist.
Ich habe die conf mittlerweile stark eingedampft. Ich werde dazu noch HPE-seitig suchen. Danke!
 
Ist den Snapshot ein Muss Kriterium? Meine Kunden habe ich alle überzeugen können, dass Backup statt Snapshot ausreichend ist.

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.

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

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!
 
Hi, SAS verhält sich wie FC, nur du kannst nicht so lange Strecken überbrücken.
 
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
 
Last edited:
Das Verzeichnis `/dlm` habe ich laut Anleitung. Meine Vermutung geht in Richtung 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 ...
 
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
 
* Passt das mit der einen Gigabit-NIC für OCFS2 und Corosync?
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.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!