Warum baut niemand S3 so?

Ich habe den Speicher-Cluster für die Firma eines Freundes entworfen. Ihre ca. 3 PB Videodaten lagen bei einem Cloud-Anbieter, der das Konto bald schliessen wollte. Also bauten wir den Cluster im eigenen Rechen­zentrum der Firma, mit brandneuen Festplatten und allem, was ich bei der Arbeit gelernt hatte.

Dann war das Konto weg und es gab kein Zurück. Ab jetzt lief alles über den neuen Cluster und der kam nicht hinterher.

Wochenlang versuchte ich alles, was ich wusste. Auch Berater und Fachleute aus meinem Netzwerk versuchten es. Jede Änderung sah auf dem Papier gut aus, brachte in der Praxis aber keine Besserung. Die Festplatten blieben ausgelastet, die Latenz blieb hoch.

Normalerweise finde ich heraus, warum etwas langsam ist. Diesmal konnte ich nichts dagegen tun.

Das Schlimmste war, dass ich das schon einmal erlebt hatte.

Es war nicht das erste Mal

Hauptberuflich war ich Site Reliability Engineer bei einem grossen Telekom­unternehmen, zuständig für einen Data Lake mit mehreren Petabyte. Einmal brauchte ein Batch-Job, der sonst 6 Stunden lief, plötzlich 18. Die ganze Pipeline dahinter wartete.

Ein Team hatte seine Jobs gerade von Hadoop auf unseren neuen S3-Speicher gezügelt. Hadoop hatte die Daten dort verarbeitet, wo sie lagen. Unser neuer Speicher schickte jedes Byte übers Netzwerk, und das gleich mehrfach.

Jede Lösung brachte das nächste Problem ans Licht. Mit mehr Gateways wurden die Jobs schneller, bis die Gateways nicht mehr reagierten, weil sie mit ihren eigenen Aufräum­arbeiten beschäftigt waren. Dann stellte sich heraus, dass die Metadaten auf denselben langsamen Festplatten lagen wie die Daten. Um sie zu verschieben, mussten wir den Cluster umbauen und jeder Umbau bedeutete tagelanges Rebalancing.

Mehrere Beratungs­firmen hatten dieses Design abgesegnet. Wir hatten ein ganzes Team nur für Speicher und trotzdem dauerte es Wochen. Wie sollte eine kleine Firma das schaffen?

Was haben wir falsch gemacht?

Niemand konnte es mir sagen und das liess mir keine Ruhe. Also baute ich eigene Prototypen. Einer nach dem anderen landete im Papierkorb. Sie waren zu komplex oder zu langsam, oder ich konnte sie nicht gründlich genug testen. Und fast überall, wo ich hinschaute, fand ich wieder Replikation, Erasure Coding und viele Komponenten. Genau das, was mir im Betrieb so viel Ärger gemacht hatte.

Also stellte ich die Frage anders: Was ist der einfachste Aufbau, um S3 bereitzustellen? Zwischen der HTTP-Anfrage und der Festplatte steht nur das Gateway. Buckets verhalten sich wie Verzeichnisse, Objekte wie Dateien.

Das war der erste Prototyp, der funktionierte. Und dann kamen die Zweifel. Wenn es so einfach ist, warum hat es niemand gebaut, der klüger ist als ich? Warum baut niemand S3 so? Das frage ich mich bis heute.

Ich sprach mit vielen aus meinem Netzwerk, die Speicher betreiben. Ihre Antwort war ernüchternd. S3 ist langweilig und niemand interessiert sich dafür, bis es nicht mehr läuft.

Alles steht und fällt mit den Metadaten

An den Metadaten waren beide Cluster gescheitert. Deshalb gehören sie bei ObjectGateway, meinem eigenen S3-Speicher, zur Datei. Sie liegen in einem erweiterten Attribut oder in einer kleinen Datei daneben. Solange das Dateisystem hält, was es verspricht, können Daten und Metadaten nicht auseinanderlaufen.

Das Gateway kopiert nie selbst Daten. Das übernimmt der Speicher darunter oder Orbit, ein eigen­ständiges Produkt. Der Haken ist, dass ein Gateway auf einer Maschine läuft und das Dateisystem unsere Tests bestehen muss. Dafür ist der Betrieb so einfach wie das Dateisystem darunter.

Heute ist ObjectGateway ein Produkt von Quadrant Systems, der kleinen Software­firma in der Schweiz, die ich gegründet habe. Wir setzen es selbst ein, unter anderem auch, um diese Website zu hosten. Es ist der Speicher, der mir damals gefehlt hat: S3, das einfach bleibt und ohne Speicher­fachleute läuft. Und hoffentlich holt es niemanden mehr nachts aus dem Bett.

Wenn Sie mitverfolgen möchten, wie es weitergeht, abonnieren Sie unsere Produkt-Updates.