Système de fichiers virtuel parallèle - Parallel Virtual File System

Système de fichiers virtuel parallèle
Auteur (s) original (s) Clemson University , Argonne National Laboratory , Ohio Supercomputer Center
Développeur (s) Walt Ligon, Rob Ross, Phil Carns, Pete Wyckoff, Neil Miller, Rob Latham, Sam Lang, Brad Settlemyer
Première version 2003
Version stable
2.8.2 / 1er janvier 2010 ; Il y a 11 ans  ( 01/01/2010 )
Écrit en C
Système opérateur Noyau Linux
Licence LGPL
Site Internet web .archive .org / web / 20160701052501 / http: // www .pvfs .org /

Le système de fichiers virtuels parallèles ( PVFS ) est un système de fichiers parallèle open-source . Un système de fichiers parallèle est un type de système de fichiers distribué qui distribue les données de fichiers sur plusieurs serveurs et permet un accès simultané par plusieurs tâches d'une application parallèle. PVFS a été conçu pour être utilisé dans le calcul en grappes à grande échelle . PVFS se concentre sur un accès haute performance à de grands ensembles de données. Il se compose d'un processus serveur et d'une bibliothèque client, tous deux écrits entièrement à partir de code de niveau utilisateur. Un module de noyau Linux et un processus pvfs-client permettent au système de fichiers d'être monté et utilisé avec des utilitaires standard. La bibliothèque cliente fournit un accès haute performance via l' interface de transmission de messages (MPI). Le PVFS est développé conjointement par le laboratoire de recherche d'architecture parallèle de l'Université de Clemson et la division de mathématiques et d'informatique du laboratoire national d'Argonne et l' Ohio Supercomputer Center . Le développement du PVFS a été financé par le centre de vol spatial Goddard de la NASA , le programme de recherche scientifique avancée du DOE Office of Science , les programmes NSF PACI et HECURA et d'autres agences gouvernementales et privées. PVFS est maintenant connu sous le nom d' OrangeFS dans sa dernière branche de développement.

Histoire

PVFS a été développé pour la première fois en 1993 par Walt Ligon et Eric Blumer en tant que système de fichiers parallèle pour Parallel Virtual Machine (PVM) dans le cadre d'une subvention de la NASA pour étudier les modèles d'E / S de programmes parallèles. PVFS version 0 était basé sur Vesta, un système de fichiers parallèle développé par IBM TJ Watson Research Center . À partir de 1994, Rob Ross a réécrit PVFS pour utiliser TCP / IP et s'est écarté de nombreux points de conception originaux de Vesta. PVFS version 1 était destiné à un cluster de postes de travail DEC Alpha mis en réseau à l'aide de FDDI commuté . Comme Vesta, PVFS répartissait les données sur plusieurs serveurs et autorisait les demandes d'E / S en fonction d'une vue de fichier décrivant un modèle d'accès strided. Contrairement à Vesta, le striping et la vue ne dépendaient pas d'une taille d'enregistrement commune. La recherche de Ross s'est concentrée sur la planification des E / S disque lorsque plusieurs clients accédaient au même fichier. Les résultats précédents avaient montré que la planification selon le meilleur modèle d'accès au disque possible était préférable. Ross a montré que cela dépendait d'un certain nombre de facteurs, y compris la vitesse relative du réseau et les détails de la vue des fichiers. Dans certains cas, une planification basée sur le trafic réseau était préférable, ainsi une planification adaptable dynamiquement a fourni les meilleures performances globales.

À la fin de 1994, Ligon a rencontré Thomas Sterling et John Dorband au Goddard Space Flight Center (GSFC) et a discuté de leurs plans pour construire le premier ordinateur Beowulf . Il a été convenu que PVFS serait porté sur Linux et présenté sur la nouvelle machine. Au cours des années suivantes, Ligon et Ross ont travaillé avec le groupe GSFC comprenant Donald Becker, Dan Ridge et Eric Hendricks. En 1997, lors d'une réunion du cluster à Pasadena, CA Sterling a demandé que PVFS soit publié en tant que package open source.

PVFS2

En 1999, Ligon a proposé le développement d'une nouvelle version de PVFS initialement baptisée PVFS2000 et plus tard PVFS2. Le design a été initialement développé par Ligon, Ross et Phil Carns. Ross a terminé son doctorat en 2000 et a déménagé au Laboratoire national d' Argonne.La conception et la mise en œuvre ont été effectuées par Ligon, Carns, Dale Witchurch et Harish Ramachandran à l'Université de Clemson , Ross, Neil Miller et Rob Latham au Laboratoire national d'Argonne , et Pete Wyckoff à l'Ohio Supercomputer Center. Le nouveau système de fichiers a été publié en 2003. La nouvelle conception comprenait des serveurs d'objets, des métadonnées distribuées, des vues basées sur MPI, la prise en charge de plusieurs types de réseau et une architecture logicielle pour une expérimentation et une extensibilité faciles.

La version 1 de PVFS a été retirée en 2005. La version 2 de PVFS est toujours prise en charge par Clemson et Argonne. Carns a terminé son doctorat en 2006 et a rejoint Axicom, Inc. où PVFS a été déployé sur plusieurs milliers de nœuds pour l'exploration de données. En 2008, Carns a déménagé en Argonne et continue de travailler sur PVFS avec Ross, Latham et Sam Lang. Brad Settlemyer a développé un sous-système de mise en miroir à Clemson, et plus tard une simulation détaillée de PVFS utilisé pour la recherche de nouveaux développements. Settlemyer est maintenant au Oak Ridge National Laboratory . en 2007, Argonne a commencé à porter PVFS pour une utilisation sur un IBM Blue Gene / P. En 2008, Clemson a commencé à développer des extensions pour prendre en charge de grands répertoires de petits fichiers, des améliorations de sécurité et des capacités de redondance. Comme beaucoup de ces objectifs entraient en conflit avec le développement de Blue Gene, une deuxième branche de l'arbre source CVS a été créée et baptisée "Orange" et la branche d'origine a été baptisée "Blue". PVFS et OrangeFS se suivent de très près, mais représentent deux groupes différents d'exigences des utilisateurs. La plupart des correctifs et des mises à niveau sont appliqués aux deux branches. Depuis 2011, OrangeFS est la principale ligne de développement.

Fonctionnalités

Dans un cluster utilisant PVFS, les nœuds sont désignés comme un ou plusieurs des éléments suivants: client, serveur de données, serveur de métadonnées. Les serveurs de données contiennent des données de fichiers. Les serveurs de métadonnées contiennent des métadonnées, notamment des informations statistiques, des attributs et des descripteurs de fichiers de données ainsi que des entrées de répertoire. Les clients exécutent des applications qui utilisent le système de fichiers en envoyant des demandes aux serveurs sur le réseau.

Conception basée sur les objets

PVFS a une conception basée sur les objets, c'est-à-dire que toutes les requêtes du serveur PVFS impliquaient des objets appelés espaces de données. Un espace de données peut être utilisé pour contenir des données de fichier, des métadonnées de fichier, des métadonnées de répertoire, des entrées de répertoire ou des liens symboliques. Chaque espace de données dans un système de fichiers a une poignée unique. Tout client ou serveur peut rechercher quel serveur contient l'espace de données en fonction du handle. Un espace de données a deux composants: un bytestream et un ensemble de paires clé / valeur. Le flux d'octets est une séquence ordonnée d'octets, généralement utilisée pour contenir des données de fichier, et les paires clé / valeur sont généralement utilisées pour contenir des métadonnées. La conception basée sur les objets est devenue typique de nombreux systèmes de fichiers distribués, notamment Lustre , Panasas et pNFS .

Séparation des données et des métadonnées

PVFS est conçu pour qu'un client puisse accéder une seule fois à un serveur pour les métadonnées, puis puisse accéder aux serveurs de données sans autre interaction avec les serveurs de métadonnées. Cela supprime un goulot d'étranglement critique du système et permet de bien meilleures performances.

Demandes basées sur MPI

Lorsqu'un programme client demande des données à PVFS, il peut fournir une description des données basée sur MPI_Datatypes. Cette fonction permet aux vues de fichiers MPI d'être directement implémentées par le système de fichiers. MPI_Datatypes peut décrire des modèles de données complexes non contigus. Le serveur PVFS et les codes de données implémentent des flux de données qui transfèrent efficacement les données entre plusieurs serveurs et clients.

Prise en charge de plusieurs réseaux

PVFS utilise une couche réseau nommée BMI qui fournit une interface de message non bloquante conçue spécifiquement pour les systèmes de fichiers. BMI dispose de plusieurs modules de mise en œuvre pour un certain nombre de réseaux différents utilisés dans le calcul haute performance, notamment TCP / IP, Myrinet , Infiniband et les portails .

Serveurs sans état (sans verrouillage)

Les serveurs PVFS sont conçus de manière à ne partager aucun état entre eux ou avec les clients. Si un serveur tombe en panne, un autre peut facilement être redémarré à sa place. Les mises à jour sont effectuées sans utiliser de verrous.

Implémentation au niveau de l'utilisateur

Les clients et serveurs PVFS s'exécutent au niveau de l'utilisateur. Les modifications du noyau ne sont pas nécessaires. Il existe un module noyau optionnel qui permet à un système de fichiers PVFS d'être monté comme n'importe quel autre système de fichiers, ou les programmes peuvent se lier directement à une interface utilisateur telle que MPI-IO ou une interface de type Posix . Cette fonctionnalité rend PVFS facile à installer et moins susceptible de provoquer des pannes du système.

Interface au niveau du système

L'interface PVFS est conçue pour s'intégrer au niveau du système. Il présente des similitudes avec le Linux VFS , ce qui le rend facile à implémenter en tant que système de fichiers montable, mais est également adaptable aux interfaces de niveau utilisateur telles que les interfaces de type MPI-IO ou Posix . Il expose de nombreuses fonctionnalités du système de fichiers sous-jacent afin que les interfaces puissent en tirer parti si elles le souhaitent.

Architecture

PVFS se compose de 4 composants principaux et d'un certain nombre de programmes utilitaires. Les composants sont le serveur PVFS2, le pvfslib, le PVFS-client-core et le module noyau PVFS. Les utilitaires incluent l'outil de gestion du karma, les utilitaires (par exemple, pvfs-ping, pvfs-ls, pvfs-cp, etc.) qui fonctionnent tous directement sur le système de fichiers sans utiliser le module du noyau (principalement pour la maintenance et les tests). Un autre point clé de conception est le protocole PVFS qui décrit les messages passés entre le client et le serveur, bien que ce ne soit pas strictement un composant.

Serveur PVFS2

Le serveur PVFS s'exécute en tant que processus sur un nœud désigné comme nœud d'E / S. Les nœuds d'E / S sont souvent des nœuds dédiés, mais peuvent être des nœuds réguliers qui exécutent également des tâches d'application. Le serveur PVFS fonctionne généralement en tant que root, mais peut être exécuté en tant qu'utilisateur si vous le souhaitez. Chaque serveur peut gérer plusieurs systèmes de fichiers distincts et est désigné pour s'exécuter en tant que serveur de métadonnées, serveur de données ou les deux. Toute la configuration est contrôlée par un fichier de configuration spécifié sur la ligne de commande et tous les serveurs gérant un système de fichiers donné utilisent le même fichier de configuration. Le serveur reçoit des demandes sur le réseau, exécute la demande qui peut impliquer des E / S de disque et répond au demandeur d'origine. Les demandes proviennent normalement de nœuds clients exécutant des tâches d'application, mais peuvent provenir d'autres serveurs. Le serveur est composé du processeur de requêtes, de la couche de travail, des couches Trove, BMI et de flux.

Demande de processeur

Le processeur de requêtes se compose de la boucle principale du processus serveur et d'un certain nombre de machines à états. Les machines d'état sont basées sur un langage simple développé pour PVFS qui gère la concurrence au sein du serveur et du client. Une machine à états se compose d'un certain nombre d'états, dont chacun exécute une fonction d'action d'état C ou appelle une machine à états imbriquée (sous-programme). Dans les deux cas, les codes de retour sélectionnent le prochain état à passer. Les fonctions d'action d'état soumettent généralement un travail via la couche de travail qui effectue une sorte d'E / S via Trove ou BMI. Les travaux ne sont pas bloquants, de sorte qu'une fois qu'un travail est émis, l'exécution de la machine à états est différée afin qu'une autre machine à états puisse exécuter le traitement d'une autre demande. Lorsque les travaux sont terminés, la boucle principale redémarre la machine à états associée. Le processeur de demande a des machines d'état pour chacun des différents types de demande définis dans le protocole de demande PVFS plus un certain nombre de machines d'état imbriquées utilisées en interne. L'architecture de la machine d'état rend relativement facile l'ajout de nouvelles requêtes au serveur afin d'ajouter des fonctionnalités ou d'optimiser pour des situations spécifiques.

Couche de tâche

La couche Job fournit une interface commune pour la soumission des jobs Trove, BMI et Flow et pour signaler leur achèvement. Il implémente également le planificateur de demandes en tant que travail non bloquant qui enregistre le type de demandes en cours sur quels objets et évite les erreurs de cohérence dues au fonctionnement simultané des mêmes données de fichier.

Trove

Trove gère les E / S des objets stockés sur le serveur local. Trove opère sur des collections d'espaces de données. Une collection a son propre espace de descripteur indépendant et est utilisée pour implémenter des systèmes de fichiers PVFS distincts. Un espace de données est un objet PVFS et possède son propre descripteur unique (au sein de la collection) et est stocké sur un serveur. Les descripteurs sont mappés aux serveurs via une table dans le fichier de configuration. Un espace de données se compose de deux parties: un flux d'octets et un ensemble de paires clé / valeur. Un flux d'octets est une séquence d'octets de longueur indéterminée et est utilisé pour stocker des données de fichier, généralement dans un fichier sur le système de fichiers local. Les paires clé / valeur sont utilisées pour stocker les métadonnées, les attributs et les entrées de répertoire. Trove a une interface bien définie et peut être implémentée de différentes manières. À ce jour, la seule implémentation a été celle de Trove-dbfs qui stocke les flux d'octets dans des fichiers et des paires clé / valeur dans une base de données Berkeley DB . Les opérations Trove ne sont pas bloquantes, l'API fournit des fonctions de publication pour lire ou écrire les différents composants et fonctions à vérifier ou attendre la fin.

IMC

Les flux

pvfslib

PVFS-client-core

Module noyau PVFS

Voir également

Les références

Liens externes