Direkt zum Hauptinhalt

ZFS Optimierung und Todsünden

ZFS Funktionen für SSDs

  • zpool get autotrim <poolname>: Auslesen ob „autotrim“ eingeschaltet ist
  • zpool trim <poolname>: Pool manuell trimmen
  • zpool status -t <poolname>: Auslesen TRIM status
  • zpool set autotrim=on <poolname>: generell trimmen (autotrim einschalten, wenn manuelles trimmen erfolgreich)
  • zfs add rpool cache nvmn0e1: füge nvmn0e1 als cache Device in rpool

ZFS mit Spindeln

  • Je mehr Spindeln desto schneller
  • Gespiegelte Disks ggf. auf mehrere SAS Lanes verteilen (dmesg beobachten)
  • SAS ist schneller als SATA!
  • Maximaler Speed ist oft durch alte HBA limitiert (6/12G)
    • G ist Gigabit, also 6/8 = 750MB/sek max

Todsünden

  • HW-RaidHW RAID Controller nutzen und dortmehrere jedeLUNs als Raid VDEVs nutzen > Datenverust, kein Smart, keine Metriken
Single VDEV Raid z. B. auf Hardware Raid oder iSCSI/FC SAN > Bei Beschädigung kann keine weitere Disk alsdie VolumeRedundanz, bzw. die Konsistenz bestätigen. Wenn ein VDEV zu viele Fehler liefert, lehnt ZFS es für ZFSeinen SWweiteren RaidImport (knallt)dauerhaft ab!!! Eventuell zpool import -fFX poolname probieren, destruktiv für Rollback auf letzten guten Zustand, sehr riskant
Deduplizierung aktivieren (geht> kann nicht mehr ausausgeschaltet prowerden, Pool)ggf. in neueren ZFS Versionen optimiert
ZFS_ARC_MAXZFS_ARC zu hoch/niedrigklein (ca/ 1GBzu progroß TB> Richtlinie)schlechte Leistung, bei Cache und LOG mehr ARC notwendig
Pool über 80% FüllgradFüllstand laufen> lassenLeistungseinschränkung bis Stillstand bei ca 96%
SnapshotbereinigungSnapshot Bereinigung / Management aus dem Blick verlieren (Empfehlung:> 8×1/4h,führt 48h,ggf. 10T,unbeobachtet 4W,zu 3M)vollem Raid
Bei ZFS-Auto-SnapshotSnapshots auf ZielBackups nicht- deaktiviertvöllig (zfskontraproduktiv, setführ com.sun:auto-snapshot=falsezu rpool/replica)sehr vollem Raid
Anfügesnapshot durch schlechtes Management verlieren (Beispiel: nur houlry replizieren, nach 49h kein Anfügen mehr möglich)
Druckbetankung (kann> beidafür schlechtenist SystemenZFS zumnicht Stillstandgemacht, führen,was gerademehr wennkann, OSbraucht aufauch Datenpool)mehr Leistung
PVE auf selbem RaidRAID wie Systeme (kannOS beiauf hoherDatenpool) > Last auf VMs führt im Härtefall bis zum Stillstand führen)Kernelcrash
FreeNASKein aufECC USBRam Sticks> Datenbeschädigung die nicht in jedem Fall durch Scrub und Resilver behoben werden kann (Die Zeit ist vorbei, bitte SSDs nehmen mit USB Adapter, als Beispiel)selten)
Virtuelle Maschinen
Proxmox Datastore auf Directory setzen > Proxmox erstellt eventuell beim Booten den Ordner selbst und ZFS kann dann nicht mounten, Rollback setzt alle virtuellen Disks im Dataset zurück
Platzangaben vertrauen > Recordsizes, Volblocksizes, Compressions, Special Devices und Co. machen eine Vorhersage fast unmöglich und rechtfertigen Thin Provisioning
zpool upgrade zu früh oder zu spät > zpool upgrade erweitert features die ggf. beim aktuellen Proxmox ISO noch nicht verfügbar, jedoch im Upgrade verfügbar sind. Im Recoveryfall kann man nur readonly mounten!
Festplatte ersetzen bei Proxmox ZFS Boot Systemen > zpool replace sollte nur nach Übernahme der Partitionstabelle einer funktionierenden Disk auf die dritte Partition ausgeführt werden, zusätzlich mit ZFSproxmox-boot-tool init/format auf die zweite Partition.
iSCSI LUNs mit Proxmox > nicht empfehlenswert, bestenfalls mit dem Free-/TrueNAS Plugin. Wie lange das supportet ist weiss keiner.
Import Proxmox Pool in Recovery Umgebung > Achtung Eigentümer des Pools ändert sich, daher zpool import -fa Abgesehenbenutzen, vonbeim dernächsten Speicherplatzverschwendung,boot kannwieder eszpool zuimport unontrollierten-fa Mountsund exit, /etc/pve ist in Recoveryumgebung nicht vorhande, da aus ZVOLsFUSE kommengeneriert
Billige USB Adapter und Gehäuse > Manche Adapter haben alle die gleiche Kennung, daher ggf. Raid erstellen und importieren über zpool import /dev/disk/by-path oder by-partuuid

Update 2024 zum Thema Volblocksize

root@pve83:~# zfs create -ovolblocksize=8k rpool/8k -V 1GWarning: volblocksize (8192) is less than the default minimum block size (16384).To reduce wasted space a volblocksize of 16384 is recommended.

rpool/16k                                               1.11G  15.2T  81.4K  -
rpool/8k                                                1.49G  15.2T  81.4K  -

NAME                                              STATE     READ WRITE CKSUM

rpool                                             ONLINE       0     0     0

  raidz1-0                                        ONLINE       0     0     0
    scsi-201000000000000005cd2e475ae4b5651-part3  ONLINE       0     0     0
    scsi-201000000000000005cd2e4f1bd4e5651-part3  ONLINE       0     0     0
    scsi-201000000000000005cd2e4ef8f4b5651-part3  ONLINE       0     0     0
    scsi-201000000000000005cd2e4889d4b5651-part3  ONLINE       0     0     0

Bei RaidZ2 wäre der Overhead über 200%

Inzwischen warnt ZFS, jedoch sieht das keine in der PVE GUI!

Emfpehlung Volblocksize für ZVOLs

Raid 1 / 10 8-16k 

Raid5(Z1) 16k

Raid6+(Z2-3) 32k

Empfehlung Recordsize für Datasets

LXC 128k

Mailarchiv 16k

Proxmox Backup Server 1024k

nach oben