Architecture : système de fichiers Lustre dans Google Cloud avec DDN EXAScaler

Last reviewed 2023-11-15 UTC

Le présent document fournit des conseils d'architecture pour vous aider à concevoir et à dimensionner un système de fichiers Lustre pour les charges de travail de calcul hautes performances (HPC). Il présente également le processus de déploiement d'un système de fichiers Lustre dans Google Cloud en utilisant DDN EXAScaler.

Lustre est un système de fichiers parallèle Open Source qui fournit un stockage à haut débit et à faible latence pour les charges de travail HPC à couplage fort. Vous pouvez adapter un système de fichiers Lustre pour supporter des dizaines de milliers de clients HPC et des pétaoctets de stockage. EXAScaler Cloud est une version d'entreprise de Lustre proposée par DDN, un partenaire de Google. Vous pouvez déployer EXAScaler Cloud dans une architecture cloud hybride pour augmenter votre capacité HPC sur site. EXAScaler Cloud peut également servir de dépôt pour stocker les éléments à plus long terme à partir d'un déploiement EXAScaler sur site.

Ce document est destiné aux architectes d'entreprise et aux utilisateurs techniques qui conçoivent, provisionnent et gèrent du stockage pour des charges de travail HPC dans le cloud. Dans le présent document, nous partons du principe que vous avez une compréhension conceptuelle des systèmes de fichiers parallèles. Vous devez également comprendre les cas d'utilisation du HPC pour lesquels les systèmes de fichiers parallèles tels que Lustre sont le choix idéal. Pour en savoir plus, consultez la page Systèmes de fichiers parallèles pour les charges de travail HPC.

Présentation du système de fichiers Lustre

Le schéma suivant illustre l'architecture d'un système de fichiers Lustre :

Architecture d'un système de fichiers Lustre

Comme le montre le schéma, l'architecture contient les composants suivants :

  • Serveur de gestion (MGS) et cibles de gestion (MGT) : le MGS stocke et gère les informations de configuration sur un ou plusieurs systèmes de fichiers Lustre. Le schéma montre le MGS gérant un seul système de fichiers Lustre. Le MGS fournit des informations de configuration aux autres composants Lustre dans tous les systèmes de fichiers qu'il gère. Le MGS enregistre les journaux de configuration du système de fichiers dans des périphériques de stockage appelés MGT.

  • Serveurs de métadonnées (MDS) et cibles de métadonnées (MDT) : les nœuds MDS gèrent l'accès client à l'espace de noms d'un système de fichiers Lustre. Cet espace de noms inclut toutes les métadonnées du système de fichiers, telles que la hiérarchie des répertoires, l'heure de création des fichiers et les autorisations d'accès. Les métadonnées sont stockées dans des périphériques de stockage appelés MDT. Un système de fichiers Lustre dispose au minimum d'un MDS et d'une MDT associée. Pour améliorer les performances des charges de travail exigeantes pour ce qui est des métadonnées, par exemple lorsque des milliers de clients créent et accèdent à des millions de petits fichiers, vous pouvez ajouter davantage de nœuds MDS au système de fichiers.

  • Serveurs de stockage d'objets (OSS) et cibles de stockage d'objets (OST) : les nœuds OSS gèrent l'accès client aux données de fichiers stockées dans un système de fichiers Lustre. Chaque fichier est stocké sous la forme d'un ou de plusieurs objets Lustre. Les objets sont stockés dans un seul appareil de stockage (appelé OST) ou répartis sur plusieurs nœuds OST et OST. Un système de fichiers Lustre dispose au minimum d'un OSS et d'une OST associée. Vous pouvez ajuster la capacité de stockage et les performances du système de fichiers en ajoutant des nœuds OSS et des OST. La capacité totale de stockage du système de fichiers correspond à la somme des capacités de stockage des OST associées à tous les nœuds OSS du système de fichiers.

  • Clients : un client Lustre est un nœud de calcul, tel qu'une machine virtuelle (VM), qui accède à un système de fichiers Lustre via un point d'installation. Le point d'installation fournit un espace de noms unifié pour l'ensemble du système de fichiers. Vous pouvez faire évoluer un système de fichiers Lustre pour permettre l'accès simultané de plus de 10 000 clients. Les clients Lustre accèdent à tous les nœuds MDS et OSS d'un système de fichiers Lustre en parallèle. Cet accès parallèle permet d'optimiser les performances du système de fichiers. L'accès parallèle permet également de réduire les hotspots de stockage, qui sont des emplacements de stockage faisant l'objet d'accès beaucoup plus fréquents que d'autres emplacements. Les hotspots sont courants dans les systèmes de fichiers non parallèles et peuvent entraîner un déséquilibre des performances entre les clients.

    Pour accéder à un système de fichiers Lustre, un client récupère les métadonnées de répertoire et de fichier requises à partir d'un MDS, puis lit ou écrit des données en communiquant avec un ou plusieurs nœuds OSS. Lustre offre une conformité étroite avec la sémantique POSIX et permet à tous les clients d'accéder au système de fichiers de manière complète et parallèle.

Pour en savoir plus sur le système de fichiers Lustre et son fonctionnement, consultez la documentation de Lustre.

Architecture de Lustre dans Google Cloud

Le schéma suivant illustre une architecture pour le déploiement d'un système de fichiers Lustre dans Google Cloud :

Architecture du système de fichiers Lustre dans Google Cloud

L'architecture présentée dans ce schéma contient les ressources suivantes : Toutes les ressources sont déployées dans un seul projet Google Cloud. Les ressources de calcul et de stockage sont provisionnées dans une seule zone.

  • Les VM Compute Engine hébergent les nœuds MGS, MDS et OSS, ainsi que les clients Lustre. Vous pouvez également choisir de déployer les clients Lustre dans un cluster Google Kubernetes Engine et de déployer le système de fichiers sur des VM Compute Engine.

  • L'architecture comprend les ressources de mise en réseau suivantes :

    • Un seul sous-réseau VPC (cloud privé virtuel) utilisé pour toutes les VM.
    • Une passerelle Cloud NAT facultative et un routeur Cloud Router facultatif pour le trafic sortant des VM privées vers Internet.
    • Des règles de pare-feu facultatives pour autoriser les connexions SSH entrantes à toutes les VM de la topologie.
    • Une règle de pare-feu facultative pour autoriser l'accès HTTP depuis Internet à la console Web DDN EXAScaler sur le MGS.
    • Un pare-feu pour autoriser les connexions TCP entre toutes les VM.

  • Les disques persistants fournissent une capacité de stockage pour les nœuds MGS, MDS et OSS. Si vous n'avez pas besoin de stockage persistant, vous pouvez créer un système de fichiers temporaire ("scratch") en utilisant des disques durs SSD locaux, qui sont associés aux VM.

    Grâce à des soumissions IO500, Google a pu démontrer les performances des systèmes de fichiers persistants et temporaires de Lustre. Consultez la soumission Google Cloud pour découvrir, dans le cadre du classement IO500 des systèmes de stockage HPC, un système de fichiers temporaire Lustre offrant une capacité supérieure à 10 Tbit/s.

Principes de conception

Suivez les principes ci-dessous pour concevoir un système de fichiers Lustre répondant aux exigences de vos charges de travail HPC. Les consignes décrites dans cette section ne sont pas exhaustives. Ils fournissent un framework qui vous aide à évaluer les besoins en stockage de vos charges de travail HPC, à évaluer les options de stockage disponibles et à dimensionner votre système de fichiers Lustre.

Exigences relatives aux charges de travail

Identifiez les exigences de stockage de vos charges de travail HPC. Définissez les exigences le plus précisément possible et tenez compte de leur évolution future. Utilisez les questions suivantes comme point de départ pour identifier les exigences de votre charge de travail :

  • Quelles sont vos exigences en termes de débit et d'opérations d'E/S par seconde (IOPS) ?
  • De quelle capacité de stockage avez-vous besoin ?
  • Quel est votre objectif de conception le plus important : débit, IOPS ou capacité de stockage ?
  • Avez-vous besoin d'un espace de stockage persistant, d'un stockage temporaire ou des deux ?

Options de stockage

Vous pouvez choisir parmi les types de disques Persistent Disk suivants pour des options de stockage plus économiques :

  • Les disques persistants standards (pd-standard) constituent l'option la plus rentable lorsque la capacité de stockage constitue le principal objectif de conception. Ils offrent un stockage de blocs efficace et fiable en utilisant des disques durs (HDD).
  • Les disques persistants SSD (pd-ssd) constituent l'option la plus rentable lorsque l'objectif est de maximiser les IOPS. Ils offrent un stockage de blocs rapide et fiable en utilisant des disques SSD.
  • Les disques persistants avec équilibrage (pd-balanced) constituent l'option la plus rentable pour optimiser le débit. Ils offrent un stockage de blocs économique et fiable en utilisant des disques SSD.

Les disques persistants extrêmes (pd-extreme) peuvent offrir de meilleures performances que les autres types de disques et vous permettent de choisir le niveau d'IOPS requis. Toutefois, les disques pd-extreme coûtent plus cher que les autres types de disques.

Pour en savoir plus sur les performances des différents disques Persistent Disk, consultez la section Performances des options de stockage de blocs.

Pour le stockage temporaire, vous pouvez utiliser des disques SSD locaux éphémères. Les disques SSD locaux sont rattachés physiquement au serveur qui héberge les VM. Par conséquent, les disques SSD locaux offrent un débit plus élevé et une latence plus faible que les disques Persistent Disk. Cependant, les données stockées sur un disque SSD local ne sont conservées que jusqu'à ce que la VM soit arrêtée ou supprimée.

Serveurs de stockage d'objets

Lorsque vous concevez l'infrastructure pour les nœuds OSS, nous vous recommandons de procéder comme suit :

  • Pour le stockage, choisissez un type de disque Persistent Disk approprié en fonction de vos exigences en termes de capacité de stockage, de débit et d'IOPS.

    • Utilisez pd-standard pour les charges de travail qui présentent les exigences suivantes :
      • La charge de travail nécessite une capacité de stockage élevée (par exemple, plus de 10 To) ou nécessite un débit de lecture et une capacité de stockage élevés.
      • La latence des E/S n'est pas importante.
      • Un faible débit en écriture est acceptable.
    • Utilisez pd-balanced pour les charges de travail qui présentent l'une des exigences suivantes :
      • Haut débit avec une faible capacité.
      • Faible latence typiquement offerte par les disques basés sur SSD.
    • Utilisez pd-ssd pour les charges de travail nécessitant des IOPS élevées (petites requêtes d'E/S ou petits fichiers).

  • Provisionnez une capacité de stockage suffisante pour atteindre les IOPS requises. Considérez les IOPS en lecture et en écriture fournies par chaque type de disque.

  • Pour les VM, utilisez un type de machine de la famille de machines N2 ou N2D. Ces types de machines offrent des performances prévisibles et économiques.

  • Allouez suffisamment de vCPU (processeurs virtuels) pour atteindre le débit requis de disque Persistent Disk. Le débit maximal de disque Persistent Disk par VM est de 1,2 Gbit/s et peut être atteint avec 16 vCPU. Commençons par un type de machine qui comporte 16 processeurs virtuels. Surveillez les performances et allouez davantage de processeurs virtuels lorsque vous devez effectuer le scaling des IOPS.

Serveurs de métadonnées

Les nœuds MDS n'ont pas besoin d'une capacité de stockage élevée pour la diffusion des métadonnées, mais ils ont besoin d'un espace de stockage capable d'offrir des IOPS élevées. Lors de la conception de l'infrastructure pour les nœuds MDS, nous vous recommandons de procéder comme suit :

  • Pour le stockage, utilisez pd-ssd car ce type de disque Persistent Disk offre un nombre élevé d'IOPS (30 IOPS par Go), même pour une faible capacité de stockage.
  • Provisionnez une capacité de stockage suffisante pour atteindre les IOPS requises.
  • Pour les VM, utilisez un type de machine de la famille de machines N2 ou N2D. Ces types de machines offrent des performances prévisibles et économiques.
  • Allouez suffisamment de processeurs virtuels pour atteindre les IOPS requises :
    • Pour les charges de travail peu exigeantes en termes de métadonnées, utilisez 16 processeurs virtuels.
    • Pour les charges de travail moyennement exigeantes en termes de métadonnées, utilisez 32 processeurs virtuels.
    • Pour les charges de travail très exigeantes en termes de métadonnées, utilisez 64 processeurs virtuels. Surveillez les performances et allouez davantage de processeurs virtuels si nécessaire.

Serveur de gestion

Le MGS nécessite des ressources de calcul minimales. Il ne s'agit pas d'un service qui demande beaucoup de stockage. Commencez par utiliser un petit type de machine pour la VM (par exemple, n2-standard-2) et un disque de 128 Go pd-ssd pour le stockage, puis surveillez les performances. Si le temps de réponse est lent, augmentez le nombre de processeurs virtuels et augmentez la taille du disque.

Disponibilité et durabilité

Si vous avez besoin d'un stockage persistant, les types de disques Persistent Disk pd-standard et pd-balanced offrent un stockage hautement disponible et durable au sein d'une zone. Pour la persistance interzone ou interrégionale, vous pouvez copier les données vers une option Cloud Storage à faible coût en utilisant la Google Cloud CLI ou le service de transfert de stockage. Pour réduire le coût de stockage des données dans Cloud Storage, vous pouvez stocker les données rarement consultées dans un bucket de classe de stockage Nearline ou de stockage Coldline.

Si vous n'avez besoin que d'un stockage éphémère pour un déploiement temporaire, utilisez des disques SSD locaux comme disques de données pour les nœuds OSS et MDS. Cette conception offre de hautes performances avec le plus petit nombre de VM OSS. Cette conception vous permet également d'obtenir un rapport coût-performances optimal par rapport aux autres options.

Exemple de dimensionnement pour les VM OSS

La stratégie recommandée pour le dimensionnement et le provisionnement de votre système de fichiers Lustre consiste à provisionner suffisamment de VM OSS pour répondre aux exigences de débit global. Augmentez ensuite la capacité de stockage des disques OST jusqu'à atteindre la capacité de stockage requise. L'exemple de charge de travail utilisé dans cette section vous montre comment mettre en œuvre cette stratégie en suivant les étapes suivantes :

  1. Déterminer les exigences de la charge de travail.
  2. Choisir un type de disque Persistent Disk.
  3. Calculer le nombre de VM OSS.
  4. Calculer la taille du disque par VM.
  5. Déterminer le nombre de processeurs virtuels par VM.

Déterminer les exigences de la charge de travail

Dans cet exemple, la charge de travail nécessite 80 To de capacité de stockage persistant avec un débit de lecture de 30 Gbit/s.

Choisir un type de disque Persistent Disk

Comme indiqué dans la section Options de stockage, pd-standard est l'option la plus rentable lorsque la capacité de stockage est l'objectif de conception principal, et pd-balanced est l'option la plus rentable pour optimiser le débit. Le débit maximal est différent pour chaque type de disque, et il évolue avec la taille du disque.

Pour chaque type de disque Persistent Disk pouvant être utilisé pour cette charge de travail, calculez la capacité de stockage nécessaire pour adapter le débit en lecture à la cible de 30 Gbit/s.

Type de disque Débit par To en lecture Capacité de stockage requise pour atteindre le débit cible
pd-standard 0,12 Gbit/s 30 divisé par 0,12 = 250 To
pd-balanced 0,28 Gbit/s 30 divisé par 0,28 = 107 To

Pour atteindre le débit de lecture cible de 30 Gbit/s en utilisant pd-standard, vous devez provisionner 250 To de capacité de stockage. Cette quantité est plus de trois fois supérieure à la capacité requise de 80 To. Ainsi, pour la charge de travail de cet exemple, pd-balanced fournit un espace de stockage économique qui répond aux exigences de performances.

Calculer le nombre de VM OSS

Le débit de lecture maximal par VM Compute Engine est de 1,2 Go/s. Pour atteindre le débit de lecture cible de 30 Go/s, divisez le débit de lecture cible par le débit maximal par VM comme suit :

   30 GBps / 1.2 GBps = 25

Vous avez besoin de 25 VM OSS pour atteindre le débit de lecture cible.

Calculer la taille du disque par VM

Pour calculer la taille du disque par VM, divisez la capacité (107 To) nécessaire pour atteindre le débit cible (30 Go/s) par le nombre de VM, comme suit :

   107 TB / 25 VMs = 4.3

Vous avez besoin de 4,3 To de capacité pd-balanced par VM.

Déterminer le nombre de processeurs virtuels par VM

Le débit en lecture d'une VM évolue avec le nombre de processeurs virtuels alloués à la VM. Le débit en lecture atteint 1,2 Gbit/s pour 16 processeurs virtuels (ou plus). Vous avez besoin d'un type de machine qui bénéficie d'au moins 16 processeurs virtuels. Choisissez donc un type de machine appartenant à la famille de machines N2 ou N2D, tel que n2-standard-32.

Résumé de la configuration

L'exemple de charge de travail présente les exigences suivantes :

  • Capacité de stockage persistant de 80 To
  • Débit de 30 Gbit/s en lecture

Pour répondre aux exigences de cette charge de travail, vous avez besoin des ressources de calcul et de stockage suivantes :

  • Nombre de VM OSS : 25
  • Famille de machines VM : N2 ou N2D
  • Nombre de processeurs virtuels par VM : 16 ou plus
  • Type de disque Persistent Disk : pd-balanced
  • Taille de disque par VM : 4,3 To

Exemple de configuration d'un système de fichiers temporaire

La configuration suivante est basée sur une soumission IO500 Google Cloud qui démontre les performances d'un système de fichiers temporaire Lustre à échelle extrême sur Google Cloud :

Paramètre de configuration MDS OSS Clients
Nombre de VM 50 200 1 000
Type de machine n2-standard-80 n2-standard-64 c2-standard-16
Nombre de processeurs virtuels par VM 80 processeurs virtuels 64 processeurs virtuels 16 processeurs virtuels
RAM par VM 320 Go 256 Go 64 Go
OS CentOS 8 CentOS 8 CentOS 8
Bande passante réseau 100 Gbit/s 75 Gbit/s 32 Gbit/s
Espace de stockage SSD local 9 To NVMe
(24 disques)		 9 To NVMe
(24 disques)		 None

La configuration précédente a fourni les performances suivantes :

Métrique de performance Résultat
Débit en écriture 700 Gbit/s (5,6 Tbit/s)
Débit en lecture 1270 Go/s (10,16 Tbit/s)
Opérations stat() sur les fichiers 1,9 million par seconde
Lectures de petits fichiers (3901 octets) 1,5 million par seconde

Options de déploiement

Cette section présente les méthodes que vous pouvez utiliser pour déployer un système de fichiers EXAScaler Cloud dans Google Cloud. Cette section décrit également les étapes à suivre lorsque vous déployez les VM clientes.

Déploiement du système de fichiers EXAScaler Cloud

Vous pouvez choisir parmi les méthodes suivantes pour déployer un système de fichiers EXAScaler Cloud dans Google Cloud :

Quelle que soit la méthode utilisée, vous pouvez personnaliser le système de fichiers lors du déploiement. Par exemple, vous pouvez spécifier le nombre de VM OSS, le type de machine des VM, les types de disques Persistent Disk et la capacité de stockage.

Lorsque vous choisissez une méthode, tenez compte des différences suivantes :

  • Modifications post-déploiement : si vous utilisez le kit HPC Cloud, vous pouvez modifier efficacement le système de fichiers après le déploiement. Par exemple, pour augmenter la capacité de stockage, vous pouvez augmenter le nombre de nœuds OSS en mettant à jour le plan du kit HPC Cloud et en appliquant à nouveau la configuration générée. Pour obtenir la liste des paramètres que vous pouvez spécifier dans le plan, consultez la section Inputs (Entrées) du fichier README du module Terraform. Pour modifier un système de fichiers déployé à l'aide de la solution Cloud Marketplace, vous devez apporter les modifications individuellement pour chaque ressource de calcul et de stockage en utilisant la console Google Cloud, gcloud CLI ou l'API.

  • Assistance : la solution Cloud Marketplace utilise Deployment Manager, qui n'est pas compatible avec VPC Service Controls. Pour en savoir plus sur cette limitation, consultez la page Produits compatibles et limites de VPC Service Controls.

Déploiement client

Vous pouvez utiliser l'une des méthodes décrites dans la section Déploiement du système de fichiers EXAScaler Cloud pour déployer les VM clientes. Toutefois, Google vous recommande de provisionner et de gérer vos VM clientes séparément du système de fichiers. La méthode recommandée pour déployer vos clients consiste à utiliser l'image de VM HPC fournie par Google, qui est optimisée pour les charges de travail HPC.

Voici un aperçu du processus d'utilisation de l'image de VM HPC pour déployer des clients Lustre :

  1. Créer une VM à l'aide de l'image de VM HPC.
  2. Installer les packages clients Lustre sur la VM.
  3. Personnaliser la VM si nécessaire.
  4. Créer une image personnalisée à partir de la VM.
  5. Provisionner les VM clientes Lustre en utilisant l'image personnalisée que vous avez créée. Pour automatiser le provisionnement et la gestion des VM clientes, vous pouvez utiliser un groupe d'instances géré Compute Engine ou un outil tiers tel que Slurm Workload Manager.
  6. Installer le système de fichiers Lustre sur les VM clientes.

Options de transfert de données

Après avoir déployé un système de fichiers Lustre dans Google Cloud, vous devez déplacer vos données vers le système de fichiers. Le tableau suivant présente les méthodes que vous pouvez utiliser pour déplacer des données vers votre système de fichiers Lustre. Choisissez la méthode qui correspond au volume de données que vous devez déplacer et à l'emplacement de vos données sources (sur site ou dans Cloud Storage).

Source des données Taille des données Méthode de transfert de données recommandée
Sur site Petite (par exemple, moins de 1 To) Préproduisez les données dans Cloud Storage en utilisant l'outil gsutil. Ensuite, téléchargez les données dans le système de fichiers Lustre en utilisant le service de transfert de stockage ou gcloud CLI.
Sur site Grande Déplacez les données vers le système de fichiers Lustre en utilisant le service de transfert de stockage. Suivez les instructions de la section Transférer des données entre des systèmes de fichiers POSIX.

Cette méthode implique l'utilisation d'un bucket Cloud Storage intermédiaire. Une fois la tâche de transfert terminée, le service de transfert de stockage supprime les données du bucket intermédiaire.
Cloud Storage Grande ou petite Téléchargez les données de Cloud Storage vers le système de fichiers Lustre en utilisant le service de transfert de stockage ou gcloud CLI.

Étapes suivantes

Contributeurs

Auteur : Kumar Dhanagopal | Cross-product solution developer

Autres contributeurs :