Solutions Dell EMC Ready pour le stockage HPC BeeGFS haute capacité

Cet article a été écrit par Nirmala Sundararajan, HPC et AI Innovation Lab, avril 2020

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 surveillance
   • Service de métadonnées
   • Service de gestion
   • Service de stockage
   • Service client
5. Évaluation des performances
   • Lectures et écritures séquentielles N-N
   • Lectures et écritures aléatoires N-N
   • Paramètres de réglage utilisés
6. Conclusion et œuvre future

Introduction

La solution Dell EMC Ready solutions for HPC BeeGFS High Capacity Storage est une solution de stockage de système de fichiers parallèle à haut débit entièrement prise en charge. Ce blog présente l’architecture de la solution, la manière dont elle est optimisée pour HPC les performances et présente les performances d’e/s en utilisant les benchmarks IOZone séquentielles et aléatoires. Une solution de stockage hautes performances BeeGFS reposant sur des périphériques NVMe a été décrite dans ce blog publié au cours du 2019 Nov. Cette architecture a mis l’accent sur les performances et la solution décrite ici est une solution de stockage haute capacité.  Ces deux solutions pour BeeGFS sont différentes en termes de objectifs de conception et d’exemples d’utilisation.  La solution hautes performances est conçue comme une solution de stockage de travail, une mise à la terre temporaire pour les datasets transitoires qui ne sont généralement pas conservées au-delà de la durée de vie de la tâche. La solution High Capacity utilise 4 Dell EMC PowerVault baies ME4084 entièrement remplies avec un total de disques de 336 et fournit une capacité brute de 4 po s’il est équipé de disques de SAS de 12 to. 

Retour au début

Architecture de référence de la solution

La solution Dell EMC Ready pour HPC BeeGFS stockage haute capacité est constituée d’un serveur de gestion, d’une paire de serveurs de métadonnées, d’une paire de serveurs de stockage et de baies de stockage associées. La solution fournit une solution de stockage qui utilise un seul espace de nommage, facilement accessible par les nœuds de calcul du cluster. La figure suivante illustre l’architecture de référence de la solution avec les composants principaux suivants :

• Management Server
• Paire de serveurs de métadonnées avec PowerVault ME4024 en tant que stockage back-end
• Paire de serveurs de stockage avec PowerVault ME4084 en tant que stockage back-end

La figure 1 présente l’architecture de référence de la solution.

Figure 1 : Solution Dell EMC Ready pour le stockage

HPC BeeGFS Dans la figure 1, le serveur de gestion exécutant le processus de surveillance BeeGFS est un PowerEdge R640.   Les deux serveurs de métadonnées (MDS) sont PowerEdge serveurs R740 dans une configuration haute disponibilité active-active.  La paire MDS est connectée à la baie 2U PowerVault ME4024 par des liaisons SAS 12 Gbit/s. La baie de stockage ME4024 héberge les cibles de métadonnées (MDTs). Une autre paire de PowerEdge serveurs R740, également dans une configuration haute disponibilité active-active, sont utilisées en tant que serveurs de stockage (SS).  Cette paire SS est connectée à quatre matrices de stockage comME4084nt entièrement remplies PowerVault à l’aide de liaisons SAS 12 Gbit/s. Les baies ME4084 prennent en charge un choix de 4 to, 8 to, 10 to ou 12 to NL SAS 7,2 K RPM lecteurs de disque dur (HDD et hébergent les cibles de stockage (STs) pour le système de fichiers BeeGFS. Cette solution utilise Mellanox InfiniBand HDR100 pour le réseau de données. Les clients et les serveurs sont connectés à l’QM8790 de commutateurs à l’aide du commutateur de bord 1 u Mellanox Quantum, qui prend en charge jusqu’à 80 ports de HDR100 à l’aide de câbles de séparateur HDR.

Retour au début

Configuration matérielle et logicielle

Les tableaux suivants décrivent le matériel Speficiations et les versions logicielles validés pour la solution.

Tableau 1 : Configuration de la plate-forme d’essai

Remarque : Dans le cadre de la caractérisation des performances, BeeGFS version 7,2 bêta2 a été utilisée.

Retour au début

Détails de la configuration de la solution

L' architecture BeeGFS se compose de quatre services principaux :

1. Service de gestion
2. Service de métadonnées
3. Service de stockage
4. Service client

Il existe également un service de surveillance BeeGFS en option.

À l’exception du service client qui est un module de noyau, les services de gestion, de métadonnées et de stockage sont des processus d’espace utilisateur. Il est possible d’exécuter n’importe quelle combinaison de services BeeGFS (client et composants serveur) sur les mêmes machines. Il est également possible d’exécuter plusieurs instances de n’importe quel service BeeGFS sur la même machine. Dans la Dell EMC configuration haute capacité de BeeGFS, le service de surveillance s’exécute sur le serveur de gestion, plusieurs instances du service de métadonnées sont exécutées sur les serveurs de métadonnées et une seule instance de service de stockage s’exécute sur les serveurs de stockage. Le service de gestion est installé sur les serveurs de métadonnées.  

Service de surveillance

Le service de surveillance BeeGFS (BeeGFS-môn. service) collecte les statistiques BeeGFS et les fournit à l’utilisateur à l’aide de l' InfluxDBde la base de données Time Series.   Pour la visualisation des données, beegfs-môn-grafana fournit des tableaux de bord grafana prédéfinis qui peuvent être utilisés en dehors de la boîte. La figure 2 fournit une présentation générale du cluster BeeGFS indiquant le nombre de services de stockage et de services de métadonnées dans le programme d’installation (appelés nœuds dans le tableau de bord). Elle répertorie également les autres vues du tableau de bord disponibles et offre une vue d’ensemble des cibles de stockage.

Figure 2 tableau de bord Grafana-présentation de BeeGFS

Retour au début

Service de métadonnées

La baie de stockage ME4024 utilisée pour le stockage des métadonnées est entièrement remplie avec des disques SSD 960 Go 24x. Ces disques sont configurés dans des groupes de disques de 1 à 12 disques durs linéaires, chacun de ces deux lecteurs, comme illustré à la figure 3. Chaque groupe RAID1 est une cible de métadonnées.

Figure 3 baie ME4024 entièrement remplie avec 12 MDTs

Dans uniBeeGFS, chaque service de métadonnées traite uniquement un seul MDT. Étant donné qu’il existe 12 MDTs, il doit y avoir 12 instances du service de métadonnées. Chacun des deux serveurs de métadonnées exécute six instances du service de métadonnées. Les cibles de métadonnées sont mises en forme avec un système de fichiers ext4 (les systèmes de fichiers ext4 fonctionnent bien avec des fichiers de petite taille et des petits fichiers). En outre, BeeGFS stocke les informations dans les attributs étendus et directement sur les inodes du système de fichiers afin d’optimiser les performances, qui fonctionnent bien avec le système de fichiers ext4.

Retour au début

Service de gestion

Le service beegfs-mgmtd est configuré sur les deux serveurs de métadonnées. La zone de stockage Mgmt beegfs est initialisée dans le répertoire Mgmt sur la cible de métadonnées 1, comme indiqué ci-dessous :

/opt/beegfs/sbin/beegfs-Setup-mgmtd-p/beegfs/metaA-numa0-1/mgmtd-S beegfs-Mgmt

Le service de gestion est démarré sur le serveur méta.
 

Retour au début

Service de stockage

Dans cette solution BeeGFS haute capacité, le stockage des données est réparti sur quatre baies de stockage PowerVault ME4084. Des groupes de disques RAID-6 linéaires de 10 disques (8 + 2) chacun sont créés sur chaque baie. Un seul volume utilisant l’ensemble de l’espace est créé pour chaque groupe de disques. Cela donnera lieu à 8 groupes de disques/volumes par baie. Chaque baie dispose de 84 lecteurs et la création de groupes de disques RAID-6 de 8 x laisse 4 disques qui peuvent être configurés en tant que disques de secours globaux sur l’ensemble des volumes de la baie.

Avec la mise en page décrite ci-dessus, il existe un total de volumes de 32 x RAID-6 sur 4 x ME4084 dans une configuration de base illustrée à la figure 1. Chacun de ces volumes RAID-6 est configuré en tant que cible de stockage (ST) pour le système de fichiers BeeGFS, ce qui se traduit par un total de 32 STs sur l’ensemble du système de fichiers.

Chaque baie ME4084 dispose de 84 disques, avec des lecteurs numérotés 0-41 dans le tiroir supérieur et ceux numérotés de 42-84 dans le tiroir inférieur.  Dans la figure 5, chaque ensemble de 10 disques marqués entre 1 et 8 représente le groupe 8xRAID6. Un volume est créé à partir de chaque groupe RAID6. Les disques marqués « S » représentent les disques de secours globaux. La figure 5 illustre la vue avant de la baie après la configuration de 8 volumes et 4 disques de secours globaux.

Figure 4 Configuration du groupe de disques RAID 6 (8 + 2) sur un seul ME4084 

Retour au début

Service client

Le module client BeeGFS est chargé sur tous les hôtes qui ont besoin d’accéder au système de fichiers BeeGFS. Lorsque le module BeeGFS est chargé et que le service BeeGFS-client est démarré, le service monte les systèmes de fichiers définis dans le fichier/etc/BeeGFS/beegfs-Mounts. conf au lieu de l’approche habituelle basée sur /etc/fstab.  Avec cette approche, beegfs-client démarre comme n’importe quel autre service Linux via le script de démarrage du service et active la recompilation automatique du module client beegfs après les mises à jour du système.

Retour au début

Évaluation des performances

Cette section présente les caractéristiques de performances de l’Dell EMC solutions prêtes pour HPC solution de stockage BeeGFS haute capacité à l’aide des benchmarks IOzone séquentiels et aléatoires.  Pour plus d’informations sur les performances à l’aide de IOR et MDtest, ainsi que des détails relatifs à la configuration de la haute disponibilité, consultez le livre blanc qui sera publié plus tard.

Les performances de stockage ont été évaluées à l’aide de IOzone benchmark (v 3.487). Le débit séquentiel de lecture et d’écriture, ainsi que les IOPS de lecture et d’écriture aléatoires ont été mesurés. Le tableau 2 décrit la configuration des serveurs PowerEdge R840 utilisés en tant que clients BeeGFS pour ces études de performances.

Tableau 2 configuration client

Les serveurs et les clients sont connectés via un réseau HDR100 et les détails du réseau indiqués dans le tableau 3 ci-dessous :  

Tableau 3 : Gestion réseau
 

Lectures et écritures séquentielles N-N

Les lectures et écritures séquentielles ont été mesurées à l’aide du mode de lecture et d’écriture séquentielles de IOzone. Ces tests ont été réalisés sur plusieurs threads à partir de 1, avec augmentation de 2 en 2 jusqu’à 64 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 (cas N-N). Les processus ont été répartis sur 8 nœuds de client physique par permutation circulaire, de sorte que les demandes ont été distribuées de façon égale avec l’équilibrage de charge.

Pour le nombre de threads de 16 et ultérieures, une taille de fichier d’agrégation de 8 to a été choisie pour réduire les effets de la mise en cache à partir des serveurs et des clients BeeGFS. Pour le nombre de threads inférieur à 16, la taille du fichier est de 768 Go par thread (c’est-à-dire 1,5 to pour 2 threads, 3 to pour 4 threads et 6 to pour 8 threads). Dans le cas d’un test donné, la taille de fichier agrégée utilisée a été divisée de manière égale entre le nombre de threads. Une taille d’enregistrement de 1MiB a été utilisée pour toutes les exécutions. La commande utilisée pour les tests séquentiels N-N est indiquée ci-dessous :

Opérations d’écriture et de lecture séquentielles : IOzone-i $test-c-e-w-r 1m-s $Size-t $Thread-+ n-+ m/Path/to/threadlist

Les caches du système d’exploitation ont également été abandonnés sur les serveurs entre les itérations, ainsi qu’entre les tests de lecture et d’écriture en exécutant la commande :

# Sync & & ECHO 3 >/proc/sys/VM/drop_caches

Le système de fichiers a été démonté et remonté sur les clients entre les itérations et entre les tests d’écriture et de lecture pour effacer le cache.

Figure 5 : performances de lecture séquentielle d’N-N

Retour au début

Lectures et écritures aléatoires N-N

IOzone a été utilisé en mode aléatoire pour évaluer les performances d’e/s aléatoires.  Les tests ont été effectués sur des nombres de threads de 16 à 512 threads.  L’option direct IO (-I) a été utilisée pour exécuter IOzone, de sorte que toutes les opérations contournent le cache de mémoire tampon et se dirige directement vers le disque. Le nombre de bandes BeeGFS de 1 et la taille de segment de 1 Mo ont été utilisés. La taille de la demande a été définie sur 4KiB. Les performances ont été mesurées en opérations d’e/s par seconde (IOPS). Les caches du système d’exploitation ont été supprimés de l’exécution sur les serveurs BeeGFS. Le système de fichiers a été démonté et remonté sur les clients entre les itérations du test. La commande utilisée pour les tests de lecture et d’écriture aléatoires est la suivante :

IOzone-i 2-w-c-O-I-r 4K-s $Size-t $Thread-+ n-+ m/Path/to/threadlist

Figure 6: n-n performances aléatoires

La figure 6 illustre que les performances d’écriture se déplacent dans 31K IOPS et restent stables des threads 32 vers 512. En revanche, les performances de lecture augmentent en augmentant le nombre de demandes d’e/s avec des performances maximales de 47K IOPS à 512 threads, ce qui correspond au nombre maximal de threads testés pour la solution. ME4 nécessite une profondeur de file d’attente plus élevée pour atteindre les performances de lecture maximales et le graphique indique que nous pouvons obtenir des performances plus élevées si nous exécutons les threads simultanés 1024. Toutefois, à mesure que les tests ont été exécutés avec 8 clients seulement, nous n’avons pas suffisamment de cœurs pour exécuter le nombre de threads 1024.


Retour au début

Paramètres de réglage utilisés

Les paramètres de réglage suivants ont été en place lors de l’exécution de la caractérisation des performances de la solution.

Le nombre de bandes par défaut pour BeeGFS est de 4. Toutefois, la taille des fragments et le nombre de cibles par fichier (nombre de Stipe) peuvent être configurés au niveau de chaque répertoire ou de chaque fichier. Pour tous ces tests, la taille de bande BeeGFS a été définie sur 1Mo et le nombre de bandes a été défini sur 1, comme indiqué ci-dessous :

$beegfs-CTL--getentryinfo--mount =/mnt/beegfs//mnt/beegfs/Benchmark/--verbose
Type d’entrée :
EntryID du répertoire : 1-5E72FAD3-1
ParentId :
nœud de métadonnées racine : metaa-numa0-1 [ID : 1]
informations sur le modèle de bande :
+ type : RAID0
+ ChunkSize : 1m
+ Nombre de cibles de stockage : vous souhaitez : 1
+ Pool de stockage : 1 (par défaut)
chemin de hachage inode : 61/4C/1-5E72FAD3-1

Les pages d’énormes transparence ont été désactivées et les paramètres de mémoire virtuelle suivants sont configurés sur les métadonnées et les serveurs de stockage :

• vm.dirty_background_ratio = 5
• vm.dirty_ratio = 20
• vm.min_free_kbytes = 262144
• vm.vfs_cache_pressure = 50

Les options de réglage suivantes ont été utilisées pour les périphériques en mode bloc de stockage sur les serveurs de stockage.

• Date et heure du planificateur d’e/s : échéance
• Nombre de demandes planifiables : 2048 :
• Quantité maximale de données en lecture anticipée : 4096

Outre les options de réglage BeeGFS spécifiques suivantes utilisées :
 
beegfs-meta. conf

connMaxInternodeNum = 64
tuneNumWorkers = 12
tuneUsePerUserMsgQueues = true # facultatif
tuneTargetChooser = RoundRobin (benchmarking)

beegfs-Storage. conf

connMaxInternodeNum = 64
tuneNumWorkers = 12
tuneUsePerTargetWorkers = true
tuneUsePerUserMsgQueues = true # facultative
tuneBindToNumaZone = 0
tuneFileReadAheadSize = 2m

beegfs-client. conf

connMaxInternodeNum = 24
connBufSize = 720896

Retour au début

Conclusion et œuvre future

Ce blog annonce la publication de Dell EMC solution de stockage BeeGFS haute capacité et met en évidence ses caractéristiques de performances. Cette solution fournit un pic de performances de 23,7 Gbit/s pour les lectures et 22,1 Gbit/s pour les écritures à l’aide des benchmarks séquentiels IOzone. Nous pouvons également voir le pic des écritures aléatoires au niveau de 31.3 K IOPS et des lectures aléatoires sur 47,5 K IOPS.

Dans le cadre des étapes suivantes, nous allons évaluer les performances des métadonnées et N threads sur un seul fichier (N à 1) IOR performances de cette solution. Un livre blanc décrivant les performances des métadonnées et des IOR de la solution avec des détails supplémentaires concernant les considérations relatives à la conception pour cette solution haute capacité, avec une haute disponibilité, devrait être publié une fois le processus de validation et d’évaluation effectué.

Retour au début