[SOLVED] Stats from last Garbage Collection

[CH.illig]

Ich biete als Zentralen Backup Server diesen Meinen Kunden an die ebenfalls auf Proxmox setzen.
Zur Abrechnung verrechne ich den Kunden Jeweils die aktuelle Nutzung.

Es wäre daher für mich sehr hilfreich wenn in der Datastore Übersicht nicht nur der Duplikate Faktor, sondern auch der aktuelle Disk Usage angezeigt werden könnte.
Der Datastore liegt lokal im selben ZFS, daher ist der Usage Global über alle Datastores.



Aktuell hohle ich mir diese Information via letztem Garbage Collect wo auch die 13.61 herkommt.

 

[Dunuin]

Wäre es nicht einfacher jedem Kunden dann einen eigenen Datastore anzulegen? Ist dann nicht ganz so gut deduplizierbar, aber wenigstens hättest du alle Kundendaten getrennt und könntest schnell sehen, wieviel Kapazität jeder Kunde wirklich verbraucht.

 

[CH.illig]

Wäre es nicht einfacher jedem Kunden dann einen eigenen Datastore anzulegen? Ist dann nicht ganz so gut deduplizierbar, aber wenigstens hättest du alle Kundendaten getrennt und könntest schnell sehen, wieviel Kapazität jeder Kunde wirklich verbraucht.

Jeder Kunde hat einen eigenen Datastore allerdings im selben ZFS

Der Datastore liegt lokal im selben ZFS, daher ist der Usage Global über alle Datastores.

Hier 2 Stores als Beispiel...


ich weiss, im Nachhinein wäre eine Lösung mit selbst erweiternden ZFS pro Kunde was aber auch andere Nachteile mit sich bringt...

 

[fabian]

entweder wie @Dunuin vermutlich gemeint hat pro datastore ein dataset anlegen (und ne refquota setzen) - dann wird die usage aktuell richtig angezeigt. sonst enthaelt die API response ohnehin den rest der daten (wenn das 'verbose' flag gesetzt ist):

{
    "data": {
        "avail": 311202807808,
        "counts": {
            "ct": {
                "groups": 3,
                "snapshots": 25
            },
            "host": null,
            "other": null,
            "vm": {
                "groups": 6,
                "snapshots": 10
            }
        },
        "gc-status": {
            "disk-bytes": 3225894163,
            "disk-chunks": 831,
            "index-data-bytes": 135291504208,
            "index-file-count": 252,
            "pending-bytes": 0,
            "pending-chunks": 0,
            "removed-bad": 0,
            "removed-bytes": 0,
            "removed-chunks": 0,
            "still-bad": 0,
            "upid": "UPID:host:0033B7F1:140BDEA3:00000096:60619906:garbage_collection:store:user@pam:"
        },
        "total": 355215867904,
        "used": 44013060096
    }
}

bzw der gc-status teil ist auch via proxmox-backup-manager verfuegbar:

proxmox-backup-manager garbage-collection status DATASTORE --output-format json-pretty
{
  "disk-bytes": 12731110663,
  "disk-chunks": 13431,
  "index-data-bytes": 382366028608,
  "index-file-count": 298,
  "pending-bytes": 0,
  "pending-chunks": 0,
  "removed-bad": 0,
  "removed-bytes": 0,
  "removed-chunks": 0,
  "still-bad": 0,
  "upid": "UPID:host:002B7744:1DEFD243:00000000:6076EBE3:garbage_collection:store:user@pam:"
}

auf der GUI standardmaessig die ganzen daten anzuzeigen ohne den kontext dass es sich dabei um einen potenziell sehr veralteten status handelt ist ein bisschen problematisch, deswegen haben wir derzeit "nur" den dedup-faktor drin.

 

[fabian]

ueber das upid feld laesst sich dann auch der komplette log des tasks bzw. die status infos (z.b. start/end zeitpunkt) auslesen (proxmox-backup-manager task ...)

 

[CH.illig]

Danke,
zur kurzen Bestätigung... oder als "Anleitung"

Ausgangslage

root@srv:~# zfs list
NAME               USED  AVAIL     REFER  MOUNTPOINT
rpool             5.09T  19.3T      162K  /rpool
rpool/ROOT        5.09T  19.3T      162K  /rpool/ROOT
rpool/ROOT/pbs-1  5.09T  19.3T     5.09T  /

root@srv:~# zfs create rpool/backup-kunde

root@svdrz220:/# zfs set quota=1T rpool/backup-kunde

und dann einen neuen Datastore erstellen in
/rpool/backup-kunde

Endresultat



Danke

 

[fabian]

genau. die quota ist prinzipiell optional - verhindert aber dass der verfuegbare speicherplatz fluktiert je nachdem wieviel global verbraucht/frei ist, und hat den angenehmen nebeneffekt das user nicht ueber ein definiertes "ziel" hinausschiessen koennen

 

[itNGO]

Danke,
zur kurzen Bestätigung... oder als "Anleitung"

Ausgangslage

root@srv:~# zfs list
NAME               USED  AVAIL     REFER  MOUNTPOINT
rpool             5.09T  19.3T      162K  /rpool
rpool/ROOT        5.09T  19.3T      162K  /rpool/ROOT
rpool/ROOT/pbs-1  5.09T  19.3T     5.09T  /

root@srv:~# zfs create rpool/backup-kunde

root@svdrz220:/# zfs set quota=1T rpool/backup-kunde

und dann einen neuen Datastore erstellen in
/rpool/backup-kunde

Endresultat
View attachment 34101


Danke

Wenn du das auf Spindeln machst ist irgendwo bei 1000 Snapshots pro Datastore allerdings Schluss.... bzw. die Backup-Ansicht in Proxmox geht dann auf Timeout.... Etwas hilft dann ein paar kleine SSDs mit Cache, Special und LOGs im ZFS-Pool hinzuzufügen. Streckt das Problem aber nur etwas.... Per Console Listen/Restoren geht dann aber weiterhin... ist wohl ein anderer Timeout als im Web....

Wenn alles auf SSDs, dann weitermachen.... Coole Sache!!! Mehr davon!

 

[Felix.]

Bei mir habe ich ein ähnliches Konstrukt @home und @wörk laufen.
Mal anhand meines privaten PBS demonstriert:

Es gibt das ZFS dataset rpool/datastore.
Dort habe ich eine Quota gesetzt um sicherzustellen, dass nicht eines Tages der Pool überschwappt, 20% Buffer für ZFS & OS.
Außerdem diverse Konfiguration, recordsize = 4M, compression = zstd, mountpoint = /datastore.

Die 4M recordsize hielt ich für eine gute Idee, da PBS ohnehin mit 4MB Blöcken agiert und größere Recordsizes zu weniger Metadaten führen, d.h. weniger RAM Einbußen, wenn man L2ARC verwendet und weniger Platzverbrauch auf den Special Devices. Bislang habe ich das auch nicht bereut.

Die Compression scheint sich trotz aller Bemühungen von PBS dennoch auszuzahlen.

1.22x mag nicht jeden beeindrucken, aber ich denke mir da "hey, it's free real estate!"

Die darunterliegenden Datasets, bspw fsn-pve-01 erben sämtliche Einstellungen von rpool/datastore, dort setze ich lediglich eine Quota, falls ich das möchte.

Privat ist das ganze ein wenig laxer geregelt mit den Quotas, auch um erstmal den Bedarf festzustellen.
Hier würde man natürlich für jeden Kunden immer eine Quota setzen, je nach bestellter Speichermenge.

Durch die Quota, passen sich auch die Werte in der Weboberfläche (und dementsprechend in den API Responses) entsprechend an - sieht man hier sehr schön am fsn-pmg-01 datastore, den ich auf 1G limitiert habe.
Als Kontrast dazu hat der fsn-pve-01 datastore keine Quota gesetzt, deshalb greifen die 3T Quota von rpool/datastore als oberes Limit.

Wenn du das auf Spindeln machst ist irgendwo bei 1000 Snapshots pro Datastore allerdings Schluss.... bzw. die Backup-Ansicht in Proxmox geht dann auf Timeout....

Bislang bleibt mir das noch erspart, aber man merkt wie es mit wachsender Zahl an Backups degradiert...

@wörk nutze ich Special Devices mit Erfolg, allerdings denke ich mir oft, es wäre noch hilfreicher wenn die kleinen Index Files auch auf SSD liegen würden und wirklich nur der Inhalt des .chunks Ordners auf den Spindeln.
Dafür habe ich leider noch keinen gangbaren Weg entdeckt.
special_small_blocks wäre vielleicht eine Idee, um die kleinen Index Files mit auf die Special Devices zu verlagern. (?)
Besonders bei den GC Jobs dauert es idR am längsten die Index Files zu markieren. Das tatsächliche durchrattern durch die Metadaten geht zack-zack dank NVMe Special Devices.

Hat ja schon mal jemand experimentiert in die Richtung? Bringt es in der Praxis nennenswerte Vorteile die Index Files auszulagern?

 

[itNGO]

Hat ja schon mal jemand experimentiert in die Richtung? Bringt es in der Praxis nennenswerte Vorteile die Index Files auszulagern?

Anhand dieser Beschreibung haben wir das bei uns umgesetzt.
https://forum.level1techs.com/t/zfs-metadata-special-device-z/159954

Bislang keine Probleme und durchaus brauchbare Perfromance-Werte.