Vorstellung von DeepSeeks verteiltem Dateisystem 3FS

 (maknee.github.io)
20 Punkte von GN⁺ 2025-04-18 | 2 Kommentare | Auf WhatsApp teilen
  • 3FS ist ein von DeepSeek entwickeltes leistungsstarkes Open-Source-Distributed-File-System und unterstützt groß angelegte Datenverarbeitung sowie hohen Durchsatz
  • Es verhält sich wie ein gewöhnliches Dateisystem, speichert Daten tatsächlich aber verteilt über mehrere Maschinen und bietet eine Abstraktionsschicht, sodass Nutzer sich dessen nicht bewusst sein müssen
  • Über vier zentrale Komponenten (Meta, Mgmtd, Storage, Client) werden Metadatenverwaltung, Knotenmanagement, tatsächliche Datenspeicherung und die Verarbeitung von Nutzeranfragen getrennt betrieben
  • Mit dem CRAQ-Algorithmus werden starke Konsistenz und Fehlertoleranz erreicht, wobei Schreibanfragen in einer Kettenstruktur sicher weitergegeben werden
  • 3FS hebt sich im Vergleich zu anderen verteilten Dateisystemen durch praktische Einsetzbarkeit und skalierbare Performance ab

Was ist 3FS?

  • 3FS steht für Fire-Flyer File System und ist ein von DeepSeek veröffentlichtes verteiltes Dateisystem
  • Es wurde zusammen mit DeepSeeks Open-Source-Veröffentlichungswoche herausgegeben
  • Es sieht wie ein gewöhnlicher Dateipfad aus, abstrahiert in Wirklichkeit aber Daten, die über mehrere Maschinen verteilt gespeichert sind

Was ist ein verteiltes Dateisystem?

  • Für Nutzer sieht es wie ein lokales Dateisystem aus, tatsächlich werden die Daten jedoch auf mehrere Server verteilt gespeichert
  • Beispiel: Der Pfad /3fs/stage/notes.txt wirkt wie eine einzelne Datei, ist in Wirklichkeit aber über mehrere Server verteilt gespeichert
  • Nutzer können es mit Befehlen wie mkdir oder cat wie eine normale Datei verwenden

Warum verwendet man ein verteiltes Dateisystem?

  • Unterstützung für große Datenmengen (im Petabyte-Bereich) und hohen Durchsatz
  • Gewährleistet Stabilität durch Fehlertoleranz (fault tolerance) und Redundanz (redundancy)
  • Praktische Einsatzbeispiele:
    • Parallele Verarbeitungs-Frameworks wie HDFS + Spark
    • Checkpointing in ML-Trainingspipelines
    • Googles Colossus
    • Metas Fotospeicher Haystack
    • Storage für KI, z. B. JuiceFS vs CephFS

Komponenten von 3FS

  • Es besteht insgesamt aus vier zentralen Knotentypen

Meta

  • Verwaltet Metadaten wie Dateipfade, Attribute und Speicherorte
  • Verarbeitet Client-Anfragen per RPC (open, stat, close usw.)
  • Metainformationen werden in FoundationDB gespeichert
  • Inode speichert Informationen wie Dateigröße und Besitzer
  • DirEntry verknüpft Pfad und Inode (wie bei symbolischen Links können mehrere Pfade auf dieselbe Datei verweisen)

Mgmtd

  • Zuständig für Knotenregistrierung und Statusprüfung im Cluster
  • Knoten registrieren sich beim Booten selbst und senden regelmäßig Heartbeats
  • Übernimmt die Rolle eines zentralen Routers, sodass Knoten keine direkten Verbindungen untereinander aufrechterhalten müssen
  • Verwaltet auch Konfigurationsinformationen für den Aufbau der CRAQ-Kette

Storage

  • Zuständig für die tatsächliche Datenspeicherung
  • Verwaltet Festplattenblöcke über die Rust-basierte ChunkEngine
    • Verfolgt Größe, Offset, Checksumme, Version usw. der Festplattenblöcke
    • Nutzer interagieren nicht direkt mit den Blöcken; stattdessen wird eine Schnittstelle bereitgestellt
    • Metadaten werden in LevelDB gespeichert
  • Es gibt verschiedene Worker
    • AllocateWorker weist neue Blöcke zu
    • PunchHoleWorker räumt ungenutzte Blöcke auf
    • AioReadWorker verarbeitet asynchrone Lesevorgänge über die io_uring-Queue
  • Bei Schreibvorgängen wird entlang der CRAQ-Kette an den nächsten Knoten weitergeleitet

Client

  • Verarbeitet Nutzeranfragen und kommuniziert mit anderen Knoten
  • Ablauf:
    • Abfrage der Knotenpositionen bei Mgmtd
    • Anforderung von Dateioperationen bei Meta
    • Datentransfer mit Storage

CRAQ-Algorithmus

  • Steht für Chain Replication with Apportioned Queries und bietet starke Konsistenz (Linearizability)
  • Schreibablauf:
    • Weitergabe des Schreibvorgangs in der Reihenfolge Head → Middle → Tail
    • In den Zwischenstufen werden Daten als dirty markiert (nicht lesbar)
    • Nach dem Commit am Tail wird der Status rückwärts als clean propagiert
  • Leseablauf:
    • Wenn clean, sofortige Rückgabe
    • Wenn dirty, Anfrage an den Tail, um die neuesten Daten abzurufen

CRAQ aus Performance-Sicht

  • Die Schreibgeschwindigkeit ist durch den langsamsten Knoten begrenzt
  • Bei häufig abgefragten dirty-Daten können sich Leseanfragen auf den Tail konzentrieren, wodurch ein Lese-Bottleneck entstehen kann
  • Beispiel: Performance-Einbruch bei Zipfian workload
  • In einem Cluster mit fünf Knoten wird auf drei repliziert, um Leistungsverluste bei Ausfällen zu minimieren

Unterschiede zu anderen verteilten Dateisystemen

  • Die Grundstruktur ist ähnlich, aber es gibt Unterschiede bei Praxistauglichkeit und Implementierungsansatz
  • Vergleichspunkte:
    • Für welche Workloads es Stärken hat
    • Flexibilität bei der Performance-Abstimmung
    • Einfachheit der Bereitstellung
    • Skalierbarkeit des Durchsatzes
    • Latenzverwaltung innerhalb von SLOs
    • Zuverlässigkeit
  • Detaillierte technische Aspekte:
    • Ursachen von Bottlenecks und deren Behandlung
    • Vorhandensein oder Fehlen von Locks
    • Verwendete Datenstrukturen
    • Zielhardware
    • Verwendete Fehlertoleranz-Algorithmen oder Fehlerkorrekturverfahren

Nächstes Thema der Blogserie

  • Geplant ist, DeepSeeks Aussagen durch eine Analyse der tatsächlichen Performance zu überprüfen
  • Prüfpunkte:
    • DeepSeeks Behauptung zu FUSE-Bottlenecks
    • Reproduzierbarkeit der Performance-Grafiken
    • Analyse von Situationen mit Performance-Abfall
    • Bottleneck-Faktoren (CPU, Speicher, Festplatte, Netzwerk)
    • Bei welchen Workloads die Performance besonders gut ist
    • Vergleichsanalyse mit bestehenden Systemen
    • Unterschiede zu den Lösungsansätzen bestehender Systeme
    • Prüfung direkter Verbesserungsmöglichkeiten

Weiterführende Materialien

Verwandte Beiträge

2 Kommentare

 
softer 2025-04-19

Das war genau das Problem, über das ich auch nachgedacht habe, und das ...
 
GN⁺ 2025-04-18
Hacker-News-Kommentare

  • S3FS ist ein skalierbares Metadaten-Dateisystem und wird mit verschiedenen verteilten Dateisystemen verglichen

    • Dazu gehören Collosus, Tectonic (Meta), ADLSv2 (Microsoft), HopsFS (Hopsworks) und PolarFS (Alibaba)
    • S3FS verwendet FoundationDB, Collosus BigTable, Tectonic einen KV-Store und HopsFS RonDB
    • Wichtig an S3FS ist, dass es (1) einen FUSE-Client unterstützt und dadurch bequem nutzbar ist und (2) NVMe-Storage unterstützt, sodass es nicht durch Disk-I/O ausgebremst wird
    • HopsFS ergänzt hierarchischen Storage, sodass aktuelle Daten auf NVMe und archivierte Daten auf S3 gespeichert werden

  • Bei der Bewertung dieser Systeme sollten theoretische Grenzen, Effizienz und praktische Grenzen berücksichtigt werden

    • Theoretisch können parallele verteilte Dateisysteme wie Lustre unbegrenzt skalieren
    • Um die Effizienz zu bewerten, wird berechnet, wie viel Storage und Durchsatz sich mit Nodes mit X TiB Festplatten erzielen lassen
    • Im Vergleich zu FSx for Lustre lässt sich 3FS auf AWS 12–30 % günstiger betreiben
    • Es bleibt die Frage, ob sich ein Dateisystem in der Größe, die die Leute bereitstellen wollen, tatsächlich aufbauen lässt
    • Es ist nachvollziehbar, dass DeepSeek solche Systeme baut, um intern die gewünschten Eigenschaften zu erhalten
    • Bei Archil hofft man darauf, bessere Defaults zu finden, die die meisten Menschen nutzen können, ohne riesige Cluster verwalten zu müssen

  • Es besteht Interesse an einem Vergleich mit SeaweedFS

    • SeaweedFS wird zum Speichern von Wetterdaten verwendet; rund 3 PB Daten werden für ML-Training genutzt

  • Frage, warum nicht CephFS verwendet wird

    • CephFS wurde in realen Szenarien gründlich getestet und hat seine Zuverlässigkeit auch im Petabyte-Maßstab bewiesen
    • Als Open-Source-Lösung kann es auf den schnellsten NVMe-Storage-Systemen laufen und mit Interconnects über 10 Gigabit sehr hohe IOPS erreichen

  • Frage nach einem Vergleich mit JuiceFS

    • Es ist geplant, JuiceFS in einem persönlichen Homelab-Setup auf S3 Garage zu betreiben
    • Garage unterstützt nur Replikation, aber kein Erasure Coding oder Sharding
    • Die Wahl fiel darauf, weil das Setup einfach aussieht

  • Als kleiner Anbieter oder Homelab-Nutzer wird man vermutlich nie ein großes verteiltes Dateisystem einsetzen

    • Bei Daten im Petabyte-Maßstab besteht Neugier, wie Backup und Wiederherstellung funktionieren

  • Das Setup ist komplex, aber es ist nicht klar, welche Funktionen für Deep-Learning-Workloads zwingend notwendig sind

    • Benötigt werden Storage im Petabyte-Maßstab, Lese-/Schreib-Parallelität und Redundanz
    • Konsistenz ist schwer zu erreichen und hier offenbar nicht erforderlich

  • Frage, wie einfach sich DeepSeeks verteiltes Dateisystem deaktivieren lässt

    • Zum Beispiel könnte eine US-Universität die Nutzung von DeepSeek für Forschung genehmigt haben, müsste aber sicherstellen, dass Daten das lokale Forschungscluster-Dateisystem nicht verlassen

  • Frage, ob sich das mit über mehrere Geräte verteilten ZFS-Laufwerken nachbilden lässt