Und wie lege ich das an? Wie wird das gemountet? Gibt's da wo eine Anleitung? danke ...
OCFS2(unsupported): Frage zu Belegung
- Thread starter sgw
- Start date
Und wie lege ich das an? Wie wird das gemountet? Gibt's da wo eine Anleitung? danke ...
Ich habe mich an die zahlreichen Anleitungen zum Thema Multipath (z.B. https://pve.proxmox.com/wiki/Multipath) gehalten.
Aber den Teil hast Du vermutlich bereits gelöst.
Der LVM-Teil ist einfach: Auf einem Node anlegen und auf den anderen Nodes erkennen (scannen lassen),
Siehe z.B. hier: https://kb.blockbridge.com/technote...rage/#how-to-set-up-lvm-shared-storage-in-pve
Aber den Teil hast Du vermutlich bereits gelöst.
Der LVM-Teil ist einfach: Auf einem Node anlegen und auf den anderen Nodes erkennen (scannen lassen),
Siehe z.B. hier: https://kb.blockbridge.com/technote...rage/#how-to-set-up-lvm-shared-storage-in-pve
Multipath läuft ja bereits, richtig.
Danke für den Link, sehe ich mir asap an.
Aktuell recherchieren wir wegen zusätzlicher Platten ... und haben noch das Ticket bei HPE laufen, wer weiß ;-)
Danke für den Link, sehe ich mir asap an.
Aktuell recherchieren wir wegen zusätzlicher Platten ... und haben noch das Ticket bei HPE laufen, wer weiß ;-)
Darf ich noch mehr ausschweifen und Euch fragen, was Ihr von einer SSD "Toshiba PX05SRB384" haltet?
Der Kunde hat die angeboten bekommen, und die ist als Read-Intensive ausgelegt, ist aber in manchen Werten unseren aktuelle Seagate-Nytro-Modellen unterlegen (Seagate XS1920SE70084, Seagate XS1920SE70004).
Ich tu mir da grad schwer, eine Auskunft zu geben, vermutlich ist das auch schwierig, weil es ja auch von der Art der VMs und deren Nutzungsprofil abhängt.
Die Toshiba ist doppelt so groß, der Kunden-Admin will wieder RAID5, ich plädiere für eine Spare, wird also vermutlich ein Array aus 4 SSDs oder so.
Momentane Idee ist es, diesen 2. Pool am MSA aufzubauen, diesmal vielleicht (zwecks Research) ein OCFS2 *ohne* Over-Committing, dann VMs rüber, und dann irgendwann Pool A auch entsprechend neu bauen. Dann würden wir die gewohnten Features behalten.
Oder eben gleich Pool B mit besagtem LVM machen (auch ohne Over-Committing, denke ich ...). Da bin ich noch nicht ganz entschieden, muss ich auch mit den Leuten dort diskutieren.
Danke Euch für die konstruktive Diskussion.
Der Kunde hat die angeboten bekommen, und die ist als Read-Intensive ausgelegt, ist aber in manchen Werten unseren aktuelle Seagate-Nytro-Modellen unterlegen (Seagate XS1920SE70084, Seagate XS1920SE70004).
Ich tu mir da grad schwer, eine Auskunft zu geben, vermutlich ist das auch schwierig, weil es ja auch von der Art der VMs und deren Nutzungsprofil abhängt.
Die Toshiba ist doppelt so groß, der Kunden-Admin will wieder RAID5, ich plädiere für eine Spare, wird also vermutlich ein Array aus 4 SSDs oder so.
Momentane Idee ist es, diesen 2. Pool am MSA aufzubauen, diesmal vielleicht (zwecks Research) ein OCFS2 *ohne* Over-Committing, dann VMs rüber, und dann irgendwann Pool A auch entsprechend neu bauen. Dann würden wir die gewohnten Features behalten.
Oder eben gleich Pool B mit besagtem LVM machen (auch ohne Over-Committing, denke ich ...). Da bin ich noch nicht ganz entschieden, muss ich auch mit den Leuten dort diskutieren.
Danke Euch für die konstruktive Diskussion.
Last edited:
Ich würde dringend dazu raten einen Benchmark mit beiden Varianten zu fahren (ja, das dauert dann halt etwas länger, weil man dann ja mehrmals neu aufsetzen und testen muss). ocfs2 ist halt wirklich nicht gut unterstützt und das wird sich auch nicht ändern. Und anders als etwa beim Linux-Kernel oder zfs scheint (soweit ich weiß) der Upstream (also Oracle) auch aktuell nicht mehr viel Arbeit rein zu stecken, es ist also auch nicht absehbar, dass sich da irgendwas verbessern wird.
Mir wären die Frickelei und Klemmzüge die mit dem Fahren eines nicht unterstützten Setups nötig sind schlicht zu blöd in Vergleich zu einer gut getesteten und robusten Variante. Aber: Ich verstehe, dass der Kunde natürlich (auch wenn er ohne Snapshots leben kann) glücklicher ist, wenn er die gewohnten Features beibehalten kann. Aber vielleicht lässt sich das ja entschärfen, wenn er dafür mit der einen Variante bessere Performance bekommt? lvm/thick ist ein Blockspeicher, das heißt die Ablage der Daten kommt ohne Dateisystem aus. Da damit ein Layer wegfällt, sollte das theoretisch eine bessere Performance als mit ocfs2 bedingen. Muss man halt benchmarken
Praktisch (mir fällt die Erfahrung für einen eigenen Vergleich, nur zum Testen setze ich im Homelab kein ocfs2 auf ) haben das hier immer mal wieder Leute aus der Praxis bestätigt.
@Falk R. berichtet hier zum Beispiel von deutlich größerer Performance für ein Setup mit Blockspeicher statt Dateisystem:
Nach seiner Erfahrung für Standardworkloads bis zu 20%, bei SQL-Servern auch deutlich mehr. Wenn sich das in euren Tests bestätigt, wäre das ja envtl. was, womit man diese bittere Pille den Kunden etwas schmackhafter machen kann
Das stimmt natürlich, aber im gängigen Sprachgebrauch wird damit ja doch die Anbindung von sehr teurer Storage-Hardware über ebenfalls vergleichsweise teure Glasfaserleitungen an sehr teure Server verstanden, man ist schließlich Enterprise
vSAN ist schließlich nur was für Mittelständler (Aussage eines mir bekannten vmware-Admins, nicht meine ). Ich habe lieber nicht nachgefragt, ob das Cern noch als Mittelstand durchgeht, weil die ja sowas ähnliches (ceph) benutzen
Mir wären die Frickelei und Klemmzüge die mit dem Fahren eines nicht unterstützten Setups nötig sind schlicht zu blöd in Vergleich zu einer gut getesteten und robusten Variante. Aber: Ich verstehe, dass der Kunde natürlich (auch wenn er ohne Snapshots leben kann) glücklicher ist, wenn er die gewohnten Features beibehalten kann. Aber vielleicht lässt sich das ja entschärfen, wenn er dafür mit der einen Variante bessere Performance bekommt? lvm/thick ist ein Blockspeicher, das heißt die Ablage der Daten kommt ohne Dateisystem aus. Da damit ein Layer wegfällt, sollte das theoretisch eine bessere Performance als mit ocfs2 bedingen. Muss man halt benchmarken
Praktisch (mir fällt die Erfahrung für einen eigenen Vergleich, nur zum Testen setze ich im Homelab kein ocfs2 auf ) haben das hier immer mal wieder Leute aus der Praxis bestätigt.@Falk R. berichtet hier zum Beispiel von deutlich größerer Performance für ein Setup mit Blockspeicher statt Dateisystem:
@JayTee75
Mal ein Schwank aus meiner Jugend
ich arbeite mit VMware seit 2006 (ESX 3.0 und manchmal 2.5), daher bin ich auch etwas doll mit meiner VMware Denke falsche Wege gegangen.
Bei proxmox wir viel mit Block Devices gearbeitet, anstatt Dateien auf ein FS zu packen. Das hat weniger Overhead und bringt mehr Performance.
Bei Benchmarks ESXi mit VMFS6 gegen RAW Disks auf ZFS Single/RAID1 oder LVM-Thin hast du auf dem gleichen Blech ca. 20% mehr Leistung. Bei SQL Bechmarks sogar bis zu 80% mehr Leistung.
Also am besten RAW (Block Devices) nutzen.
Mal ein Schwank aus meiner Jugend
ich arbeite mit VMware seit 2006 (ESX 3.0 und manchmal 2.5), daher bin ich auch etwas doll mit meiner VMware Denke falsche Wege gegangen.
Bei proxmox wir viel mit Block Devices gearbeitet, anstatt Dateien auf ein FS zu packen. Das hat weniger Overhead und bringt mehr Performance.
Bei Benchmarks ESXi mit VMFS6 gegen RAW Disks auf ZFS Single/RAID1 oder LVM-Thin hast du auf dem gleichen Blech ca. 20% mehr Leistung. Bei SQL Bechmarks sogar bis zu 80% mehr Leistung.
Also am besten RAW (Block Devices) nutzen.
Das stimmt natürlich, aber im gängigen Sprachgebrauch wird damit ja doch die Anbindung von sehr teurer Storage-Hardware über ebenfalls vergleichsweise teure Glasfaserleitungen an sehr teure Server verstanden, man ist schließlich Enterprise
vSAN ist schließlich nur was für Mittelständler (Aussage eines mir bekannten vmware-Admins, nicht meine ). Ich habe lieber nicht nachgefragt, ob das Cern noch als Mittelstand durchgeht, weil die ja sowas ähnliches (ceph) benutzen 
Die ist OK, aber halt nicht mehr neu. Toshiba hat die SSD Sparte vor einigen Jahren in Kioxia umbenannt, daher weiß man, wenn da auf einer SSD noch Toshiba steht, ist die nicht neu.
In der Regel sollte das schon passen, die MSA mit ihrem Raid Algorithmus ist vermutlich eher die Bremse.
Raid5 kann die MSA recht vernünftig, aber das Pooldesign finde ich bei allen DotHill Produkten nicht so schön. jeder Pool ist imemr an einen Controller gebunden und bei einer MSA mit nur einem Pool, ist immer nur ein Controller aktiv.
Warum nicht einfach auf LVM gehen? Da sparst du dir das ganze ungetestete und kannst ganz entspannt PVE Updates machen ohne Zicken vom OCFS zu erwarten.
Mach das. Du hast ja das Thin Provisioning im MSA Pool und kannst entspannt auf LVM Thick setzen.
Last edited:
Danke an @Johannes S und @Falk R. ! ich gehe jetzt nicht auf alle einzelnen Punkte ein ...
Mein Plan geht nun in Richtung 4 oder 5 von diesen Toshibas (gewünschte Kapazität des Pools kläre ich noch mit dem Kunden), als RAID5, vermutlich sinnvollerweise mit einer hot spare, oder?
Und da drauf testweise Euer LVM-stuff ;-) .. das können wir dann mal testen mit ein paar VMs, und nach und nach siedeln etc.
OCFS2 samt Snapshots lasse ich also langsam los, der Admin beim Kunden meint eh, er verwendet die nie. Gut so!
Toshiba und nicht neu: ja, das ist auch eine refurbished, denke ich ... (hat der Kunde sich anbieten lassen)
Mein Plan geht nun in Richtung 4 oder 5 von diesen Toshibas (gewünschte Kapazität des Pools kläre ich noch mit dem Kunden), als RAID5, vermutlich sinnvollerweise mit einer hot spare, oder?
Und da drauf testweise Euer LVM-stuff ;-) .. das können wir dann mal testen mit ein paar VMs, und nach und nach siedeln etc.
OCFS2 samt Snapshots lasse ich also langsam los, der Admin beim Kunden meint eh, er verwendet die nie. Gut so!
Toshiba und nicht neu: ja, das ist auch eine refurbished, denke ich ... (hat der Kunde sich anbieten lassen)
Jetzt nur mal so als fun fact: heute vormittags war der Pool auf 95% Belegung .. Scrub aktiv, schneckengleich.
Ich hab mit dem Admin dort telefoniert und wir haben die Platten diskutiert etc
Er hat berichtet, eine VM von raw auf qcow2 konvertiert zu haben, und dass sich da nix getan hat in der Belegung des Pools im MSA-GUI.
Ich hab dann einen fstrim ausgeführt, der hat 4 oder 500GB freigegeben.
Wir haben dann andere Dinge getan, irgendwann schauen wir ins MSA-GUI und der Pool steht auf 89%
Alles etwas undurchsichtig ;-)
Das war bis jetzt nie so, dass da irgendwas sofort sichtbar wurde ...
Testweise konvertieren wir jetzt noch ein paar raw-disks, mal schauen (da gibt es noch VMs, bei denen das nach der Übernahme von den ESXis vergessen wurde ... weil es halt auch nicht irgendwie problematisch schien).
Die Toshiba-SSDs für Pool B werden jedenfalls bestellt.
Ich hab mit dem Admin dort telefoniert und wir haben die Platten diskutiert etc
Er hat berichtet, eine VM von raw auf qcow2 konvertiert zu haben, und dass sich da nix getan hat in der Belegung des Pools im MSA-GUI.
Ich hab dann einen fstrim ausgeführt, der hat 4 oder 500GB freigegeben.
Wir haben dann andere Dinge getan, irgendwann schauen wir ins MSA-GUI und der Pool steht auf 89%
Alles etwas undurchsichtig ;-)
Das war bis jetzt nie so, dass da irgendwas sofort sichtbar wurde ...
Testweise konvertieren wir jetzt noch ein paar raw-disks, mal schauen (da gibt es noch VMs, bei denen das nach der Übernahme von den ESXis vergessen wurde ... weil es halt auch nicht irgendwie problematisch schien).
Die Toshiba-SSDs für Pool B werden jedenfalls bestellt.
Ich schnupper da schon mal rein.
Aktuell habe ich ja eine multipath.conf mit der einzelnen LUN:
Bash:
# cat /etc/multipath.conf
defaults {
polling_interval 2
path_selector "round-robin 0"
path_grouping_policy multibus
uid_attribute ID_SERIAL
rr_min_io 100
failback immediate
no_path_retry queue
user_friendly_names yes
}
blacklist {
wwid .*
}
blacklist_exceptions {
wwid 3600c0ff000530bf1b018186001000000
}
multipaths {
multipath {
wwid 3600c0ff000530bf1b018186001000000
alias msa2060_lun1
}
}Ich vermute, nach Anlegen des 2. Pools auf der MSA scanne ich nach einer weiteren wwid, trage dann ein entsprechendes Alias ein ... und danach kann ich das entstehende `/dev/mapper/msa2060lun2` als PV (im Kontext von LVM) anlegen?
Die multipath.conf dann auf allen Nodes gleich ziehen ...
Braucht es https://kb.blockbridge.com/technote...orage/#register-the-lvm-volume-group-with-pve auf allen 3 Nodes?
Ich hab schon etwas Nervosität davor, aber es wird schon werden, sonst frag ich wieder Euch
Ich trage die Vielen LUNs gar nicht manuell da ein. Du kannst einfachIch schnupper da schon mal rein.
Aktuell habe ich ja eine multipath.conf mit der einzelnen LUN:
Bash:# cat /etc/multipath.conf defaults { polling_interval 2 path_selector "round-robin 0" path_grouping_policy multibus uid_attribute ID_SERIAL rr_min_io 100 failback immediate no_path_retry queue user_friendly_names yes } blacklist { wwid .* } blacklist_exceptions { wwid 3600c0ff000530bf1b018186001000000 } multipaths { multipath { wwid 3600c0ff000530bf1b018186001000000 alias msa2060_lun1 } }
Ich vermute, nach Anlegen des 2. Pools auf der MSA scanne ich nach einer weiteren wwid, trage dann ein entsprechendes Alias ein ... und danach kann ich das entstehende `/dev/mapper/msa2060lun2` als PV (im Kontext von LVM) anlegen?
Die multipath.conf dann auf allen Nodes gleich ziehen ...
Braucht es https://kb.blockbridge.com/technote...orage/#register-the-lvm-volume-group-with-pve auf allen 3 Nodes?
Ich hab schon etwas Nervosität davor, aber es wird schon werden, sonst frag ich wieder Euch
multipath -a /dev/sdX deine neu Discoverte Disk hinzufügen. Mit multipath -v3 machst du eine scan auf die Pfade und schon ist dein mpath Gerät nutzbar.Mittlerweile 2TB frei durch qcow2 statt raw ... plus evtl der daily fstrim seit letzter Woche.
SSDs für Pool B und LVM sind dennoch bestellt ;-)
Guten Morgen, Proxmox-Kollegen.
Ich beginne heute mit einer Test-LUN im neuen Pool B, den der Kunden-Admin bereits angelegt hat:
Ich hab darin mal ein Test-Volume mit 200GB erstellt, und nach etwas multipath-Action nun eine LVM-VG namens "LUN2" in PVE.
Eine Test-VM läuft schon mit einer Disk da drin, sehr schön.
Ich hab das am Node `srv1` gemacht, danach auf `srv2` die selbe multipath-conf eingetragen, LUN und mapper-device sind da, auch die VG ist sichtbar.
Jetzt wollte ich die Test-VM von `srv1` auf `srv2` migrieren, und das verhält sich anders als erwartet:
"Migration with local disk might take long: LUN2:vm-180-disk1 (8.00 GiB)"
Habe ich eine falsche Vorstellung von der Funktionalität, fehlt mir noch ein Schritt oder ein Setting, ... ?
Bitte um sachdienliche Hinweise ;-) danke ...
(ps: das Entfernen der Test-LUN sollte ja kein Problem sein später ...)
SOLVED: Häkchen "shared" hatte noch gefehlt, jetzt sieht das fein aus.
Ich baue schon um in Richtung 3 Nodes, mit passender Size der LUN etc
Ich beginne heute mit einer Test-LUN im neuen Pool B, den der Kunden-Admin bereits angelegt hat:
Code:
Overcommit: enabled
Pool Overcommitted: FalseIch hab darin mal ein Test-Volume mit 200GB erstellt, und nach etwas multipath-Action nun eine LVM-VG namens "LUN2" in PVE.
Code:
pvcreate /dev/mapper/msa2060_lun2
vgcreate LUN2 /dev/mapper/msa2060_lun2
pvesm add lvm LUN2 --vgname LUN2 --content imagesEine Test-VM läuft schon mit einer Disk da drin, sehr schön.
Ich hab das am Node `srv1` gemacht, danach auf `srv2` die selbe multipath-conf eingetragen, LUN und mapper-device sind da, auch die VG ist sichtbar.
Jetzt wollte ich die Test-VM von `srv1` auf `srv2` migrieren, und das verhält sich anders als erwartet:
"Migration with local disk might take long: LUN2:vm-180-disk1 (8.00 GiB)"
Habe ich eine falsche Vorstellung von der Funktionalität, fehlt mir noch ein Schritt oder ein Setting, ... ?
Bitte um sachdienliche Hinweise ;-) danke ...
(ps: das Entfernen der Test-LUN sollte ja kein Problem sein später ...)
SOLVED: Häkchen "shared" hatte noch gefehlt, jetzt sieht das fein aus.
Ich baue schon um in Richtung 3 Nodes, mit passender Size der LUN etc
Last edited:
Vermutlich können wir "aio=threads,iothread=1" nun mit shared-LVM weglassen ... ?
Wir sind am Testen ...
Wir sind am Testen ...
Sieht gut aus: shared LVM läuft auf allen 3 Nodes, ist flott und unauffällig.
Die Belegung stimmt nun überein: Ansicht im MSA-GUI passt zu Ansicht in PVE.
Wir haben schon einige VMs da hin migriert, klarerweise wurden nun aus den qcow2-Disks raw-disks (weil eben native LVs).
Wir schauen uns das einige Tage an, migrieren stückweise die VMs, und planen, kommenden Mittwoch das OCFS2 leer zu haben.
Danach baue ich das ganze OCFS2-Setup weg von den Nodes (den Ablauf überlege ich mir noch genauer), disable das OCFS2 und dann werfe ich das alte MSA-Volume auf Pool A weg und erstelle ein neues, ohne Overcommitting und daraus wird ein neues, zweites shared-LVM-storage.
Theoretisch könnte diese LUN ein 2. PV in meiner heute erstellten VG werden, korrekt? Dann kann ich als Admin aber nicht mehr unterscheiden, bzw. beeinflussen, ob ich VMs gezielt auf den älteren oder neueren SSDs plazieren will ...
Ich neige eher dazu, das getrennt auszuführen, außer Ihr habt da noch ein schlagendes Argument in eine Richtung.
An dieser Stelle nochmals ein großes DANKE für all Euren Support in dieser Sache!
Die Belegung stimmt nun überein: Ansicht im MSA-GUI passt zu Ansicht in PVE.
Wir haben schon einige VMs da hin migriert, klarerweise wurden nun aus den qcow2-Disks raw-disks (weil eben native LVs).
Wir schauen uns das einige Tage an, migrieren stückweise die VMs, und planen, kommenden Mittwoch das OCFS2 leer zu haben.
Danach baue ich das ganze OCFS2-Setup weg von den Nodes (den Ablauf überlege ich mir noch genauer), disable das OCFS2 und dann werfe ich das alte MSA-Volume auf Pool A weg und erstelle ein neues, ohne Overcommitting und daraus wird ein neues, zweites shared-LVM-storage.
Theoretisch könnte diese LUN ein 2. PV in meiner heute erstellten VG werden, korrekt? Dann kann ich als Admin aber nicht mehr unterscheiden, bzw. beeinflussen, ob ich VMs gezielt auf den älteren oder neueren SSDs plazieren will ...
Ich neige eher dazu, das getrennt auszuführen, außer Ihr habt da noch ein schlagendes Argument in eine Richtung.
An dieser Stelle nochmals ein großes DANKE für all Euren Support in dieser Sache!
Der Abbau der OCFS2-Struktur wird noch spannend, ich lese dazu noch mal das hilfreiche howto von @gurubert ... und plane schon mal die Steps, um die systemd-requirements dann wieder sauber zu entfernen.
Die Dienste können dann ja zumindest disabled werden, bzw. vielleicht dann sogar das ganze Package "ocfs2-tools" entfernt.
Und auch die extra NIC-configs für das Cluster-FS können dann weg (plus die Kabel und Switch-Configs).
Es bleibt spannend!
Die Dienste können dann ja zumindest disabled werden, bzw. vielleicht dann sogar das ganze Package "ocfs2-tools" entfernt.
Und auch die extra NIC-configs für das Cluster-FS können dann weg (plus die Kabel und Switch-Configs).
Es bleibt spannend!
Gilt es aktuell eigentlich immer noch als unsicher dieselbe LUN mit shared LVM über mehrere Proxmox Cluster hinweg zu betreiben? Wir bauen gerade ein Testlab mit einer größeren Testumgebung und sind nun gerade an diesem Punkt. Bis jetzt scheint dies zu funktionieren, die Dokumentation dahingehend aber lückenhaft bzw. finde ich keine definitive Aussage dazu.
Disclaimer: ich betreibe nichts entsprechendes.
Die koordinierende Instanz innerhalb eines Clusters ist die PVE-middleware, nicht etwa das Target. Ein Cluster weiß aber nichts von dem anderen. Und da hilft vermutlich auch kein PDM. Der ist in dieser Hinsicht ja nicht aktiv eingebunden, um so das Locking zu organisieren.
Also ja - zwei Cluster, die auf eine LUN zugreifen werden sich nach meinem Verständnis behindern/zerstören.
