Solution Dell EMC Ready pour le stockage HPC PixStor - Expansion de la capacité

Aucune

Sommaire

1. Introduction
   1. Solution Architecture
   2. Composants de la solution
2. Caractérisation des performances
   1. Clients N performances IOzone séquentielles vers N
   2. Clients N de performances IOR séquentielles vers 1 fichier
   3. Blocs de petite taille aléatoires Clients IOzone Performance N vers N
   4. Performances des métadonnées avec MDtest à l’aide de fichiers vides
   5. Performances des métadonnées avec MDtest à l’aide de fichiers de 4 Ko
3. Conclusions et travaux futurs

 

---

Introduction

Les environnements HPC actuels ont augmenté les demandes de stockage très haut débit qui nécessitent également souvent une capacité élevée et un accès distribué via plusieurs protocoles standard tels que NFS, SMB et d’autres. Ces exigences HPC à forte demande sont généralement couvertes par les systèmes de fichiers parallèles qui fournissent un accès simultané à un seul fichier ou à un ensemble de fichiers à partir de plusieurs nœuds, en distribuant très efficacement et en toute sécurité les données à plusieurs LUN sur plusieurs serveurs.

 

---

Solution Architecture

Ce blog est une solution de système de fichiers parallèles (PFS) pour les environnements HPC, la solution DellEMC Ready Solution for HPC PixStor Storage, où les baies PowerVault ME484 EBOD sont utilisées pour augmenter la capacité de la solution. Figure 1 présente l’architecture de référence illustrant les ajouts saS d’extension de capacité aux baies de stockage PowerVault ME4084 existantes.
La solution PixStor inclut le système de fichiers parallèle général, également appelé Spectrum Scale, en tant que composant PFS, en plus de nombreux autres composants logiciels Arcastream tels que l’analytique avancée, l’administration et la surveillance simplifiées, la recherche de fichiers efficace, les fonctionnalités avancées de passerelle et bien d’autres.


Figure 1 : Architecture de référence.

 

---

Composants de la solution

Cette solution devrait être commercialisée avec les derniers processeurs Intel Xeon scalables Xeon de 2e génération, c’est-à-dit des processeurs Cascade Lake, et certains des serveurs utiliseront la RAM la plus rapide disponible (2 933 MT/s). Toutefois, en raison du matériel actuel disponible pour travailler sur le prototype de la solution afin de caractériser les performances, les serveurs dotés de processeurs Intel Xeon Xeon évolutifs de 1ère génération, c’est-à-dire Des processeurs Skylake et, dans certains cas, une RAM plus lente ont été utilisés pour caractériser ce système. Étant donnée que le goulot d’étranglement de la solution se situe sur les contrôleurs SAS des baies Dell EMC PowerVault ME40x4, aucune disparité significative des performances n’est attendue une fois que les processeurs Skylake et la RAM sont remplacés par les processeurs Cascade Lake envisagés et une RAM plus rapide. En outre, la solution a été mise à jour vers la dernière version de PixStor (5.1.1.4) qui prend en charge RHEL 7.7 et OFED 4.7 pour caractériser le système.

En raison de la situation décrite précédemment, le Tableau 1 contient la liste des principaux composants de la solution, mais lorsque des divergences ont été introduites, la première colonne de description comporte des composants utilisés au moment de la publication et, par conséquent, disponibles pour les clients. La dernière colonne est les composants réellement utilisés pour caractériser les performances de la solution. Les disques répertoriés pour les données (NLS 12 To) et les métadonnées (SSD 960 Go) sont utilisés pour la caractérisation des performances. Les disques plus rapides peuvent fournir de meilleures E/S par seconde aléatoires et peuvent améliorer les opérations de création/suppression des métadonnées.

Enfin, pour des raisons d’exhaustivité, la liste des disques durs de données et des disques SSD de métadonnées possibles a été incluse, qui est basée sur les disques pris en charge tels qu’énumérés dans la matrice de support DellEMC PowerVault ME4, disponible en ligne.

Tableau 1 : composants utilisés au moment de la libération et ceux utilisés dans le banc d’essai

Composant de la solution		À la version	Banc d’essai
Connectivité Internet		Dell Networking S3048-ON Gigabit Ethernet
Sous-système de stockage des données		1 à 4 modèles Dell EMC PowerVault ME4084 1 à 4 disques durs Dell EMC PowerVault ME484 (un par ME4084) 80 à 12 To Disques durs NL SAS3 de 3,5 pouces options 900 Go @15K, 1,2 To @10K, 1,8 To @10K, 2,4 To @10K, NLS 4 To, NLS 8 To, NLS 10 To, NLS 12 To.     8 LUN, RAID 6 linéaire 8+2, taille de fragment 512 Ko. 4 disques SSD SAS3 de 1,92 To pour les métadonnées – 2 disques RAID 1 (ou 4 disques de secours globaux, si le module de métadonnées à forte demande en option est utilisé)
Sous-système de stockage de métadonnées à forte demande en option		1 à 2 disques Dell EMC PowerVault ME4024 (4 me4024 si nécessaire, configuration large uniquement) 24 disques SSD SAS3 de 960 Go 2,5 pouces (options 480 Go, 960 Go, 1,92 To) 12 LUN, RAID 1 linéaire.
Contrôleurs de stockage RAID		SAS 12 Gbit/s
Capacité configurée		Cru: 8 064 To (7 334 Tio ou 7,16 PiB) ~ 6 144 Go (5 588 Tio ou 5,46 PiB)
Processeur	Gateway	2 processeurs Intel Xeon Gold 6230 2,1 G, 20C/40T, 10,4 GT/s, 27,5 Mo de cache, Turbo, HT (125 W) DDR4-2933	Sans objet
	Métadonnées à forte demande		2 processeurs Intel Xeon Gold 6136 à 3 GHz, 12 cœurs
	Nœud de stockage		2 processeurs Intel Xeon Gold 6136 à 3 GHz, 12 cœurs
	Nœud de gestion	2 processeurs Intel Xeon Gold 5220 2,2G, 18C/36T, 10,4 GT/s, 24,75 Mo de cache, Turbo, HT (125 W) DDR4-2666	2 processeurs Intel Xeon Gold 5118 à 2,30 GHz, 12 cœurs
Mémoire	Gateway	12 barrettes RDIMM 16 Gio 2 933 MT/s (192 Gio)	Sans objet
	Métadonnées à forte demande		24 barrettes RDIMM de 16 Gio à 2 666 MT/s (384 Gio)
	Nœud de stockage		24 barrettes RDIMM de 16 Gio à 2 666 MT/s (384 Gio)
	Nœud de gestion	12 barrettes DIMM de 16 Go, 2 666 MT/s (192 Gio)	12 barrettes RDIMM 8 Gio 2 666 MT/s (96 Gio)
Système d’exploitation		Red Hat Enterprise Linux 7,6	Red Hat Enterprise Linux 7.7
Version du noyau		3.10.0-957.12.2.el7.x86_64	3.10.0-1062.9.1.el7.x86_64
Logiciel PixStor		5.1.0.0	5.1.1.4
Échelle du spectre (GPFS)		5.0.3	5.0.4-2
Connectivité réseau hautes performances		Mellanox ConnectX-5 InfiniBand EDR/100 GbE à deux ports et 10 GbE	Mellanox ConnectX-5 InfiniBand EDR
Commutateur hautes performances		2 mellanox SB7800 (haute disponibilité – redondant)	1 carte Mellanox SB7700
Version OFED		Mellanox OFED-4.6-1.0.1.0	Mellanox OFED-4.7-3.2.9
Disques locaux (SYSTÈME d’exploitation et analyse/surveillance)		Tous les serveurs à l’exception du nœud de gestion 3 disques SSD SAS3 de 480 Go (RAID1 + HS) pour le système d’exploitation Contrôleur RAID PERC H730P Nœud de gestion 3 disques SSD SAS3 de 480 Go (RAID1 + HS) pour le système d’exploitation Contrôleur RAID PERC H740P	Tous les serveurs à l’exception du nœud de gestion 2 disques SAS3 300 Go 15 000 t/min (RAID 1) pour le système d’exploitation Contrôleur RAID PERC H330 Nœud de gestion 5 disques SAS3 300 Go 15 000 t/min (RAID 5) pour le système d’exploitation et l’analyse/surveillance Contrôleur RAID PERC H740P
Gestion de systèmes		iDRAC 9 Enterprise + DellEMC OpenManage	iDRAC 9 Enterprise + DellEMC OpenManage

 

---

Caractérisation des performances

Pour caractériser cette nouvelle Ready Solution, nous avons utilisé le matériel spécifié dans la dernière colonne du Tableau 1, y compris le module de métadonnées à forte demande (en option). Afin d’évaluer les performances de la solution, les points de référence suivants ont été utilisés :

• IOzone N à N séquentielle
• IOR N à 1 séquentiel
• Zone d’E/S aléatoire
• Test MD

 Pour tous les benchmarks répertoriés ci-dessus, le banc d’essai disposait des clients, comme décrit dans le Tableau 2 ci-dessous. Étant donnée que le nombre de nœuds de calcul disponibles pour les tests n’était que de 16, lorsqu’un plus grand nombre de threads était nécessaire, ces threads étaient distribués de manière égale sur les nœuds de calcul (c’est-à-dire 32 threads = 2 threads par nœud, 64 threads = 4 threads par nœud, 128 threads = 8 threads par nœud, 256 threads = 16 threads par nœud, 512 threads = 32 threads par nœud, 1 024 threads = 64 threads par nœud). L’objectif était de simuler un plus grand nombre de clients simultanés avec le nombre limité de nœuds de calcul. Comme les benchmarks prennent en charge un grand nombre de threads, une valeur maximale allant jusqu’à 1 024 a été utilisée (spécifiée pour chaque test), tout en évitant une commutation de contexte excessive et d’autres effets secondaires connexes qui n’affectent pas les résultats des performances.

Tableau 2 Banc d’essai client

Nombre de nœuds client	16
Nœud client	C6320
Processeurs par nœud client	2 processeurs Intel(R) Xeon(R) Gold E5-2697v4 18 cœurs à 2,30 GHz
Mémoire par nœud client	12 modules RDIMM 16 Gio 2 400 MT/s
BIOS	2.8.0
Noyau du système d’exploitation	3.10.0-957.10.1
Version GPFS	5.0.3

 

---

Clients N performances IOzone séquentielles vers N

Les performances séquentielles des clients N vers les fichiers N ont été mesurées avec la version IOzone 3.487. Les tests exécutés ont varié d’un seul thread à 1 024 threads, et les résultats de la solution à capacité étendue (4 ME4084s + 4 x ME484s) sont comparés à la solution de grande taille (4 me4084s). Les effets de mise en cache ont été minimisés en définissant le pool de pages GPFS réglable sur 16 Gio et en utilisant des fichiers plus volumineux deux fois plus volumineux. Il est important de noter que pour GPFS, ce paramètre réglable définit la quantité maximale de mémoire utilisée pour la mise en cache des données, quelle que soit la quantité de RAM installée et libre. Il est également important de noter que, dans les solutions HPC DellEMC précédentes, la taille de bloc pour les transferts séquentiels volumineux était de 1 Mio, GPFS était formaté avec 8 blocs de 8 Mio. Par conséquent, cette valeur est utilisée sur l’analyse comparative pour des performances optimales. Cela peut sembler trop volumineux et, apparemment, gaspiller trop d’espace, mais GPFS utilise l’allocation de sous-blocs pour éviter cette situation. Dans la configuration actuelle, chaque bloc a été subdivisé en 256 sous-blocs de 32 Ko chacun.

Les commandes suivantes ont été utilisées pour exécuter le benchmark pour les écritures et les lectures, où Threads était la variable avec le nombre de threads utilisés (1 à 1 024 incrémentés par puissances de deux), et threadlist était le fichier qui allouait chaque thread sur un nœud différent, à l’aide d’une permutation circulaire pour les répartir de manière homogène sur les 16 nœuds de calcul.

./iozone -i0 -c -e -w -r 8M -s 128G -t $Threads -+n -+m ./threadlist
./iozone -i1 -c -e -w -r 8M -s 128G -t $Threads -+n -+m ./threadlist

Figure 2 :  Performances séquentielles


de N à ND’après les résultats, nous pouvons observer que les performances augmentent très rapidement avec le nombre de clients utilisés, puis atteignent un plateau stable jusqu’à ce que le nombre maximal de threads autorisés par IOzone soit atteint. Par conséquent, les performances séquentielles de fichiers volumineux sont stables, même pour 1 024 clients simultanés. Notez que les performances de lecture et d’écriture ont bénéficié du doublement du nombre de disques. Les performances de lecture maximales étaient limitées par la bande passante des deux liaisons IB EDR utilisées sur les nœuds de stockage à partir de 8 threads, et les baies ME4 peuvent avoir des performances supplémentaires disponibles. Notez également que les performances d’écriture maximales ont augmenté de 16,7 à 20,4 Gbit/s à 64 et 128 threads et qu’elles sont plus proches des spécifications maximales des baies ME4 (22 Go/s).

Il est important de garder à l’esprit que le mode de fonctionnement préféré de GPFS est dispersé et que la solution a été formatée pour utiliser ce mode. Dans ce mode, les blocs sont alloués dès le début de l’opération de manière pseudo aléatoire, en répartissant les données sur l’ensemble de la surface de chaque disque dur. Bien que l’inconvénient évident soit une performance maximale initiale plus petite, ces performances sont maintenues assez constantes, quelle que soit la quantité d’espace utilisée sur le système de fichiers. Contrairement à d’autres systèmes de fichiers parallèles qui utilisent initialement les pistes externes qui peuvent contenir plus de données (secteurs) par révolution de disque et ont donc les performances les plus élevées possibles que les disques durs peuvent fournir, mais étant donné que le système utilise plus d’espace, les pistes internes avec moins de données par révolution sont utilisées, avec une réduction des performances consécutive.

 

---

Clients N de performances IOR séquentielles vers 1 fichier

Les clients N séquentiels vers un seul fichier partagé ont été mesurés avec iOR version 3.3.0, avec l’aide d’OpenMPI v4.0.1 pour exécuter l’analyse comparative sur les 16 nœuds de calcul. Les tests exécutés varient d’un thread à 512 threads (car il n’y avait pas suffisamment de cœurs pour 1 024 threads), et les résultats sont comparés à la solution sans l’extension de la capacité.
Les effets de mise en cache ont été minimisés en définissant le pool de pages GPFS réglable sur 16 Gio et en utilisant des fichiers plus volumineux deux fois plus volumineux. Ces tests d’évaluation utilisaient 8 blocs MiB pour des performances optimales. La section test de performances précédente fournit une explication plus complète de ces points.

Les commandes suivantes ont été utilisées pour exécuter le benchmark pour les écritures et les lectures, où Threads était la variable avec le nombre de threads utilisés (1 à 1 024 incrémentés par deux), et my_hosts.$Threads est le fichier correspondant qui a alloué chaque thread sur un nœud différent, en utilisant la permutation circulaire pour les répartir de manière homogène sur les 16 nœuds de calcul.

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/source /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -w -s 1 -t 8m -b 128G 

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/source /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -r -s 1 -t 8m -b 128G

Figure 3 : N à 1 Performances séquentielles

Les résultats nous permettent de constater à nouveau que les disques supplémentaires bénéficient des performances de lecture et d’écriture. Les performances augmentent à nouveau très rapidement avec le nombre de clients utilisés, puis atteignent un plateau relativement stable pour les lectures et écritures jusqu’au nombre maximal de threads utilisés lors de ce test. Notez que les performances de lecture maximales étaient de 24,8 Go/s à 16 threads et que le goulot d’étranglement était l’interface InfiniBand EDR, avec les baies ME4 qui avaient encore des performances supplémentaires disponibles. À partir de là, les performances de lecture ont diminué à partir de cette valeur jusqu’à atteindre le plateau à environ 23,8 Go/s. De même, notez que les performances d’écriture maximales de 19,3 ont été atteintes à 8 threads et atteignent un plateau.
 

---

Blocs de petite taille aléatoires Clients IOzone Performance N vers N

Les performances des clients N aléatoires vers les fichiers N ont été mesurées avec fio version 3.7 au lieu de la zone Iozone traditionnelle. L’intention, comme indiqué dans le blog précédent, était de tirer parti d’une plus grande profondeur de file d’attente pour examiner les performances maximales possibles que les baies ME4084 peuvent fournir (les tests précédents pour différentes solutions ME4 ont montré que les baies ME4084 ont besoin d’une pression d’E/S supérieure que la zone Iozone peut fournir pour atteindre leurs limites d’E/S aléatoires).

Les tests exécutés allaient d’un seul thread à 512 threads, car il n’y avait pas suffisamment de cœurs client pour 1 024 threads. Chaque thread utilisait un fichier différent et les threads étaient attribués à la permutation circulaire sur les nœuds du client. Ces tests d’évaluation utilisaient des blocs de 4 Ko pour émuler le trafic de blocs de petite taille et utiliser une profondeur de file d’attente de 16. Les résultats de la solution de grande taille et de l’extension de la capacité sont comparés.

Les effets de mise en cache ont de nouveau été minimisés en définissant le pool de pages GPFS réglable sur 16 Gio et en utilisant des fichiers deux fois plus volumineux. La première section de test de performances fournit une explication plus complète de la raison pour laquelle elle est efficace sur GPFS.

 
Figure 4 :  Performances

aléatoires de N à N Les résultats nous permettent de constater que les performances d’écriture commencent à une valeur élevée de 29,1 000 E/S par seconde et augmentent régulièrement jusqu’à 64 threads, alors qu’elles semblent atteindre un plateau d’environ 40 000 E/S par seconde. En revanche, les performances de lecture commencent à 1,4 K E/S par seconde et augmentent les performances presque de manière linéaire avec le nombre de clients utilisés (gardez à l’esprit que le nombre de threads est doublé pour chaque point de données) et atteignent les performances maximales de 25,6 K IOPS à 64 threads, là où semble être proche d’un plateau. L’utilisation de plus de threads nécessitera plus de 16 nœuds de calcul pour éviter une pénurie de ressources et des performances apparentes inférieures, où les baies pourraient en fait maintenir les performances.

 

---

Performances des métadonnées avec MDtest à l’aide de fichiers vides

Les performances des métadonnées ont été mesurées avec MDtest version 3.3.0, avec l’aide d’OpenMPI v4.0.1 pour exécuter l’analyse comparative sur les 16 nœuds de calcul. Les tests exécutés varient d’un seul thread à 512 threads. L’analyse comparative a été utilisée pour les fichiers uniquement (aucune métadonnée de répertoire), en obtenant le nombre de créations, de statistiques, de lectures et de suppressions que la solution peut gérer, et les résultats ont été comparés à la solution de grande taille.

Pour évaluer correctement la solution par rapport à d’autres solutions de stockage HPC Dell EMC et aux résultats précédents du blog, le module de métadonnées à forte demande en option a été utilisé, mais avec une seule baie ME4024, même si la configuration volumineuse et testée dans ce travail était désignée comme ayant deux ME4024. Ce module de métadonnées à forte demande peut prendre en charge jusqu’à quatre baies ME4024, et il est recommandé d’augmenter le nombre de baies ME4024 à 4, avant d’ajouter un autre module de métadonnées. Des baies ME4024 supplémentaires devraient augmenter les performances de métadonnées de manière linéaire avec chaque baie supplémentaire, sauf peut-être pour les opérations de statistiques (et les lectures pour les fichiers vides), étant donné que les nombres sont très élevés, à un moment donné, les processeurs deviendront un goulot d’étranglement et les performances ne continueront pas d’augmenter de manière linéaire.

La commande suivante a été utilisée pour exécuter le benchmark, où Threads était la variable avec le nombre de threads utilisés (1 à 512 incrémentés par deux), et my_hosts.$Threads est le fichier correspondant qui allouait chaque thread sur un nœud différent, à l’aide d’une permutation circulaire pour les répartir de manière homogène sur les 16 nœuds de calcul. À l’instar du benchmark d’E/S aléatoires, le nombre maximal de threads a été limité à 512, car il n’y a pas suffisamment de cœurs pour 1 024 threads et la commutation de contexte affecterait les résultats, en signalant un nombre inférieur aux performances réelles de la solution.

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --prefix /mmfs1/perftest/machine --mca btl_openib_allow_ib 1 /mmfs1/perftest/lanl_ior/bin/mdtest -v -d /mmfs1/perftest/ -i 1 -b $Directories -z 1 -L -I 1024 -y -u -t -F

Étant donné que les résultats des performances peuvent être affectés par le nombre total d’E/S par seconde, le nombre de fichiers par répertoire et le nombre de threads, il a été décidé de maintenir fixe le nombre total de fichiers à 2 Fichiers MIO (2^21 = 2097152), le nombre de fichiers par répertoire fixe à 1 024 et le nombre de répertoires a changé en fonction du nombre de threads, comme indiqué dans le Tableau 3.

Tableau 3 :  Distribution MDtest des fichiers sur les répertoires

Nombre de threads	Nombre de répertoires par thread	Nombre total de fichiers
1	2048	2,097,152
2	1024	2,097,152
4	512	2,097,152
8	256	2,097,152
16	128	2,097,152
32	64	2,097,152
64	32	2,097,152
128	16	2,097,152
256	8	2,097,152
512	4	2,097,152
1024	2	2,097,152

Figure 5 : Performances des métadonnées : fichiers

videsTout d’abord, notez que l’échelle choisie était logarithmique avec la base 10, pour permettre de comparer les opérations qui ont des différences d’ordre de grandeur multiples. Sinon, certaines opérations ressembleraient à une ligne plate proche de 0 sur un graphique normal. Un graphique de log avec la base 2 peut être plus approprié, car le nombre de threads est multiplié par 2, mais le graphique semble très similaire et les utilisateurs ont tendance à gérer et à mémoriser de meilleurs chiffres en fonction des puissances de 10.
Le système obtient de très bons résultats avec des opérations de statistiques et de lecture atteignant leur valeur maximale à 64 threads avec près de 11 millions d’opérations et 4,7 millions d’opérations respectivement. Les opérations de suppression ont atteint le maximum de 170 600 op/s à 16 threads et les opérations de création ont atteint leur maximum de 32 threads avec 222 100 op/s. Les opérations de statistiques et de lecture ont plus de variabilité, mais une fois qu’elles atteignent leur valeur maximale, les performances ne sont pas inférieures à 3 millions d’opérations pour les statistiques et 2 millions d’opérations pour les lectures. La création et la suppression sont plus stables une fois qu’elles atteignent un plateau et restent supérieures à 140 000 opérations pour la suppression et 120 000 pour la création. Notez que les disques supplémentaires n’affectent pas la plupart des opérations de métadonnées sur les fichiers vides comme prévu.
 

---

Performances des métadonnées avec MDtest à l’aide de fichiers de 4 Ko

Ce test est presque identique à celui du précédent, sauf qu’au lieu de fichiers vides, de petits fichiers de 4 Ko ont été utilisés. 
La commande suivante a été utilisée pour exécuter le benchmark, où Threads était la variable avec le nombre de threads utilisés (1 à 512 incrémentés par deux), et my_hosts.$Threads est le fichier correspondant qui allouait chaque thread sur un nœud différent, à l’aide d’une permutation circulaire pour les répartir de manière homogène sur les 16 nœuds de calcul.

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --prefix /mmfs1/perftest/machine --mca btl_openib_allow_ib 1 /mmfs1/perftest /lanl_ior/bin/mdtest -v -d /mmfs1/perftest/ -i 1 -b $Directories -z 1 -L -I 1024 -y -u -t -F -w 4K -e 4K

Figure 6 :  Performances des métadonnées - Fichiers de petite taille (4K)

Le système obtient de très bons résultats pour les opérations de statistiques et de suppression qui atteignent leur valeur maximale à 256 threads avec respectivement 8,2 millions d’opérations et 400 000 opérations. Les opérations de lecture ont atteint le maximum de 44 800 opérations et les opérations de création ont atteint leur maximum avec 68,1 Kops, tous deux à 512 threads. Les opérations de statistiques et de suppression ont plus de variabilité, mais une fois qu’elles atteignent leur valeur maximale, les performances ne sont pas inférieures à 3 millions d’opérations pour les statistiques et 280 000 op/s pour la suppression. La création et la lecture ont moins de variabilité et continuent d’augmenter à mesure que le nombre de threads augmente. Comme on peut le constater, les disques supplémentaires des extensions de capacité ne fournissent que des modifications marginales dans les performances des métadonnées.
Ces chiffres étant destinés à un module de métadonnées avec un seul ME4024, les performances augmenteront pour chaque baie ME4024 supplémentaire, mais nous ne pouvons pas simplement supposer une augmentation linéaire pour chaque opération. À moins que le fichier entier ne s’insère dans l’inode de ce fichier, les cibles de données sur les me4084s seront utilisées pour stocker les fichiers 4K, ce qui limite les performances à un certain degré. Étant donné que la taille de l’inode est de 4 Ko et qu’il doit toujours stocker des métadonnées, seuls les fichiers d’environ 3 KiB s’intègrent à l’intérieur et tout fichier plus grand que celui qui utilise des cibles de données.
 

---

Conclusions et travaux futurs

La solution avec une capacité étendue a été en mesure d’améliorer les performances, non seulement pour les accès aléatoires, mais aussi pour les performances séquentielles. Cela était normal, car le mode en nuages de points se comporte comme des accès aléatoires et le fait d’avoir plus de disques permet l’amélioration. Ces performances, qui peuvent être présentées dans le Tableau 4, devraient être stables à partir d’un système de fichiers vide jusqu’à ce qu’ils soient presque pleins. En outre, la solution évolue de manière linéaire en termes de capacité et de performances à mesure que davantage de modules de nœuds de stockage sont ajoutés, et une augmentation des performances similaire peut être attendue à partir du module de métadonnées à forte demande en option. Cette solution fournit aux clients HPC un système de fichiers parallèle très fiable utilisé par de nombreux clusters HPC des 500 principaux. En outre, il offre des fonctionnalités de recherche exceptionnelles, une surveillance et une gestion avancées, et l’ajout de passerelles facultatives permet le partage de fichiers via des protocoles standard omniprésents tels que NFS, SMB et d’autres, à autant de clients que nécessaire.

Tableau 4  Performances optimales et durables

	Performances optimales		Performances durables
	Écrire	Read	Écrire	Read
Grands clients Séquentiels N vers N fichiers	20,4 Go/s	24,2 Go/s	20,3 Go/s	24 Go/s
Clients Séquentiels N volumineux vers un seul fichier partagé	19,3 Go/s	24,8 Go/s	19,3 Go/s	23,8 Go/s
Blocs de petite taille aléatoires des clients N vers les fichiers N	40KIOps	25.6KiOps	40.0KIOps	19.3KiOps
Métadonnées Créer des fichiers vides	169 400 E/S par seconde		123 500 E/S par seconde
Fichiers vides des statistiques de métadonnées	11 millions d’E/S par seconde		3,2 millions d’E/S par seconde
Métadonnées Lire les fichiers vides	4,7 millions d’E/S par seconde		2,4 millions d’E/S par seconde
Métadonnées Supprimer les fichiers vides	170 600 E/S par seconde		156 500 E/S par seconde
Métadonnées Création de fichiers 4KiB	68 100 E/S par seconde		68 100 E/S par seconde
Métadonnées Statistiques Fichiers 4KiB	8,2 millions d’E/S par seconde		3 millions d’E/S par seconde
Fichiers 4KiB de lecture de métadonnées	44 800 E/S par seconde		44 800 E/S par seconde
Métadonnées Suppression de fichiers 4KiB	400 000 E/S par seconde		280 000 E/S par seconde

Étant donné que la solution est destinée à être commercialisée avec des processeurs Cascade Lake et une RAM plus rapide, une fois que le système a la configuration finale, certaines vérifications des points de performances seront effectuées. Testez également le module de métadonnées à forte demande en option avec au moins 2 fichiers ME4024s et 4KiB pour mieux documenter la façon dont les performances des métadonnées évoluent lorsque des cibles de données sont impliquées. En outre, les performances des nœuds de passerelle seront mesurées et signalées, ainsi que les résultats pertinents des vérifications ponctuelles dans un nouveau blog ou un livre blanc. Enfin, d’autres composants de la solution doivent être testés et publiés pour offrir encore plus de fonctionnalités.