4 Punkte von GN⁺ 2025-12-20 | 1 Kommentare | Auf WhatsApp teilen
  • 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

 
GN⁺ 2025-12-20
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

    • Garage zielt offiziell nicht auf maximale Performance ab
      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
    • Wenn nur S3 gebraucht wird, wird Rook nicht empfohlen
      Die Komplexität ist sehr hoch, und ohne tiefes Verständnis ist eine Wiederherstellung schwierig, wenn der Cluster beschädigt ist
    • Es wird vorgeschlagen, SeaweedFS ebenfalls in die Testliste aufzunehmen
  • 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

    • Es wird nach einem eingebetteten KV-Store gefragt, der Transaktionen, hohe Geschwindigkeit, Rust-Bindings sowie eingebaute Prüfsummen und Integritätsprüfungen bietet
      Dann würde man ihn sofort in Garage integrieren
    • Für lokale Entwicklung wurde bisher MinIO verwendet, aber diese Version wird inzwischen nicht mehr gepflegt
      Dass Garage mindestens 1 GB RAM benötigt, wurde als etwas belastend empfunden
    • Das Problem von Datenkorruption bei Stromausfällen lässt sich per Software nur schwer vollständig lösen
      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

    • Nicht selbst genutzt, aber Versity S3 Gateway wirkt ebenfalls vielversprechend
      Siehe GitHub-Link
      Ein Vergleich mit dem Ceph S3 Gateway wäre auch interessant
    • Es wurde gefragt, warum RustFS ausgeschlossen wurde
    • Aus früheren Diskussionen und Berufserfahrung heraus wirkt Garage wie eine stabile Alternative
    • In Benchmarks zeigte auch SeaweedFS gute Leistung
  • Die offizielle Website von Deuxfleurs hat das schönste Design, das ich je auf einer Website gesehen habe

    • Künstlerisch hervorragend, aber bei Lesbarkeit und Barrierefreiheit eher schwach
  • 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

    • Das Entwicklerteam antwortete, dass es das Feedback dankbar aufnimmt
  • 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

    • Es wurde gefragt, mit welchem Setup es genutzt wird
  • Dass es kein Erasure Coding gibt, ist ein Nachteil bei Fehlertoleranz und Effizienz

    • Es sollte in einer LTO-Tape-Library eingesetzt werden, aber dass nur replikationsbasierte Fehlertoleranz geboten wird, war bedenklich
      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