Der De-facto Standard für den Internet-Speicher, Teil 3 Massendatenhaltung im Internet gelingt bis auf Weiteres nur mit dem Lastwagen

Das Internet ist nicht dafür gebaut, dass man ganz viele Daten in ganz kurzer Zeit von einem Ort zu einem anderen transportiert. Das wird sich auch in Zukunft nicht ändern, da die Datenmengen schneller wachsen als die Bandbreite. Auch Amazon zollt der Legende von der Bandbreite eines LKWs Tribut.

Anbieter zum Thema

Schneider Electric GmbH

DataCore Software GmbH

Fujitsu Technology Solutions GmbH

Amazon Deutschland GmbH

Die dritte Möglichkeit, die AWS bei 10-GBit/s-Verbindungen ab einem Datenvolumen von über 60 TByte empfiehlt, bei langsamerer Connectivity und bei weniger Datenvolumen, ist eine spezielle Appliance namens Snowball.

Datentransfer per Hardware

Der „Snowball“ ist gegen physische und unbefugte logische Eingriffe geschützt, wiegt unter 25 Kilo und wird von AWS auf Anforderung in der Managementkonsole für 200 US-Dollar zum Kunden geschickt.

Der installiert bei sich einen speziellen Software-Client, verbindet die Appliance mit dem lokalen Netz und gibt ihm eine IP-Adresse. Dann markiert er die Directories, die in S3 eingespeist werden sollen. Der Snowball-Client befüllt den Snowball nur mit den Daten, die zuvor automatisch verschlüsselt werden. Dauert das Beladen länger als 10 Tage, werden pro weiterem Tag 15 US-Dollar fällig.

Ein elektronisches Label sorgt dafür, dass der Snowball anschließend an das richtige Rechenzentrum geschickt wird. Sobald die Daten in S3 gelandet sind, wird der Snowball nach den Standards des National Institute of Standards and Technology (NIST) gelöscht.

Caching mit dem AWS Storage Gateway

Um S3 mehr Anwendungsfelder zugänglich zu machen, stellt AWS sein Storage Gateway bereit, eine Software, die auf der Seite der Endkunden installiert wird und sich mit dem Cloud-Speicher verbindet. Dort kann man in sogenannten Gateway-Cached-Volumes mit bis zu 32 TByte Kapazität häufig genutzte Daten lokal vorhalten. Sie sind dann für die lokalen Server über eine iSCSI-Schnittstelle zugänglich. Client-Computer greifen über CIFS (Common Internet File System) oder NFS auf die Daten zu.

Mit Gateway-Stored-Volumes kann man gleich den gesamten Datenbestand lokal speichern und verschiebt nur asynchron zeitpunktbezogene Snapshots auf S3. Auch die Archivierung von Daten ist mit dem Gateway möglich. Dabei hilft die Funktion Gateway-VTL, die wahlweise entweder auf S3 oder den Archivierdienst Glacier zugreift. Über die iSCSI-Schnittstelle können die Anwender mittels ihrer Sicherungssoftware auf die virtuellen Bänder in S3 zugreifen. Lokale Anwendungen müssen für die Nutzung des Gateway nicht geändert werden.

Restart in der Cloud

Eine interessante Nutzungsmöglichkeit ist auch die Spiegelung lokaler Anwendungen und ihrer Anwendungsdaten auf Amazon EC2 in S3 als Amazon-EBS-Snapshot. Bricht die lokale Infrastruktur zusammen, lassen sich die Applikationen dann in EC2 ausführen. Dabei werden nur geänderte Daten in S3 geladen (Delta), um nicht mehr Bandbreite als nötig zu verbrauchen.

Ein wichtiger Anwendungsfall des Gateways ist neben Sicherung, Notfallsicherung und Ausfallsicherheit die gemeinsame Dateinutzung. Denn auch die Zugriffsrechte lassen sich in S3 speichern. Zudem kann man über das Gateway auch Daten in EC2 spiegeln, etwa wenn Testumgebungen, die häufig in EC2 gefahren werden, stets auf aktuelle Produktionsdaten zugreifen sollen.

Neben den schon genannten Anwendungsgebieten hält Gonzalez S3 für besonders vorteilhaft bei der Softwareverteilung und für den Aufbau von Datalakes. „In den firmeninternen RZ-Umgebungen kann man die Prozessoren oft nicht voll ausschöpfen, weil die Ein-/Ausgabekapazität der Speicher leistungsmäßig hinterherhinkt“, erklärt Gonzalez. Dieses Problem gebe es in S3 nicht, da hier, wie oben erwähnt, Speicher- und Schnittstellenserver getrennt sind.

Unterstützend für die Entwicklung neuer Anwendungen, die S3 nutzen, wirken die zahlreichen Software Development Kits, die AWS für den Dienst bereitstellt. Es gibt sie für Java, PHP, .net, Python, Node.js und Ruby, dazu kommt das AWS Mobile API. Alle Entwicklungskits haben eine REST-Schnittstelle der generischen S3-Schnittstelle.

Billig oder preiswert?

Ob AWS S3 wirklich sehr viel kostengünstiger ist als konventionelle Speicherlösungen, wenn man die Kosten langfristig betrachtet, sei dahingestellt. Sicher ist jedenfalls, dass die Kostenkalkulation oder Rechnungskontrolle keinesfalls das Kinderspiel ist, als das AWS sie gern darstellt.

Die Kostenkontrolle kann jederzeit über die Amazon Managementkonsole erfolgen. Über APIs kann man diese Kosten auch Kostenstellen, Anwendungen oder Zuständigen zuweisen, wenn die Buckets vorher mit Tags gekennzeichnet wurden. Das Preissystem ist nichtsdestotrotz recht verwirrend und die Berechnungen aufwändig. Nicht umsonst verschlingt die Antwort auf die Frage, was S3 in Rechnung stellt, in den S3-FAQ etwa drei Seiten, während die meisten anderen Fragen wesentlich kürzer beantwortet werden.

Berechnet wird der durchschnittliche Speicherraumverbrauch in einer bestimmten Zeitperiode, der dann wiederum bestimmten Volumenkorridoren zugeordnet wird. Die Maßeinheit sind US-Dollar pro Gigabyte und Monat, wobei sich die Preise hier zwischen den S3-Speicherklassen unterscheiden.

Weiter fallen in der Regel Kosten für Datentransfers aus der Cloud an, für die Menge der Datenanforderungen und für die Zahl der Datenabrufe. Auch regionale Unterschiede gibt es. Das summiert sich, obwohl AWS S3-Kunden im ersten Jahr ein kostenloses Grundkontingent zur Verfügung stellt, von dem allerdings bestimmte Services wie Direct Connect ausgeschlossen sind.

(ID:44067795)