Platz vor jedem Snapshot pruefen, bei Mangel alte loeschen, per Mail warnen
Volle Ceph-Pools legen alle VMs darauf lahm. Vor jedem Snapshot gilt jetzt je Storage des Gastes: frei >= sofortiger Verbrauch + space_min_free (Vorgabe 20 %). Die Reserve bleibt also auch nach dem Snapshot frei. Reicht es nicht, wird der aelteste pvesnap-Snapshot des Gastes geloescht und neu geprueft, bis es reicht. Sind nur noch die neuesten space_keep (Vorgabe 7) uebrig, entfaellt der Snapshot und der naechste Gast kommt dran. Gezaehlt wird je Gast ueber alle Gruppen, anders als bei der Vorhaltezeit. Auf dem Testhost haette eine Grenze je Gruppe nie gegriffen: keep_count = 5 liegt unter 7, und 13 GiB steckten in einer Gruppe, die es nicht mehr gibt. Sofortiger Verbrauch: Dicke ZFS-Zvols muessen ihre Reservierung auch nach dem Snapshot garantieren, das kostet alles seit dem letzten Snapshot Geschriebene. Exakt ist das refreservation - usedbyrefreservation; die Werte kommen per zfs get, bei anderen Nodes per ssh ueber die IP aus dem Clusterstatus, weil Node-Namen nicht ueberall aufloesen. Dazu kommt der RAM bei vmstate. --dry-run zeigt die Rechnung je Storage. Ceph und ZFS geben Platz erst im Hintergrund frei. Deshalb wird nach jedem Loeschen gewartet, solange der Platz waechst, und erst nach space_settle (Vorgabe 30s) ohne Zuwachs weitergemacht. Ohne das wurde auf Ceph ein Snapshot zu viel geloescht. Laesst sich der Platz nicht feststellen, wird nichts geloescht und der Snapshot trotzdem versucht. Neu ist [mail]: eine Alarm-Mail je Gruppe und Lauf, wenn ein Snapshot wegen Platzmangels ausfaellt. STARTTLS oder SSL/TLS mit Zertifikatspruefung, ohne Rueckfall auf Klartext. Einzurichten im Editor (Taste m) oder von Hand, Test mit pvesnap mail-test. Liegt ein Passwort in der Datei, setzt der Editor die Rechte auf 600, auch fuer die .bak. Das Handbuch beschreibt, wie man Ceph (Ratios) und ZFS (Notreserve) frueher "voll" sagen laesst und was im Notfall zu tun ist. Ausserdem war "pvesnap run --dry-run" ueberall falsch: Die Option ist global und muss vor dem Unterbefehl stehen. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
duffyduck
co-authored by
Claude Opus 5.5
Claude Opus 5.5
parent
d9d9345d03
commit
74be5aee59
@@ -51,13 +51,99 @@ bleibt immer einer übrig.
|
||||
|
||||
---
|
||||
|
||||
## Platz vor dem Snapshot
|
||||
|
||||
```ini
|
||||
space_min_free = 20% # so viel muss frei sein (auch absolut: 20G; 0 = keine Prüfung)
|
||||
space_keep = 7 # so viele bleiben auch bei Platzmangel stehen
|
||||
```
|
||||
|
||||
Vor jedem Snapshot sieht pvesnap auf **allen Storages der VM** nach, ob
|
||||
`space_min_free` auch danach noch frei bleibt. Die Werte oben gelten als Vorgabe,
|
||||
auch ohne Eintrag in der Konfiguration. Wer mehr oder weniger möchte, setzt sie
|
||||
in `[defaults]` für alle Gruppen, je Gruppe einzeln oder im
|
||||
[Editor](editor.md) unter *Mindestens frei*.
|
||||
|
||||
1. Genug Platz: Der Snapshot wird angelegt.
|
||||
2. Zu wenig Platz: Der **älteste** pvesnap-Snapshot der VM wird gelöscht, dann wird
|
||||
erneut geprüft. Das wiederholt sich, bis der Platz reicht. Weiter gelöscht
|
||||
wird dann nicht.
|
||||
3. Sind nur noch die neuesten `space_keep` übrig und es reicht immer noch
|
||||
nicht, entsteht für diese VM **kein** Snapshot. Das steht als Fehler im
|
||||
Protokoll, und die nächste VM kommt dran.
|
||||
|
||||
**Was geprüft wird:** `frei ≥ sofortiger Verbrauch + space_min_free`. Die Reserve
|
||||
bleibt also auch nach dem Snapshot frei und ist für das da, was die VM danach
|
||||
schreibt, denn wie groß ein Snapshot später wird, lässt sich nicht vorhersagen.
|
||||
|
||||
| | Sofortiger Verbrauch |
|
||||
|---|---|
|
||||
| Ceph, LVM-thin, dünne ZFS-Zvols, qcow2 | praktisch nichts |
|
||||
| [Dicke ZFS-Zvols](../nachschlagen/speicher.md#zfs-die-notreserve) | alles seit dem letzten Snapshot Geschriebene, exakt berechnet |
|
||||
| `vmstate = yes` | zusätzlich der zugewiesene RAM, als Obergrenze |
|
||||
|
||||
Eine Vorschau zeigt `pvesnap --dry-run run --force`: Je Storage steht dort, was frei
|
||||
ist, was der Snapshot belegen würde, was danach frei bleibt und wie groß die Reserve
|
||||
ist.
|
||||
|
||||
Dabei gilt:
|
||||
|
||||
* Gezählt wird **je VM über alle Gruppen**, anders als bei der normalen
|
||||
Vorhaltezeit. Ein voller Pool ist schlimmer als ein verlorener alter Stand.
|
||||
Bei Platzmangel kann eine stündliche Gruppe deshalb auch die Monatsstände
|
||||
derselben VM löschen, ebenso Snapshots von Gruppen, die es nicht mehr gibt.
|
||||
* Halbfertige Einträge werden zuerst entfernt und zählen nicht mit.
|
||||
* Das `keep_min` jeder Gruppe bleibt auch hier gewahrt.
|
||||
* Von Hand angelegte Snapshots bleiben auch hier unangetastet.
|
||||
* Lässt sich der Platz nicht feststellen, wird nichts gelöscht und der Snapshot
|
||||
trotzdem versucht.
|
||||
* Ein Klon-Quell-Snapshot (`snapshot is protected`) wird als Fehler gemeldet und
|
||||
übergangen, weiter geht es mit dem nächsten.
|
||||
* `pvesnap run --no-prune` löscht nie. Fehlt der Platz, entfällt der Snapshot.
|
||||
* `pvesnap --dry-run run` löscht nichts und kann deshalb nicht sehen, wann es
|
||||
reichen würde. Es nennt alle Snapshots, die infrage kämen.
|
||||
|
||||
**Wie viel Puffer?** Die Schwelle bleibt frei für das, was die VMs bis zum
|
||||
nächsten Lauf schreiben, und damit Löschen überhaupt noch funktioniert. Grobe
|
||||
Werte aus einem Ceph-Cluster mit 8 OSDs und 3 Replikaten:
|
||||
|
||||
| `space_min_free` | Vollste OSD | |
|
||||
|---|---|---|
|
||||
| `10%` | 86 % | schon über der `nearfull`-Warnung |
|
||||
| `15%` | 82 % | knapp darunter, wenig Reaktionszeit |
|
||||
| `20%` | 78 % | Vorgabe |
|
||||
| `30%` | 69 % | für viel Schreiblast oder kleine Pools |
|
||||
|
||||
Als Probe sollte der Puffer mindestens das Dreifache von dem abdecken, was im
|
||||
Pool zwischen zwei Läufen im schlimmsten Fall neu belegt wird. Bei großen Pools
|
||||
passt oft eine feste Größe wie `2T` besser.
|
||||
|
||||
Fällt deshalb ein Snapshot aus, kann pvesnap
|
||||
[per Mail warnen](../nachschlagen/konfiguration.md#mail). Wie man Ceph und ZFS
|
||||
schon vorher eine Grenze setzt, damit im Notfall Luft zum Löschen bleibt, steht
|
||||
unter [Früher „voll“ sagen](../nachschlagen/speicher.md#fruher-voll-sagen-damit-luft-zum-loschen-bleibt).
|
||||
|
||||
!!! note "`space_settle`: warten, bis der Platz zurückkommt"
|
||||
|
||||
Ceph und ZFS geben gelöschten Platz erst im Hintergrund frei. Würde pvesnap
|
||||
sofort nachsehen, wäre scheinbar noch nichts frei und der nächste Snapshot
|
||||
würde umsonst gelöscht. Deshalb wartet es, solange der freie Platz wächst,
|
||||
und geht erst weiter, wenn sich `space_settle` lang (Vorgabe `30s`, in
|
||||
`[global]`) nichts mehr getan hat. Auf einem Test-Cluster mit NVMe war der Platz
|
||||
nach wenigen Sekunden zurück; ohne die Wartezeit wurde dort ein Snapshot zu viel
|
||||
gelöscht. Bei HDDs und großen Snapshots dauert es länger. Das Löschen einer VM kann also dauern;
|
||||
die Arbeitssperre bleibt währenddessen gehalten.
|
||||
|
||||
---
|
||||
|
||||
## Getrennt je VM und Gruppe
|
||||
|
||||
Beide Grenzen zählen **pro Gast und pro Gruppe**, nicht insgesamt.
|
||||
|
||||
`keep_count = 24` bei 30 Maschinen heißt also: bis zu 720 Snapshots — aber je
|
||||
Maschine nur 24. Und eine VM, die in drei Gruppen steckt, hat 24 + 14 + 6
|
||||
Snapshots nebeneinander, die sich nicht gegenseitig verdrängen.
|
||||
Snapshots nebeneinander, die sich nicht gegenseitig verdrängen. Einzige Ausnahme
|
||||
ist der [Platzmangel](#platz-vor-dem-snapshot).
|
||||
|
||||
---
|
||||
|
||||
@@ -89,7 +175,7 @@ vor-update-14.2 ← wird nie angefasst
|
||||
```bash
|
||||
pvesnap prune # alle Gruppen
|
||||
pvesnap prune -g stuendlich # nur diese
|
||||
pvesnap prune --dry-run # zeigt, was wegkäme
|
||||
pvesnap --dry-run prune # zeigt, was wegkäme
|
||||
```
|
||||
|
||||
Praktisch nach dem Verkürzen einer Vorhaltezeit: Der Dienst würde erst beim
|
||||
|
||||
Reference in New Issue
Block a user