OCFS2(unsupported): Frage zu Belegung

Interessanter und lustiger thread ... da fällt mir noch eine Antwort von HPE Sofia bzgl. eines damaligen Tape Library + Backup-SW (beides HP) Tickets ein, welches so endete: "... Zu ihrem Problem gibt es keine Lösung. Deswegen lohnt es sich auch nicht noch weiter danach zu suchen ..." - köstliche Antwort, die über das damalige Problem hinwegtröstete
:)
 
  • Like
Reactions: Johannes S
Ich folge dieser Meinung ja auch. Ich frage mich nur warum nirgends so wirklich ausdrücklich darauf hingewiesen wird.
Weil ja eigentlich ProxmoxVE ja historisch eigentlich nicht darauf ausgelegt ist, dass mehrere Cluster den gleichen shared Storage nutzen. Die implizite Grundannahme war ja immer 1 Cluster=1 shared storage. Wirklich ein Thema ist das erst mit den ProxmoxDatacenterManager geworden und den gibt es ja nun noch nicht so lange. Und auch beim PDC geht es ja explizit um das Managen verschiedener Cluster oder single-nodes, nicht um gemeinsam genutzten Storage.
 
Last edited:
  • Like
Reactions: sgw and UdoB
Soooo: OCFS2 ist hier Geschichte:

PVE-Storage entfernt, diverse systemd-requires entfernt, services disabled, fstab editiert usw ...

Die alte LUN am MSA entfernt, eine neue angelegt, mittlerweile ist die bereits ein 2. LVM-shared-storage im Datacenter :-)

Mini-Frage am Rande: 2 Nodes zeig(t)en das neue LVM-Storage mit Fragezeichen an, einen habe ich rebootet, das hat das behoben.
Sowas wie "pvesm scan lvm" hat das nicht gelöst.

Kein Problem, wir machen ohnehin grad auch Upgrades, ein Reboot passt da auch rein, ist ja jetzt nicht jeden Tag.

Sieht gut aus! danke, schönen Tag
 
  • Like
Reactions: Johannes S
Nice :) Und: Kunde zufrieden, Unterschiede in der Performance bemerkt?

Ja, bemerkt er.

Allerdings: im Zuge der Diskussion hatte er vor 2 Wochen gemeint "Snapshots brauche ich nie, kein Problem".
Jetzt baue ich das alles um, heute kommt er "können wir dieses Volume-Chaining-Dings einschalten, gestern wäre ein Snapshot super gewesen".

hach ja

Jetzt hab ich ihm das in dem einen Pool enabled, und ihm nahegelegt, dort nur Test-VMs zu snapshotten.
Und in Pool B mit den Kunden-VMs erstmal die Finger davon zu lassen.

Für PBS-Backups vor haarigen Eingriffen hab ich ihm noch ein local storage in eine Disk am MSA gepackt, statt dem Repository am NAS (Flaschenhals Gigabit-NIC und älteres NAS ...). Das ist brauchbar ...

Unterm Strich alles fein soweit.
 
Ja, bemerkt er.

Sehr schön, ich liebe es, wenn ein Plan funktioniert :) Lässt sich das in Prozentzahlen übersetzen oder ist es eher "gefühlt" ("Ist alles irgendwie flotter jetzt")?

Allerdings: im Zuge der Diskussion hatte er vor 2 Wochen gemeint "Snapshots brauche ich nie, kein Problem".
Jetzt baue ich das alles um, heute kommt er "können wir dieses Volume-Chaining-Dings einschalten, gestern wäre ein Snapshot super gewesen".

Der Klassiker der IT, das Problem ist nie eine Lösung zu finden, sondern den Kunden/User dazu zu bringen, dass er weiß, was er eigentlich will ;)
Ansonsten hast du ihn mit PBS ja einen praktikablen Workaround gezeigt.
 
Sehr schön, ich liebe es, wenn ein Plan funktioniert :) Lässt sich das in Prozentzahlen übersetzen oder ist es eher "gefühlt" ("Ist alles irgendwie flotter jetzt")?

Eher gefühlt. Die sind dort nicht ganz so organisiert, dass es da jetzt Vorher-Nachher-Benchmarks gäbe. Aber er bemerkt es deutlich, das ja.

Der Klassiker der IT, das Problem ist nie eine Lösung zu finden, sondern den Kunden/User dazu zu bringen, dass er weiß, was er eigentlich will ;)
Ansonsten hast du ihn mit PBS ja einen praktikablen Workaround gezeigt.

Ja. Das local-Backup-Repo ist etwa doppelt so schnell wie das übers Netzwerk, das ist brauchbar.

Und mittlerweile haben wir die qcow2-Snapshots am shared-LVM ausprobiert, er kann ja nun seine Entwicklungs-VMs auf diesem Storage plazieren, wenn er das braucht.

Natürlich sind Snapshots praktisch, für gewisse Zwecke, deswegen hatte ich sie damals ja auch haben wollen ;-)

Seine Kunden-VMs soll er aber auf dem anderen LVM betreiben, ohne experimentelles Feature. Die Changes letzte Woche waren aufregend genug, ich kann jetzt keine reihenweisen Ausfälle oder Probleme gebrauchen (kann ich nie ...).
 
  • Like
Reactions: Johannes S
Noch ein Nachtrag zu dem Thema mit dem fstrim/UNMAP am MSA-Storage:

Im HPE-Forum wurde ich noch auf die Möglichkeit hingewiesen, dass die multipath-Config evtl die discards nicht weiter gibt.
Diesen Teil der "Kette" hatte ich noch nicht als dafür verantwortlich in Erwägung gezogen (und hier im Thread auch noch keiner, außer ich übersehe was).

Soweit ich verstehe, ist ja nun mit shared-LVM das Thema fstrim eher außen vor, oder?
Wir haben da ja nun kein Filesystem, sondern ein Block-Device. (Was passiert, wenn eine VM innerhalb ihres OS ein fstrim macht?)

Meine multipath.conf ist recht schlank:

Code:
# 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 3600c0ff000fb00fb1e07bd6901000000
    wwid 3600c0ff000530bf13e49c26901000000
}

multipaths {
    multipath {
        wwid 3600c0ff000530bf13e49c26901000000
        alias msa2060_lun1
    }
    multipath {
        wwid 3600c0ff000fb00fb1e07bd6901000000
        alias msa2060_lun2
    }
}

In der Debian-manpage zu multipath.conf finde ich nix zu "discard", und ich will da jetzt auch nix dran ändern, wenn es nicht erforderlich oder sinnvoll ist.

Was meint Ihr zu der These? Ich lern halt gerne dazu, für ein etwaiges nächstes Mal ;-)
 
Warum sollte Multipathing den discard-Befehl nicht weitergeben?
Bzw sollte das Discard ja die qcow2-Datei im OCFS2 kleiner machen. Auf der Ebene hat das mit Multipathing zum SAN ja noch gar nichts zu tun.

Soweit ich verstehe, ist ja nun mit shared-LVM das Thema fstrim eher außen vor, oder?
Wir haben da ja nun kein Filesystem, sondern ein Block-Device. (Was passiert, wenn eine VM innerhalb ihres OS ein fstrim macht?)

Wenn das SAN-Storage selber die LUN thin-provisioned macht, kann ein discard aus der VM heraus durchaus sinnvoll sein. Die VM teilt damit dem Storage mit, welche Blöcke durch das Filesystem nicht mehr verwendet werden. Das Storage kann sie dann wieder freigeben.
So funktioniert es jedenfalls mit Ceph und RBDs.
 
  • Like
Reactions: sgw and Johannes S