ZFS Tuning
ZFS su Linux è una brutta bestia, che va compresa a fondo per non farsela scoppiare in faccia. La mia personale opinione è che non solo io non ci capisco nulla, ma anche chi sviluppa PVE non ci capisce nulla, o comunque non ci capiva nulla negli anni precedenti. Nelle vecchie versioni di PVE (4.x e anche 5.x se ricordo bene) veniva fatto lo swap su ZFS per esempio che è decisamente una cattiva idea, che causava un "effetto valanga" con conseguente riavvio dell'intera macchina non appena la RAM scarseggiava un poco. Inoltre, anche se sul forum di PVE dicono il contrario, almeno nelle vecchie versioni di ZFS non c'era verso di farle rilasciare la RAM che si mangiava.
NOTA BENE: La mia scarsissima esperienza si limita al solo mirroring in ZFS, niente di più complesso.
Per riferimento, leggete anche questa documentazione: https://pve.proxmox.com/wiki/ZFS:_Tips_and_Tricks
Limitare la ARC cache di ZFS
Limitare la cache è fondamentale per non trovarsi la macchina con metà della RAM usata da ZFS. Quindi a meno che non siate ricchi e vogliate comperare il doppio della RAM che pensate vi serva per le VM, dovrete porre un freno alla fame di ZFS.
Editare il file /etc/modprobe.d/zfs.conf e scriverci dentro: (per esempio 4G max e 1G min)
options zfs zfs_arc_max=4294967296 options zfs zfs_arc_min=1073741824
Eseguire update-initramfs -u
- Riavviare la macchina
Nota: e` possibile limitare la dimensione "a runtime" senza riavviare, usando echo 4294967296 > /sys/module/zfs/parameters/zfs_arc_max ma questo funziona solo la dimensione attuale della ARC cache e` inferiore a quella impostata. Se e` gia` cresciuta oltre, non calera` mai piu` se non riavviando. Ovviamente questa impostazione non e` persistente dopo il reboot. C'e` chi sostiene che eseguendo echo 3 > /proc/sys/vm/drop_caches la cache dovrebbe ridursi... ma io non ci proverei su una macchina in produzione.
Configurazione di un sistema di allarme per email se il raidz di zfs va in degraded
Non e` proprio un avviso in tempo reale, ma queste righe aggiunte a /etc/crontab permettono di avere un allarme sufficientemente tempestivo, si spera.
# allarme se si rompe zfs. MAILTO=youremail@example.com 00 6,12,20 * * * root zpool status | grep DEGRADED
Nelle versioni piu` recenti di PVE si può installare il pacchetto zfs-zed che manda allarmi via email. Va impostata la configurazine della email in /etc/zfs/zed.d/zed.rc scommentando la riga ZED_EMAIL_ADDR="root". L'ho provato sulla versione 6 (e` di default) e mi ha segnalato tutti gli eventi tranne quello importante, cioe` quando ho staccato apposta un disco per mandare il pool in degraded, quindi io consiglierei di usare anche la soluzione "fatta in casa" con cron. Due allarmi sono meglio di uno.
Problema di corruzione dei dati in ZFS su PVE 7.2 o successivo
A quanto pare in tutte le versioni di ZFS dal 2013 al 2023 c'e` un rischio che ci sia perdita di dati (lettura di blocchi tutti a zero) nel caso in cui si verifichi una particolare race condition. La probabilita` è bassa ma non nulla. Per ridurre al minimo la probabilità è opportuno impostare
echo 0 > /sys/module/zfs/parameters/zfs_dmu_offset_next_sync
Lo si puo` mettere in grub come parametro di boot al kernel zfs.zfs_dmu_offset_next_sync=0 oppure in sysyctl.
Qui c'e` un poco di documentazione a riguardo, con anche una FIX per PVE 8.1. Probabilmente sarà inclusa nella prossima release.
https://www.reddit.com/r/Proxmox/comments/1877yaz/bugfix_now_available_for_dataloss_bug_in_zfs/ https://forum.proxmox.com/threads/opt-in-linux-6-5-kernel-with-zfs-2-2-for-proxmox-ve-8-available-on-test-no-subscription.135635/ https://github.com/openzfs/zfs/issues/15526