Solutions Dell EMC Ready pour le stockage de performance HPC BeeGFS

Article écrit par Nirmala Sundararajan, membre du laboratoire d’innovation en matière d’IA et HPC de Dell EMC, en novembre 2019

Solutions Dell EMC Ready pour le stockage de performance HPC BeeGFS

Sommaire

1. Introduction
2. Architecture de référence de la solution
3. Configuration matérielle et logicielle
4. Détails de la configuration de la solution
   • Service de gestion
   • Service de métadonnées
   • Service de stockage
   • Service client
5. R740xd, 24 disques NVMe, détails sur le mappage du processeur
6. Caractérisation des performances
   • Lectures et écritures séquentielles N-N
   • Lectures et écritures aléatoires N-N
7. Conclusion et travaux futurs
    

Introduction

Architecture de référence de la solution

Configuration matérielle et logicielle

Les tableaux 1 et 2 décrivent respectivement les spécifications matérielles du serveur de gestion et du serveur de métadonnées/de stockage. Le tableau 3 indique les versions logicielles utilisées pour la solution.

Détails de la configuration de la solution

• Service de gestion
• Service de métadonnées
• Service de stockage
• Service client

Service de gestion

Service de métadonnées

Figure 3 :  Serveur de métadonnées

La figure 4 illustre la configuration RAID du serveur de métadonnées. Elle met en évidence la façon dont, dans le serveur de métadonnées, les disques de la zone NUMA 0 hébergent les MDT et ceux de la zone NUMA 1 hébergent les données de stockage, tandis que les serveurs de stockage hébergent les ST dans les deux zones NUMA.

Service de stockage

1. Les performances d’écriture ont été mesurées à l’aide de la commande dd en créant un fichier de 10 Gio de taille de bloc de 1 Mio et des E/S directes pour les données. Pour les appareils RAID 0, la moyenne était d’environ 5,1 Go/s pour chaque appareil, tandis que pour les appareils RAID 10, la moyenne était de 3,4 Go/s pour chaque appareil.
2. Les tests de performances StorageBench ont montré que le débit maximal était de 5,5 Go/s pour la configuration RAID 0, alors qu’il est de 3,4 Go/s pour une configuration RAID 10. Ces résultats sont semblables à ce qui a été obtenu à l’aide des commandes dd.
3. RAID 10 fournit une utilisation de 50 % de la capacité du disque et une réduction de 50 % des performances d’écriture. L’utilisation de RAID 10 est un moyen coûteux d’obtenir une redondance de stockage.
4. Les disques NVMe coûtent cher et offrent des vitesses optimales dans une configuration RAID 0.

Service client

$ cat /etc/beegfs/beegfs-mounts.conf
/mnt/beegfs-medium /etc/beegfs/beegfs-client-medium.conf
/mnt/beegfs-small /etc/beegfs/beegfs-client-small.conf

R740xd, 24 disques NVMe, détails sur le mappage du processeur

# cat /proc/sys/kernel/numa_balancing
0

Caractérisation des performances

Lectures et écritures séquentielles N-N

Pour évaluer les lectures et écritures séquentielles, le test de performances IOzone a été utilisé en mode de lecture écriture séquentiel. Ces tests ont été réalisés sur plusieurs threads à partir de 1, avec augmentation de 2 en 2 jusqu’à 1 024 threads. Pour chaque nombre de threads, un nombre égal de fichiers a été généré, car ce test fonctionne avec un fichier par thread ou avec N clients pour N fichiers (cas N-N). Les processus ont été distribués sur 32 nœuds client physiques de manière circulaire ou cyclique afin que les demandes soient réparties de manière égale et qu’il y ait un équilibrage de charge. La taille de fichier agrégée de 8 To a été sélectionnée, divisée de façon égale entre le nombre de threads au cours d’un test donné. La taille de fichier agrégé a été choisie suffisamment grande pour minimiser les effets de la mise en cache à partir des serveurs ainsi que des clients BeeGFS. IOzone a été exécuté en mode d’écriture puis de lecture (-i 0, -i 1) pour lui permettre de coordonner les limites entre les opérations. Pour ces tests et résultats, nous avons utilisé la taille d’enregistrement de 1 Mio pour chaque exécution. Les commandes utilisées pour les tests séquentiels N-N sont indiquées ci-dessous :

Écritures et lectures séquentielles : iozone -i 0 -i 1 -c -e -w -r 1m -I -s $Size -t $Thread -+n -+m /path/to/threadlist

Les caches du système d’exploitation ont également été supprimés ou nettoyés sur les nœuds client entre les itérations, ainsi qu’entre les tests d’écriture et de lecture en exécutant la commande ci-dessous :

# sync & echo 3 > /proc/sys/vm/drop_caches

Pour Beegfs, le nombre de bandes par défaut est 4. Toutefois, la taille des fragments et le nombre de cibles par fichier peuvent être configurés par répertoire. Pour tous ces tests, la taille de bande BeeGFS de 2 Mo et le nombre de bandes de 3 ont été choisis, car nous avons trois cibles par zone NUMA, comme indiqué ci-dessous :

$ beegfs-ctl --getentryinfo --mount=/mnt/beegfs /mnt/beegfs/benchmark --verbose
EntryID: 0-5D9BA1BC-1
ParentID: root
Metadata node: node001-numa0-4 [ID: 4]
Stripe pattern details:
+ Type: RAID0
+ Chunksize: 2M
+ Number of storage targets: desired: 3
+ Storage Pool: 1 (Default)
Inode hash path: 7/5E/0-5D9BA1BC-1

Les pages volumineuses transparentes ont été désactivées et les options de réglage suivantes ont été définies sur les serveurs de métadonnées et de stockage :

• vm.dirty_background_ratio = 5 
• vm.dirty_ratio = 20 
• vm.min_free_kbytes = 262144 
• vm.vfs_cache_pressure = 50
• vm.zone_reclaim_mode = 2 
• kernel.numa_balancing = 0

En plus des éléments ci-dessus, les options de réglage BeeGFS suivantes ont été utilisées : 

• Le paramètre tuneTargetChooser a été défini sur « roundrobin » dans le fichier de configuration des métadonnées. 
• Le paramètre tuneNumWorkers a été défini sur 24 pour les métadonnées et 32 pour le stockage. 
• Le paramètre connMaxInternodeNum a été défini sur 32 pour les métadonnées, 12 pour le stockage et 24 pour les clients.

Sur la figure 9, nous constatons que les performances de lecture optimales sont de 132 Go/s à 1 024 threads et que le pic d’écriture est de 121 Go/s à 256 threads. Chaque disque peut fournir des performances optimales de lecture de 3,2 Go/s et des performances d’écriture optimales de 1,3 Go/s, ce qui permet un pic théorique de 422 Go/s pour les lectures et de 172 Go/s pour les écritures. Toutefois, ici, le réseau est le facteur limitant. Dans cette configuration, nous disposons d’un total de 11 liaisons EDR InfiniBand pour les serveurs de stockage. Chaque liaison peut fournir des performances optimales théoriques de 12,4 Go/s, ce qui permet des performances optimales théoriques de 136,4 Go/s. Les performances optimales obtenues en lecture et en écriture sont respectivement de 97 % et 89 % des performances optimales théoriques.

Les performances d’écriture d’un thread unique sont d’environ 3 Go/s et les performances de lecture d’environ 3 Go/s. Nous observons que les performances d’écriture évoluent de manière linéaire, ont un pic à 256 threads, puis commencent à diminuer. À un nombre de threads inférieur, les performances de lecture et d’écriture sont les mêmes, car jusqu’à 8 threads, 8 clients écrivent 8 fichiers sur 24 cibles, ce qui signifie que toutes les cibles de stockage ne sont pas entièrement utilisées. Nous disposons de 33 cibles de stockage dans le système. Il faudrait donc au moins 11 threads pour utiliser pleinement tous les serveurs. Les performances de lecture enregistrent une augmentation linéaire constante avec l’augmentation du nombre de threads simultanés et nous observons des performances presque similaires à 512 et à 1 024 threads.

Nous observons également que les performances de lecture sont inférieures aux écritures pour les nombres de threads de 16 à 128, puis que les performances de lecture commencent à évoluer. En effet, alors qu’une lecture PCIe est une opération « Non-Posted », nécessitant à la fois une demande et une exécution, une écriture PCIe est une opération « fire and forget ». Une fois que le paquet de couche de transaction (TLP) est transféré à la couche de liaison de données, l’opération se termine. Une écriture est une opération « Posted » qui se compose d’une seule demande.

Le débit de lecture est généralement inférieur au débit d’écriture, car les lectures nécessitent deux transactions au lieu d’une seule écriture pour la même quantité de données. PCI Express utilise un modèle de transaction fractionné pour les lectures. La transaction de lecture inclut les étapes suivantes :

• Le demandeur envoie une demande de lecture de mémoire (MRR).
• L’exécuteur envoie l’accusé de réception de la MRR.
• L’exécuteur renvoie une exécution avec des données.

Le débit de lecture dépend du délai entre l’émission de la demande de lecture et le temps nécessaire à l’exécuteur pour renvoyer les données. Toutefois, lorsque l’application émet un nombre suffisant de demandes de lecture pour couvrir ce délai, le débit est optimisé. C’est la raison pour laquelle, même si les performances de lecture sont inférieures aux performances d’écritures de 16 threads à 128 threads, nous observons une augmentation du débit lorsque le nombre de demandes augmente.  Un débit inférieur est mesuré lorsque le demandeur attend la fin de l’exécution avant d’émettre les demandes suivantes. Un débit supérieur est enregistré lorsque plusieurs demandes sont émises pour amortir le délai après le retour des premières données.

Lectures et écritures aléatoires N-N

Pour évaluer les performances d’E/S aléatoires, IOzone a été utilisé en mode aléatoire. Les tests ont été effectués sur un nombre de threads allant de 4 à 1 024 threads. L’option Direct IO (-I) a été utilisée pour exécuter IOzone afin que toutes les opérations contournent le cache de la mémoire tampon et accèdent directement au disque. Le nombre de bandes BeeGFS de 3 et la taille de fragment de 2 Mo ont été utilisés. La taille de demande de 4 Kio est utilisée sur IOzone. Les performances ont été mesurées en opérations d’E/S par seconde (IOPS). Les caches du système d’exploitation ont été abandonnés entre les exécutions sur les serveurs BeeGFS et les clients BeeGFS. La commande utilisée pour exécuter les écritures et lectures aléatoires est indiquée ci-dessous :

Lectures et écritures aléatoires : iozone -i 2 -w -c -O -I -r 4K -s $Size -t $Thread -+n -+m /path/to/threadlist

Figure 10 :  Performances de lecture et d’écriture aléatoires à l’aide d’IOzone avec une taille de fichier agrégé de 8 To

Les écritures aléatoires atteignent un pic d’environ 3,6 millions d’E/S par seconde à 512 threads et les lectures aléatoires atteignent un pic d’environ 3,5 millions d’E/S par seconde à 1 024 threads, comme illustré sur la figure 10. Les performances d’écriture et de lecture affichent de meilleures performances lorsqu’il y a un plus grand nombre de demandes d’E/S. Cela est dû au fait que la norme NVMe prend en charge jusqu’à 64 000 files d’attente d’E/S et jusqu’à 64 000 commandes par file d’attente. Ce vaste pool de files d’attente NVMe offre des niveaux plus élevés de parallélisme des E/S. Par conséquent, les E/S par seconde sont supérieures à 3 millions.

Conclusion et travaux futurs

Ce blog annonce la sortie de la solution Dell EMC pour le stockage hautes performances BeeGFS et met en évidence ses caractéristiques de performances. La solution offre des performances de lecture et d’écriture séquentielles optimales d’environ 132 Go/s et d’environ 121 Go/s respectivement, et les écritures aléatoires atteignent environ 3,6 millions d’E/S par seconde et les lectures aléatoires environ 3,5 millions d’E/S par seconde.

Ce blog est la première partie de « Solution de stockage BeeGFS », qui a été conçue pour se concentrer sur l’espace de travail hautes performances. Soyez attentifs à la deuxième partie de cette série de blog qui décrira comment la solution peut évoluer en incrémentant le nombre de serveurs pour augmenter les performances et la capacité. La troisième partie de cette série de blog abordera les fonctionnalités supplémentaires de BeeGFS et mettra en évidence l’utilisation de « StorageBench », le test de performances des cibles de stockage intégré de BeeGFS.

Dans le cadre des prochaines étapes, nous publierons un livre blanc présentant les performances des métadonnées et les performances IOR (N threads pour 1 fichier), ainsi que des détails supplémentaires sur les considérations de conception, le réglage et la configuration.

Références