Vor allem Anwender bemängeln, dass es in Sachen SDS keinen einheitlichen Standard gibt, und sich die Anbieter mit ihren eigenen Definitionen ins SDS-Umfeld schummeln können. Jedwede Software, die Storage verwaltet bzw. virtualisiert, wird als SDS angepriesen. Das soll sich dank SNIA nun ändern. Ein Entwurf für den Standard ist bereits vorhanden, wann dieser allerdings abgesegnet wird, ist nicht abzusehen. Für Kunden, Hersteller und IT-Anbieter, die neugierig auf die SNIA-Idee sind, ist in diesem Artikel der Entwurf dargelegt.

»Software-defined Storage« (SDS) wurde zirka 2013 als eine neue Klasse von Speicher-Software-Produkten vorgestellt. SDS kann sowohl ein Element innerhalb eines »Software-defined Data-Center« (SDDC) als auch eine alleinstehende Technologie sein. Der Terminus Software-defined Storage ist ein Marketing-Schlagwort und eine Folge des Begriffes »Software Defined Networking«. Dieser wurde als erstes benutzt, um einen Ansatz in der Netzwerktechnik zu beschreiben, mit dessen Hilfe sich verschiedene Elemente eines Netzwerkes abstrahieren und auf eine entsprechende Schicht in der Software abbilden lassen. Darüber hinaus gibt es Bestrebungen, den Begriff »Software-defined Compute« zu definieren. Der Software-Defined-Ansatz abstrahiert und vereinfacht die Verwaltung von Netzwerken in virtualisierten Diensten. Im Netzwerkbereich wurden die Kontroll- und Datenebene in traditionellen Switchen integriert, was die Abstraktion und Virtualisierung in komplexen Umgebungen schwerer handhabbar macht. Die Möglichkeiten von Datennetzen holen momentan erst den Vorsprung auf, den die Speicherindustrie für über ein Jahrzehnt in diesem Bereich hatte. SDS stellt eine neue Evolutionsstufe der Speicherindustrie dar, wie in Zukunft Massenspeicher verwaltet und ausgerollt werden.

Attribute von Software-defined Storage

Die folgenden Attribute von SDS können heute im Markt beobachtet werden:

• Erlaubt Kunden, »es selbst zu bauen«, die eigene Standard-Hardware zu nutzen, um mit Hilfe der angebotenen Software eine Lösung zu erstellen.
• Funktioniert entweder mit beliebiger Standardhardware oder verbessert die existierenden Funktionen spezialisierter Systeme.
• Ermöglicht Scale-Out von Speichersystemen, nicht nur Scale-Up wie bisher bei großen Speichersystemen üblich.
• Umfasst annähernd immer die Zusammenfassung von Speicher- und anderen Ressourcen.
• Ermöglicht die Erstellung von Speicher- und Datenlösungen ohne Verzögerung.
• Umfasst Verwaltungs-Automation.
• Enthält eine Self-Service-Schnittstelle für Endbenutzer.
• Enthält eine Form des Service-Level-Managements, das mit Hilfe von Metadaten die angewendeten Daten- und Speicherlösungen betreibt. Die Granularität wird zunächst sehr grob sein, aber es wird erwartet, dass sie mit der Zeit immer feiner wird.
• Erlaubt Administratoren, Regeln zur Verwaltung der Daten- und Speicherdienste zu setzen.
• Erlaubt die Trennung von Speicher- und Datendiensten.

Einige Analysten und Hersteller vertreten die Ansicht, dass SDS auf heterogenen Block-Speichersystemen zu betreiben sei. Dies ist nicht die Position der SNIA, die plattformunabhängig auftreten will. Die SNIA-Definition erlaubt sowohl proprietäre als auch heterogene Plattformen. Um die Definition der SNIA zu erfüllen, müssen die Plattformen eine Self-Service-Schnittstelle zur Provisionierung und Verwaltung interner virtueller Instanzen anbieten.

Abgrenzung von Software-defined Storage

Der Aspekt von SDS, der es von anderen Ansätzen unterscheidet, ist die Art wie einige der Produkte ausgerollt werden. Datendienste lassen sich entweder auf Rechnern, Speichersystemen oder beidem ausführen und erweitern so die Grenzen der bisherigen Umgebungen. Dies hat mögliche Einflüsse auf Sicherheit und Zuverlässigkeit und kann in einigen Fällen zu einer interessanten Wiedergeburt direkt angeschlossenen Speichers (DAS) führen.

Während SDS auf der Virtualisierung des Datenpfades basiert, ist SDS nicht allein Virtualisierung. Der Kontrollpfad muss ebenfalls als ein Dienst abstrahiert werden. Die Speicherdienst-Schnittstelle muss dem Datenbesitzer ermöglichen, Anforderungen sowohl über die Daten als auch über die benötigten Service Level zu senden. Eine Cloud, ein Rechenzentrum, ein Speichersystem oder ein Datenverwalter können zur Implementierung dieser Schnittstelle dienen.

Notwendige Funktionen von Software-defined Storage

Welche Eigenschaften sollten vorhanden sein, um den Titel Software Defined Storage zu verdienen, wo doch heute bereits viele Angebote im Speichermarkt abstrahiert oder virtualisiert sind?

Software Defined Storage sollte enthalten:

• Automation - einfache Verwaltung, die die Kosten zum Betrieb der Speicher-Infrastruktur reduziert.
• Standard-Schnittstellen - APIs zur Verwaltung, Provisionierung und zum Betrieb von Speichergeräten und -diensten.
• Virtualiserte Datenpfade - Block-, Datei- und Objektschnittstellen, welche für diese geschriebene Anwendungen unterstützen.
• Skalierbarkeit - Möglichkeiten, die Speicher-Infrastruktur nahtlos und ohne Unterbrechung der Verfügbarkeit und Leistung zu erweitern.

Idealerweise erlaubt SDS den Anwendungen und Datenquellen den Umgang mit ihren Informationen durch die Speicher-Infrastruktur ohne den Bedarf nach Eingriff durch den Speicherverwalter, ohne explizite Provisionierungs-Vorgänge und mit automatisiertem Service-Level-Management.

Darüber hinaus sollten Datendienste automatisch ausgerollt werden können. Regeln sollten zur Einhaltung der Service Level und deren Anpassung an die gegebenen Möglichkeiten verwendet werden. Metadaten sollten verwendet werden, um:

• Anforderungen zu definieren.
• Die Datendienste zu kontrollieren.
• Service Level Möglichkeiten zu definieren.

Der Blick des Anwenders auf Software-defined Storage

Die Sicht eines Speichernutzers oder einer Anwendung auf SDS umfasst – so wie es die SNIA versteht –  sowohl Daten- als auch Kontrollpfad. Der Datenpfad besteht aus einer Kombination bereits standardisierter Block-, Datei- und Objektschnittstellen, für die Anwendungen entwickelt wurden. Aber was ist mit dem Kontrollpfad?

Fast alle heute eingeführten Speichersysteme benötigen Administratoren, um virtuelle Speichergeräte für die Anwendungen zu erstellen (logische Laufwerke für Block, Dateisystem-Freigaben, Objekt-Container). Hinter den Kulissen rollt der Administrator Dienste für die auf diesen Geräten gespeicherten Daten aus. In der Mehrheit der Fälle benötigt jeder Datendienst eine eigene Verwaltungsschnittstelle. Änderungen an diesen Datendiensten betreffen alle auf den virtuellen Geräten gespeicherten Daten und können fehleranfällig und empfindlich sein. Die Übermittlung der Anforderungen für diese Daten findet für gewöhnlich außerhalb der Speicherschnittstelle und direkt mit dem Speicheradministrator statt.

Wie im Bild ersichtlich wird, ist diese Speicherumgebung nicht sehr Software Defined, sondern eher Administrator defined und installiert. Dies führt zu hohen Gesamtkosten für die Speicherumgebung aufgrund eines Mangels an Automation.

Die Rolle von Metadaten

Um Automation in eine Speicherumgebung einzuführen und damit die Gesamtkosten durch Reduktion manueller Eingriffe zu verringern, muss es eine Möglichkeit geben, die Anforderungen an die Daten direkt an die Automatisierungssoftware zu übermitteln. Die Granularität dieser Anforderungen muss mindestens so fein sein wie diejenige, die bei heutigen virtuellen Speichergeräten üblich ist. Um für zukünftige Anforderungen gewappnet zu sein, sollte jedes Datenobjekt in der Lage sein, seine Anforderungen unabhängig vom virtuellen Speichergerät zu übermitteln. Die Objekte sollten gruppiert und abstrahiert werden, um dem »Nutzer« ihre Auswahl zu verdeutlichen. Anderenfalls muss der Nutzer ein Speicherexperte sein.

Um die Anforderungen dem Speichersystem zu übermitteln, müssen die Anwendung oder der Nutzer jede einzelne Datei bzw. jedes einzelne Objekt mit diesen Anforderungen verknüpfen. Metadaten, also »Daten über Daten«, sind die perfekte Lösung für diesen Zweck. Wenn ein Datenobjekt mit Metadaten verknüpft ist, welche dessen Anforderungen enthalten, kann das Speichersystem diese mit den Datendiensten adressieren, wie in der Grafik hzu sehen ist.

Die Anforderungen können zwar immer noch außerhalb des Datenpfades transportiert werden, aber dieses Bedürfnis lässt sich durch Automation eliminieren. Mit SDS kann sich der Administrator mit höherwertigen Aufgaben wie der Definition von Regeln befassen, und muss seine Zeit nicht mehr mit der Lösung kurzfristiger Probleme verbringen, die die Service Level senken.

Software-defined Storage: eine Übersicht

Software-Verteiler arbeiten über eine Daten-Management-Schnittstelle (beispielsweise CDMI), um die Anforderungen für die von ihnen kontrollierten Daten zu vermitteln. Sie erreichen die gewünschten Service-Level durch eine Kombination der SDS-Lösung und der Administratoren.

Heute fasst SDS Ressourcen in Pools zusammen. Die Eigenschaften der Datendienste werden auf die Daten angewendet, um die Anforderungen an Service-Level zu erreichen und zu halten. Neue Ressourcen werden zu Pools hinzugefügt, wo man diese benötigt, und ausgefallene Komponenten und Systeme werden aus den Pools genommen, bis sie repariert sind.

Das SDS-Konzept auf einen BlickSDS bevorzugt eine standardisierte Speicher-Verwaltungsschnittstelle (beispielsweise SMI-S), um die Verwaltung der Ressourcen und den Umgang mit deren Eigenschaften in verschiedenen Pools zu automatisieren. Dagegen sind heute Verwaltungsschnittstellen von Unternehmensspeichersystemen üblich, und ihre Zukunft vorhersagen zu wollen ist verfrüht. Hinzu kommt, dass es zahlreiche Open-Source-APIs gibt, die sich zu einer Art Standard entwickeln (zum Beispiel OpenStack »Cinder«).

Zu guter Letzt ermöglicht es SDS dem Administrator, über abstrakte Schnittstellen Pools zu verwalten, neue Ressourcen zuzuweisen, Regeln aufzustellen und Service-Level zu definieren.

Metadaten in CDMI

Das »Cloud Data Management Interface« (CDMI) nutzt viele unterschiedliche Arten von Metadaten, inklusive HTTP, Datensysteminformationen, Benutzerdaten und solche von Speichersystemen. Um die Anforderungen von Unternehmensanwendungen und der von ihnen verwalteten Daten zu erfüllen, erlaubt die Nutzung von Metadaten CDMI, Einfachheit durch eine Standardschnittstelle zu bieten. CDMI nutzt bereits vorhandene SNIA-Standards wie die »eXtensible Access Method« (XAM) für die Metadaten eines jeden einzelnen Datenelementes. Im Speziellen bietet XAM Metadaten, über welche sich Compliance und eDiscovery sicherstellen lassen.

Die Nutzung von Metadaten durch CDMI geht über die an individuellen Datenelementen hinaus bis hin zu Datencontainern. Damit übernehmen sämtliche Daten automatisch auch die Metadaten des Containers, in welchem sie abgelegt sind. Auch ein neuer Untercontainer, der in einem Container erstellt wird, »erbt« dessen Metadaten. Natürlich lassen sich diese Metadaten auch nach Wunsch überschreiben.

Die Erweiterung der Metadaten zur Verwaltung von Containern, nicht nur von Daten, ermöglicht eine deutliche Reduzierung des Verwaltungsaufwandes von Speicherkomponenten und damit deutliche Kostensenkungen. Durch die Unterstützung von Metadaten über eine Cloud-Speicher-Schnittstelle und die genaue Beschreibung, wie Speicher- und Daten-Metadaten zu interpretieren sind, um die Anforderungen des Gesamtsystems zu erfüllen, wird die Einfachheit bewahrt, die von einem Cloud-Speicher-Paradigma gefordert ist, während die Anforderungen an Unternehmensanwendungen und ihre Daten erfüllt werden können.

SDS als integraler Bestandteil des Software Defined Data Center

Eine Frage vieler Systemadministratoren ist: Wo passt SDS in mein Rechenzentrum? Eine einfache Antwort ist, sich das Software-defined Data-Center (SDDC) als das Hirn der Hardware-Infrastruktur vorzustellen, welches unausweichlich hinter einer Cloud oder als ein Teil eines mehr traditionellen oder älteren Rechenzentrums läuft. Aus einer höheren Warte betrachtet besteht SDDC aus drei Komponenten.

Software-defined Compute ist eine virtualisierte Rechenumgebung, welche alle Computing-Schichten von SDDC bereitstellt. Software Defined Network bietet eine weniger komplexe Umgebung für seine Umgebung. Software Defined Storage bietet eine weniger komplexe Umgebung zur Speicherverwaltung. Alle drei werden für den Betrieb eines wohlabgestimmten Software-defined Data-Center benötigt. Kurz gesagt ist SDS ein integraler Bestandteil eines SDDC.

Bislang nur der Wille zum Standard

Noch ist der Standard weder bestätigt noch in Kürze in Aussicht gestellt. Und das heißt, dass der Weg hin zu SDS oder SDDC noch steinig und lang werden könnte, sowohl für die Anwender als auch für die Anbieter. Ohne gleichstellende Merkmale ist es für den Anwender bzw. IT-Verantwortlichen schwierig, die einzelnen Vorteile oder Alleinstellungsmerkmale von Lösungen zu identifizieren. Im Umkehrschluss macht es dies diffizil für die Hersteller wirklich mit den Vorteilen ihrer Lösung hausieren zu gehen. Vorteile haben alle derzeitigen Lösungen, wirklich heterogen und allumfassend sind aber die wenigsten. Deswegen muss der geneigte SDS-Interessent genau prüfen, was er mit einer SDS-Lösung erreichen will und welche Hersteller dies wirklich leisten können.

.