Suchen

Online-Umfrage zum Schwerpunkt Software Defined Storage - Markus Smieja, Teil 1

Ein ordentliches Sizing ist wichtig

Seite: 2/2

Firmen zum Thema

Was ist notwendig, damit SDS über mehrere unterschiedliche Speichersysteme hinweg funktionieren kann?

Smieja: Durch den Einsatz von Storage-Virtualisierung als Mittel zum SDS ist primär ein ordentliches Sizing wichtig, um sich durch den Segen der Funktionen keinen Bottleneck einzufangen. Des Weiteren sollte man das Thema Management nicht unbetrachtet lassen, denn viele Systeme haben auch viele GUIs und Begehrlichkeiten. Wenn diese zwei Aspekte befriedigt sind, kann es sofort losgehen. Ein klassisches Deployment einer Storage-Virtualisierung kann innerhalb eines Tages erledigt sein.

Was unterscheidet SDS von einem heterogenen Storage Pool und was könnte SDS besser machen als Automated Storage Tiers?

Smieja: Die Antwort auf beiden Fragen ist dieselbe: Beide Funktionen, „Storage Tiering“ und „Storage Pooling“ enden im Regelfall an den Außenkanten des Subsystems: Sie sind nicht über weitere separate Einheiten desselben oder gar unterschiedlicher Hersteller miteinander kompatibel. Konkretes Beispiel: Ein fast abgeschriebener Storage wird durch eine Funktion des SDS „beschleunigt“ – etwa Safecache mit Violin Storage im IPStor. Hierzu wird nur ein kleiner Teil der Kapazität des vorhandenen Storage in neuem SSD Storage vorgeschaltet. Durch diese „Frischzellenkur“ kann der bereits getätigte Invest noch weiter genutzt werden.

Müsste man nicht, noch vor SDS, ein einheitliches Datencontainer-Konzept umsetzen?

Smieja: Das ist ja bei den meisten Kunden gar nicht oder nicht mehr möglich, da durch den Kostendruck nicht ständig neue Systeme angeschafft werden können und bestehende Systeme solche Funktionen kaum unterstützen. In Kombination mit Server-Hypervisoren ist diese Vereinheitlichung sicher leichter, da hier beispielsweise VMFS-Filesysteme das bereits bewerkstelligen.

Kann man SDS auch ohne Software-defined Networking und Software-defined Computing betreiben?

Smieja: Natürlich. Alle drei Komponenten (Storage, Networking, Computing) plus „Software-based facilities“ stellen das von IDC beschriebene Modell eines Software-defined Datacenters dar. Die Kunden haben schon mit dem Einsatz von Server-Hypervisoren erlebt, welche Einsparpotenziale sich in der Hardware allerorts ergeben – das geht mit SDS ebenso. Nicht jeder Kunde wird alle Teile des Software-defined Datacenters nutzen und kann sich für jeden Baustein separat entscheiden.

Kann SDS auch Cloud-Storage miteinbeziehen?

Smieja: Ja, diese Kombination bietet erhebliche Funktionalitätsgewinne. Schon seit einiger Zeit stellen wir fest, dass Kunden bestimmte Daten in die Cloud „verlagern“ oder auch nur für den „Fall der Fälle“ dort abgelegt wissen möchten. Natürlich nutzen die Daten ohne die Server für die Produktion wenig, aber auch hier gibt es hervorragende Lösungen: Replizieren Sie die Daten doch gleich mitsamt den Servern kontinuierlich in die Cloud, um im Desaster-Fall eine komplette Umgebung dort starten zu können. Tools wie beispielsweise unser Recovertrac können das unter Nutzung von IPStor-SDS-Funktionen bereits heute.

Warum sollte ausgerechnet SDS die Evolution von Storage-Services sein?

Smieja: Gegenfrage: Warum nicht? Der Vorteil, dass SDS-Funktionen für alle und in gleicher Qualität zeitgleich dargeboten werden, ist nicht von der Hand zu weisen. Die Zeiten während man in „Villarriba“ noch sinniert und entwickelt, aber in „Villabajo“ schon fertig ist, sind mit SDS vorbei: Alle feiern das Fest mit denselben Werkzeugen zur gleichen Zeit – und gemeinsam feiern ist eh am schönsten, oder?

(ID:42317238)