FORUM

Das rasante Wachstum bei unstrukturierten Daten wie Bildern, E-Mails, technischen Dokumenten oder Videos stellt die IT vor erhebliche Herausforderungen. Abhilfe schafft der Einsatz von Software-defined Storage. Von Gerald Sternagl, EMEA Business Unit Manager Storage bei Red Hat.

Mit den traditionellen Methoden, wie sie klassische Storage-Systeme bereitstellen, lässt sich das explosionsartige Datenwachstum bei Audio- und Bilddateien, E-Mails, Office-Dokumenten, Log-Dateien, Sensordaten und technischen Zeichnungen kaum mehr bewältigen. Wollen Unternehmen die drastisch ansteigende Menge unstrukturierter Daten, auf die mittlerweile rund 90 Prozent der entstehenden Datenmenge entfällt, in den Griff bekommen, müssen sie effiziente Methoden einsetzen, wie sie Software-defined Storage bietet.

Software-defined Storage ermöglicht den Aufbau einer hochskalierbaren, flexiblen Architektur, mit der sich eine breite Vielfalt von Daten verwalten lässt. In einer
Software-defined-Umgebung werden Daten (Blöcke, Files oder Objekte) hardwareunabhängig in einer verteilten Architektur auf einer großen Zahl von Standardservern als einheitlicher, gemeinsam zu nutzender Speicherpool abgelegt.

Jedes Unternehmen muss seinen individuellen Weg bei der Implementierung von Software-defined Storage finden. Charakteristisch sind eine hohe Agilität und ein iteratives Vorgehen. Statt des ganz großen Wurfes empfiehlt sich zunächst die Konzentration auf ein Anwendungsszenario, bei dem der Bedarf zu handeln besonders gravierend ist. Die folgenden sechs Best Practices unterstützen Unternehmen beim Einstieg in eine Software-defined-Storage-Lösung.

1. Unternehmensbereiche mit dem größten Bedarf ermitteln. Nur ein geringer Anteil der Unternehmensdaten ist in relationalen Datenbanken abgelegt. Wichtig ist daher zunächst einmal festzustellen, an welchen Speicherorten sich die relevanten unstrukturierten Informationen wie Bilder, Dokumente, Tabellen und Zeichnungen befinden. Ein weiterer Bestandteil der Bestandsaufnahme ist die Ermittlung der dafür jeweils benötigten aktuellen und künftigen Kapazitäten unter Beachtung von Verfügbarkeit und Reaktionsfähigkeit.
   
   
2. Die Anwendungsszenarien mit dem größten Handlungsdruck identifizieren. Als Ergebnis der Ist-Analyse zeigen sich die Bereiche und Anwendungsszenarien, in denen der größte Handlungsbedarf bezüglich unstrukturierter Informationen vorhanden ist. Im nächsten Schritt sollte festgestellt werden, wer welche Dokumente, Medieninhalte oder Geodaten wie oft in welchen Anwendungsszenarien nutzt und welchen Stellenwert diese Informationen für ein Unternehmen haben.
   
   
3. Weniger kritische Daten und neue Applikationen als Erstes migrieren. Die Migration unstrukturierter Daten auf eine neue Software-defined-Storage-Plattform ist aus organisatorischer und IT-Sicht ein ambitioniertes Projekt mit vielfältigen Implikationen, kann jedoch dabei helfen, den Kostendruck massiv zu senken. Um erste Erfahrungen zu sammeln, sollten Unternehmen in einem klar umgrenzten Anwendungsszenario ihre Anforderungen und die Zielerreichung testen. Auf dieser Basis können dann weitere Datenbestände migriert und die Adaption von Software-defined Storage weiter vorangetrieben werden.
   
   
4. Festlegen, ob die Anwendungsszenarien vor Ort betrieben oder in die Cloud verlagert werden sollen. Aus organisatorischen Gründen sollten sich die Verantwortlichen frühzeitig Gedanken darüber machen, ob die Software-defined-Storage-Plattform auf physischen Servern, in einer virtualisierten Umgebung oder in der Cloud laufen soll. Wollen Unternehmen alle drei Bereitstellungsmodelle gleichzeitig verwenden, benötigen sie eine flexible Lösung, die dies unterstützt.
   
   
5. Das richtige Maß an Datensicherung und Replikation definieren. Egal, ob die Software-defined-Storage-Plattform vor Ort, in der Cloud oder einer hybriden Konstellation eingesetzt wird, müssen von Anfang an Backup- und Recovery-Pläne definiert und Maßnahmen implementiert werden. Dafür sollten in verschiedenen Szenarien mögliche Schadensfälle und die Kosten durchgespielt werden. Diese Ergebnisse dienen als Grundlage für die benötigten Investitionen in die Datensicherung und Wiederherstellung. Unternehmenskritische Daten erfordern dabei naturgemäß mehr Schutz. Eine moderne SDS-Lösung bietet die Möglichkeit, verschiedene Speicherklassen zu definieren und diese nach den erforderlichen Verfügbarkeits- und Wiederherstellbarkeitsanforderungen der Daten zu priorisieren.
   
   
6. Den regulatorisch vorgegebenen Aufbewahrungszeitraum der Daten berücksichtigen. Für alle in einem Unternehmen erzeugten Daten gelten die einschlägigen Vorschriften aus dem Bundesdatenschutzgesetz bezüglich der Aufbewahrungsorte und -fristen. Cloud-Anwendungsszenarien, bei denen keine personenbezogenen Daten zur Verarbeitung an Server im Ausland gesendet werden, sind datenschutzrechtlich weniger problematisch.
   
   

Ein skalierbarer Ansatz für Software-defined Storage erfordert eine Entkopplung der Daten-Services von den zugrundeliegenden Datenstrukturen, damit mehr Services in einem breiten Spektrum von Anwendungsszenarien eingesetzt werden können. Bezüglich der Daten-Services gilt es zwischen Filesystemen, Blockspeicher, Objektspeicher sowie Shared-File- und Object-Storage zu unterscheiden. Herkömmliche Dateisysteme sind aufgrund ihrer hierarchischen Struktur nur begrenzt skalierbar. Block-basierter Speicher, wie ihn SANs verwenden, verwalten die Daten als Blöcke mit Sektoren und Tracks. Im Cloud-Bereich ist das OpenStack-Projekt Cinder einer der weit verbreiteten Blockspeicher. Objektorientierte Speichersysteme sind historisch als Alternative zu den Datei- und Block-basierten Systemen entstanden und enthalten zusätzlich zu den eigentlichen Information auch Metadaten, die sich einfacher indizieren lassen als unstrukturierte Daten. Sie nutzen die Representational-State-Transfer- (REST)-Architektur zur Abstraktion der Daten von der Applikation. Das OpenStack-Projekt Swift ist der typische Vertreter eines objektorientierten Speichersystems. Shared-File- und Objektspeicher-Lösungen verwenden die Stärken der weitverbreiteten Datei-basierten Applikationen. Gleichzeitig machen sie die Daten auch für Objekt-basierte Applikationen zugänglich, nutzen dazu REST-basierte Methoden und bieten so eine hohe Flexibilität.

Scale-Out File-basierte Software-defined-Storage-Plattform
Der typische Vertreter einer File-basierten Shared-Nothing-Storage-Plattform ist Red Hat Gluster Storage, ein verteiltes File System, das Speichergrößen im Petabyte-Bereich unterstützt. Es basiert auf dem Open-Source-Filesystem GlusterFS und zieht eine Abstraktionsschicht zwischen dem physikalischen Speicher und dem Benutzer ein. Zur eigentlichen Ablage nutzt die Software Block-basierte Dateisysteme. Es verteilt die Daten nicht auf Serverknoten- sondern auf Brick-Ebene.
Als erste grundlegende Speichereinheit enthalten die Bricks die Pfadangaben zum physischen Speicherort. Bricks sind Linux-Rechner mit frei verfügbarem Plattenplatz, beispielsweise Partitionen, ganzen Festplatten oder sogar RAID-Arrays. Dabei ist es egal, wie viele Datenträger pro Brick tatsächlich zur Verfügung stehen oder wie viele Server eingebunden sind. Ein Gluster Volume entsteht aus den Bricks verschiedener Server. Aus Benutzersicht bilden die Volumes einen Shared Storage Pool, auf den sie lesend und schreibend zugreifen können. Die zweite zentrale Komponente von GlusterFS sind Translatoren, die bestimmte Funktionen zur Verfügung stellen, etwa die Bereitstellung und Nutzung der POSIX-Schnittstelle, die Verteilung von Daten im Hintergrund oder auch der Aufbau eines verteilten RAID-Verbunds über mehrere Bricks.

Ein weiteres Kennzeichen von GlusterFS ist die Meta-Daten-Verwaltung. Während andere verteilte Storage-Lösungen dazu dedizierte Server oder Instanzen nutzen, kennt GlusterFS so etwas nicht. Stattdessen verteilt GlusterFS Dateien auf Basis eines Algorithmus im gesamten Storage-Cluster. Mit GlusterFS können Anwender Kapazität und Performance im Gleichschritt steigern. Damit entsteht eine leistungsfähige Software-defined-Storage-Infrastruktur, um unstrukturierte Daten File-basiert auf standardbasierten x86-Servern zu speichern.

Red Hat Gluster Storage stellt seine Speicherpools üblicherweise über die File-basierten Standard-Netzwerkprotokolle NFS und SMB zur Verfügung, bietet zudem aber mit Gluster Fuse auch ein eigenes, hoch optimiertes Netzwerkprotokoll samt eigenem API (libGFAPI) für Linux-basierte Clients und ermöglicht zudem einen Objekt-basierten Zugriff auf Dateien über die Swift-Schnittstelle.

Objekt-basiertes Software-defined-Storage-Speichersystem
Der typische Vertreter eines Objekt-basierten Software-defined-Storage-Speichersystems ist Red Hat Ceph Storage, das auf der Open-Source-Lösung Ceph basiert. Object Stores speichern die Daten in Form binärer Objekte, die sich in viele kleine Teile aufspalten lassen. Die einzelnen Teile des binären Objekts können verteilt – beispielsweise über mehrere Festplatten – gespeichert werden. Damit umgehen Objektspeicher den größten Schwachpunkt klassischer Storage-Lösungen, nämliche die starre Einteilung in Blöcke.

Die Kernkomponente von Ceph ist der Objektspeicher, vormals bekannt unter dem Namen Rados (Redundant Autonomic Distributed Object Store). Der Objektspeicher besteht aus den Kernkomponenten Object Storage Device (OSD) und dem Monitoring-Server. Ein OSD ist im Grunde genommen die einzelne Festplatte in einem Ceph-Verbund. Die OSDs speichern als Datensilos die binären Objekte. Um Daten in einen Cluster zu laden, kommunizieren Anwender mit diesen OSDs, die sich auch um Themen wie Replikation kümmern.

Über die Monitoring-Server können Clients und OSDs feststellen, welche OSDs zu einem Cluster gehören. Der Objektspeicher von Ceph arbeitet mit dem CRUSH (Controlled Replication Under Scalable Hashing)-Algorithmus und verteilt die Daten über die verfügbaren Speichersysteme. Die Platzierung der Daten erfolgt über Regeln, in denen etwa auch definiert wird, wie viele Kopien aus Gründen der Ausfallsicherheit angelegt werden.

Red Hat Ceph Storage stellt seine Speicherpools üblicherweise über Objekt-basierte Protokolle wie S3 oder Swift zur Verfügung. Weitere Integrationsmöglichkeiten bieten eigene APIs wie die Objekt-basierte Librados-Schnittstelle, die Block-basierte librbd/kRBD-Schnittstelle oder die direkte Anbindung an die OpenStack-Speicherschnittstellen Cinder und Glance.

Zu den Einsatzgebieten von Software-defined Storage zählen beispielsweise Archive für medizinische Daten etwa beim Gene-Sequencing, Daten aus metereologischen Aufzeichnungen, komplexe Medieninhalte oder Audio- und Videodaten wie sie von Content Delivery Networks benötigt werden. Unternehmen, die mit einem massiven Wachstum unstrukturierter Daten zu kämpfen haben, erhalten mit einer Software-basierten Lösung die Möglichkeit, zusätzliche Kapazitäten in die Cloud zu verlagern. Weitere Möglichkeiten ergeben sich durch die Einbindung in OpenStack. Sowohl GlusterFS als auch Ceph sind optimal auf OpenStack abgestimmt.