Blogpost Teil 2: Einsatzkriterien und Leistungmerkmale von Objekt Storage

Starnberg, 28. Mai 2020 - Warum verwendet Object Storage beim Datenschutz Erasure Coding und nicht RAID? Mehr zu Beschaffungskritierien, RESTful APIs und S3...

Um was geht es hier? Wie im ersten Teil dieses Blogs zu Object Storage am 29.04. angekündigt, beschäftigt sich dieser (zweite) Teil mit weiteren technologischen Aspekten, also z.B. warum Erasure Coding oder RAIN und nicht RAID; was sind die Vorteile von Protokollen auf Basis RESTful APIs, S3 und wo liegen die kritischen Einsatzkriterien? Zum Blogpost Teil 2: Object Storage bedeutet in der Regel den Verzicht auf RAID-basierte Verfahren durch Data-Protection-Technologien, die unter den Bezeichnungen Erasure Coding (s.a. Reed Solomon-ECC Codes etc.) bekannt wurden. Diese helfen im Unterschied zu RAID-5/6, die Datenverfügbarkeit bei geringerem Kapazitäts-Overhead bei deutlich niedrigeren Kosten zu verbessern.

Weiterer Vorteil: Da Objektspeichersysteme größere Kapazitäten verwenden, werden für den kostengünstigen Aufbau eines Speicherpools in der Regel Festplatten mit hoher Kapazität (>10 TB+) verwendet. Bei einem RAID-basierten Speichersubsystem würde es für den Re-Build dann oft Tage dauern, bis ein einzelnes ausgefallenes Laufwerk wiederhergestellt ist. Mit Erasure Coding geht das schneller, denn hier arbeiten Software-Algorithmen, welche Datenobjekte in redundante Prüfblöcke kodieren, die über den gesamten Speicherpool verteilt sind. Es sind je nach Verfahren meist nur wenige Prüfblöcke erforderlich, um das ursprüngliche Datenobjekt wiederherzustellen. Diese Art von Datenschutz ist somit nicht nur schneller, sondern auch deutlich skalierbarer als das klassische RAID-Verfahren und GEO-redundant, weil die Daten auf jeweils unabhängige Hardwareelemente (n-Knoten) im Netzwerk verteilt werden können. Hinweis: Bei der Objektdatenspeicherung steigen mit der Kapazität natürlich auch die Hardware-Kosten (x86 nodes).

Welche Protokolle finden bei Object Storage Anwendung?

Als Protokoll wird REST (Representational State Transfer) verwendet. Representationen können z.B. XML- oder JSON-basierend sein. Es gibt “Dialekte”, wie Amazon S3 als de-facto Standard, wobei es aber immer spezifische S3-Varianten bestimmter Hersteller und nicht nur von AWS selbst gibt. Weitere Lösungen basieren auf OpenStack SWIFT sowie CDMI (dieser Protokollvorschlag der SNIA ist aber sehr selten im Markt anzutreffen und wird von Anbietern kaum unterstützt). Sowohl für die Archivierung als auch für Objekt Storage benutzt man zum Zugriff REST-Protokolle über RESTful-APIs. Diese liefern granulare Sicherheit auf Objektebene und umfangreiche Metadaten, die mit entsprechenden Tags versehen werden können.

Representational State Transfer bezeichnet eine Programmierlogik für verteilte Systeme, insbesondere für Webservices. Der Vorteil von REST liegt darin, dass im WWW bereits ein Großteil der für REST nötigen Infrastruktur (z. B. Web- und Applicationserver, HTTP-fähige Clients, Sicherheitsmechanismen usw.) vorhanden ist, und viele Web-Dienste REST-konform sind.  Das Verfahren arbeitet zustandslos via API über eine einheitliche Schnittstelle.

Als Anwendungsschicht-Protokolle werden meist HTTP und HTTPS eingesetzt

Wird über HTTP (Standard) zugegriffen, so gibt die verwendete Methode, darunter GET, POST, PUT und DELETE, an, welche Operation gewünscht ist. Ein großer Vorteil von REST in diesem Zusammenhang ist die Möglichkeit einer hohen Automatisierung der Storage-Infrastruktur durch die Nutzung von REST APIs, wie sie Objektspeicher-Anbieter liefern, um auch komplexe, verteilte Umgebungen wirtschaftlich sinnvoll betreiben zu können.

Vorteile der Objektspeicher-Technologie

  • Flexibilität – Aufgrund kundenspezifischer Metadaten kann jedes Objekt eigene Regeln umfassen. Immer mehr Anwendungen unterstützen Objektspeicher inzwischen auch nativ, d.h. es werden keine Gateway-Funktionalitäten benötigt.

  • Skalierbarkeit – Aufgrund der Verwendung von Objekt-ID‘s kann nicht nur horizontal, sondern auch über Geografien hinweg gespeichert werden, mit der Möglichkeit zur Verwaltung von Billionen von Objekten.

  • Kostenoptimierung – da die Schnittstellen über Standardx86 Infrastrukturen aber auch als virtuelle Instanzen – abgebildet werden. Die Anbindung geschieht über native HTTP Mechanismen, d.h. auch eine Mehrfach-Mandantenfähigkeit lässt sich einfacher abbilden (VPN Forwarding, Caching, transparente Proxies, Zertifikate usw).

  • Kein File-Locking – der Dateninhalt wird einmalig geschrieben als jeweils neues Objekt, ggf. mit Versionierung; sinnvoll im Bereich von Backend-Archiven.

Klingt alles super! Jetzt also nur noch Objektspeicher?

Object Storage eignet sich für große Datenmengen (>250 TB), aber die Anwendung sollte natürlich diese Form der Datenspeicherung auch entsprechend performant und im Betrieb robust unterstützen. In den Bereiche Videos, Musik, Images, Reports, Gesundheitsdaten usw. werden Objektspeicher bereits von vielen Unternehmen verwendet, jedoch es sind einige Randbedingungen zu beachten. Leicht entstehen Performanceprobleme bei kontinuierlicher Datenänderung (insbesondere bei kleinen Datenfragmenten); zudem ist die Technologie (noch) nicht sinnvoll für Anwendungen, die sehr niedrige Latenzzeiten erfordern.

Gelegentlich wird Object Storage mit Cloud Storage verwechselt: Cloud Storage ist vereinfacht eine über das Internet verfügbare Speicherressource, die aber nicht notwendigerweise mit Object Storage bereitgestellt werden muss. Sie ist meist EBS-basiert (block-storage) und wird ähnlich S3 über APIs adressiert, aber im Bereich von Low-Performance-Storage genutzt. Allerdings gibt es optional wie erwähnt Gateways zu Object Storage (Cloud Integrated Storage).

Objektspeicherprodukte sind heute in verschiedenen Varianten am Markt - als virtuelle Appliances, Managed Service Angebote, speziell entwickelte Hardware-Appliances oder als klassische - Software Defined Storage Lösung - die auf Standard (x86) Server-Hardware installiert wird. Vor-Ort-Objektspeicherung ist typischerweise für Arbeitslasten ausgelegt, die eine hohe Bandbreite erfordern, und wird nicht verwendet, um hohe Input/Output-Operationen pro Sekunde (IOPS) bei niedrigen Latenzzeiten, also z.B. Datenbanken zu unterstützen Hier kommt Blockstorage über dafür optimierte Speichernetze zum Einsatz (iSCSI oder FC); neuerdings aber auch NVMe/oF im Zusammenhang mit NoSQL und Flash sowie Storage Class Memory (SCM) wie Intel Optane.

3. Kritische Merkmale, auf die Anwender bei der Evaluierung von Objektspeicherlösungen achten sollten, werden  im dritten (und letzten) Teil dieser Blog-Serie hier abschließend in Kürze behandelt!


Querverweis: