Cet article fait suite à un ensemble de questions posés par des collègues (avec leur autorisation, après tri et anonymisation) suite au Tour de France DELL Matinfo3.

TL;DR: ça cause de stockage zfs on linux (pros, cons) sur du matériel Dell (mais pas que, 'fin si).

Disclaimer: Je suis un nain posé sur l'épaule d'un géant. Et mon géant à moi, c'est Emmanuel Quemener (http://www.cbp.ens-lyon.fr/emmanuel.quemener/), collègue, ami et voisin de bureau. L'autre nain, c'est Kevin Reverchon qui a conduit la majorité des tests et benchs sur nos configs.

Q- On envisage d'acheter du stockage dans mon laboratoire/unité/whatever et on est plus ou moins partis sur une solution de type Dell R720 + MD1200. Je crois savoir que tu as une solution qui se rapproche de ce que j'envisage...

R- Tout à fait. Dell PowerEdge R720xd (en 12 ou 24 disques) + 2x Carte SAS HBA (Host Bus Adapter) + des baies à deux controleurs, pleins (MD1200, MD1220 et MD3060e).

Q- je crois que tu fais du ZFS raidz2 sous Debian et non du RAID matériel. Cela marche bien ?

R- Oui. Mais il faut le tuner (modprobe.d/zfs.conf ; en fin d'article).

Et parceque le monde n'est pas parfait, on est tombé sur deux cas de machines "maraboutées" (sur 11 R720), dont une reste encore sous surveillance trés rapprochée, parce que ça merde grave et qu'on ne trouve pas pourquoi (probablement un souci matériel, mais bien planqué).

Q- si tu enchaînes les châssis MD, tu ne perds pas trop en perf ?

R- Non, pas constaté de perte de perfs. On mixe du MD1200, MD1220 et MD3060e sur des frontales R720 et R720xd.

Q- en cas de plusieurs châssis MD, tu les chaînes ou cumules des cartes PCI ?

R- Les deux, on utilise multipathd (multipath logiciel). On va jusqu'à 6 chassis MD12x0 chainés par deux chemins. Par contre, 2 chassis MD3060e max (120 disques est le maximum géré par les cartes SAS HBA 6G).

Q- Comment fais-tu pour exporter les disques en JBOD ?

R- Les cartes RAID (H700/710 et H800/810) sont formellement interdites chez nous ;o). Sinon, un VD raid0 par disque... Mais c'est chiant à administrer. Les cartes SAS HBA, c'est du pur JBOD.

Q- Avec cette solution, on peut avoir des spare globaux inter MD ?

R- Pas sûr. Jamais testé.

Q- Coté perf, cela donne quoi ?

R- On sature les liens SAS avant de saturer les disques (1.2 ~ 1.6 GB/s sur les MD12x0, jusqu'à 2 GB/s sur une MD3060e).

Q- Ça résiste bien aux pannes électriques ?

R- Plutot oui (zfs, c'est du COW transactionnel). L'année 2012 a été riche en coupures (travaux du tramway à Debourg) : Jamais perdu de donnée à cause de ça.

Q- Les quotas perso et de groupe marche bien sous ZFS ?

R- Oui. Il y a un affinage (le quota se règle au niveau filesystem) qui peut aller jusqu'à 1 filesystem / user. ZFS offre des possibilités, mais c'est une politique sysadmin (filesystem, et donc quota, groupe ou user).

Q- Ton volume ZFS s'étend sur plusieurs châssis MD ou fais-tu un/des volume(s) ZFS par châssis ?

R- Je fait les deux, ça dépends de l'usage. Je recommande plutot un volume par chassis pour le tout venant. J'ai fais un gros volume avec plusieurs chassis parce qu'il y avait vraiment besoin d'un gros filesystem unique (rare).

Q- Peut-on mélanger les tailles de disques ?

R- C'est vraiment pas conseillé au sein d'un même pool.

Q- As-tu du cache sur la frontale, par exemple via des disque SSD ? Si oui, combien à peu près ?

R- Pas au PSMN, mais la DSI de l'ENS-Lyon le fait sur certains serveurs. 2x HDD 146 GB 15k en zmirror pour les logs (ZIL) et 4x HDD 300 GB 15k à plat pour le cache. Le ZIL peut être passé sur des SSD, c'est une petite volumétrie (~ 200 GB)

Q- Le cache ZFS, ça change vraiment la donne ?

R- Apparement, oui. Mais c'est aussi trés risqué : en cas de coupure, les transactions resté dans les caches sont souvent perdues.

EDIT: Ma première réponse était idiote. Le ZIL, c'est le cache en écriture, et il est surprotégé (zmirror, controleur avec batterie). Les disques de cache à plat, c'est pour la lecture, aucun risque de perte de données.

N'utilisant pas cette configuration, les perfs actuelles me conviennent, je n'ai jamais été au bout de la documentation.

Il n'en reste pas moins qu'une des deux machines qui déconnent à l'ENS-Lyon est justement dans cette config.

Q- Avec le temps, pas trop de dégradation de perf coté ZFS ?

R- Heu, oui, mais non. Je profite des quota de pool pour prendre de la réserve et éviter les 80 % de remplissage. J'ai vérifié cette règle (deux fois) : au-delà de 80 % de remplissage d'un volume, les perfs s'écroulent. Pour de vrai. Users ! Faites le ménage !

Q- Pas de soucis avec NFS et Samba ?

R- Aucun (je ne fais que du NFS et du iscsi). Y'a des réglages un peu tricky pour Samba (acl, xattr). C'est documenté.

Q- Tu es sous Debian wheezy ?

R- Oui. Et zfs on linux 0.6.2 et 0.6.3. Emmanuel a commencé ses tests et validations pour Jessie.

Q- Les processeurs, ça a une importance ?

R- Oui. Les Best Practices disent 1 Ghz par To servi, plus si tu veux activer la déduplication (ce que je déconseille, ça écroule vraiment les frontales). ZFS apprécie l'HyperThreading mais supporte mal les changements de fréquence (réglages bios 'max perf' + désactivation c-states). Plus y'a de coeurs, mieux c'est.

Q- La vache, ça bouffe quand même pas mal. Si tu distribue 100 To, il te faut 100 Ghz en cumulé !?

R- Dans l'idéal d'un serveur offrant des performances exceptionnelles permanentes... :o)

Q- Machine bi-sockets 8 cores à 2 Ghz -> 64 Ghz avec l'hyperthreading activé donc 64 To max ?

R- Ici, je bloque à 83 Ghz cumulés (E5-2670 @2.6 Ghz) pour servir indifférement de 110 To à 528 To bruts. Et ça suffit (même pour le pool de 528 To). C'est juste que c'est un aspect important à ne vraiment pas négliger.

Le mono socket 4c @1.8 Ghz, il faut oublier. J'aurais tendance à conseiller n'importe quel bi-socket au-dessus de 2.4 Ghz.

La thumper originelle (SunFire X4500) était un veau (pas assez de cores, trop lent, et peu de mémoire), et elle pouvait quand même servir 24 TB brut sur 4 interfaces gigabit. C'était (vraiment, trés) lent, mais ça fonctionnait.

Depuis les R510, j'utilise le même ratio performance/prix que pour nos noeuds de calculs (en gros, entre @2.6 Ghz et @2.9 Ghz) et le plus possible de RAM.

Entre le CBP et le PSMN, on a recyclé ~20 SunFire X4150 en petits serveurs de fichier : 8 coeurs E5440 @2.83 GHz, 16 à 24Go RAM pour 8x HDD 1TB 7.2k SATA. C'est étonnant comment c'est performant.

Q- La mémoire aussi ?

R- Oui, aussi. 1 Go par To servi. 512 Mo par To servi est un minimum plancher strict pour les petites volumétries rapides (<36/48 To bruts). Pour de plus grosses volumétries, on peut se permettre un plancher plus bas (mais pas moins de 256 Mo par To). Et il faut tuner le ARC (voir modprobe.d/zfs.conf) pour lui mettre des limites, sinon, zfs overcommit facilement (et paf! le serveur).

Q- La compression zfs, c'est efficace ?

R- Oui. Et comme t'auras une "grosse" machine, ce sera (presque) transparent. Le taux de compression dépendra des données.

Q- Et les imports/exports ? Les upgrades de versions ZFS ?

R- Sous Solaris, ça marche trés bien. Depuis Solaris vers FreeBSD ou ZFS on Linux, il faut obligatoirement être dans la même version de filesystem (v5000). Le bug https://github.com/zfsonlinux/zfs/issues/2025 référence bien les problèmes liés aux upgrades de filesystem (v3/4 vers v5/5000) en ZoL.

Q- Et les transferts de pool ?

R- Comme l'original. Mieux, on peut mixer zfs send/receive avec mbuffer. Et là, on arrache les poils à la maman ours de la carte 10g tellement ça poutre.

C'est tout.

PJ: /etc/modprobe.d/zfs.conf

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

# zfs module options
# /etc/modprobe.d/zfs.conf
#PSMN: $Id: zfs.conf 949 2014-09-26 07:21:39Z ltaulell $

## see modinfo zfs/spl for the available (and changing) parameters

# limits, in bytes
# 1G => 1073741824 (multiplier)
# standard 8GB => 8589934592
# 16G => 17179869184
# 24G => 25769803776
# 32G => 34359738368
# 48G => 51539607552
# 64G => 68719476736
# 96G => 103079215104
# 128G => 137438953472
# 144G => 154618822656
# 192G => 206158430208
# 256G => 274877906944
# 384G => 412316860416

options spl spl_kmem_cache_slab_limit=16384

## standard 8G (miniserv)
# options zfs zfs_vdev_scheduler=deadline zfs_arc_max=8589934592
#
# options zfs zil_replay_disable=1 zfs_arc_max=34359738368
# zfs_arc_memory_throttle_disable=1 zfs_arc_meta_limit=34359738368
# zfs_dedup_prefetch=0 zfs_txg_timeout=10
#
## default 64G, zfs 0.6.2
#options zfs zfs_vdev_scheduler=deadline zfs_arc_min=68719476736 zfs_arc_max=68719476736 \
#zfs_vdev_min_pending=1 zfs_vdev_max_pending=3 zfs_prefetch_disable=1 zfs_txg_synctime_ms=2000 \
#zfs_txg_timeout=5 zfs_nocacheflush=0
## default 64G, zfs 0.6.3
options zfs zfs_vdev_scheduler=deadline zfs_arc_min=68719476736 zfs_arc_max=68719476736 \
zfs_prefetch_disable=1 zfs_txg_timeout=5 zfs_nocacheflush=0

# only for gluster nodes and kvm hosts
#options zfs zfs_vdev_scheduler=deadline zfs_arc_min=51539607552 zfs_arc_max=51539607552 \
#zfs_vdev_min_pending=1 zfs_vdev_max_pending=3 zfs_prefetch_disable=1 zfs_txg_synctime_ms=2000 \
#zfs_txg_timeout=5 zfs_nocacheflush=1

# ref SATA vs SAS
# http://dan.langille.org/2013/02/15/zfs-tuning-2/
# Set maximum oustanding vdev I/O to "1" to prevent parallel reads/writes
# since we only have lowly 5400RPM SATA drives in this thing
#vfs.zfs.vdev.min_pending="1"
#vfs.zfs.vdev.max_pending="1" # 1 sur du SATA, jusqu'a 4 sur du SAS.

#The zfs:zfs_arc_shrink_shift tunable was adjusted to reduce the shrink size,
#which also made them more frequent. The worst-case I/O improved from 10s to 100ms.

Virtual Disk (disque logique dans un contrôleur RAID)

Copy On Write, see https://fr.wikipedia.org/wiki/Copy-on-write

ZFS Intent Log : Avec le SLOG (Separate intent Log), forment le cache en écriture de ZFS.