Système de fichiers en cluster

Un système de fichiers en cluster ( CFS ) est un système de fichiers partagé en étant monté simultanément sur plusieurs serveurs . Il existe plusieurs approches de clustering , dont la plupart n'utilisent pas de système de fichiers en cluster (uniquement un stockage directement attaché pour chaque nœud). Les systèmes de fichiers en cluster peuvent fournir des fonctionnalités telles que l'adressage indépendant de l'emplacement et la redondance qui améliorent la fiabilité ou réduisent la complexité des autres parties du cluster. Les systèmes de fichiers parallèles sont un type de système de fichiers en cluster qui répartit les données sur plusieurs nœuds de stockage, généralement pour des raisons de redondance ou de performances.

Un système de fichiers à disque partagé utilise un réseau de stockage (SAN) pour permettre à plusieurs ordinateurs d'accéder directement au disque au niveau du bloc . Le contrôle d'accès et la traduction des opérations au niveau du fichier utilisées par les applications vers les opérations au niveau du bloc utilisées par le SAN doivent avoir lieu sur le nœud client. Le type de système de fichiers en cluster le plus courant, le système de fichiers à disque partagé, en ajoutant des mécanismes de contrôle de concurrence , fournit une vue cohérente et sérialisable du système de fichiers, évitant ainsi la corruption et la perte de données involontaire , même lorsque plusieurs clients tentent d'accéder aux mêmes fichiers en même temps. Les systèmes de fichiers à disque partagé utilisent généralement une sorte de mécanisme de séparation pour empêcher la corruption des données en cas de défaillance d'un nœud, car un périphérique non séparé peut entraîner une corruption des données s'il perd la communication avec ses nœuds frères et tente d'accéder aux mêmes informations auxquelles d'autres nœuds accèdent.

Le réseau de stockage sous-jacent peut utiliser un certain nombre de protocoles de niveau bloc, notamment SCSI , iSCSI , HyperSCSI , ATA over Ethernet (AoE), Fibre Channel , périphérique de bloc réseau et InfiniBand .

Il existe différentes approches architecturales pour un système de fichiers à disque partagé. Certaines distribuent les informations sur les fichiers sur tous les serveurs d'un cluster (entièrement distribué).

Les systèmes de fichiers distribués ne partagent pas l'accès au niveau des blocs au même stockage mais utilisent un protocole réseau . Ceux-ci sont communément appelés systèmes de fichiers réseau , même s'ils ne sont pas les seuls systèmes de fichiers qui utilisent le réseau pour envoyer des données. Les systèmes de fichiers distribués peuvent restreindre l'accès au système de fichiers en fonction des listes d'accès ou des capacités des serveurs et des clients, selon la conception du protocole.

La différence entre un système de fichiers distribué et un magasin de données distribué est que ce dernier permet d'accéder aux fichiers en utilisant les mêmes interfaces et la même sémantique que les fichiers locaux, par exemple le montage/démontage, la liste des répertoires, la lecture/écriture aux limites d'octets, le modèle d'autorisation natif du système. Les magasins de données distribués, en revanche, nécessitent l'utilisation d'une API ou d'une bibliothèque différente et ont une sémantique différente (le plus souvent celle d'une base de données).

Les systèmes de fichiers distribués peuvent viser la « transparence » sous plusieurs aspects. En d'autres termes, ils visent à être « invisibles » pour les programmes clients, qui « voient » un système similaire à un système de fichiers local. En coulisses, le système de fichiers distribué gère la localisation des fichiers, le transport des données et fournit potentiellement d'autres fonctionnalités répertoriées ci-dessous.

• Transparence d'accès : les clients ne savent pas que les fichiers sont distribués et peuvent y accéder de la même manière que les fichiers locaux.
• Transparence de localisation : il existe un espace de noms cohérent englobant les fichiers locaux et distants. Le nom d'un fichier ne donne pas son emplacement.
• Transparence de concurrence : tous les clients ont la même vue de l'état du système de fichiers. Cela signifie que si un processus modifie un fichier, tous les autres processus du même système ou des systèmes distants qui accèdent aux fichiers verront les modifications de manière cohérente.
• Transparence des pannes : le client et les programmes clients doivent fonctionner correctement après une panne du serveur.
• Hétérogénéité : le service de fichiers doit être fourni sur différentes plates-formes matérielles et de systèmes d'exploitation.
• Évolutivité : le système de fichiers doit bien fonctionner dans des environnements de petite taille (1 machine, une douzaine de machines) et également s'adapter facilement à des environnements plus grands (des centaines à des dizaines de milliers de systèmes).
• Transparence de la réplication : les clients ne doivent pas avoir à être informés de la réplication de fichiers effectuée sur plusieurs serveurs pour prendre en charge l'évolutivité.
• Transparence de la migration : les fichiers doivent pouvoir se déplacer entre différents serveurs à l'insu du client.

Le système de partage de temps incompatible utilisait des périphériques virtuels pour un accès transparent au système de fichiers entre machines dans les années 1960. D'autres serveurs de fichiers ont été développés dans les années 1970. En 1976, Digital Equipment Corporation a créé le File Access Listener (FAL), une implémentation du protocole d'accès aux données dans le cadre de DECnet Phase II qui est devenu le premier système de fichiers réseau largement utilisé. En 1984, Sun Microsystems a créé le système de fichiers appelé « Network File System » (NFS) qui est devenu le premier système de fichiers réseau basé sur le protocole Internet largement utilisé . D'autres systèmes de fichiers réseau notables sont Andrew File System (AFS), Apple Filing Protocol (AFP), NetWare Core Protocol (NCP) et Server Message Block (SMB) qui est également connu sous le nom de Common Internet File System (CIFS).

En 1986, IBM a annoncé la prise en charge client et serveur de l'architecture de gestion des données distribuées (DDM) pour les ordinateurs centraux System/36 , System/38 et IBM exécutant CICS . Cette prise en charge a été suivie par la prise en charge des ordinateurs personnels IBM , AS/400 , des ordinateurs centraux IBM sous les systèmes d'exploitation MVS et VSE , et de FlexOS . DDM est également devenue la base de l'architecture de base de données relationnelle distribuée , également connue sous le nom de DRDA.

Il existe de nombreux protocoles réseau peer-to-peer pour les systèmes de fichiers distribués open source pour le cloud ou les systèmes de fichiers en cluster à source fermée, par exemple : 9P , AFS , Coda , CIFS/SMB , DCE/DFS , WekaFS, Lustre , PanFS, Google File System , Mnet, Chord Project .

Le stockage en réseau (NAS) fournit à la fois un stockage et un système de fichiers, comme un système de fichiers sur disque partagé sur un réseau de stockage (SAN). Le NAS utilise généralement des protocoles basés sur des fichiers (par opposition aux protocoles basés sur des blocs qu'utiliserait un SAN) tels que NFS (populaire sur les systèmes UNIX ), SMB/CIFS ( Server Message Block/Common Internet File System ) (utilisé avec les systèmes MS Windows), AFP (utilisé avec les ordinateurs Apple Macintosh ) ou NCP (utilisé avec OES et Novell NetWare ).

La défaillance d'un disque dur ou d'un nœud de stockage donné dans un cluster peut créer un point de défaillance unique pouvant entraîner une perte ou une indisponibilité des données. La tolérance aux pannes et la haute disponibilité peuvent être assurées par une réplication des données d'un type ou d'un autre, de sorte que les données restent intactes et disponibles malgré la défaillance d'un seul élément d'équipement. Pour des exemples, consultez les listes des systèmes de fichiers tolérants aux pannes distribués et des systèmes de fichiers parallèles tolérants aux pannes distribués .

Une mesure courante des performances d'un système de fichiers en cluster est le temps nécessaire pour satisfaire les demandes de service. Dans les systèmes conventionnels, ce temps se compose d'un temps d'accès au disque et d'une petite quantité de temps de traitement du processeur . Mais dans un système de fichiers en cluster, un accès à distance entraîne une surcharge supplémentaire en raison de la structure distribuée. Cela comprend le temps nécessaire pour transmettre la demande à un serveur, le temps nécessaire pour transmettre la réponse au client et, pour chaque direction, une surcharge du processeur liée à l'exécution du logiciel de protocole de communication .

Le contrôle de concurrence devient un problème lorsque plusieurs personnes ou clients accèdent au même fichier ou bloc et souhaitent le mettre à jour. Par conséquent, les mises à jour du fichier à partir d'un client ne doivent pas interférer avec l'accès et les mises à jour des autres clients. Ce problème est plus complexe avec les systèmes de fichiers en raison des écritures simultanées qui se chevauchent, où différents auteurs écrivent simultanément dans des régions du fichier qui se chevauchent. Ce problème est généralement traité par le contrôle de concurrence ou le verrouillage qui peut être intégré au système de fichiers ou fourni par un protocole complémentaire.

Dans les années 1970, les ordinateurs centraux IBM pouvaient partager des disques physiques et des systèmes de fichiers si chaque machine disposait de sa propre connexion de canal aux unités de contrôle des lecteurs. Dans les années 1980, les clusters TOPS-20 et OpenVMS de Digital Equipment Corporation (VAX/ALPHA/IA64) incluaient des systèmes de fichiers sur disque partagés.