Déployer le système de fichiers parallèle BeeGFS

BeeGFS est un système de fichiers de cluster parallèle, développé en mettant fortement l'accent sur les performances d'entrée/sortie et conçu pour une installation et une gestion faciles. A l'aide de BeeGFS, vous pouvez créer un serveur de fichiers HPC (calcul haute performance) sur Oracle Cloud Infrastructure.

BeeGFS répartit de manière transparente les données utilisateur sur plusieurs serveurs. En augmentant le nombre de serveurs et de disques dans le système, vous pouvez augmenter les performances et la capacité du système de fichiers de petits clusters à des systèmes de classe entreprise avec des milliers de noeuds.

Architecture

Cette architecture de référence utilise une région avec un domaine de disponibilité unique et des sous-réseaux régionaux. Vous pouvez utiliser la même architecture de référence dans une région avec plusieurs domaines de disponibilité. Nous vous recommandons d'utiliser des sous-réseaux régionaux pour votre déploiement, quel que soit le nombre de domaines de disponibilité.

Le diagramme suivant illustre cette architecture de référence.

Description de l'architecture -deploy-beegfs.png suivante
Description de l'illustration architecture-deploy-beegfs.png

L'architecture comporte les composants suivants :

  • Région

    Une région est une zone géographique localisée composée d'un ou de plusieurs domaines de disponibilité. Les régions sont indépendantes des autres régions et de vastes distances peuvent les séparer (d'un pays ou d'un continent à l'autre).

  • Domaines de disponibilité

    Les domaines de disponibilité sont des centres de données autonomes et indépendants au sein d'une région. Les ressources physiques de chaque domaine de disponibilité sont isolées des ressources des autres domaines de disponibilité, ce qui permet de tolérer les pannes. Les domaines de disponibilité ne partagent pas d'infrastructure telle que l'alimentation ou le refroidissement, ou le réseau de domaine de disponibilité interne. Par conséquent, il est peu probable qu'un échec dans un domaine de disponibilité affecte les autres domaines de disponibilité de la région.

  • Domaines d'erreur

    Un domaine de pannes est un regroupement de matériel et d'infrastructure dans un domaine de disponibilité. Chaque domaine de disponibilité comporte trois domaines de pannes avec alimentation et matériel indépendants. Lorsque vous placez des instances de calcul sur plusieurs domaines de pannes, les applications peuvent tolérer l'échec du serveur physique, la maintenance du système et de nombreuses pannes de réseau et d'alimentation communes dans le domaine de disponibilité.

  • Réseau cloud virtuel (VCN) et sous-réseaux

    VCN est un réseau défini par logiciel que vous configurez dans une région Oracle Cloud Infrastructure. Les VCN peuvent être segmentés en sous-réseaux, qui peuvent être spécifiques à une région ou à un domaine de disponibilité. Les sous-réseaux propres à chaque région et à chaque domaine de disponibilité peuvent coexister dans le même VCN. Un sous-réseau peut être public ou privé.

  • Listes de sécurité

    Pour chaque sous-réseau, vous pouvez créer des règles de sécurité qui spécifient la source, la destination et le type de trafic qui doivent être autorisés dans et hors du sous-réseau.

  • Tables de routage

    Les tables de routage virtuelles contiennent des règles permettant d'acheminer le trafic de sous-réseaux vers des destinations en dehors de VCN, généralement via des passerelles.

  • Passerelle Internet

    La passerelle Internet permet le trafic entre VCN et Internet public.

  • Noeuds client

    Les clients sont des instances Compute qui accèdent au système de fichiers BeeGFS.

  • Management Server

    Le serveur de gestion (MGS) est un point de rencontre pour les services de métadonnées, de stockage et de client BeeGFS. Un MGS stocke les informations de configuration d'un ou de plusieurs systèmes de fichiers et fournit ces informations à d'autres hôtes. Cette ressource globale peut prendre en charge plusieurs systèmes de fichiers.

  • Service de métadonnées

    Le service de métadonnées (MDS) stocke des informations sur les données, telles que les informations d'annuaire, la propriété des fichiers et répertoires, et l'emplacement du contenu des fichiers utilisateur sur les cibles de stockage. Le service de métadonnées est un service de mise à l'échelle, ce qui signifie que vous pouvez utiliser un ou plusieurs services de métadonnées dans un système de fichiers BeeGFS.

    Le contenu des métadonnées est stocké sur des volumes appelés cibles de métadonnées (MDT).

  • Service Object Storage

    Le service Object Storage (OSS) est le service principal pour stocker le contenu des fichiers utilisateur ou les fichiers de blocs de données. Les serveurs Object Storage sont également appelés serveurs de stockage.

    Comme pour le service de métadonnées, le service Object Storage est basé sur une conception évolutive. Une instance d'O/S a une ou plusieurs cibles de stockage d'objet.

    Chaque serveur de stockage permet d'accéder à un ensemble de volumes de stockage, appelés cibles Object Storage (OST). Chaque OST contient plusieurs objets binaires qui représentent les données des fichiers.

Recommandations

Vos exigences peuvent différer de l'architecture décrite ici. Utilisez les recommandations suivantes comme point de départ.

  • VCN

    Lorsque vous créez VCN, déterminez le nombre d'adresses IP requises pour vos ressources cloud dans chaque sous-réseau. À l'aide de la notation CIDR (Classless Inter-Domain Routing), spécifiez un masque de sous-réseau et une plage d'adresses réseau suffisamment grande pour les adresses IP requises. Utilisez une plage d'adresses située dans l'espace IP privé standard.

    Sélectionnez une plage d'adresses qui ne chevauche pas votre réseau sur site, de sorte que vous puissiez configurer une connexion entre VCN et votre réseau sur site, si nécessaire.

    Après avoir créé un VCN, vous ne pouvez pas modifier sa plage d'adresses.

    Lorsque vous concevez les sous-réseaux, tenez compte de vos besoins en matière de flux de trafic et de sécurité. Attachez toutes les instances de calcul du même niveau ou rôle au même sous-réseau, qui peut servir de limite de sécurité.

  • Listes de sécurité

    Utilisez les listes de sécurité pour définir les règles entrantes et sortantes qui s'appliquent à l'ensemble du sous-réseau.

  • Hôte de Bastion

    Un hôte bastion permet d'accéder à tous les noeuds du sous-réseau privé. Utilisez la forme VM.Standard.E2.1.

  • Serveur de gestion (MGS)

    Puisque le MGS n'est pas exigeant en ressources, vous pouvez choisir de le déployer avec le serveur MDS. Si vous le déployez séparément, la forme VM.Standard2.2 est suffisante.

    Utilisez un volume de bloc de niveau de performance équilibré de 50 Go. Le volume de bloc peut être redimensionné si plus d'espace est nécessaire.

  • Serveur MDS (Metadata Service)

    Utilisez une forme VM.Standard2.8 ou supérieure. Les exigences dépendent du fait que votre charge globale est à forte intensité de métadonnées (pour les petites charges globales de fichiers) ou non, du nombre d'instances de métadonnées en cours d'exécution par noeud, etc.

    Pour des performances optimales, une forme Bare Metal telle que BM.Standard2.52 est recommandée car elle dispose de deux cartes réseau physiques, chacune avec une vitesse réseau de 25 Gbps. Utilisez une carte d'interface réseau pour tout le trafic afin de bloquer le stockage et utilisez l'autre carte d'interface réseau pour les données entrantes vers les noeuds MDS à partir des noeuds client.

    Utiliser le stockage de volume de blocs ; les modifications de taille et de nombre par besoin de déploiement pour plus de stockage. Si plus d'espace est nécessaire, le volume de bloc peut être redimensionné.

  • Serveur OSS (Object Storage Service)

    Utilisez VM.Standard2.8 ou supérieur. Le besoin dépend du débit d'E/S agrégé requis dans GBps à partir du système de fichiers.

    Pour des performances optimales, une forme Bare Metal telle que BM.Standard2.52 est recommandée car elle dispose de deux cartes d'interface réseau physiques, chacune avec une vitesse réseau de 25 Gbps. Utilisez une carte d'interface réseau pour tout le trafic afin de bloquer le stockage et utilisez l'autre carte d'interface réseau pour les données entrantes vers les noeuds OSS à partir des noeuds client.

  • Noeuds client

    Choisissez une forme de machine virtuelle en fonction de vos plans de déploiement. La forme détermine la bande passante réseau disponible pour l'instance à lire et à écrire dans le système de fichiers. Par exemple, une forme VM.Standard2.16 a une bande passante réseau maximale de 16.4 Gbps, ce qui signifie que le débit d'E/S maximal est de 2.05 GBps.

    Les formes de calcul Intel et AMD VM et Bare Metal peuvent être utilisées pour les clients.

Remarques

  • Performances

    Pour obtenir les meilleures performances, choisissez la forme de calcul correcte avec la bande passante appropriée.

  • Disponibilité

    Envisagez d'utiliser une option de haute disponibilité en fonction de vos besoins de déploiement.

  • Coût

    Le service Bare Metal offre une bande passante réseau plus élevée, mais pour un coût plus élevé. Évaluez vos exigences pour choisir la forme de calcul appropriée.

  • Alertes et surveillance

    Configurez la surveillance et les alertes sur l'utilisation de l'UC et de la mémoire pour vos noeuds MGS, MDS et OSS afin d'augmenter ou de réduire la forme de la machine virtuelle au besoin.

Déployer

Le code Terraform de cette architecture de référence est disponible sur GitHub.

Vous pouvez déployer à l'aide du script Terraform directement ou via le service Oracle Cloud Infrastructure Resource Manager.

  1. Accédez à GitHub.
  2. Cloner ou télécharger le référentiel sur votre ordinateur local.
  3. Pour utiliser le script Terraform, suivez les instructions du document README.
  4. Pour utiliser Oracle Cloud Infrastructure Resource Manager, suivez les instructions de README dans le répertoire orm du référentiel.