5 Vom Portable Operating System for Unix Filesystems (POSIX), erstmals 1988 eingeführt, bis zum 2006 eingeführten Simple Storage Service (S3) von Amazon Web Services: Die Datenpersistenz erlebt eine Revolution. 2013 gab AWS bekannt, dass seine S3-Plattform mehr als 2 Billionen Objekte beherbergt und sich diese Zahl jedes Jahr verdoppelt. Damit läge sie heute bei etwa 16 Billionen gespeicherten Objekten. Geht man davon aus, dass ein Objekt im Durchschnitt nur 256 KB groß ist, würde die Plattform derzeit weit im Exabyte-Bereich liegen und damit rund 1 % aller digitalen Daten der Welt beherbergen, wahrscheinlich mehr. Das ist sicherlich die größte einzelne Datenspeicherplattform der Welt. Der Erfolg von AWS und seiner Speicherplattform lässt sich nicht länger ignorieren – doch ist S3 auch zukunftsfähig? Es lohnt sich, darüber nachzudenken, warum AWS ein solches Protokoll auf den Markt gebracht hat und warum es sinnvoll ist oder nicht. Wir können nicht wissen, was Amazon bei der Einführung des Protokolls alles gedacht hat, doch die Grenzen herkömmlicher Dateisysteme sind gut bekannt. AWS wurde entwickelt, um IT-Infrastruktur nach Bedarf bereitzustellen – heute IaaS genannt. Dienste bei Bedarf starten und stoppen zu können, war großartig, doch die erzeugten Informationen mussten dauerhaft gespeichert werden. Das System zur Datenpersistenz brauchte besondere Eigenschaften, darunter: Unbegrenzte Skalierbarkeit: Das Wachstum des Systems durfte keine Grenze haben Das Protokoll musste WAN-tauglich sein Das System musste einfache, zuverlässige Sicherheit bieten Das System musste hochverfügbar und robust sein Der Speicher musste in eine zunehmend webzentrierte Welt passen. POSIX-Dateisysteme sind seit ihrer Einführung die tragende Säule der Speicherung, und das hierarchische Organisationsmodell von Dateisystemen ist für Menschen zweifellos gut verständlich. Dennoch haben sie Einschränkungen, die ihre Skalierung mit wachsender Größe schwierig, wenn nicht unmöglich machen. Viele Speicheradministratoren haben schon die Inode-Zahlen (die eindeutigen Kennungen von Dateien und Verzeichnissen) beobachtet wie Milch, die auf dem Herd warm wird – wissend, dass das System jenseits bestimmter Grenzen instabil wird. Auch die Nutzer von POSIX-Dateisystemen sind anspruchsvoll. Erwartet wird volle Konsistenz über den gesamten Datenbaum. Jede Änderung an einer Datei oder an der Verzeichnisstruktur muss allen Nutzern des Dateisystems gleichzeitig mitgeteilt werden. Von den Fehlerbehandlungsmechanismen der Anwendungen wird nicht einmal erwartet, dass sie die Möglichkeit in Betracht ziehen, dass dies nicht zutrifft. Das POSIX-Dateisystem muss jede Abweichung von den Regeln öffentlich eingestehen, indem es einen gefürchteten I/O-Fehler zurückgibt. Es ist leicht zu erkennen, dass AWS die Regeln auf die eine oder andere Weise brechen musste, um auf die schwindelerregenden Höhen zu skalieren, die es heute erreicht hat – und wie ließen sich Regeln besser brechen, als sie einfach zu ändern? Mit einem völlig neuen Protokoll konnte AWS neue Regeln und Konventionen etablieren, die die Skalierung ermöglichten und Dienste boten, die für seine Kunden sinnvoller waren. Hier ein Überblick: S3 ist nicht hierarchisch: Objekte werden nach Namen in einer Sammlung gespeichert, die Bucket heißt. Der Bucket ist indiziert und lässt sich mit einer präfixbasierten Suche auflisten. Das bietet einen klaren Skalierungsvorteil: Die Konsistenzdomäne beschränkt sich auf einen einzelnen Bucket statt auf den gesamten hierarchischen Baum wie bei POSIX. Für den Bucket wird Eventual Consistency garantiert. Die Anwendung muss akzeptieren, dass ein gerade aktualisiertes Objekt möglicherweise nicht sofort in der Liste erscheint und womöglich nicht die neuesten Informationen enthält; die Plattform darf sich lediglich nach besten Kräften um sofortige Konsistenz bemühen. Mit der Zeit hat die Leistung des Systems gezeigt, dass Daten in der Regel vollständig konsistent sind, doch die architektonische Freiheit, diese Bedingung zu lockern, bringt echte Vorteile bei Leistung und Skalierbarkeit. Anfragen sind REST-basiert und in sich abgeschlossen. Diese Methode eignet sich sehr gut für Interaktionen über WAN. Anfragen werden mit einem gemeinsamen Geheimnis signiert und über eine SSL-Verbindung übertragen. Das schützt vor Man-in-the-Middle-Angriffen und verhindert, dass Passwörter in Anfragen übertragen werden. Der Inhalt eines Buckets kann über ein virtuelles Hosting-Modell bereitgestellt werden, bei dem er als https://bucket.s3.amazonaws.com/object_name erscheint. So kann sich ein AWS-S3-Bucket direkt wie eine statische Website verhalten. Aufgrund dieses virtuellen Hosting-Modells müssen Bucket-Namen den DNS-Namenskonventionen entsprechen, sind auf der gesamten AWS-Plattform eindeutig und auf 100 Buckets pro Endnutzer begrenzt. Diese Einschränkungen haben zu einem Modell geführt, bei dem Anwendungen in der Regel einen einzigen Bucket nutzen und Tausende oder Millionen von Objekten darin ablegen. Hierarchische Dateisystemmodelle werden oft durch Präfixe nachgebildet, deren Namen Verzeichnispfaden ähneln, etwa /foo/bar/foo/object. So können GUI-Anwendungen zwar den Eindruck vermitteln, man durchsuche eine Hierarchie, doch S3-basierter Speicher wird vor allem von Anwendungen und nicht von Nutzern verwendet Objekten oder ganzen Buckets können dauerhafte oder temporäre Zugriffsrechte für jeden identifizierten Nutzer der Plattform oder für anonyme Nutzer erteilt werden. Eine sehr granulare Abrechnung ist möglich, basierend auf der Menge der gespeicherten Daten und der Häufigkeit des Zugriffs. Im nächsten Teil besprechen wir, wie Anwendungen AWS-S3-Speicher nutzen und wie sich das Modell in den zehn Jahren seines Bestehens verbessert hat. Außerdem zeigen wir, wie das branchenführende Objektspeicher-Backend von Scality diese Revolution der Datenpersistenz aufgreift. Lesen Sie die Pressemitteilung zu RING 6.0 (auf Englisch) Erfahren Sie, was RING 6.0 Neues bietet (auf Englisch)
