Exemple de dimensionnement d’un filer ZFS (HPE, 2021)

Contexte :

Calcul de dimensionnement d’un serveur ZFS pour un service NFS (NAS) des homes dans un laboratoire de mathématiques. Pour 1000 utilisateurs totalisant environ 30 TiB de fichiers, constitués essentiellement de mails, codes et textes d’article en cours de rédaction. Ce service est accessible depuis environ 400 postes clients, avec un taux d’augmentation des volumes de l’ordre du TiB par an.

Dans ce laboratoire, il y a la possibilité d’avoir une sauvegarde asynchrone fréquente vers un serveur secondaire en PRA. Il existe un risque important de ne pas retrouver dans 5 ou 7 ans les fonds nécessaire pour le remplacement et devoir laisser fonctionner cette solution aussi longtemps que possible.

Les chassis disponibles sur MatInfo5 en janvier 2022 ont 24 (HPE 4200) ou 60 (HPE 4510) emplacements disques, avec 7 ans de garantie au maximum. Compte tenu du cas d’usage, on choisit le petit modèle que l’on dotera des plus petits médias disponible sur ce marché (8 TiB).

La factorisation en nombre premier du nombre de slots disponible pour former des groupes raidz donne :

  • 24 = 2 x 2 x 2 x 3

  • 23 = 23

  • 22 = 2 x 11

  • 21 = 3 x 7

  • 20 = 2 x 2 x 5

  • 19 = 19

  • 18 = 2 x 3 x 3

  • 17 = 17

Au dessous, la perte d’emplacements pour le spare (disque de secours dormant) dépassera la taille d’un groupement raisonnable, et en pratique, on considére pour l’exemple que des groupes de 3, 4, 6, 8 ou 12 HDD sans spare ou des groupes de 5, 7, 9, 10, 11 ou 23 HDD avec spare.

On peut calculer une espérance de vie des RAID [1], à l’aide de calculatrices en ligne ([2], [3]).

Ces outils permettent de faire apparaître l’importance des risques, d’une part d’une double panne de média pendant le temps écoulé entre le moment de la panne et la fin de la reconstruction d’un nouveau disque, mais aussi d’autre part les risques liés à la présence d’erreur systématiques à la relecture des données stockées sur un media. Ces facteurs deviennent prépondérants depuis que les média ont franchi la barre du TiB.

Ici, pour l’exemple, on choisit des valeurs très conservatives avec un taux d’attrition autour de 8 % par an et par disque, ce qui majore les pires taux communément observés sur les statistiques des gros consommateur de media [4].

Avec ces média, on me donne aussi une probabilité de perte d’information à la lecture de l’ordre de 1 bloc de 4096 octets de perdu tout les \(10^{15}\) octets écrits, ce qui implique que sans au moins 1 disque de parité présent, on aura forcement dans un groupe RAID une erreur de vérification de cohérence de la donnée dans un groupe de disques et qu’il faut donc considerer les raidz2 ou raidz3 et éliminer les modes mirror ou à simple parité raidz1.

On souhaite aussi un maximum de groupes de disques car avec les codes de correction d’erreur à distribution de parité de ZFS (raidz) en écritures aléatoires, au pire, la latence d’un groupe de disque est celle du plus lent [5].

Cette condition de performance dans le cas des homesdir des mathématiciens, implique d’avoir des performances supérieures à celles d’un petit nombre d’accés. Pour cette raison, on ne considère pas les organisations de groupe ne permettant pas d’avoir moins de 4 groupes avec les 24 emplacements de notre chassis. Reste donc les groupes des 3, 4, 5 et 6 HDD.

Dans les pires conditions d’écriture avec des médias à 7200 t/mn, on aura une latence annoncée de l’ordre de 10 ms, soit 100 entrées/sorties par seconde (IO/s) ou en fonction des organisations possible sur le chassis :

  1. 8x (3x HDD en raidz2) = 64 TiB avec 800 IO/s

  2. 6x (4x HDD en raidz2) = 96 TiB avec 600 IO/s

  3. 4x (5x HDD en raidz2 + 4x spare) = 96 TiB avec 400 IO/s

  4. 4x (6x HDD en raidz2) = 128 TiB avec 400 IO/s

  5. 4x (5x HDD en raidz3 + 4x spare) = 64 TiB avec 400 IO/s

  6. 4x (6x HDD en raidz3) = 96 TiB avec 400 IO/s

Toutes ces solutions couvrent largement le volume cible à 7 ans qui sera de moins de 40 TiB. Les raidz2 avec spare ou raidz3 offrent les plus grandes espérances de vie au calcul des MTTDL, en particulier dans un contexte ou l”ASR, lors d’une panne le soir de veille d’un pont, ne pourrait remplacer le média qu’aprés 5 ou 6 jours, avec les temps de remplacement du fournisseur (on peut alors calculer une vitesse de reconstruction bien inférieur au MiB).

De plus, le contexte du laboratoire impliquant un risque de non-renouvellement du matériel à 7 ans induit l’acceptation d’une petite perte de performance pour une plus grande tolérance à la panne.

Pour ces raisons, le choix d’un raidz2 sans secours est difficile. Ici, on sélectionnera le raidz3 avec une organisation de 4 groupes de 6 HDD.

Ce choix induira une nécessité d’optimisation du serveur pour satisfaire les utilisateurs. Les CPU du chassis détermineront la performance du service sur le chiffrement et la compression.

L’abondance de la RAM permettra de maintenir un grand nombre de processus serveurs NFS et un cache important pour ceux-ci. La réduction des IO/s avec le choix sous-performant de l’organisation des medias pourra être compensé par la présence de cache L2ARC et ZIL. La présence d’un média séparé pour le journal évite en effet une double écriture, l’une pour la journalisation plus une pour la modification des données.

Les NVDIMM Optane, disponible pour le HPE 4x00 sur le marché MatInfo5, en lot de 4, et placés sur les 2 CPU permettront d’égaliser les temps d’accès vers le ZIL, ce qui est bon, compte tenu de la sensibilité de l’algorithme de ZFS, pour anticiper les temps d’accès au média et ordonnancer les demandes d’écriture.

La plus petite taille de NVDIMM disponible au marché MatInfo5 est de 128 GiB. Avec un tunning éventuel, le ZIL pourra agréger plus de 5 secondes d’écritures aléatoires et permettront des pics de charge courts sur ces périodes, tout en accélerant le déverrouillage des fichiers écrits via NFS. L’agrégation en mode mirror de 2 barrettes par CPU (groupe 1 en miroir sur CPU 1 et 2, groupe 2 en miroir sur CPU 1 et 2) réduira le risque de perte d’un ZIL et de corruption du pool.

Des NVMe, par exemple dans la cage arrière du serveur, amenagée pour 6 média hotplug, serviront de cache en lecture.

Ici, avec 6 des plus petit NVMe, on aura \(1/10e\) de l’espace de stockage en cache, ce qui, une fois passée deux ou trois jours de fonctionnement, permettra d’avoir en cache pratiquement toutes les opérations de lecture et de laisser descendre vers les medias les seules opérations d’écriture.

Avec une connectivité sur 2 ou 4 ports 10 Gbits/s sur le commutateur central, la plupart des utilisateurs devraient avoir des performances de l’ordre de 150 MiB/s et 10 kIO/s dans leurs cas d’usage (lectures fréquentes de leurs maildir et de leurs documents, écritures rares d’un fichier de quelques MiB). Ces performances doivent permettre d’éviter un fort désir de migration de leurs données sur les SSD local de leurs postes de travail.

zpool create raidz3 disk0 disk1 disk2 disk3 disk4 disk5 \
raidz3 disk6 disk7 disk8 disk9 disk10 disk11 \
raidz3 disk12 disk13 disk14 disk15 disk16 disk17 \
raidz3 disk18 disk19 disk20 disk21 disk22 disk23 \
log mirror pmem1 pmem3 \
log mirror pmem2 pmem4 \
cache nvme0 nvme1 nvme2 nvme3 nvme4 nvme5