Exemple de dimensionnement d'un filer ZFS (HPE, 2021) ===================================================== .. meta:: :authors: Sylvain Maurin Contexte : Calcul de dimensionnement d'un serveur :term:`ZFS` pour un service :term:`NFS` (:term:`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 :term:`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 :term:`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 :term:`HDD` sans spare ou des groupes de 5, 7, 9, 10, 11 ou 23 :term:`HDD` avec spare. On peut calculer une espérance de vie des :term:`RAID` [#Greenan_2010]_, à l'aide de calculatrices en ligne ([#gh]_, [#sth]_). 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 [#blackblaze]_. 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 :math:`10^{15}` octets écrits, ce qui implique que sans au moins 1 disque de parité présent, on aura forcement dans un groupe :term:`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 :term:`raidz2` ou :term:`raidz3` et éliminer les modes *mirror* ou à simple parité :term:`raidz1`. On souhaite aussi un maximum de groupes de disques car avec les codes de correction d'erreur à distribution de parité de :term:`ZFS` (:term:`raidz`) en écritures aléatoires, au pire, la latence d'un groupe de disque est celle du plus lent [#Patterson_88]_. 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 :term:`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 : #. 8x (3x HDD en raidz2) = 64 TiB avec 800 IO/s #. 6x (4x HDD en raidz2) = 96 TiB avec 600 IO/s #. 4x (5x HDD en raidz2 + 4x spare) = 96 TiB avec 400 IO/s #. 4x (6x HDD en raidz2) = 128 TiB avec 400 IO/s #. 4x (5x HDD en raidz3 + 4x spare) = 64 TiB avec 400 IO/s #. 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 :term:`raidz2` avec spare ou :term:`raidz3` offrent les plus grandes espérances de vie au calcul des :term:`MTTDL`, en particulier dans un contexte ou l':term:`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 :term:`raidz2` sans secours est difficile. Ici, on sélectionnera le :term:`raidz3` avec une organisation de 4 groupes de 6 :term:`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 :term:`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 :term:`L2ARC` et :term:`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 :term:`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 :term:`ZIL`, ce qui est bon, compte tenu de la sensibilité de l’algorithme de :term:`ZFS`, pour anticiper les temps d'accès au média et ordonnancer les demandes d'écriture. La plus petite taille de :term:`NVDIMM` disponible au marché MatInfo5 est de 128 GiB. Avec un tunning éventuel, le :term:`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 :term:`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 :term:`ZIL` et de corruption du pool. Des :term:`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 :term:`NVMe`, on aura :math:`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. .. code-block:: bash 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 .. [#Greenan_2010] https://www.usenix.org/legacy/event/hotstorage10/tech/full_papers/Greenan.pdf .. [#gh] https://github.com/fomy/simd .. [#sth] https://www.servethehome.com/raid-calculator/raid-reliability-calculator-simple-mttdl-model/ .. [#blackblaze] https://www.backblaze.com/b2/hard-drive-test-data.html .. [#Patterson_88] https://www.cs.cmu.edu/~garth/RAIDpaper/Patterson88.pdf