Les systèmes de cache

À faire

explain transactions (calculs des checksums, des checksums de checksums, métadata, compression/déduplication, ordonnancement des flux d’écriture, lock & COW)

Adaptive Replacement Cache (ARC)

Le ARC est placé en RAM. Il contient les transactions en cours d’écriture ainsi que les derniers objets lus (par extension, les fichiers les plus utilisés).

Déterminer la taille maximale du ARC est important : Il faut trouver un équilibre entre quantité et besoin. Il n’y a pas de recette magique, ses valeurs dépendent du contexte d’utilisation.

Par défaut, les recommandations [1] sont de 75 % de la mémoire vive maximum sur les systèmes dotés de moins de 4 GiB de mémoire. Vous pouvez vous aider de cette calculatrice : http://www.matisse.net/bitcalc/.

Créer le fichier /etc/modprobe.d/zfs.conf :

# vi /etc/modprobe.d/zfs.conf

Quelques exemples en fonction de votre mémoire disponible :

# 384 GiB
options zfs zfs_arc_max=412316860416
# 256 GiB
options zfs zfs_arc_max=274877906944
# 192 GiB
options zfs zfs_arc_max=206158430208
# 144 GiB
options zfs zfs_arc_max=154618822656
# 128 GiB
options zfs zfs_arc_max=137438953472
# 96 GiB
options zfs zfs_arc_max=103079215104
# 80 GiB
options zfs zfs_arc_max=85899345920
# 50 GiB
options zfs zfs_arc_max=53687091200
# 40 GiB
options zfs zfs_arc_max=42949672960
# 30 GiB
options zfs zfs_arc_max=32212254720
# 24 GiB
options zfs zfs_arc_max=25769803776
# 16 GiB
options zfs zfs_arc_max=17179869184
# 8 GiB
options zfs zfs_arc_max=8589934592

Il ne faut en choisir, et appliquer, qu’une seule dans cette longue liste.

# /etc/modprobe.d/zfs.conf
# serveur avec 24 GiB de RAM -> 16 GiB dédiés au ARC
options zfs zfs_arc_max=17179869184

Après le reboot de votre machine, vérifier la prise en compte des xx GiB en visualisant la consommation de l”ARC :

# arc_summary -p 1  # DEPRECATED!
# arc_summary -s arc
...
Target size (adaptive):                       100.0 %   XX.0 GiB
...

Level 2 ARC (L2ARC)

Le L2ARC est une extension sur disque et propre au pool, dédiée aux opérations de lecture, du ARC. Par analogie, le L2ARC est au ARC ce que le swap est à la RAM : Il contiendra les fichiers les moins utilisés des fichiers les plus souvent lus, ou ceux trop gros pour tenir dans le ARC.

Il est nécessaire d’utiliser des SSD. Il vaut mieux plus de RAM pour le ARC qu’un L2ARC placé sur des disques mécaniques.

Pour ajouter un L2ARC au pool tank :

zpool add tank cache ssd1

Comme toujours, l’usage du L2ARC dépend du contexte. Un serveur NFS de gros fichiers régulièrement lu, mais peu écrit, en bénéficiera, par exemple.

ZFS Intent Log (ZIL)

Le ZIL est une structure propre au pool, stockée en RAM (la partie écriture du ARC) par défaut, qui contient les transactions en cours d’écriture. Il peut être déporté sur un vdev dédié pour sécuriser ces flux d’écritures. Ceci afin de se protéger d’une coupure de courant, en l’absence de cache matériel et de batterie (rappel: pas de contrôleur RAID). C’est un tampon généralement petit (au plus une dizaine de GiB).

Il s’avère que cela apporte aussi des performances : La présence d’un média séparé pour le journal évite en effet une double écriture, l’une pour la journalisation, l’autre pour la modification des données.

Il faut privilégier les SSD rapides, write-intensive, voire les NVDIMM. Ils seront assemblés obligatoirement en mirror (la perte du ZIL pouvant entrainer la corruption du pool).

Encore une fois il n’y a pas de règle d’or, la bonne réponse est de s’adapter au contexte. En principe, on utilise le ZIL lorsqu’on héberge des bases de données de tailles importantes, pour l’hébergement de machines virtuelles ou sur des serveurs de fichiers trés sollicités. En fonction des taux d’utilisation, il peut rapidement devenir indispensable.

Exemple :

zpool add tank log mirror nvd0 nvd1