München, Starnberg, 20. Nov. 2019 - Ein Beitrag zur Diskussion um das "Für und Wider" von SDS versus spezialisierter Speicherhardware inklusive Software (Array)...
Zum Hintergrund: Seit einigen Jahren werden bereits Diskussionen um das Für und Wider von SDS versus „integrierte Storage Appliances“ (hier hauptsächlich im Bereich Enterprise Block-Storage als Array Subsystems) geführt. Unabhängig von Definitionsfragen** betonen Anbieter von Software Defined Storage wie VMware (vSAN), SUSE Storage, Red Hat Storage, Veritas oder DataCore, um hier nur einige Softwarefirmen zu nennen, dabei die Vorteile des agilen Software Definierten, hochvirtualisierten Speicheransatzes, insbesondere weil sich damit Silos beseitigen und Hardware‑Abhängigkeiten lösen lassen.
Meist wird in diesem Zusammenhang auf die Reduzierung der Hard- und Softwarekosten (TCO) beim SDS-Einsatz verwiesen. Um das Kapazitätswachstum bestehender und neuer Workloads zu berücksichtigen, müssten IT-Teams deutliche Teile ihres Jahresbudgets für diese Investitionen aufwenden (Capex), weil eine einfache Erweiterung der bestehenden Speicher-Infrastruktur oft nicht ausreicht. SDS hingegen erlaubt eine einheitliche, intelligente und agile Speicherumgebung – unabhängig von Anbieter und Architektur.
Anbieter von integrierter Speicher-Hardware und Software („Physical Storage“) argumentieren je nach Lösungsangebot naturgemäß in eine etwas andere Richtung und es ist hilfreich, die Argumente an Hand eines konkreten Beispiels wiederzugeben. Im folgenden Beitrag von Berthold Höflich, Sales Direktor für Deutschland und Österreich bei Infinidat (1) zum Thema „Software Defined Storage in agilen Infrastrukturen“ wird aus Sicht des Verfassers versucht, auf einige Widersprüche und vielleicht auch Gemeinsamkeiten von SDS vs. dezidierter Speicherhardware-/Software einzugehen. Laut Höflich stellt sich am Ende die Frage, ob SDS künftig wirklich die überlegene Technologie ist, oder ob es Alternativen im Bereich der Enterprise Speicher-Appliances gibt.
Zum Gastbeitrag: „Software Defined Storage (SDS) flexibilisiert Speicherlösungen und bietet mehr Agilität, eine bessere Leistung und gleichzeitig eine höhere Skalierbarkeit. Wie jeder softwaredefinierten Technologie, liegt auch ihr eine richtlinienbasierte Bereitstellung und Verwaltung ihrer Ressourcen zugrunde. Die Funktionsweise ist dabei weitgehend unabhängig von der zugrundeliegenden Hardware. Daher ließe sich der Speicher viel flexibler verwalten als dies bei einem physikalischen Storage-Ansatz möglich wäre. Mittlerweile kommt für die Unterstützung dieser administrativen Aufgaben auch maschinelles Lernen und künstliche Intelligenz zum Einsatz. Software Defined Storage lohnt sich dabei durchaus. Denn mit ihr können Unternehmen eine höhere Fehlertoleranz, eine standardisierte Hardware-Infrastruktur und schnellere Hardware-Aktualisierungszyklen zu niedrigeren Anschaffungskosten realisieren. Zudem müssen sie keine Herstellerbindung eingehen, da Software Defined Storage auf Standard-Schnittstellen setzt.
Jedoch hat sich Software Defined Storage noch nicht im vollen Umfang durchgesetzt. Da stellt sich die Frage, ob es wirklich die überlegene Technologie ist, oder ob Alternativen die Nase vorn haben.
Schleppende Einführung
Gewöhnlich wird Software Defined Storage in hyperkonvergenten integrierten Systemen (HCIS) verwendet. Auch am Rand von IoT-Infrastrukturen sowie für die Etablierung kostengünstiger scale-out Sekundär-Storage-Arrays findet sie ihre Anwendung. Da IT-Entscheider immer noch dazu neigen, Software Defined Storage immer noch nicht vollumgänglich zu vertrauen – besonders wenn hauptsächlich unstrukturierte Daten zunehmen, die auf preiswerten lokalen Medien oder in der Cloud gespeichert werden können – kommt Software Defined Storage hauptsächlich in geschäftskritischen Anwendungen zum Einsatz.
Zusätzlich wird die Verbreitung von Software Defined Storage dadurch erschwert, dass einige Hersteller die entsprechenden Lösungen nicht sehr aktiv vermarkten. Das ist verständlich, denn ihre Kunden haben bereits große Summen in klassische Storage Arrays investiert. Dies ist eine Einnahmequelle, die diese Hersteller natürlich nicht in Gefahr bringen möchten. Es gibt daher sogar Fälle, in denen anwendende Unternehmen den Storage-Anbieter aktiv auffordern müssen, um ein Angebot über Software Defined Storage zu erhalten. Diese Vorgehensweise wird solange erhalten bleiben, bis dsie auf entsprechende Gegenangebote des lokalen Wettbewerbs reagieren müssen.
Agilität nur theoretisch erreichbar
Einer der Hauptargumente für den Einsatz der Software Defined Storage ist, die Speicherung von Daten agiler durchführen zu können. Jedoch wird dieser Vorteil in der Praxis kaum genutzt. Denn der Datenaustausch zwischen Arrays oder Rechenzentren ist ein sehr zeit- und ressourcenaufwändiger fehleranfälliger Prozess. Um diesen Problemen aus dem Weg zu gehen, entscheiden sich Administratoren oft dafür, dass die Daten dort verbleiben, wo sie anfangs gespeichert wurden – trotz dem Umstand, dass dieser Speicherplatz nicht mehr der kostengünstigste ist.
Skalierbarkeit mit Hindernissen
Auch die Skalierbarkeit als ein weiteres Argument für Software Defined Storage verliert an Glanz. Da dieselbe SDS-Array-Software, die für den Betrieb der Anbieter-Arrays eingesetzt wird auch für spezielle SDS-Instanzierungen eingesetzt wird, sind diese nicht unbedingt skalierbarer. Allerdings kann eine höhere Skalierbarkeit bei Scale-Out-SDS-Instanziierungen gewährleistet werden. Aber nur wenn einige Bedingungen erfüllt sind. So müsste eine Scale-Out-SDS mit niedrigeren Betriebs- und Anschaffungskosten zu Buche schlagen als Storage-Arrays. Dazu müssten sie Leistung linear skalieren können und über ein konstantes Performance-Verhalten bei einer hohen Zahl von Knoten verfügen. Außerdem sollte der gleichzeitige Betrieb asymmetrischer Knoten verschiedener Generationen im selben Cluster reibungslos verlaufen. Falls aber ein Unternehmen auch aufgrund schneller Modellwechsel bei Servern, SSDs und Festplatten eine Just-in-Time-Upgrade-Strategie definiert hat, ist dieser reibungslose Betrieb fast nicht mehr möglich. Den Leistungs- und Kapazitätsbedarf können Scale-up-Arrays in diesem Fall nicht mehr sicherstellen.
Lebensdauer relevant?
Software Defined Storage verspricht in aller Regel eine höhere Leistung sowie Lebensdauer. Letzteres dürfte aber in der Realität kaum punkten. Denn in einer Umgebung, in der Komponenten ohnehin laufend getauscht werden, riskieren Administratoren es nicht, eine davon bis zur letzten Reserve auszureizen. Daher wirken sich beispielsweise 30 Prozent zusätzliche Lebensdauer über dem schlechtesten Wert kaum aus. Außerdem müssen IT-Entscheider auch die laufenden Betriebskosten in ihre Kalkulation mit einbeziehen, da diese den Preisvorteil in der Anschaffung übersteigen können.
Stabiler Betrieb erfordert Fehlertoleranz
Bei ähnlicher Leistung und Kapazität verfügen Scale-Out-Architekturen über mehr Komponenten als Scale-Up-Arrays. Deswegen müssen sie eine höhere Fehlertoleranz bei einer vergleichbaren Kapazität bieten. Die häufigste Ursache für Fehler sind dabei Ausfälle der Speichermedien, etwa Festplatten und SSDs. Diese sollten entsprechend behandelt werden können, ohne dass die Datenintegrität gefährdet wird. Insbesondere sollte der Umstand berücksichtigt werden, dass Ausfälle von Speichermedien eine längere Wiederherstellungszeit in Anspruch nehmen können als Ausfälle von Rechnern oder im Netzwerk. Falls eine Komponente ihre Funktion einstellt, wird die laufende Anwendung von einem definierten Checkpoint wieder neu gestartet. Dies kann bei einem Fehler, der im Software Defined Networking (SDN) auftritt, länger dauern als die Wiederherstellung und der Neustart der abgebrochenen Applikation. Jedoch nimmt dies immer noch weniger Zeit in Anspruch als die Wiederherstellung nach einem Verlust der Datenintegrität in einer Software Defined Storage.
Alternativen zu Software Defined Storage
Doch welchen Weg können IT-Entscheider gehen, um sowohl die Vorteile von Software Defined Storage in einem agilen Umfeld zu nutzen, ohne die Nachteile in Kauf nehmen zu müssen? Hier bieten hardwarebasierte Storage-Lösungen eine Alternative. Denn diese bieten eine standardisierte Hardware-Infrastruktur und gleichzeitig dieselbe oder eine sogar noch höhere Flexibilität, als es Software Defined Storage vermag. Ein Beispiel dafür ist die InfiniBox. Diese verfügt über mehr Kapazität, als der Anwender zum Zeitpunkt der Implementierung benötigt. In Rechnung gestellt wird aber nur der tatsächlich in Anspruch genommene Speicherplatz. Ändert sich nun der Bedarf des Anwenders, kann er schnell und bequem weitere Kapazität freischalten lassen. Verringert sich der Bedarf wieder, kehrt er zum vorigen Volumen zurück. Vorteil dabei ist, dass der nicht genutzte Speicherplatz jederzeit als Sicherheitspuffer vorliegt und im Spitzenbetrieb flexibel abrufbar ist.
Ein weiterer Vorteil ist die Stabilität im Betrieb. Die hardwarebasierte Storage-Lösung administriert sich selbst. Im Gegensatz dazu benötigt eine Software Defined Storage schon einiges mehr an Eingriffen durch die IT-Administratoren. So können bereits menschliches Versagen und Softwarefehler weitestgehend ausgeschlossen werden, die in der Praxis für 80 Prozent der Ausfallzeiten verantwortlich sind. Überdies bieten die hardwarebasierten Storage-Lösungen auch dadurch eine höhere Flexibilität, da die Daten im Grunde dort verbleiben, wo sie erstmals hinterlegt werden. Der fehleranfällige und zeitaufwändige Prozess der Datenübermittlung zwischen Speicherknoten und Arrays entfällt weitgehend.
Prinzipiell sollten IT-Entscheider vor der Evaluierung eines Software Defined Storages auch die spezialisierten Storage-Angeboten in Betracht ziehen, das als in sich geschlossenes System einen stabileren und performanteren Betrieb bietet.“
(1) Das Foto zeigt Berthold Höflich, Infinidat Sales Direktor für Deutschland und Österreich (Bildquelle: Infinidat).
Querverweis:
Storage Consortium Blogpost > Zum Einfluss von Digitalisierung auf das Datenmanagement und IT-Infrastrukturen
** SNIA SDS Definition: Virtualized storage with a service management interface. SDS includes pools of storage with data service characteristics that may be applied to meet the requirements specified through the service management interface. Link > https://www.snia.org/sds
Abb. 1: SNIA SDS Übersicht (Bildquelle: SNIA).