RustFS/S3-Objektspeicher und ZFS
haben unterschiedliche Anwendungsfälle.
Wenn man sie kombiniert – zum Beispiel mit einer bidirektionalen Synchronisation zwischen SMB- und S3-Freigaben unter Berücksichtigung der SMB-Ordner-ACL-Vererbung –,
ist das Ergebnis weit mehr als die bloße Summe der einzelnen Funktionen-
ein idealer SMB und Internet File/Backup/Cloud Server gleichzeitig
RustFS-Betriebsmodi
- Einzelknoten (Single Node), Einzeldatenträger (Single Disk)
- Einzelknoten (Single Node), Mehrfachdatenträger (RustFS Software-RAID)
- Mehrknoten-System (HA-Cluster), jeweils mit Einzel- oder Mehrfachdatenträgern
RustFS auf ZFS – Meine Zusammenfassung
Der
RustFS-Einzeldatenträgermodus auf einem ZFS-Pool ist dem nativen RustFS-Software-RAID / Multi-Disk-Erasure-Coding in jeder Hinsicht überlegen:
- Prüfsummen: Block-Ebene inkl. Selbstreparatur (Self-Healing) vs. reine Objekt-Ebene.
- Snapshots: Copy-on-Write (COW) nahezu ohne Performance-Verlust vs. Versionierung pro Objekt mit realen Speicher-Zusatzkosten.
- Caching: Hybrides Tiering über ARC/L2ARC/SLOG vs. einfacher Page-Cache des Betriebssystems.
- CPU-Effizienz: Kein redundanter Reed-Solomon-CPU-Overhead für Ausfallsicherheit, die ZFS ohnehin schon bereitstellt.
Hinweis: „Einzeldatenträger“ bedeutet hier ein einzelnes RustFS-Ziel (Target). Der darunterliegende ZFS-Pool selbst kann als Mirror, RAIDZ, dRAID oder in naher Zukunft AnyRAID über mehrere physische Festplatten verteilt sein – es wird also keinerlei physische Redundanz aufgegeben.
Das gilt selbst für große
Multi-Node-Deployments:
Verteiltes Erasure Coding über mehrere Knoten hinweg bleibt zwar das richtige Werkzeug für die Toleranz kompletter Knotenausfälle (ohne Replikations-Lag), für eine zusammenhängende Namespace-Kapazität über die Grenzen eines Knotens hinaus und für eine höhere Gesamt-Durchsatzleistung. Dennoch sollte der lokale Speicher jedes einzelnen Knotens weiterhin ein
ZFS-redundanter Pool sein und nicht aus nativen, von RustFS verwalteten Rohdatenplatten (
Raw Disks) bestehen. Lokale Festplattenfehler werden so von ZFS abgefangen, bevor sie überhaupt die distributed EC-Schicht erreichen – und das völlig ohne Nachteile.
Das Ideal:
- RustFS Single-Node / Single-Target auf ZFS
- Ergänzt durch RustFS Bucket-/Site-Replikation für die Ausfallsicherheit über Knoten und Standorte hinweg.
Für kleine bis mittlere Setups ist das bereits die vollständige Lösung. Für große Setups bleibt es das gleiche Muster pro Knoten – mit einer darübergelegten distributed EC-Schicht nur dann, wenn die Anforderungen an Knotenanzahl, Durchsatz oder Namespace-Größe dies tatsächlich erfordern.
Offener Wunsch (aktuell noch nicht realisiert, issue steht auf todo/accepted bei RustFS)
Die Bereitstellung von
ZFS-Snapshots des RustFS-Datenverzeichnisses als schreibgeschützte S3-Objektversionen nativ in RustFS.
Dies ist heute noch nicht implementiert – RustFS müsste dafür aktiv mit dem Verzeichnis .zfs/snapshot/ interagieren und dieses mit seiner eigenen Objekt-Metadatenbank abgleichen. Das ist ein echter Funktionswunsch (
Feature Request) an das Projekt und keine bloße Konfigurationsoption. Bis dahin bleiben die zwei Mechanismen getrennt, aber komplementär:
- ZFS-Snapshot: Für die Point-in-Time-Gesamtwiederherstellung des Speichers.
- RustFS-eigene Objekt-Versionierung: Für die granulare Historie einzelner Objekte.
Die einzige verbleibende Ausnahme
Hosts ohne ZFS-Unterstützung. Wenn der OpenZFS-Support auf Windows/macOS die Produktionsreife erreicht, könnte diese Ausnahme schrumpfen oder komplett verschwinden. Es lohnt sich, den aktuellen Status zu prüfen, bevor man darauf bei spezifischen Windows-Pools oder macOS-Hosts baut. OpenZFS ist für macOS bereits veröffentlicht und steht auf Windows kurz vor einem release-fähigen RC.
Fazit: Genau so integriere ich es in mein napp-it cs Einzelserver- bzw. Cluster-Management-Tool für S3, Storage Spaces und ZFS.
