Wie AWS S3 auf langsamen HDDs 1 Petabyte pro Sekunde verarbeitet

 (bigdata.2minutestreaming.com)
19 Punkte von GN⁺ 2025-09-27 | 2 Kommentare | Auf WhatsApp teilen
  • AWS S3 ist ein groß angelegter mandantenfähiger Objektspeicher und bietet hohe Verfügbarkeit und Dauerhaftigkeit zu niedrigen Kosten
  • Es nutzt alte und langsame HDDs (≈120 IOPS), maximiert aber die Wirtschaftlichkeit von extrem günstigen Speichermedien mit hoher Kapazität
  • S3 entwirft seine interne Speicherschicht (ShardStore) als Log-Struktur (LSM), richtet den Schreibpfad auf sequentielles I/O aus und gleicht Leistungsprobleme im Lesepfad mit Erasure Coding (5-of-9) und massiver Parallelisierung aus
  • Vom Client über das Frontend bis zum Storage reduziert S3 mit Multipart-Uploads, Byte-Range-GETs, Connection Pools und Hedge Requests die Tail-Latenz und addiert den Durchsatz
  • Mit zufälliger Verteilung, Power of Two Random Choices, kontinuierlichem Rebalancing und Dekorrelation, durch die sich Last bei größerem Maßstab glättet, vermeidet S3 Hotspots und erreicht dadurch einen Durchsatz von >1 PB/s

Die Storage-Architektur von AWS S3 im großen Maßstab

  • Fast jeder weiß, was AWS S3 ist, aber nur wenige wissen, in welchem riesigen Maßstab S3 arbeitet und welche Innovationen dafür nötig waren
  • S3 ist ein skalierbarer mandantenfähiger Objektspeicherdienst, über dessen API sich Objekte speichern und abrufen lassen, und der sehr hohe Verfügbarkeit und Dauerhaftigkeit zu relativ geringen Kosten bietet

  • Der Maßstab von S3

    • Speicherung von mehr als 400 Billionen Objekten
    • Verarbeitung von 150 Millionen Anfragen pro Sekunde
    • Unterstützung von mehr als 1 PB/s Traffic in Spitzenzeiten
    • Betrieb von zig Millionen Festplatten
  • Hohe Verfügbarkeit und Dauerhaftigkeit (Designziel „11 nines“) bei relativ niedrigen Kosten werden als Grundlage der Nutzererfahrung gesetzt
    • Das hat sich bis zur zentralen Storage-Schicht für Datenanalytik und Machine-Learning-Data-Lakes ausgeweitet
  • Das Designziel ist, bei kosteneffizientem Betrieb zufällige Zugriffsmuster und massive Gleichzeitigkeit zu bewältigen
    • S3 geht von einem kollektiven Random-Access-Workload aus, bei dem jeder Tenant mit beliebigen Größen und Offsets zugreift

Basistechnologie: Festplatten (HDDs)

  • Die beeindruckende Skalierbarkeit und Performance von S3 basiert auf dem traditionellen Speichermedium HDD
  • HDDs sind eine alte Technologie, die zwar dauerhaft, bei IOPS (Ein-/Ausgaben pro Sekunde) und Latenz aber durch physische Bewegung begrenzt ist
    • Rotation pro Sekunde (z. B. 7200 RPM) und Actuator-Seeking sind als mechanische Bewegung unverzichtbar, daher ist die Latenz strukturell hoch und unvermeidbar
    • Durchschnittliches Halbplatten-Seeking ≈4 ms, durchschnittliche halbe Umdrehung ≈4 ms, Übertragung von 0,5 MB ≈2,5 ms → zufälliges Lesen von 0,5 MB im Mittel ≈11 ms, Random-Durchsatz einer einzelnen Platte ≈45 MB/s
  • Anders als SSDs sichern HDDs durch ihre langfristige Kurve aus mehr Kapazität und sinkenden Preisen weiterhin die Wirtschaftlichkeit von „extrem günstig/großvolumig“ und werden daher weiter für Storage im großen Maßstab eingesetzt
    • Preis: 6 Milliarden Mal günstiger pro Byte (inflationsbereinigt)
    • Kapazität: 7,2 Millionen Mal größer
    • Größe: 5.000 Mal kleiner
    • Gewicht: 1.235 Mal geringer
  • Allerdings stagnieren die IOPS seit 30 Jahren bei etwa 120, und Performance sowie Latenz bei Random Access haben sich kaum verbessert
  • SSDs sind bei Random I/O im Vorteil, bei Speicher im Peta- bis Exabyte-Maßstab aber bei den Gesamtbetriebskosten (TCO) im Nachteil

Für sequentielles I/O optimierter Schreibpfad

  • HDDs sind für sequentiellen Zugriff optimiert; wenn zusammenhängende Bytes gelesen und geschrieben werden, kann die rotierende Platter Daten sehr schnell verarbeiten
  • Log-basierte Datenstrukturen (log-structured) nutzen diese sequentiellen Eigenschaften
    • ShardStore, die interne Speicherschicht von S3, verwendet eine log-strukturierte LSM, um Schreibvorgänge als sequentielle Appends auf die Platte auszuführen
    • Ähnlich lässt sich mit Batch-Verarbeitung der sequentielle Durchsatz von Festplatten maximieren

Parallelisierung und Erasure Coding für den Random-Read-Pfad

  • Beim Lesen sind je nach Nutzeranfrage Sprünge zu beliebigen Positionen nötig und damit die physischen Grenzen direkt spürbar (die mittlere Latenz von Random I/O liegt bei etwa 11 ms)
    • Eine einzelne HDD kann mit Random I/O maximal 45 MB/s verarbeiten
    • Deshalb sind HDDs für die Speicherung großer Datenmengen äußerst kosteneffizient, haben aber schwache Leistung bei zufälligen Zugriffen
  • Um diese physische Grenze zu überwinden, setzt S3 auf massive Parallelisierung, indem es Daten über viele Platten shardet und gleichzeitig liest, um den Gesamtdurchsatz zu addieren
    • Daten werden über unzählige HDDs verteilt gespeichert, und das I/O jeder einzelnen Platte wird parallel genutzt, um den Gesamtdurchsatz stark zu erhöhen
    • Wird etwa eine 1-TB-Datei über 20.000 HDDs verteilt gespeichert, kann der aggregierte Durchsatz der gesamten Festplatten Lesen im TB/s-Bereich ermöglichen

Erasure Coding

  • In Speichersystemen ist garantierte Redundanz unverzichtbar
  • S3 verwendet Erasure Coding (EC), um Daten in K Datenfragmente und M Paritätsfragmente aufzuteilen
    • Von insgesamt K+M Fragmenten reichen beliebige K zur Wiederherstellung
  • S3 nutzt Erasure Coding (5-of-9) mit einer Struktur aus 9 Teilen (5 Datenshards, 4 Paritätsshards) als ausgewogenen Kompromiss
    • 5 Daten + 4 Parität = 9 Fragmente
    • Der Verlust von bis zu 4 Shards kann toleriert werden; mit beliebigen 5 Fragmenten ist das Original wiederherstellbar, was Fehlertoleranz bietet
    • Der Storage-Overhead liegt bei ≈1,8x und ist damit kapazitätseffizienter als dreifache Replikation (3x)
    • Gleichzeitig entstehen 5 parallele Lesepfade, was Shard-Parallelisierung und das Vermeiden von Stragglern begünstigt
  • Damit überwindet S3 diese physische Grenze und bietet Random Access auf große Datenmengen

Struktur der Parallelverarbeitung

  • S3 verwendet drei zentrale Arten der Parallelisierung
    • 1. Nutzer teilen Daten für Upload und Download in mehrere Chunks auf
    • 2. Clients senden gleichzeitige Anfragen an mehrere Frontend-Server
    • 3. Server verteilen Objekte über mehrere Storage-Server

  • 1. Parallelverarbeitung auf Ebene der Frontend-Server

    • Nutzung interner HTTP-Connection-Pools, um gleichzeitig Verbindungen zu mehreren verteilten Endpunkten aufzubauen
    • Verhindert Überlastung einzelner Infrastrukturknoten oder Caches

  • 2. Parallelverarbeitung zwischen Festplatten

    • EC-basiert werden Daten als kleine Shards über mehrere HDDs verteilt gespeichert

  • 3. Parallelverarbeitung von PUT-/GET-Anfragen

    • Clients zerlegen Daten in mehrere Teile und laden sie parallel hoch
    • PUT: Multipart-Uploads maximieren neue Parallelität
    • GET: Unterstützung für Byte-Range-GETs (nur Teilbereiche eines Objekts werden gelesen)
  • Durch verteilte Parallelverarbeitung sind auch Uploads von 1 GB/s ohne Schwierigkeiten erreichbar

Vermeidung von Hotspots

  • S3 arbeitet mit zig Millionen Laufwerken, hunderten Millionen Anfragen pro Sekunde und hunderten Millionen Shards in parallelem Betrieb
  • Wenn sich Last auf einzelne Festplatten oder Knoten konzentriert, droht ein Leistungsabfall des Gesamtsystems
  • Zentrale Strategien dagegen sind:
    • 1. Zufällige Verteilung der Speicherorte
    • 2. Kontinuierliches Rebalancing
    • 3. Wachstum des Gesamtsystems

  • 1. Shuffle Sharding & Power of Two

    • Der anfängliche Speicherort von Daten wird zufällig verteilt
    • Anwendung des Algorithmus Power of Two Random Choices:
      • Wird zwischen zwei zufällig gewählten Knoten der weniger belastete gewählt, ergibt sich wirksames Load Balancing

  • 2. Rebalancing

    • Datentemperatur: Neue Daten sind heißer (werden häufiger abgerufen); diese Eigenschaft wird mit periodischem Rebalancing genutzt, um Platz und I/O neu zu verteilen
      • Je älter Daten werden, desto seltener werden sie abgerufen, wodurch die I/O-Reserven des Gesamtspeichers steigen
    • S3 verteilt kalte Daten neu, um die Nutzung von Speicherplatz und Ressourcen zu maximieren
    • Bei Einführung neuer Racks (z. B. 20 PB/Rack, 1000×20 TB) ist eine aktive Verteilung auf freie Kapazität nötig

  • 3. Chill@Scale

    • Skaleneffekt: Je unabhängiger Workloads sind, desto stärker tritt Dekorrelation auf, wodurch sich Burst-Gleichzeitigkeit verringert und aggregierte Last geglättet wird
    • Je größer das System, desto geringer der Abstand zwischen Peak- und Durchschnittslast und desto besser die Vorhersagbarkeit
    • Das heißt: Auch wenn einzelne Nutzungen zwischen Lastspitzen und Ruhephasen wechseln, gleichen sie sich im großen Maßstab gegenseitig aus und erzeugen eine vorhersehbare Last

Betriebs- und Zuverlässigkeitskultur sowie weitere Techniken

  • Shuffle Sharding auf DNS-Ebene sorgt bereits bei der Namensauflösung für Isolation zwischen Tenants und gleichmäßige Verteilung
  • Software-Rollouts werden wie EC schrittweise und ohne Unterbrechung durchgeführt; auch die Umstellung von ShardStore erfolgte ohne Auswirkungen auf den Dienst
  • Dauerhaftigkeitskultur: Prozessbasierte Zuverlässigkeit durch kontinuierliche Fehlererkennung, chain of custody, Modellierung von Bedrohungen für die Dauerhaftigkeit und formale Verifikation

Warum das wichtig ist: Trends bei Dateninfrastruktur auf Basis von S3

  • Mit der Verbreitung von stateless Architekturen nimmt das Muster zu, dass Application-Nodes zustandslos bleiben und Persistenz, Replikation und Load Balancing an S3 delegieren
    • Beispiele: Kafka Diskless (KIP-1150), SlateDB, Turbopuffer, Lucene on S3, die Integration von Objektspeicher in ClickHouse/OpenSearch/Elastic usw.
  • Vorteile sind elastische Skalierung, vereinfachter Betrieb und geringere Kosten; Nachteil kann höhere Latenz sein, weshalb je nach Workload der Zielkonflikt zwischen Latenz, Kosten und Dauerhaftigkeit entworfen werden muss

Zusammenfassung

  • AWS S3 ist ein mandantenfähiger Storage-Dienst im großen Maßstab, der die Grenzen langsamer Speichermedien mit massiver Parallelität, Load Balancing und Daten-Sharding überwindet
  • Mit Erasure Coding, zufälliger Verteilung, kontinuierlichem Rebalancing und Hedge Requests sichert S3 Stabilität und Performance
  • Anfangs lag der Schwerpunkt auf Backups und Medien, inzwischen hat sich S3 zum Hauptspeicher für Big-Data-Infrastrukturen wie Datenanalyse und Machine Learning entwickelt
  • S3-basierte Architekturen ermöglichen stateless Skalierbarkeit und erlauben es, Probleme rund um Dauerhaftigkeit, Replikation und Load Balancing wirksam an AWS zu delegieren
  • Das bringt auch geringere Cloud-Kosten und höhere Effizienz in der Verwaltung

Verwandte Beiträge

2 Kommentare

 
shakespeares 2025-10-05

Ich glaube, wenn die Technologie nicht gut wäre, würde sich damit kein Gewinn erzielen lassen.
 
GN⁺ 2025-09-27
Hacker-News-Kommentare

  • Es gibt ein paar sachliche Fehler, aber sie beeinflussen den Fluss des Artikels nicht wesentlich. Ein Beispiel ist die Behauptung, S3 verwende ein 5:9-Sharding-Schema; tatsächlich verwendet S3 verschiedene Sharding-Schemata, und soweit ich weiß, ist 5:9 keines davon. Das Verhältnis von 1,8 physischen Bytes pro 1 logischem Byte ist aus Sicht der HDD-Kosten wirklich kein guter Wert. Tatsächlich gibt es Möglichkeiten, dieses Verhältnis weiter zu senken, während die Parallelität steigt und die Verfügbarkeit besser wird. Man muss zum Beispiel überlegen, wie viele Shards verloren gehen können, bevor ein Objekt bei einem Ausfall einer gesamten AZ nicht mehr per GET verfügbar ist

    • Bei Minute 42:20 in diesem YouTube-Video hatte ich es so verstanden, dass S3 dieses Sharding-Schema verwendet. Falls du mehr weißt, würde mich das interessieren

    • Dass sich das Verhältnis von 1,8x senken lässt und gleichzeitig die Verfügbarkeit steigt, wirkt intuitiv schwer nachvollziehbar. Wenn es weniger Replikate gibt, steigt bei einem AZ-Ausfall nicht das Risiko von Datenverlust? Ich dachte, AWS stelle vollständig unabhängige Replikate über 3 AZs bereit. Und die Erklärung, dass man zum Lesen eines einzelnen 16MB-Chunks tatsächlich 4MB von 5 verschiedenen Festplatten lesen muss, damit es schneller ist, finde ich immer noch bemerkenswert

    • VAST Data verwendet ein 146+4-Schema. (Link)

  • Ich habe den Artikel gern gelesen, aber die Antwort auf die Frage im Titel ist zu offensichtlich: Parallelität

    • Normalerweise denke ich kaum in so großem Maßstab über Storage-I/O-Geschwindigkeit nach. Früher habe ich RAID0 verwendet, um Festplatten schneller zu beschreiben, aber das ist lange her. Zuerst dachte ich, es käme ein interessanter Ansatz wie Caching oder Tiering. Erst nach dem Lesen wurde mir klar, dass Parallelität die naheliegende Antwort ist, aber über die Implementierungsdetails von S3 oder die Art der Fehlerkorrektur hatte ich nicht nachgedacht. Das Wort Parallelität ist der Kern, aber die Details lieferten viele Einsichten. Ich vermute, MinIO hat eine ähnliche Skalierungsgeschichte: ebenfalls Parallelität

    • Ich finde, der Titel des Artikels ist etwas irreführend, weil er sich nur auf den Spitzen-Durchsatz von S3 insgesamt konzentriert. Die wirklich interessante Frage ist meiner Meinung nach: „Wie ist ein GET-Durchsatz möglich, der über dem maximalen Durchsatz einer HDD liegt?“ Bei einfacher Replikation könnte man mehrere HDDs für denselben GET parallel ansprechen; aus Sicht von S3 insgesamt würde der Durchsatz steigen, aber letztlich wäre man immer noch auf individuellen HDD-Durchsatz * Anzahl der GET-Anfragen begrenzt. Dass S3 diese Grenze nicht hat, ist das Geheimnis und der spannende Punkt

    • Wenn man Millionen von Festplatten zusammenfasst, erhält man eine enorme IO-Bandbreite

    • Das klingt nach einer Logik wie: „Der Weg zum Mond ist offensichtlich: reisen.“

  • full-platter seek time: ~8ms; half-platter seek time (avg): ~4ms
    Wenn zwei Punkte im Intervall [0,1] gleichverteilt sind, ist der Erwartungswert ihrer Distanz im Mittel nicht 0,5, sondern 1/3. Wenn die Full-Platter-Seek-Zeit also 8ms beträgt, liegt die durchschnittliche Seek-Zeit bei 2,666ms

    • Bei modernen Laufwerken liegt ein Full Seek näher bei 25ms als bei 8ms. Wenn du das selbst testen willst: mit einer Festplatte und Root-Rechten kannst du in fio mit der Option --readonly abwechselnde Lesevorgänge an den beiden Enden der Platte ausführen. Es gibt auch eine gute Arbeit (hier), die erklärt, warum der 1/3-Wert bei modernen Laufwerken nicht exakt zutrifft. Wenn du noch mehr zu Mechanik oder Leistung von Festplatten wissen willst, kann ich antworten

    • Beim Bewegen zwischen Tracks wird der Kopf beschleunigt. Je kürzer die Distanz, desto geringer ist die Spitzengeschwindigkeit, und es gibt auch eine konstante Verzögerung (etwa durch Settling Time), daher kann der tatsächliche Mittelwert durchaus 4ms sein

    • Da die Platter kreisförmig sind, sollte man keine Gleichverteilung auf [0, 1], sondern auf dem Einheitskreis [0, 2π] annehmen, und da sich der Platter nur in eine Richtung dreht, muss die Distanz immer nur im Uhrzeigersinn berechnet werden.
      Vereinfacht: Wenn der Startpunkt bei 0 Grad liegt und der Zielpunkt zufällig ist, wie groß ist dann die durchschnittliche Distanz? Da die Bogenlänge von 0–180 Grad und 180–360 Grad gleich ist, beträgt die durchschnittliche Distanz 180 Grad. Das heißt, ein Half-Platter-Seek ist genau die Hälfte eines Full-Platter-Seek

  • Wenn man wissen will, ob S3 HDDs noch im Basisdienst verwendet, kann man anhand des Preises und einer Umrechnung auf IOPS grob abschätzen. Die Preise von S3 für GET/PUT-Anfragen sind hoch genug, dass AWS es sich leisten kann, für leistungsstarke Tenants Plattenkapazität ungenutzt zu lassen. Aber viel teurer als ein kleiner Aufschlag ist es wohl nicht

  • Ich frage mich, ob Teile von S3 auf SSDs laufen. Ich hatte angenommen, dass selbst Standard-S3 SSD-basiert ist und nur langsamere Tiers HDDs oder langsamere Systeme nutzen

    • Der KeyMap-Index von S3 verwendet SSDs. Zum jetzigen Zeitpunkt dürfte SSD wahrscheinlich schon Teil eines Hot-Object-Caches oder des neuen One-Zone-Produkts sein

    • Die eigentlichen gespeicherten Daten liegen höchstwahrscheinlich überwiegend auf HDDs. Aber ich würde erwarten, dass Metadaten, Indizes usw. deutlich schnelleren Flash-Storage verwenden. Selbst MDS-Server in kleineren Ceph-Clustern tun das normalerweise, und S3 ist um Größenordnungen größer

    • Ich hatte es oben schon einmal erwähnt: Im Standard-Tier sind die Request-Preise hoch genug, dass sich für Kunden mit hohem IOPS/TB-Verhältnis ein gewisser Anteil ungenutzter Festplattenkapazität noch kosteneffizient rechnet. Wenn es darüber hinausgeht, lohnt es sich aber nicht mehr. Moderne HDDs speichern etwa 30TB; ich weiß nicht, was AWS tatsächlich zahlt, aber grob schätze ich 300–500 Dollar. Im Vergleich zu 30TB-SSDs ist das viel günstiger. Außerdem kann man solche HDDs in sehr dichten Systemen verbauen (z. B. 100 Laufwerke in 4U), und das kostet vielleicht nur etwa 25 % mehr in der Gesamtkalkulation. Dagegen sind Hardware-Boxen für viele SSDs pro Slot deutlich teurer

    • Ich vermute, dass S3 Express One Zone SSD-basiert ist. Soweit ich weiß, legt Amazon das aber nicht offen dar

    • Ich würde sicher erwarten, dass die Metadaten auf SSDs gespeichert werden. Häufig gelesene Hot Objects werden womöglich ebenfalls auf SSDs gecacht

  • Es ist bemerkenswert, dass die HDD-Preise weiter gefallen sind, die S3-Preise aber mindestens 8 Jahre lang gleich geblieben sind. Wegen mangelndem Preiswettbewerb konnte das hohe Preisniveau offenbar gehalten werden. Man kann sich vorstellen, wie profitabel das für AWS ist

    • Die AWS-Preispolitik ist bei allen Diensten ähnlich. Zum Beispiel kostet eine m7a.medium-Instanz bei EC2 On-Demand 50 Dollar pro Monat und mit 1-Jahres-Reservierung 35 Dollar. Selbst im Vergleich mit ähnlichen Angeboten anderer Anbieter ist das nicht besonders wettbewerbsfähig

    • Man muss auch die Inflation berücksichtigen; selbst bei gleichem Nominalpreis ist der reale Preis also gefallen. Ich stimme aber zu, dass Inflation viel langsamer wirkt als technologischer Fortschritt

    • Ich glaube nicht, dass Kostensenkung das Ziel der Anreize ist. Wenn man sich Unternehmen wie Splunk oder CrowdStrike ansieht, die riesige Datenmengen in AWS speichern, gibt es dort sehr viele sich wiederholende Daten, die sie ihren Kunden unverändert in Rechnung stellen und nur mit einfacher Deduplizierung behandeln. Wenn man die Kosten senkt, schafft das eher Anreize für noch mehr unnötigen Verbrauch

    • Ich frage mich, wie stark die HDD-Preise tatsächlich noch fallen. In den letzten Jahren hat sich der Preisrückgang pro GB bei Festplatten deutlich verlangsamt, sodass SSDs sie wohl bald einholen könnten

  • Als noch interessanteren Artikel über S3 empfehle ich „Building and operating a pretty big storage system called S3“

  • Ich würde gern wissen, wie rustfs in der Praxis performt

  • Die Erwähnung von zig Millionen HDDs lässt vermuten, dass die Gesamtkapazität von AWS S3 im Bereich von Hunderten Exabyte liegt, wenn Enterprise-HDDs 10–20TB fassen. Es ist wahrscheinlich das größte Storage-System der Welt

    • Wenn die Hardware seit 2013 aufgerüstet wurde, könnte ein bestimmtes Rechenzentrum in Utah diese Kapazität übertreffen (Artikel dazu)

    • Aktuelle Enterprise-HDDs haben 30TB, und bald könnten sogar 50TB möglich werden

  • Ich würde gern einen Open-Source-Dienst kennen, der für HDDs optimiert ist und ähnliche Leistung erreicht. Die großen Projekte (MinIO, Swift, Ceph+RadosGW, SeaweedFS) empfehlen alle Deployments nur mit Flash. Ich schaue mir gerade ein neueres Projekt namens Garage an, das sich im Design deutlich unterscheidet, unter anderem weil es kein EC verwendet

    • Ceph+RadosGW funktioniert auch mit HDDs gut genug. Man braucht aber SSDs für den Index-Pool und ein realistisches Verständnis dafür, welche IOPS-Zahlen man von einem HDD-Pool erwarten kann. IOPS auf Client-Seite vervielfachen sich tatsächlich intern, und S3 löst dieses Problem durch sehr viele HDDs. Für 4MB-Streaming in großem Umfang ist das kein großes Problem, aber wenn man viele kleine Keys zufällig liest und schreibt oder viele verteilte Zugriffe auf denselben Key hat, ist die Backend-Leistung entscheidend

    • Lustre/ZFS kann ähnliche Geschwindigkeiten erreichen. Aber wenn hohe IOPS benötigt werden, braucht Lustre Flash für den MDS und ZFS dedizierte Log-SSDs

    • All diese Dienste erreichen dieselbe Leistung nur mit sehr vielen Laufwerken auf Rechenzentrumsniveau. Nur sehr wenige Installationen kommen auf diese Skalierung. Deshalb ist Flash für schnellen Zugriff in Bezug auf Platz/Kosten effizienter

    • SeaweedFS hat sich in den letzten Jahren stark weiterentwickelt und unterstützt inzwischen auch RDMA und EC

    • Bei einem früheren Arbeitgeber haben wir Objektspeicher auf Basis von SwiftStack betrieben; die Metadaten lagen auf SSDs, die Objektdaten auf normalen HDDs. Das funktionierte völlig ausreichend