PowerEdge : Dell Ready Solutions pour le stockage de performance HPC BeeGFS

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

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

L’équipe HPC de Dell est fière d’annoncer la sortie des « Dell EMC Ready Solutions for HPC BeeGFS Storage », qui vient compléter la gamme de stockage HPC. Cette solution utilise des serveurs R740xd, chacun équipé de 24 disques NVMe Intel P4600 1,6To, de disques Express Flash à usage mixte et de deux adaptateurs Mellanox ConnectX-5 InfiniBand EDR. Dans cette configuration à 24 disques NVMe, 12 disques SSD NVMe se connectent à un commutateur PCIe et chaque commutateur est connecté à un processeur à l’aide d’une carte d’extension PCIe x16. En outre, chaque interface IB est connectée à un processeur. Une telle configuration équilibrée avec chaque processeur connecté à un adaptateur InfiniBand et gérant 12 disques SSD NVMe offre des performances maximales en veillant à ce que les processeurs soient également occupés à gérer les demandes d’E/S vers et depuis les disques NVMe.

La solution se concentre sur les E/S hautes performances et a été conçue comme une solution scratch à grande vitesse. La solution repose sur l’utilisation de disques SSD NVMe haute vitesse qui offrent une bande passante élevée et une faible latence en supprimant le planificateur et en mettant en file d’attente les goulots d’étranglement à partir de la couche de blocs. Le système de fichiers BeeGFS prend également en charge un débit d’E/S agrégé élevé.

Architecture de référence de la solution

La figure 1 montre l’architecture de référence de la solution. Le serveur de gestion est uniquement connecté en Ethernet aux serveurs de métadonnées et de stockage. Chaque serveur de métadonnées et de stockage dispose de deux liaisons InfiniBand et est connecté au réseau privé via Ethernet. Les clients disposent d’une liaison InfiniBand et sont connectés à l’interface privée via Ethernet.

Graphique 1 :  Dell Ready Solutions for HPC BeeGFS Storage - Architecture de référence

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

L’architecture BeeGFS se compose de quatre services principaux :

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

À l’exception du service client qui est un module noyau, les services de gestion, de métadonnées et de stockage sont des processus d’espace utilisateur. La figure 2 illustre la façon dont l’architecture de référence des solutions Dell EMC Ready pour le stockage HPC BeeGFS est mappée à l’architecture générale du système de fichiers BeeGFS.

Figure 2 :  Système de fichiers BeeGFS sur PowerEdge R740xd avec disques SSD NVMe

Service de gestion

Chaque espace de nommage ou système de fichiers BeeGFS dispose d’un seul service de gestion. Le service de gestion est le premier service qui doit être configuré, car lorsque nous configurons tous les autres services, ils doivent s’enregistrer auprès du service de gestion. Un serveur PowerEdge R640 est utilisé comme serveur de gestion. En plus d’héberger le service de gestion (beegfs-mgmtd.service), il héberge également le service de surveillance (beegfs-mon.service) qui collecte les statistiques à partir du système et les fournit à l’utilisateur, à l’aide de la base de données de séries chronologiques InfluxDB. Pour la visualisation des données, beegfs-mon fournit des volets Grafana prédéfinis et prêts à l’emploi. Le serveur de gestion dispose de 6 disques durs de 300 Go configurés dans RAID 10 pour le système d’exploitation et InfluxDB.

Service de métadonnées

Le service de métadonnées est un service scale-out, ce qui signifie qu’il peut y avoir de nombreux services de métadonnées dans un système de fichiers BeeGFS. Toutefois, chaque service de métadonnées possède exactement une cible de métadonnées pour stocker les métadonnées. Sur la cible de métadonnées, BeeGFS crée un fichier de métadonnées par fichier créé par l’utilisateur. Les métadonnées BeeGFS sont distribuées par répertoire. Le service de métadonnées fournit les informations d’agrégation par bandes de données aux clients et n’est pas impliqué dans l’accès aux données entre l’ouverture et la fermeture du fichier.

Un serveur PowerEdge R740xd avec 24 disques Intel P4600 NVMe de 1,6 To est utilisé pour le stockage des métadonnées. Étant donné que les exigences en matière de capacité de stockage pour les métadonnées BeeGFS sont très faibles, au lieu d’utiliser un serveur de métadonnées dédié, seuls les 12 disques de la zone NUMA 0 ont été utilisés pour héberger les argets Tde métadonnées (MDT), tandis que les 12 disques restants sur les argetsTde stockage (ST) de l’hôte de la zone NUMA sont très faibles.

La Figure 3 illustre le serveur de métadonnées. Les 12 disques visibles dans le rectangle jaune sont les MDT de la zone NUMA 0, tandis que les 12 disques du rectangle vert sont les ST de la zone NUMA 1. Non seulement cette configuration évite les problèmes liés aux zones NUMA, mais elle fournit aussi suffisamment de stockage des métadonnées pour faciliter l’évolution de la capacité et des performances en fonction des besoins.

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.

Figure 4 :  Configuration des disques dans le serveur

de métadonnées Les 12 disques utilisés pour les métadonnées sont configurés en tant que groupe de disques RAID 1 à 6 disques, chacun servant de MDT. Six services de métadonnées sont en cours d’exécution, chacun d’eux gérant une MDT. Les 12 disques de stockage restants sont configurés en 3 groupes de disques RAID 0 de quatre disques chacun. Il existe trois services de stockage en cours d’exécution sur la zone NUMA 1, soit un service pour chaque ST. Ainsi, le serveur qui héberge les métadonnées et les cibles de stockage dispose de 6 MDT et de 3 ST. Il exécute également six services de métadonnées et trois services de stockage. Chaque MDT est un système de fichiers ext4 basé sur une configuration RAID 1. Les ST sont basés sur un système de fichiers XFS configuré en RAID 0.
 

Service de stockage

À l’instar du service de métadonnées, le service de stockage aussi est un service scale-out. Il peut y avoir de nombreuses instances du service de stockage dans un système de fichiers BeeGFS. Toutefois, contrairement au service de métadonnées, il peut y avoir plusieurs cibles de stockage par service de stockage. Le service de stockage stocke le contenu des fichiers utilisateur agrégés par bandes, également appelés fichiers de fragments de données.

La Figure 5 illustre les 5 serveurs PowerEdge R740xd utilisés comme serveurs de stockage.

Graphique 5 :  Serveurs

de stockage dédiés Chaque serveur de stockage est configuré avec 6 groupes RAID 0, chacun comportant quatre disques, hébergeant ainsi 6 ST par serveur (3 par zone NUMA), comme illustré à la Figure 6 ci-dessous :

Figure 6 :  Configuration des disques dans les serveurs

de stockage Au total, la configuration de l’architecture de référence de base héberge 6 MDT et 33 ST. Les cinq serveurs de stockage dédiés fournissent une capacité brute de 211 To et une capacité utile de 190 Tio. Capacité utile estimée en Tio = Nombre de disques x capacité par disque en To x 0,99 (surcharge du système de fichiers) x (10^12/2^40). Il s’agit d’une solution de milieu de gamme avec suffisamment de stockage de métadonnées pour faciliter l’ajout de serveurs de stockage à mesure que les besoins en capacité augmentent.

Compte tenu des facteurs suivants, une configuration RAID 0 a été choisie pour les cibles de stockage par rapport à la configuration RAID 10.

1. Les performances d’écriture ont été mesurées à l’aide de la commande dd en créant un fichier de 10 Go d’une taille de bloc de 1 Mo et des E/S directes pour les données. Pour les périphériques RAID 0, la moyenne était d’environ 5,1 Go/s par périphérique, tandis que pour les périphériques RAID 10, la moyenne était de 3,4 Go/s pour chaque périphérique.
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

Le module client BeeGFS doit être chargé sur tous les hôtes qui doivent accéder au système de fichiers BeeGFS. Lorsque beegfs-client est chargé, il 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. L’adoption de cette approche démarre beegfs-client comme n’importe quel autre service Linux via le script de démarrage de service. Cela permet également la recompilation automatique du module client BeeGFS après les mises à jour du système. 

Une fois le module client chargé, il monte les systèmes de fichiers définis dans beegfs-mounts.conf. Il est possible de monter plusieurs instances beegfs sur le même client, comme indiqué ci-dessous :

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

L’exemple ci-dessus montre deux systèmes de fichiers différents montés sur le même client. Dans le cadre de ce test, 32 nœuds C6420 ont été utilisés en tant que clients.

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

Dans la configuration à 24 disques NVMe du serveur PowerEdge R740xd, il existe deux cartes de passerelle NVMe x16 qui alimentent le commutateur PCIe sur le fond de panier et alimentent les disques (x4) à l’avant, comme illustré sur la figure 7 ci-dessous :


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

Dans l’accès à la mémoire non uniforme (NUMA), la mémoire système est divisée en zones appelées « nœuds », qui sont alloués aux processeurs ou aux sockets. L’accès à la mémoire locale d’un processeur est plus rapide que l’accès à la mémoire connectée à des processeurs distants sur le système. Une application à threads fonctionne généralement mieux lorsque les threads accèdent à la mémoire sur le même nœud NUMA. L’impact sur les performances des échecs NUMA est significatif et commence généralement à se faire sentir à hauteur de 10 % ou plus. Pour améliorer les performances, les services sont configurés de sorte à utiliser des zones NUMA spécifiques afin d’éviter l’utilisation inutile de liaisons inter-sockets UPI, ce qui réduit la latence. Chaque zone NUMA gère 12 disques et utilise l’une des deux interfaces EDR InfiniBand sur les serveurs. Cette séparation NUMA s’obtient en configurant manuellement l’équilibrage NUMA, c’est-à-dire en créant des fichiers d’unité système personnalisés et en configurant l’hébergement multiple. Par conséquent, l’équilibrage NUMA automatique est désactivé, comme indiqué ci-dessous :

# cat /proc/sys/kernel/numa_balancing
0

La figure 8 illustre la plateforme d’essai où les connexions InfiniBand à la zone NUMA sont mises en surbrillance. Chaque serveur dispose de deux liaisons IP, et le trafic via la zone NUMA 0 est transmis par l’interface IB0, tandis que le trafic via la zone NUMA 1 est géré par l’interface IB1.

Graphique 8 :  Configuration de la plate-forme d’essai
 

Caractérisation des performances

Cette section présente l’évaluation des performances qui permet de caractériser la solution Dell EMC Ready pour le stockage hautes performances HPC BeeGFS. Pour plus d’informations et de mises à jour, veuillez consulter un livre blanc qui sera publié ultérieurement. Les performances du système ont été évaluées à l’aide du test de performances IOzone. Le test de la solution porte sur le débit de lecture et d’écriture séquentielles, ainsi que sur les E/S par seconde de lecture et d’écriture aléatoires. Le tableau 4 décrit la configuration des serveurs C6420 qui ont été utilisés en tant que clients BeeGFS pour les études de performances présentées dans ce blog.
 

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é effectués sur plusieurs threads en commençant par un thread et en augmentant les puissances de 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 du fichier agrégé a été choisie suffisamment grande pour minimiser les effets de la mise en cache à partir des serveurs et 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é une taille d’enregistrement de 1 Mo 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 clients entre les itérations et entre les tests d’écriture et de lecture en exécutant la commande suivante :

# 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 2 Mo et le nombre de bandes 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 : 

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

Figure 9 :  Taille du fichier agrégé IOzone séquentiel de 8 To.

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. Nous disposons d’un total de 11 liaisons EDR InfiniBand pour les serveurs de stockage dans la configuration. 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, Parce que jusqu’à huit threads, nous avons huit clients qui é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. Par conséquent, au moins 11 threads sont nécessaires 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 à 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 effectuer 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 avec IOzone avec une taille de fichier agrégée de 8 To.

Le pic d’écritures aléatoires est de ~3,6 millions d’E/S par seconde à 512 threads et le pic de lectures aléatoires à ~3,5 millions d’E/S par seconde à 1 024 threads, comme le montre 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 fournit des niveaux plus élevés de parallélisme d’E/S. Par conséquent, nous observons des E/S par seconde 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 partie 3 de cette série de blogs traite des fonctionnalités supplémentaires de BeeGFS et met en évidence l’utilisation de « StorageBench », le point de référence des cibles de stockage intégré de BeeGFS.

Dans le cadre des étapes suivantes, nous publierons ultérieurement un livre blanc présentant les performances des métadonnées et les performances des E/S par seconde des N threads vers un fichier, ainsi que des détails supplémentaires sur les considérations relatives à la conception, au réglage et à la configuration.

Références

[1] Documentation BeeGFS :  https://www.beegfs.io/wiki/
[2] How to connect two interfaces on the same subnet :  https://access.redhat.com/solutions/30564