FreeBSD, ZFS und dedup

Ein paar dedup-Erfahrungen möchte ich hier mitteilen…

Dedup ist ein feature im zfs, welches Daten auf Blocklevel-Ebene dedupliziert. Wird also eine Datei zweimal in zfs-Volume kopiert, wird sie nur einmal ihren Speicherplatz beanspruchen. Aktuell habe ich in meinem Serverchen 2 zpools, einen Raid1-basierten (2x4TB) mit aktiviertem dedup und einen mit Raid5 (4x6TB).
Da dedup sehr viel memory für die Verwaltung benötigt (die sogenannten ddt-tables), wurde auf einer nvme für jeden zpool neben einem 1GB großes ZIL (zfs intent log; Pufferung von metadaten im synchronen IO) ein 29GB großer cache für den L2ARC (hier werden die ddt-Tabellen verwaltet).

[maulwurf@alpina ~]$ zpool list
NAME       SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
WD14TB    12.7T  10.5T  2.24T        -         -    12%    82%  1.11x  ONLINE  -
archiv    21.8T  16.8T  5.01T        -         -    24%    77%  1.14x  ONLINE  -
backup3G  2.72T   497G  2.23T        -         -     0%    17%  1.00x  ONLINE  -
raid1     3.62T  3.45T   180G        -         -    47%    95%  1.17x  ONLINE  -
root       382G   257G   125G        -         -    40%    67%  1.03x  ONLINE  -

Im zpool raid1 liegt ein zfs Volume „backup“, in welches regelmäßig eine WordPress-Seite gesichert wird, sowie eines für Musik-Dateien…
Im zpool archiv befindet sich ein Time Machine-Volume (zusätzlich ein Archiv für große files), auf welches 2 High-Sierra Systeme sowie 2 Big Sur Systeme (macOS) Installationen gesichert werden.
Die Idee ist einfach: Da fallen einige „Dubletten“ an, welche hervorragend dedupliziert werden können… leider gibt aber die zpool-Statistik nur Infos aus, welche den pool als Ganzes betreffen. Im Zuge einer Optimierung der zpool device Verwaltung, muss der zpool archiv noch neu eingerichtet werden.
Für die Reorganisierung wurde eine externe Backup-Festplatte mit 14TB angeschafft, das Kopieren des zfs mit den Backupdaten (9TB/~27,000 files) via zfs send/receive geschah recht zügig mit rund 150MB/s. Danach erfolgte das gleiche Verfahren mit dem Time Machine-Volume (3.75TB/~190,000 files), welches eine Woche brauchte, anfänglich mit rund 30MB/s, letztlich bei knapp 7.6MB/s im Schnitt landete für transferierte 4.14TB (Ausgabe vom Transfer mit -v Option). Was mich verwundert, warum ~400GB mehr transferiert wurden, als vom Urpsrungsvolume angegeben wurden – die Verwunderung wird dann vom Ärger verdrängt, wenn man feststellen darf, daß beim Ziel-zpool keine compression aktiviert war…
Nunja, die Backup-Platte hat keinen L2ARC-cache, was ich als mögliche Ursache für den langsamen Transfer sehe (hat sich beim Wiederherstellen mehr oder minder bestätigt)…
Der Restore war wesentlich erfreulicher, hat er das DatenVolume beim Backup noch um rund 400GB erhöht, behielt der Prozess es diesmal bei und die Datentransferrate lag bei beachtlichen 63MB/s für das dedup-Volume.
Jetzt kommt die Frage, hat der L2ARC cache ausgereicht?, hierzu ist folgende Ausgabe als Ergebnis interessant, beim monitoring hat man die Nutzung prima verfolgen können:

maulwurf@alpina /raid5]# zpool iostat -v raid5
               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
raid5       4.93T  16.9T    177  2.77K  5.32M  72.4M
  raidz1    4.93T  16.9T    177  2.77K  5.32M  72.4M
    ada0p1      -      -    46    532  1.30M  26.3M
    ada1p1      -      -     43    531  1.28M  25.7M
    ada2p1      -      -     43    531  1.44M  26.3M
    ada4p1      -      -     44    532  1.42M  25.6M
  nvd0p6     128K   960M      0      0      1  24.9K
cache           -      -      -      -      -      -
  nvd0p7    19.5G  9.52G    504     41  1.20M  3.09M
----------  -----  -----  -----  -----  -----  -----

von den zur Verfügung stehenden 29GB (L2ARC cache) werden in etwa 2/3 genutzt, für dieses Volume also ausreichend (?)- der ZIL wird fast gar nicht verwendet (mehr oder minder logisch)…
Jetzt kopier ich noch das rund 300GB große Backup-Volume vom raid1 pool in den raid5 –

11:08:51    303G   raid1/backup@backup
received 303GB stream in 5217 seconds (59.5MB/sec)
[root@alpina /raid5]# zpool iostat -v raid5
               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
raid5       5.31T  16.5T    176  2.76K  5.02M  71.2M
  raidz1    5.31T  16.5T    176  2.76K  5.02M  71.2M
    ada0p1      -      -     46    532  1.22M  25.9M
    ada1p1      -      -     43    531  1.21M  25.2M
    ada2p1      -      -     43    531  1.35M  25.9M
    ada4p1      -      -     44    532  1.33M  25.2M
  nvd0p6     256K   960M      0      0      1  48.2K
cache           -      -      -      -      -      -
  nvd0p7    18.6G  10.4G    515     41  1.22M  3.05M
----------  -----  -----  -----  -----  -----  -----

Man sieht hier sogar noch eine Abnahme der cache (L2ARC) Nutzung.

Interessant zur Berechnung benötigter Ressourcen ist der Artikel „dedup or not dedup„, in welchem auch beschrieben wird, wieviel voraussichtlich an ARC-Speicher benötigt wird, in meinem hier betrachteten Falle (vor Umstellung):

[root@alpina ~]# zdb -b raid1 

Traversing all blocks to verify nothing leaked ...

loading concrete vdev 1, metaslab 14 of 15 .....
3.87T completed (3323MB/s) estimated time remaining: 277098hr 45min 20sec        
	No leaks (block sum matches space maps exactly)

	bp count:              35419785
	ganged count:                 0
	bp logical:       4477203583488      avg: 126404
	bp physical:      4252535812096      avg: 120061     compression:   1.05
	bp allocated:     4270123028480      avg: 120557     compression:   1.05
	bp deduped:        463651233792    ref>1: 1992696   deduplication:   1.11
	Normal class:     3806470971392     used: 95.50%

	additional, non-pointer bps of type 0:     132437
	Dittoed blocks on same vdev: 1466474

[root@alpina ~]# zdb -b archiv

Traversing all blocks to verify nothing leaked ...

loading concrete vdev 1, metaslab 14 of 15 .....
17.5T completed (14304MB/s) estimated time remaining: 341616hr 56min 05sec        
	No leaks (block sum matches space maps exactly)

	bp count:             111509014
	ganged count:                 0
	bp logical:      14381112954368      avg: 128968
	bp physical:     13922814364672      avg: 124858     compression:   1.03
	bp allocated:    19192156401664      avg: 172113     compression:   0.75
	bp deduped:        710846349312    ref>1: 3355041   deduplication:   1.04
	Normal class:    18481309908992     used: 77.06%

	additional, non-pointer bps of type 0:     197376
	Dittoed blocks on same vdev: 1664068

Rechnet man den Speicherbedarf für den pool raid1 aus (bp count: 35419785 x 320bytes), kommt man auf ~10GB; bei knapp 32GB Ram und der Kausalität, daß für dedup nur ca 25% vom ARC genutzt werden, ist der Hauptspeicher definitiv zu klein.
Der pool archiv mit seinem Time Machine-Volume würde um die 33GB beanspruchen wollen.

Somit habe ich mittlerweile den Entschluss gefasst, auf dem RAID1 keine Deduplikation mehr zu verwenden und das backup-zfs auf das archiv umzuziehen, sowie den L2ARC für archiv auf 96GB zu erweitern.

Das „Ende“ aktuell vom Lied:

[maulwurf@alpina ~]# zpool list
NAME       SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
backup3G  2.72T   497G  2.23T        -         -     0%    17%  1.00x  ONLINE  -
raid1     3.62T  3.19T   443G        -         -    41%    88%  1.19x  ONLINE  -
raid5     21.8T  17.2T  4.60T        -         -     6%    78%  1.16x  ONLINE  -
root       382G   259G   123G        -         -    41%    67%  1.03x  ONLINE  -

References:
zfs dedup or not dedup
zfs, arc overview
memory requirements dedup/L2ARC

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.