Garage – hochzuverlässiger S3-Objektspeicher, der auch außerhalb von Rechenzentren betrieben werden kann
(garagehq.deuxfleurs.fr)- Garage ist ein S3-kompatibler Objektspeicher, der auch in Umgebungen außerhalb von Rechenzentren zuverlässig betrieben werden kann
- Wird als einzelne Binärdatei ohne Abhängigkeiten bereitgestellt und lässt sich auf allen Linux-Distributionen einfach ausführen
- Daten werden über 3 Zonen (zones) repliziert, um hohe Redundanz und Fehlertoleranz zu gewährleisten
- Implementiert die Amazon S3 API und ist damit mit zahlreichen Anwendungen wie Nextcloud, Matrix und Mastodon kompatibel
- Niedrige Hardwareanforderungen und ein auf offener Forschung basierendes Design verbessern die Zugänglichkeit verteilter Systeme
Überblick
- Garage ist ein S3-Objektspeicher, der auch außerhalb von Rechenzentren stabil betrieben werden kann, und kann über das Internet verteilt über mehrere Rechenzentren hinweg laufen
- Eignet sich für verschiedenste Einsatzzwecke wie Website-Hosting, Medienspeicherung und Backup-Ziele
Designziele
- Ein System, das mit Fokus auf Leichtgewichtigkeit und Effizienz entwickelt wurde
- Wird als einzelne ausführbare Datei ohne Abhängigkeiten ausgeliefert und läuft auf allen Linux-Distributionen
- Administratorfreundlich konzipiert, um schnelle Bereitstellung und sicheren Betrieb zu ermöglichen
- So entworfen, dass es in jeder Umgebung bereitgestellt werden kann, auch über mehrere Rechenzentren im Internet hinweg ohne dediziertes Backbone-Netz
- Hohe Resilienz gegenüber Netzwerkausfällen, Latenz, Festplattenfehlern und Bedienfehlern
Mindestanforderungen
- CPU: x86_64, ARMv7 oder ARMv8 aus den letzten 10 Jahren
- RAM: 1 GB
- Speicherplatz: mindestens 16 GB
- Netzwerk: Latenz unter 200 ms, Bandbreite über 50 Mbps
- Unterstützung für heterogene Hardware, sodass sich Cluster auch mit gebrauchter Ausrüstung aufbauen lassen
Datenresilienz und Kompatibilität
- Jeder Datenblock (chunk) wird repliziert und in 3 Zonen gespeichert
- Implementiert die Amazon S3 API und ist dadurch sofort mit bestehenden Anwendungen kompatibel
- Unterstützte Beispiele: Nextcloud, Matrix, Cyberduck, Mastodon, Rclone, PeerTube
Technische Grundlage
- Garage wurde auf Basis aktueller Forschungsergebnisse zu verteilten Systemen entwickelt
- Amazons Key-Value-Store Dynamo
- Conflict-Free Replicated Data Types (CRDTs)
- Der Software-Netzwerk-Load-Balancer Maglev
Sponsoring und Finanzierung
- Das Garage-Projekt hat mehrfach öffentliche Fördermittel erhalten
- 2021–2022: NGI POINTER – Finanzierung von 3 Vollzeitmitarbeitenden für 1 Jahr
- 2023–2024: NLnet / NGI0 Entrust – Finanzierung von 1 Vollzeitmitarbeitenden für 1 Jahr
- 2025: NLnet / NGI0 Commons Fund – Finanzierung von 1,5 Vollzeitmitarbeitenden für 1 Jahr
- Finanzielle Unterstützung durch das EU-Forschungs- und Innovationsprogramm Horizon 2021 sowie das Programm Next Generation Internet
- Zusätzliche Förderung oder Beteiligung über Support-Verträge möglich (Kontakt: garagehq@deuxfleurs.fr)
1 Kommentare
Hacker-News-Kommentare
Garage wurde kürzlich in internen Tests recht umfassend evaluiert
Die Bereitstellung war etwas einfacher als bei MinIO, bei der Spitzenleistung lag es aber zurück
In einer 25G-NIC-Umgebung erreichte MinIO 20–25 Gbit/s, während Garage bei etwa 5 Gbit/s gedeckelt war
Es wirkt nicht so, als ziele Garage auf solche High-Performance-Anwendungsfälle ab
Als Nächstes sollen auch RustFS und Ceph/Rook mit geprüft werden
Wegen der jüngsten Entwicklung bei MinIO scheint man sich am Ende nach anderen Alternativen umsehen zu müssen
Die Philosophie lautet: „Hohe Performance schränkt Design und Infrastruktur ein, daher streben wir Performance durch Minimalismus an“
(Dokument zu den Designzielen)
Interessant ist aber, wo genau der Performance-Flaschenhals entsteht. Möglicherweise verarbeitet es weniger parallel als MinIO
Die Komplexität ist sehr hoch, und ohne tiefes Verständnis ist eine Wiederherstellung schwierig, wenn der Cluster beschädigt ist
Für lokale Entwicklung wirkt es wie ein interessantes Projekt
Beim Blick in den Leitfaden für Produktions-Setups wird einem aber etwas mulmig
Da Garage beim Speichern von Metadaten keine eigenen Prüfsummen und Integritätsprüfungen durchführt, werden Dateisysteme wie BTRFS oder ZFS empfohlen
Die Standard-Engine LMDB birgt bei unsauberem Shutdown ein Risiko von Datenkorruption, daher sind regelmäßige Snapshots nötig
Auch SQLite ist möglich, aber es war überraschend, dass die Standard-DB gegenüber Stromausfällen anfällig ist
Dann würde man ihn sofort in Garage integrieren
Dass Garage mindestens 1 GB RAM benötigt, wurde als etwas belastend empfunden
Empfohlen werden NVMe-Laufwerke mit PLP (Power Loss Protection) oder eine USV
Seit der MinIO-Sache wird ein starker Anstieg der Garage-Adoption beobachtet
Der Benchmark-Vergleich von Repoflow war hilfreich
RustFS wirkte ebenfalls interessant, wurde aber aus nichttechnischen Gründen ausgeschlossen
Falls jemand Tipps für den Ersatz von MinIO hat, wären diese willkommen
Siehe GitHub-Link
Ein Vergleich mit dem Ceph S3 Gateway wäre auch interessant
Die offizielle Website von Deuxfleurs hat das schönste Design, das ich je auf einer Website gesehen habe
Garage wird für lokale Entwicklung und Tests genutzt
Zusammen mit s5cmd lassen sich 15 GB und mehr als 60.000 Objekte in unter 60 Sekunden seeden
Per Docker ist eine Staging-Umgebung inklusive API, DB, Cache und Objekt-Containern in unter 2 Minuten reproduziert
Die Konfiguration ist sehr einfach und läuft stabil
Zuvor wurde LocalStack S3 genutzt, aber fehlende Persistenz war ein Problem, und MinIO OSS wird ebenfalls nicht mehr gepflegt
SeaweedFS und RustFS wurden auch geprüft, aber Garage war am einfachsten
Garage machte im Testcode und in Benchmarks einen sehr beeindruckenden Eindruck
Die Bereitstellung ist mit einer einzelnen Binärdatei einfach, und die Dokumentation ist gut
Das Fehlen von Object-Tagging war jedoch ein großer Nachteil
In der Welt der Cloud-APIs sind Tags eine Grundfunktion, daher wäre hier eine Verbesserung wünschenswert
Ich mag Garage wirklich sehr
Es ist mehr als nur eine einfache S3-Alternative und auch in hyperkonvergenten Architekturen nützlich
Die Struktur, Daten zuerst lokal zu lesen und das Netzwerk nur bei Bedarf zu nutzen, ist elegant
Dass es kein Erasure Coding gibt, ist ein Nachteil bei Fehlertoleranz und Effizienz
Die zentrale Sorge war, wie die Wiederherstellung bei Hardware-Ausfällen abläuft
In Data-Engineering-Skripten war Garage nützlich
Da die meisten Tools S3-Integration unterstützen, kann man Daten in Garage dumpen und später leicht in die Cloud skalieren
Garage wurde kürzlich getestet
Nach dem Upload von etwa 300 Dokumenten (1 GB) und einem anschließenden Löschversuch crashte der S3-Dienst im Container und musste neu gestartet werden
Ein tolles Projekt, aber nach dieser Erfahrung ist die Zuverlässigkeit noch nicht ausreichend