Présentation de 3FS, le système de fichiers distribué de DeepSeek

 (maknee.github.io)
20 points par GN⁺ 2025-04-18 | 2 commentaires | Partager sur WhatsApp
  • 3FS est un système de fichiers distribué open source haute performance développé par DeepSeek, conçu pour le traitement de données à grande échelle et un débit élevé
  • Il se comporte comme un système de fichiers classique, mais stocke en réalité les données de façon distribuée sur plusieurs machines, avec une couche d’abstraction transparente pour l’utilisateur
  • Il repose sur 4 composants principaux (Meta, Mgmtd, Storage, Client) qui séparent la gestion des métadonnées, la gestion des nœuds, le stockage effectif des données et le traitement des requêtes utilisateur
  • Grâce à l’algorithme CRAQ, il atteint une forte cohérence et une tolérance aux pannes, en propageant de manière sûre les requêtes d’écriture dans une structure en chaîne
  • 3FS se distingue des autres systèmes de fichiers distribués par sa praticabilité réelle et sa scalabilité des performances

Qu’est-ce que 3FS ?

  • 3FS signifie Fire-Flyer File System, un système de fichiers distribué publié par DeepSeek
  • Il a été lancé pendant la semaine de publication open source de DeepSeek
  • Il ressemble à un chemin de fichier classique, mais fournit en réalité une abstraction de données réparties sur plusieurs machines

Qu’est-ce qu’un système de fichiers distribué ?

  • Pour l’utilisateur, il ressemble à un système de fichiers local, mais les données sont en réalité réparties sur plusieurs serveurs
  • Exemple : le chemin /3fs/stage/notes.txt semble être un seul fichier, alors qu’il est en fait réparti sur plusieurs serveurs
  • L’utilisateur peut s’en servir comme d’un fichier ordinaire avec des commandes comme mkdir ou cat

Pourquoi utiliser un système de fichiers distribué ?

  • Il prend en charge de très gros volumes de données (à l’échelle du pétaoctet) et un débit élevé
  • Il garantit la stabilité grâce à la tolérance aux pannes (fault tolerance) et à la redondance
  • Exemples d’usage concrets :
    • des frameworks de traitement parallèle comme HDFS + Spark
    • le checkpointing dans les pipelines d’entraînement ML
    • Colossus de Google
    • Haystack, le stockage photo de Meta
    • des exemples de stockage pour l’IA : JuiceFS vs CephFS

Composants de 3FS

  • Le système est composé de 4 types de nœuds principaux

Meta

  • Gère les métadonnées comme les chemins de fichiers, les attributs et les emplacements
  • Traite les requêtes client via RPC (open, stat, close, etc.)
  • Les métadonnées sont stockées dans FoundationDB
  • Inode stocke des informations comme la taille du fichier ou son propriétaire
  • DirEntry relie un chemin à un inode (comme avec un lien symbolique, plusieurs chemins peuvent donc exister pour un même fichier)

Mgmtd

  • S’occupe de l’enregistrement des nœuds du cluster et du suivi de leur état
  • Au démarrage, les nœuds s’enregistrent eux-mêmes puis envoient périodiquement des heartbeats
  • Joue un rôle de routeur central, ce qui évite d’avoir à maintenir directement des connexions entre tous les nœuds
  • Gère aussi les informations de configuration nécessaires à la constitution des chaînes CRAQ

Storage

  • Assure le stockage effectif des données
  • Gère les blocs disque via ChunkEngine, basé sur Rust
    • Suit la taille, l’offset, le checksum, la version, etc. des blocs disque
    • Fournit une interface sans que l’utilisateur interagisse directement avec les blocs
    • Les métadonnées sont stockées dans LevelDB
  • Plusieurs workers spécialisés sont présents
    • AllocateWorker alloue de nouveaux blocs
    • PunchHoleWorker récupère les blocs inutilisés
    • AioReadWorker gère les lectures asynchrones via la file io_uring
  • Lors d’une écriture, les données sont transmises au nœud suivant le long de la chaîne CRAQ

Client

  • Traite les requêtes utilisateur et communique avec les autres nœuds
  • Flux de travail :
    • interrogation de Mgmtd pour connaître l’emplacement des nœuds
    • requêtes d’opérations sur les fichiers vers Meta
    • transfert des données avec Storage

Algorithme CRAQ

  • Acronyme de Chain Replication with Apportioned Queries, il fournit une forte cohérence (linearizability)
  • Flux d’écriture :
    • propagation de l’écriture dans l’ordre Head → Middle → Tail
    • aux étapes intermédiaires, les données sont marquées dirty (lecture impossible)
    • après commit au niveau du Tail, l’état clean est propagé en sens inverse
  • Flux de lecture :
    • si l’état est clean, la donnée est renvoyée immédiatement
    • si l’état est dirty, une requête est envoyée au tail pour récupérer la donnée la plus récente

CRAQ du point de vue des performances

  • La vitesse d’écriture est limitée par le nœud le plus lent
  • Les données dirty fréquemment consultées peuvent concentrer les lectures sur le tail, ce qui peut créer un goulot d’étranglement en lecture
  • Exemple : baisse de performances avec une charge de travail zipfienne
  • Dans un cluster de 5 nœuds, une réplication sur 3 nœuds permet de limiter la perte de performances en cas de panne

Différences avec les autres systèmes de fichiers distribués

  • L’architecture est similaire, mais 3FS se distingue par son applicabilité dans le monde réel et ses choix d’implémentation
  • Éléments de comparaison :
    • les workloads pour lesquels il est particulièrement adapté
    • la flexibilité du réglage des performances
    • la facilité de déploiement
    • la scalabilité du débit
    • la gestion de la latence dans le respect des SLO
    • la fiabilité
  • Détails techniques à observer :
    • les causes des goulots d’étranglement et leur traitement
    • la présence ou non de verrous
    • les structures de données utilisées
    • le matériel cible
    • l’algorithme de tolérance aux pannes ou la méthode de correction d’erreurs utilisés

Prochain sujet de la série d’articles

  • L’auteur prévoit de vérifier les affirmations de DeepSeek à travers une analyse des performances réelles
  • Points examinés :
    • les affirmations de DeepSeek sur les goulots d’étranglement de FUSE
    • la possibilité de reproduire les graphiques de performances
    • l’analyse des situations de dégradation des performances
    • les éléments de goulot d’étranglement (CPU, mémoire, disque, réseau)
    • les workloads dans lesquels les performances sont bonnes
    • la comparaison avec les systèmes existants
    • la différence avec les approches de résolution de problèmes des systèmes existants
    • l’examen de possibilités d’amélioration directe

Ressources supplémentaires

À lire aussi

2 commentaires

 
softer 2025-04-19

C’était justement le genre de problème sur lequel je réfléchissais, et ça...
 
GN⁺ 2025-04-18
Avis Hacker News

  • S3FS est un système de fichiers de métadonnées évolutif, comparé à divers systèmes de fichiers distribués

    • On peut citer Collosus, Tectonic (Meta), ADLSv2 (Microsoft), HopsFS (Hopsworks) et PolarFS (Alibaba)
    • S3FS utilise FoundationDB, Collosus utilise BigTable, Tectonic un KV store, et HopsFS utilise RonDB
    • Les points importants de S3FS sont (1) la prise en charge d’un client FUSE, ce qui le rend pratique à utiliser, et (2) la prise en charge du stockage NVMe, ce qui évite d’être limité par les E/S disque
    • HopsFS ajoute un stockage hiérarchisé, avec les données récentes sur NVMe et les données archivées sur S3

  • Lors de l’évaluation de ces systèmes, il faut prendre en compte les limites théoriques, l’efficacité et les limites pratiques

    • En théorie, les systèmes de fichiers distribués parallèles comme Lustre peuvent passer à l’échelle indéfiniment
    • Pour évaluer l’efficacité, on calcule combien de stockage et de débit on peut obtenir avec des nœuds disposant de disques de X TiB
    • Par rapport à FSx for Lustre, il est possible d’exploiter 3FS sur AWS à un coût inférieur de 12 à 30 %
    • La question reste ouverte de savoir s’il est réellement possible de configurer le système de fichiers à l’échelle de déploiement voulue par les utilisateurs
    • Il est compréhensible que DeepSeek construise ce type de système afin d’obtenir en interne les propriétés qu’il recherche
    • Chez Archil, on espère trouver une meilleure configuration par défaut que la plupart des gens pourront utiliser sans avoir à gérer d’énormes clusters

  • Il y a un intérêt pour une comparaison avec SeaweedFS

    • SeaweedFS est utilisé pour stocker des données météo, avec environ 3 PB de données utilisées pour l’entraînement ML

  • Question sur les raisons de ne pas utiliser CephFS

    • CephFS a été rigoureusement testé dans des scénarios réels et a prouvé sa fiabilité à l’échelle du pétaoctet
    • En tant que solution open source, il peut fonctionner sur les stockages NVMe les plus rapides et atteindre un très haut niveau d’IOPS avec des interconnexions supérieures à 10 gigabits

  • Question sur une comparaison avec JuiceFS

    • Il est prévu d’exécuter JuiceFS au-dessus de S3 Garage dans une configuration homelab personnelle
    • Garage ne prend en charge que la réplication, pas l’erasure coding ni le sharding
    • Ce choix a été fait parce que la configuration semble simple

  • En tant que petit acteur ou utilisateur de homelab, il semble peu probable d’avoir un jour besoin d’un système de fichiers distribué à grande échelle

    • Il y a des interrogations sur la sauvegarde et la restauration lorsqu’on manipule des données à l’échelle du pétaoctet

  • La configuration semble complexe, mais il n’est pas clair quelles fonctionnalités sont réellement indispensables pour des workloads de deep learning

    • Les fonctionnalités nécessaires sont un stockage à l’échelle du pétaoctet, le parallélisme en lecture/écriture et la redondance
    • La cohérence est difficile à obtenir, et elle ne semble pas nécessaire ici

  • Question sur la facilité avec laquelle le système de fichiers distribué de DeepSeek peut être désactivé

    • Par exemple, une université américaine pourrait être autorisée à utiliser DeepSeek pour la recherche, tout en exigeant que les données ne quittent pas le système de fichiers du cluster de recherche local

  • Question sur la possibilité de reproduire cela avec des disques ZFS répartis sur plusieurs machines