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
@@ -182,6 +182,161 @@ nennt den Grund, bevor etwas angelegt wird.
|
||||
|
||||
---
|
||||
|
||||
## Früher „voll“ sagen, damit Luft zum Löschen bleibt
|
||||
|
||||
Auf einem wirklich vollen Speicher stehen die VMs, und auch das Aufräumen kann
|
||||
scheitern, weil Löschen selbst ein Schreibvorgang ist. Deshalb lohnt es sich, den Speicher schon bei etwa
|
||||
80 % als voll zu behandeln. Im Notfall gibt man die Grenze kurz frei, räumt auf
|
||||
und setzt sie wieder zurück.
|
||||
|
||||
Das gilt zusätzlich zu [`space_min_free`](../sichern/vorhaltezeit.md#platz-vor-dem-snapshot).
|
||||
Beide Grenzen wirken aufeinander: `space_min_free` rechnet mit dem, was Proxmox
|
||||
als frei meldet, und das schrumpft mit der Grenze. Auf einem Test-Cluster sank
|
||||
`MAX AVAIL` mit `full = 0.80` von 41 auf 29 GiB. Bei einer Grenze von 80 % passt
|
||||
deshalb `space_min_free = 15%` besser als die Vorgabe: pvesnap greift dann bei etwa
|
||||
70 % der vollsten OSD ein, mit der Vorgabe von 20 % schon bei etwa 65 %.
|
||||
|
||||
### Ceph: die Ratios
|
||||
|
||||
```bash
|
||||
ceph osd dump | grep ratio # aktuelle Werte
|
||||
ceph df # MAX AVAIL je Pool
|
||||
ceph osd df # Belegung je OSD; die vollste entscheidet
|
||||
ceph health detail # wer ist nearfull, backfillfull, full?
|
||||
```
|
||||
|
||||
| Ratio | Vorgabe | Was passiert, wenn eine OSD sie erreicht |
|
||||
|---|---|---|
|
||||
| `nearfull` | `0.85` | nur eine Warnung |
|
||||
| `backfillfull` | `0.90` | Ceph verschiebt keine Daten mehr auf diese OSD |
|
||||
| `full` | `0.95` | **Schreibvorgänge der VMs hängen**, bis wieder Platz da ist |
|
||||
|
||||
**Einrichten**, Beispiel „voll bei 80 %“. Die Werte müssen aufsteigend bleiben und
|
||||
gelten sofort, ohne Neustart:
|
||||
|
||||
```bash
|
||||
ceph osd set-nearfull-ratio 0.70
|
||||
ceph osd set-backfillfull-ratio 0.75
|
||||
ceph osd set-full-ratio 0.80
|
||||
```
|
||||
|
||||
**Im Notfall**, wenn der Cluster `full` meldet:
|
||||
|
||||
```bash
|
||||
pvesnap list -a # was belegt den Platz?
|
||||
qm delsnapshot <vmid> <snapshot> # zuerst einfach versuchen
|
||||
ceph -s # löst sich full von selbst?
|
||||
|
||||
ceph osd set-full-ratio 0.90 # wenn es hängt, oder die VMs sofort weiter sollen
|
||||
ceph osd set-full-ratio 0.80 # nach dem Aufräumen sofort zurück
|
||||
```
|
||||
|
||||
Bei einem Test mit Ceph 18.2 ging das Löschen trotz `full` durch: Snapshot und
|
||||
ganze Platte waren nach Sekunden weg, der Platz nach 15 Sekunden zurück, `full` löste
|
||||
sich von selbst, und die VMs konnten weiterschreiben. Das Anheben allein ließ die
|
||||
hängenden Schreibvorgänge ebenfalls sofort weiterlaufen.
|
||||
|
||||
Verlassen sollte man sich darauf nicht. Der Test setzte `full` knapp unter die
|
||||
Belegung, die OSDs hatten also noch reichlich echten Platz. Auf wirklich vollen OSDs
|
||||
kann es anders aussehen, und ein früherer Vorfall mit einem vollgelaufenen Pool lief
|
||||
genau so: Auch Löschen stand.
|
||||
|
||||
!!! danger "Nie über `0.96`"
|
||||
|
||||
Ab dem Failsafe-Wert (`ceph config get osd osd_failsafe_full_ratio`, Vorgabe
|
||||
`0.97`) verweigern die OSDs selbst das Schreiben, egal was `full` sagt. Und
|
||||
läuft eine OSD wirklich auf 100 %, startet sie unter Umständen nicht mehr.
|
||||
Das Anheben ist keine Lösung, es verschafft nur Zeit zum Aufräumen.
|
||||
|
||||
!!! warning "Eine niedrige Grenze hat einen Preis"
|
||||
|
||||
Fällt ein Node aus, verteilt Ceph seine Daten auf die übrigen. Das hält bei
|
||||
`backfillfull` an, mit `0.75` also früher, und der Cluster bleibt dann
|
||||
ungeschützt, bis Platz da ist oder die Ratio angehoben wird. Bei 4 Nodes und
|
||||
3 Replikaten steigt die Belegung durch den Ausfall um ein Drittel.
|
||||
|
||||
### ZFS: die Notreserve
|
||||
|
||||
ZFS hat keine solche Ratio. Die Grenze muss man **vorher** einrichten, im Ernstfall
|
||||
lässt sie sich nicht mehr nachholen. Am einfachsten ist ein leeres Dataset, das
|
||||
Platz reserviert. Beispiel: ein Pool `tank` mit 10 TiB, voll bei 80 %:
|
||||
|
||||
```bash
|
||||
zpool list tank # Größe des Pools
|
||||
zfs create -o refreservation=2T -o canmount=off -o mountpoint=none tank/notreserve
|
||||
zfs list -o name,used,avail tank tank/notreserve
|
||||
```
|
||||
|
||||
**Im Notfall**, wenn VMs `No space left on device` melden:
|
||||
|
||||
```bash
|
||||
zfs set refreservation=none tank/notreserve # Reserve freigeben
|
||||
|
||||
pvesnap list -a # was belegt den Platz?
|
||||
zfs list -t snapshot -o name,used -s used # die größten Snapshots zuletzt
|
||||
qm delsnapshot <vmid> <snapshot> # aufräumen
|
||||
|
||||
zfs set refreservation=2T tank/notreserve # danach sofort zurück
|
||||
```
|
||||
|
||||
Das Zurücksetzen gelingt erst, wenn genug Platz da ist. Sonst meldet ZFS
|
||||
`size is greater than available space`, dann muss weiter aufgeräumt werden.
|
||||
|
||||
**Was man dabei sieht** (gemessen an einem kleinen Testpool mit 200 MiB Reserve,
|
||||
vollgeschrieben):
|
||||
|
||||
| Stelle | Anzeige | |
|
||||
|---|---|---|
|
||||
| `zpool list` | `CAP 65 %` | die echte Belegung der Laufwerke, die Reserve zählt nicht |
|
||||
| `zfs list` | `AVAIL 0` | das ist die Grenze, an die die VMs stoßen |
|
||||
| Proxmox-Storage auf einem Dataset (`tank/data`) | 100 % von 631 MiB | die Gesamtgröße schrumpft um die Reserve |
|
||||
| Proxmox-Storage auf dem Pool selbst (`tank`) | 100 % von 832 MiB | Gesamtgröße bleibt, die Reserve zählt als belegt |
|
||||
|
||||
Der Pool wird dabei **nicht schreibgeschützt**. Lesen geht weiter, neue Daten
|
||||
scheitern mit `No space left on device`, und das Löschen von Dateien und Snapshots
|
||||
klappte im Test auch ohne Freigabe der Reserve. Für die VMs ist das trotzdem ein
|
||||
Ausfall: Sie bekommen Schreibfehler, und je nach Einstellung hält Proxmox sie an.
|
||||
|
||||
!!! note "Alternative: Quota"
|
||||
|
||||
`zfs set quota=8T tank/data` wirkt genauso und zählt Snapshots mit, begrenzt
|
||||
aber nur dieses Dataset und seine Kinder. Im Notfall `zfs set quota=9T tank/data`.
|
||||
Die Notreserve ist einfacher, weil sie unabhängig vom Aufbau des Pools für alles
|
||||
gilt.
|
||||
|
||||
!!! warning "Dick angelegte Zvols: Ein Snapshot kostet sofort Platz"
|
||||
|
||||
Ohne `sparse` am Storage reserviert Proxmox die ganze Platte, und diese
|
||||
Reservierung muss auch nach dem Snapshot gelten. Alles, was seit dem letzten
|
||||
Snapshot geschrieben wurde, wird deshalb beim Anlegen zusätzlich belegt. Fehlt
|
||||
der Platz, scheitert der Snapshot mit `out of space`. Bei dünn angelegten Zvols
|
||||
(`sparse 1`) kostet er nichts.
|
||||
|
||||
Das lässt sich exakt ausrechnen:
|
||||
|
||||
```bash
|
||||
zfs get -Hp refreservation,usedbyrefreservation tank/data/vm-100-disk-0
|
||||
# Kosten = refreservation - usedbyrefreservation
|
||||
```
|
||||
|
||||
pvesnap rechnet genau das ein und prüft `frei ≥ Kosten + space_min_free`, die
|
||||
Reserve bleibt also auch nach dem Snapshot frei. `pvesnap --dry-run run --force`
|
||||
zeigt die Rechnung, ohne etwas zu ändern:
|
||||
|
||||
```
|
||||
VM 100 (web): 'zfs': 1.1G frei, Snapshot belegt sofort 100.6M, danach frei 992.2M, Reserve 50.0M
|
||||
```
|
||||
|
||||
Die Werte liefert die Proxmox-API nicht. Läuft der Gast auf einem anderen Node,
|
||||
fragt pvesnap sie per `ssh` ab, über den Schlüssel, den Proxmox im Cluster ohnehin
|
||||
einrichtet. Klappt das nicht, steht eine Warnung im Protokoll und das Volume zählt
|
||||
mit 0, gelöscht wird deswegen nichts.
|
||||
|
||||
Das Löschen alter Snapshots gibt bei Zvols nur frei, was allein dieser Snapshot
|
||||
festhält. Überschreibt eine VM immer dieselben Blöcke, ist das viel, sonst wenig.
|
||||
|
||||
---
|
||||
|
||||
## Empfehlung
|
||||
|
||||
| Lage | |
|
||||
|
||||
Reference in New Issue
Block a user