Stockage de fichiers distribué expliqué : comment ça marche

Le stockage de fichiers distribué répartit les données sur plusieurs nœuds afin qu'aucune machine ne constitue un goulot d'étranglement ni un point de défaillance unique. Ceph gère en production des clusters de plusieurs pétaoctets avec une durabilité à 11 neuf, tandis que MinIO, compatible S3, peut être déployé sur du matériel ordinaire en quelques minutes. Les choix de conception — comment placer les données, les répliquer, gérer les pannes de nœuds et maintenir la cohérence — distinguent des systèmes comme Ceph (objet/bloc/fichier), GlusterFS (POSIX), HDFS (traitement batch massif) et IPFS (adressage par contenu). RGPD oblige : si vos données résident dans l'UE, la localisation du cluster n'est pas un détail technique mais une obligation légale que la CNIL peut contrôler. Voici un tour complet du fonctionnement concret de ces architectures.

Réplication versus codage par effacement

Deux stratégies protègent contre la défaillance d'un nœud. La réplication stocke plusieurs copies complètes : la configuration par défaut de Ceph est une réplication ×3, ce qui signifie qu'un objet de 1 Go consomme 3 Go de stockage brut. Simple à raisonner, rapide en lecture, coûteux en espace. Le codage par effacement divise les données en k blocs de données et m blocs de parité via des codes Reed-Solomon : un schéma (10,4) stocke 14 blocs et tolère 4 pannes avec seulement 40 % de surcoût au lieu de 200 %. MinIO utilise le codage par effacement par défaut ; les Backblaze Vaults recourent à Reed-Solomon 17+3. Les lectures avec codage par effacement sont plus lentes car la reconstruction peut nécessiter plusieurs blocs, aussi les données chaudes utilisent souvent la réplication et les données froides le codage par effacement.

Hachage cohérent et placement des données

Comment un système décide-t-il quel nœud stocke quel objet ? Le hachage cohérent, introduit par Karger et al. (1997) et popularisé par DynamoDB et Cassandra, hache les clés sur un anneau et mappe chaque plage à un nœud. L'ajout ou la suppression d'un nœud ne redistribue qu'une fraction des clés, pas l'ensemble du jeu de données. Ceph utilise CRUSH (Controlled Replication Under Scalable Hashing), un algorithme déterministe qui place les objets en fonction d'une carte topologique (baie, rangée, centre de données) pour que les répliques se retrouvent dans des domaines de défaillance distincts. Les nœuds virtuels (vnodes) par nœud physique lissent les déséquilibres de charge.

Modèles de cohérence : forte, éventuelle et causale

Le théorème CAP stipule qu'on ne peut avoir simultanément cohérence, disponibilité et tolérance aux partitions réseau — on en choisit deux. La cohérence forte (linéarisabilité) signifie que les lectures voient toujours la dernière écriture ; des systèmes comme Spanner et etcd le garantissent via Paxos ou Raft. La cohérence éventuelle (DynamoDB, Cassandra, S3 pour certaines opérations historiques) signifie que les répliques convergent avec le temps, avec des lectures obsolètes possibles pendant la propagation. La cohérence causale préserve l'ordre cause-effet sans linéarisabilité complète. Le stockage de fichiers accepte souvent la cohérence éventuelle pour les métadonnées (liste, taille) et la cohérence forte pour les lectures après écriture du même objet.

Architecture Ceph : OSD, moniteurs, managers et MDS

Ceph fait tourner quatre types de démons. Les OSD (Object Storage Daemons) stockent les objets et les répliquent ; un cluster en compte typiquement 10 à 1 000 sur des disques rotatifs ou NVMe. Les moniteurs (MON) maintiennent l'état du cluster via Paxos ; 3 ou 5 MON assurent le quorum. Les managers (MGR) exposent les métriques et hébergent les tableaux de bord. Les MDS (Metadata Servers) servent la couche de système de fichiers POSIX CephFS. La passerelle RADOS (RGW) présente les API S3 et Swift. Le stockage bloc via RBD alimente les volumes OpenStack et les disques de VM. Un seul code source, trois personnalités, configurées via /etc/ceph/ceph.conf et les modifications de la carte CRUSH.

HDFS et l'héritage Hadoop

HDFS (Hadoop Distributed File System) cible les grandes lectures séquentielles pour les jobs MapReduce et Spark. Les fichiers sont découpés en blocs de 128 Mo ou 256 Mo ; chaque bloc est répliqué ×3 par défaut sur les DataNodes. Un NameNode conserve toutes les métadonnées en mémoire, limitant l'échelle à environ 500 millions de fichiers par NameNode. HDFS Federation et HDFS Router ajoutent la prise en charge multi-espaces de noms. HDFS n'est pas adapté aux petits fichiers (les métadonnées dominent) ni à la compatibilité POSIX, mais il excelle pour l'analyse de jeux de données à l'échelle du téraoctet. Il est également supplanté par le stockage objet (S3, GCS) à mesure que le calcul se dissocie du stockage dans le cloud.

Stockage adressé par contenu : IPFS et Filecoin

IPFS (InterPlanetary File System) identifie le contenu par son hachage (CID, Content IDentifier) plutôt que par son emplacement. Toute personne stockant un fichier avec le même contenu produit le même CID. La récupération utilise une DHT (Distributed Hash Table, basée sur Kademlia) pour trouver les nœuds hébergeant le contenu. Filecoin ajoute des incitations économiques : les mineurs prouvent qu'ils stockent le contenu via PoRep (Proof-of-Replication) et PoSt (Proof-of-Spacetime) et gagnent des tokens FIL. IPFS convient à l'archivage et à la publication décentralisée (métadonnées NFT, sites web3) ; il est lent pour les charges interactives en raison de la latence de recherche DHT (des centaines de millisecondes à quelques secondes).

Stockage objet : S3, R2, B2 et MinIO

Le stockage objet présente une API clé-valeur plate : PUT un objet avec une clé, GET pour le récupérer. Pas de répertoires, pas de sémantique POSIX. Cette simplicité permet une échelle massive — AWS S3 stocke des milliers de milliards d'objets avec une durabilité à 11 neuf. Des clones comme Cloudflare R2, Backblaze B2, Wasabi et DigitalOcean Spaces implémentent l'API S3 sur des backends différents. MinIO tourne sur site en open source AGPL v3, souvent dans Kubernetes en StatefulSet, offrant un stockage compatible S3 sur du matériel ordinaire. Le stockage objet a largement conquis le marché du stockage cloud car l'API est simple, la tarification claire et la durabilité fiable.

Codage par effacement en pratique : la reconstruction

Quand un nœud tombe dans un système à codage par effacement, les nœuds restants reconstruisent les blocs perdus. Pour un code Reed-Solomon (10,4), n'importe quels 10 des 14 blocs permettent de reconstruire les 10 blocs de données d'origine via de l'algèbre matricielle sur un corps fini. La charge de reconstruction incombe aux nœuds survivants ; perdre 1 nœud dans un cluster de 100 déclenche des lectures depuis 10 autres nœuds par bloc perdu. La bande passante lors de la reconstruction est un problème opérationnel majeur. Des systèmes comme Ceph limitent le débit de reconstruction pour éviter d'impacter les I/O de production. Des codes plus récents comme Local Reconstruction Codes (LRC, utilisé par Azure) réduisent la bande passante de reconstruction en permettant des lectures partielles.

Domaines de défaillance et résidence des données

Placer trois répliques n'aide pas si les trois se trouvent dans le même rack et que le switch top-of-rack tombe. La prise en compte des domaines de défaillance signifie que les répliques atterrissent dans des racks, rangées ou centres de données différents. Les règles CRUSH de Ceph encodent « au moins 2 copies dans des racks différents, 1 copie dans un centre de données différent ». Le stockage objet cloud gère cela de manière transparente : S3 Standard stocke sur 3+ zones de disponibilité. Pour la réplication inter-régions, S3 Cross-Region Replication (CRR) reflète de manière asynchrone les objets vers une autre région — une exigence que la CNIL peut imposer dans le cadre du RGPD pour les données personnelles hébergées hors UE.

Implications pratiques pour les services de transfert de fichiers

Un service de transfert de fichiers s'appuie généralement sur le stockage objet plutôt que sur un système de fichiers POSIX. Les backends compatibles S3 (AWS S3, Cloudflare R2, MinIO) gèrent la durabilité et l'échelle sans que l'équipe ait à opérer Ceph ou GlusterFS. Le service ajoute l'authentification, les URL présignées, les métadonnées et les fonctionnalités orientées utilisateur. HexaTransfer utilise un backend compatible S3 avec chiffrement côté client AES-256-GCM, de sorte que la couche de stockage distribué gère la durabilité tandis que la couche applicative protège le contenu des fichiers de chaque niveau intermédiaire.

Essayez-le sur https://hexatransfer.com — gratuit, sans compte, 10 Go maximum.