Historique des systèmes de fichiers DFS
En quelques mots, un système de fichiers DFS (Distributed File System) est un système de fichiers dont les fichiers sont répartis entre plusieurs serveurs de fichiers. Il est important de noter que dans un système de fichiers DFS, le client visualise un espace de noms global unique qui englobe tous les fichiers figurant sur tous les serveurs du système de fichiers. Les systèmes de fichiers DFS nécessitent la gestion des métadonnées pour que les clients puissent localiser les fichiers et blocs de fichiers requis sur les serveurs de fichiers. Ils sont généralement déployés sur plusieurs nœuds de partage de fichiers et sont destinés à être utilisés par plusieurs utilisateurs en même temps. Comme pour toute ressource partagée, plusieurs considérations relatives à la conception doivent être prises en compte : performances, cohérence, tolérance de panne, disponibilité, etc.
Origines et évolution des systèmes de fichiers DFS
Les systèmes de fichiers ont été largement influencés par le système de fichiers UNIX et le système de fichiers FFS (Fast File System) de BSD, lesquels étaient utilisés comme systèmes de fichiers locaux. Rappelons que l’objectif principal de ces systèmes de fichiers était d’organiser les données sur disque de manière rapide et fiable.
Des systèmes de fichiers en réseau comme NFS ont depuis vu le jour afin de permettre aux utilisateurs de partager des fichiers sur un réseau. NFS utilise une architecture client-serveur, dans laquelle un serveur peut partager les données qu’il détient avec plusieurs clients. Il s’agit d’un protocole simple qui continue à être utilisé à ce jour pour partager des fichiers sur un réseau. Les fichiers ne pouvant pas être distribués sur plusieurs serveurs de manière coordonnée dans NFS, chaque serveur peut simplement partager un certain nombre de fichiers. Il n’existe non plus aucune vue globale cohérente de l’espace de noms. Les clients peuvent monter des partages NFS n’importe où dans l’arborescence de leur système de fichiers local. Par conséquent, cette approche est limitée dans sa capacité à s’adapter à des milliers de clients/serveurs et est restreinte à une utilisation dans des réseaux locaux (LAN, Local Area Network).
AFS (Andrew File System) est un des premiers exemples d’un véritable système de fichiers DFS. AFS permet aux hôtes coopérants (clients et serveurs) de partager efficacement des ressources de système de fichiers sur des réseaux locaux et étendus. AFS est constitué de cellules, d’un groupe administratif de serveurs qui présentent un système de fichiers cohérent unique. Les cellules peuvent être combinées pour former un espace de noms global unique. Tout client qui accède à des données à partir d’AFS copie tout d’abord le fichier localement sur le client. Les modifications apportées au fichier sont effectuées localement tant que le fichier est ouvert. Une fois le fichier fermé, le client AFS synchronise les modifications sur le serveur. Une évolution d’AFS est CODA, un système de fichiers DFS qui améliore AFS, en particulier en ce qui concerne le partage de la sémantique et de la réplication. AFS et CODA sont conformes à POSIX, ce qui signifie qu’ils fonctionnent avec les applications UNIX existantes sans aucune modification.
En 2003, Google a révélé la conception de son système de fichiers distribué, appelé GFS2, conçu à partir de zéro pour fournir un accès efficace et fiable aux données à l’aide de grands clusters de matériel de base. GFS est conçu pour stocker des fichiers très volumineux sous la forme de blocs (généralement d’une taille de 64 Mo) sur plusieurs serveurs, en mode répliqué. Bien que GFS dispose d’une vue client unique comme AFS, l’emplacement des blocs de fichiers est exposé à l’utilisateur, offrant ainsi aux clients des opportunités de récupération des fichiers à partir du réplica disponible le plus proche. GFS, toutefois, n’est pas conforme à POSIX, ce qui signifie que les applications doivent utiliser une API spéciale pour fonctionner avec GFS. Le système de fichiers DFS Hadoop (HDFS) est une variante open source de GFS que nous explorerons en détail dans ce module.
En 2006, Ceph a été décrit pour la première fois dans un article de Weil et.al.1 Ceph est conçu pour être un service de stockage d'objets distribué qui peut être mis à l'échelle jusqu’à des centaines de milliers de machines, tout en stockant des pétaoctets de données. Les applications communiquent ensuite avec Ceph par le biais d’API diverses, allant d’une API native au fonctionnement semblable à celui de GFS à une API de système de fichiers conforme à POSIX appelée Ceph FS. Ceph prend également en charge une abstraction de périphérique de bloc, ce qui en fait un système de fichiers adapté au stockage d’images de machines virtuelles.
Google a depuis fait évoluer GFS vers un système nommé de Colossus.3.
Références
- Weil, S. A., Brandt, S. A., Miller, E. L. et Maltzahn, C. (2006). Ceph: A scalable, high-performance distributed file system Compte-rendu du 7e symposium sur la conception et l’implémentation des systèmes d’exploitation (OSDI), 307-320
- Sanjay Ghemawat, Howard Gobioff et Shun-Tak Leung (2003). The Google File Systems 19e symposium ACM sur les principes des systèmes d’exploitation
- McKusick, Kirk et Quinlan, Sean (mars 2010). GFS: Evolution on Fast-forward Communications de l’ACM