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.