Mein Ziel ist eine Standardkonfiguration für LVM-Thin-Provisioning, die flexibel genug ist, um einen Sicherheitsspielraum für ein Admin-VM-LV (VolA) gegenüber Benutzer-LVs (VolU1, VolU2, VolU3 ...) zu reservieren, selbst wenn verschiedene Administratoren (bei separaten Installationen) sehr unterschiedliche Mengen an Speicherplatz in ihren jeweiligen Admin-VMs verwenden.
Beispielsweise kann ein Administrator 4 GB in VolA von System1 verwenden, ein anderer Administrator jedoch 50 GB in VolA von System2. Dies bedeutet, dass ein Volume mit fester Größe von 50 GB für den ersten Administrator nicht akzeptabel wäre (und umgekehrt). Aus Flexibilitätsgründen muss VolA daher mit den anderen „Benutzer“-VM-Volumes in den Thin Pool eingefügt werden. Es ist nicht möglich, Installationen für diese Systeme manuell anzupassen.
Weitere Voraussetzungen:
- Admin VM ist der Speicherhost und läuft vom Thinpool aus
- Benutzer-VMs belegen denselben Pool
- Überbereitstellung; alle virtuellen LV-Größen = Größe der physischen Festplatte.
Das Problem tritt auf, wenn Unerfahrenheit des Benutzers, Fehler oder DoS-Versuche in Benutzer-VMs dazu führen,Zuteilung des gesamten verbleibenden freien Speicherplatzesfür ihre Benutzervolumes (VolU1, VolU2 usw.) und hinterlassen auf VolA keinen freien Speicherplatz und die Admin-VM kann nicht booten oder normal funktionieren.
Die Lösung/Ausfallsicherung sollte so automatisch und passiv wie möglich sein. Eine ideale Lösung wäre eine LVM-Eigenschaft, die für alle Benutzer-LVs festgelegt ist, sodass sie nur dann Speicherplatz zuweisen können poolFree < N
, wenn dies der Fall ist, während VolA keine solche Einschränkung hat. Ich konnte jedoch eine solche Funktion in Linux LVM nicht finden und brauche Vorschläge.
Nach einigen Recherchen scheint eine Lösung darin zu bestehen, eine Einstellung zu verwenden, um dmeventd
Befehle auszuführen (wie „alle VMs anhalten“), wenn ein Schwellenwert erreicht wird. Eine neuere Manpage für, die dmeventd
ich online gefunden habe, besagt, dass dies mit einer Einstellung in lvm.conf möglich ist dmeventd/thin_command
; es scheint, dass diese Funktion im Mai 2017 hinzugefügt wurde, also müsste ich einen Backport finden.
Eine andere Möglichkeit könnte das Hinzufügen einer Regel wie der folgenden zu rsyslog.conf sein:
:msg, contains, "some dmeventd message" ^my_pause_vm_script
Antwort1
Wenn Sie verhindern möchten, dass Benutzer denselben Thin Pool wie Ihr Admin-Host übermäßig belegen, sollten Sie bei dieser Zuweisung einen anderen Ansatz wählen.
Sie könnten die administrativen Arbeitslasten in einen separaten Thin Pool auslagern. Und wenn Sie zu viel zuweisen, ist es im Allgemeinen ein guter Ansatz, Ihren Pools einen flexibleren, zuweisbaren Backup-Speicher bereitzustellen, um mit einer vorübergehenden Überzuweisung umzugehen. Eine gute und einfache Möglichkeit hierfür wäre, einige große, langsamere LUNs als kostengünstige „Notfall“-PV für Ihre Pools zu reservieren.
Ich weiß, dass LVM diese Notfallerweiterung mithilfe seiner eigenen Konfiguration durchführen kann, aber ich schreibe dies auf einem Schinkensandwich, das sich kaum aus dem Weg räumen kann, also muss ich die Dokumentation später heraussuchen.