Starnberg, 14. Okt. 2016 - Speichervirtualisierung, Software Defined Storage, Container und mehr; welche Anforderungen sich Data & Storage Management-seitig ergeben...

Um was es hier geht: Die Entkopplung der Anwendungsseite von physikalischen Servern (via Hypervisor) und dem Storage (via Storage Virtualization) hat für mehr Flexibilität (Data / Apps Mobility) und Kostenvorteilen nebst weiteren Initiativen zur Standardisierung / Konsolidierung gesorgt. Eine rein Software-basierte Ebene ist in der Breite dafür verantwortlich, funktionale Abhängigkeiten auf der Hardwareseite zu vermeiden und mehr Agilität zu erzielen, erzeugt damit aber auch eine Vielzahl neuer virtueller Instanzen, die in Bezug auf Verwaltung, Sicherung und Monitoring komplexer werden und vor allem sehr schnell wachsen. Ein pro-aktive Infrastruktur-Monitoring (Analytics) Ansatz und ein verstärkter Automatisierungsgrad (Beispiel: AutoQoS mit Flash) werden bei weiter rasant steigenden Datenmengen essentiell. Abhängigkeiten haben sich damit verlagert und neue Entwicklungen wie Container sind bei der Planung bzw. Integration in künftige Storage- und Anwendungsumgebungen hinzugekommen. Man kann also nicht unbedingt sagen, dass Technologien zur Konsolidierung, Virtualisierung und auch das Cloud Computing die Unternehmens-IT nur vereinfachen ;)

Zentralisierung, Kontrolle (s.a. data governance) und mehr Transparenz, Flexibilität und Kosteneffizienz sind deshalb auf der Data & Storage Management - Seite angesagt und Software Defined Storage verspricht Abhilfe. Fast alle großen Storageanbieter sind jedenfalls mit diesen Argumenten auf den Zug aufgesprungen und beginnen sich/ihre Lösungen unter dem Begriff SDS zu positionieren. Deshalb ist es in Bezug auf eine strategisch sinnvolle Planung & Positionierung wichtig zu verstehen, was mit SDS eigentlich gemeint ist und welche Vorteile daraus entstehen.

TCO-seitig kommt der zentralen Verwaltung von Speicher-Ressourcen eine zunehmend wichtigere Bedeutung zu. Software Definierte Infrastrukturen versprechen Hilfe, da durch die Entkopplung der Data Services von der Physik (Speichermedien-/Arrays = Data Plane) eine plattformübergreifende Orchestrierung der heterogenen Speicherinfrastruktur leichter möglich wird. Im Software-definierten Rechenzentrum werden alle Storage Services auf eine unabhängige Software - Kontrollebene (= Control Plane) verlagert. Damit entsteht eine zentrale systemweite Verwaltungsinstanz, die nicht von spezifischen Funktionen einzelner Storage Subysteme abhängig ist. Die Control Plane regelt das Management (Provisioning, LUN-Konfiguration, Access, Deduplizierung, Komprimierung, Snapshots, Replikation usw.) aller in dieser Umgebung angeschlossenen Speicher.

• Dies schließt natürlich das Vorhandensein von „Hardware Defined Storage“, also dedizierten Speichersystemen z.B. für virtualisierte Workoads und bestimmte Anwendungen wie Big Data Apps, Datenbanken, VDI etc. nicht aus (es gibt heute noch nicht die „Eierlegende Speicher Wollmilchsau" ;).

• Ein zweiter Punkt betrifft jedoch das Handling von aktuellen und vor allem künftigen Anwendungs-Workloads, die auf Grund der Datentypen (un-/semi-hochstrukturiert) nach extrem skalierbaren, flexiblen und hochleistungsfähigen Data Storage Systemen (z.B. block, file, object - mix und cloud storage) verlangen.

Ein weiterer Weg besteht im logischen Zusammenfassen von internen Serverfestplatten, um Storage- und CPU-Ressourcen gemeinsam zu verwalten (Stichwort: hyperconverged); das Data Management erfolgt hier im Rahmen von Direkt Attached Storage auf virtual machine - level (Server-centric virtual Storage anstelle von FC SAN Storage) oder über externe Software Tools. Entscheidend ist hier jedoch der speicherbezogene Funktionsumfang, die Skalierbarkeit von nativen VM-Filesystemen sowie die Kapazitäts- und Performanceanforderungen für I/O-intensive und schnell wachsende Anwendungen (siehe Server I/O Verhalten; Netzwerkengpäße, skalierbares Workload-Management mit balanced I/O, Apps Response times, Latenzen...). Konvergente Infrastrukturlösungen setzen beim Storage I/O auf VM-optimierte Architekturen, die allerdings ihre eigene Verwaltungslogik mitbringen und im Zusammenspiel mit vorhandenen (Speicher-) Landschaften zusätzliche Komplexität erzeugen können.

Der Terminus SDS kann vor diesem Hintergrund jedenfalls ziemlich unterschiedlich aufgefasst werden... auch weil er teilweise mit dem Begriff Storage Virtualisierung vermischt, sich auf ganz unterschiedlichste Anwendungsfälle bezieht (z.B. I/O-Performance Optimierung Software). Wenn man versucht, die derzeitigen Lösungsangebote zu strukturieren, habe ich nach folgender Logik unterschieden:

1. Reine Softwarelösungen mit größtenteils proprietären Filesystemen ohne wesentliche Hardware-Präferenz-/Bindung mit Schnittstellen (APIs) zu Cloud-Umgebungen wie VMware, S3, REST, Docker oder OpenStack (Cinder, Swift...). Meist als block-, aber auch file/object storage (Commodity HW / x86 of the shelf und Hypervisor-neutral) wie von Datacore, FalconStor, Hedwig, IBM Spectrum Scale, Scality, IBM CleverSafe, Quantum StorNext usw. (kein Anspruch auf Vollständigkeit!).

2. Offene SDS-Architekturen unter open source Linux (file, block, object) wie Red Hat Storage (Ceph, GlusterFS), BeeGFS, QueByte, Nexenta (ZFS), Lustre etc. auf Basis Commodity-Hardware und typischerweise als clustered, distributed scale-out und-/oder shared nothing Architektur aufgebaut.

3. Software mit direkter Hardwarebindung (Appliance-Charakter) wie IBM SVC (Spectrum Virtualize), Oracle ZFS, Dell EMC (Isilon, Nexenta, Scality, EMC ViPR), Fujitsu (Red Hat/DataCore/FalconStor), NetApp SolidFire / virtual Cloud ONTAP usw. Meist als block oder file, seltener als Object Store über scale-up oder zunehmend distributed scale-out Architektur.

4. Kommerzielle konvergente (integrierte) bzw. hyperkonvergente Systeme stellen eine hardwarebezogene Variante dar, bei der das Storage Management unterhalb oder parallel zur Hypervisor-Ebene (KVM, Hyper-V, VMware oder eigener Hypervisor) stattfindet. Hyperkonvergente Systeme nutzen CPU- und Storage Ressourcen gemeinsam (Direkt Attached) innerhalb einer integrierten Umgebung (nicht über ein "shared SAN"). Beispiele sind: Cisco NetApp, HPE, Oracle, Dell EMC, IBM, HDS, Fujitsu, Nutanix, SimpliVity, Scale Computing StorMagic, Sanbolic etc. Wenn der Storage dieser Systeme über APIs von einer zentralen SDS-Lösung mitverwaltet werden können, kann man von einem Software Defined Datacenter (SDDC) Ansatz mit Schwerpunkt Storage sprechen.

5. Virtual Storage Appliances (VSAs) als 100%-ige Software-Implementierungen sind logisch beim Hypervisor angesiedelt mit Integration in den Virtual Machine Mgmt. Stack (z.B. vSphere Data Services). Anbieter wie HP mit StoreVirtual VSA, NetApp mit ONTAP Edge VSA, Nexenta über Connect for vSAN, FalconStor oder auch DataCore nutzen dabei die Vorteile einer engen Verzahnung mit dem Hypervisior und dessen Mobilitätsfunktionen für Migrations- und Verfügbarkeitszwecke, meist für VMware und Hyper-V. Jedoch sind diese VSA-Angebote meist nicht wirklich für sehr große skalierbare Performance-Anforderungen im Verbund mit den hierfür notwendigen Data Services ausgelegt (Enterprise Class Deduplication, Thin Provisioning etc.); sie adressieren derzeit den Bereich der mittleren Leistungsanforderungen (preiswerte Bundles mit Server-HW ohne FC-Komponenten auf Basis iSCSI unterstreichen diesen Ansatz).

Abb. 1: Welche IT-Projekte derzeit OpenStack Technologien einsetzen / Quelle: OpenStack User Survey, 2016 / openstack.org (57% nutzen dannach Cinder Block Storage produktiv).

Ein erstes Fazit: Der Begriff Software Defined Storage ist leider sehr allgemein gefasst und kann verwirren. Aber gleich, welche Form gewählt wird: Software Defined Datacenter Entwicklungen in Verbindung mit Cloud Computing werden durch die zunehmende Konvergenz von Servervirtualisierung, SDN und SDS beschleunigt. Kritische Punkte betreffen dabei das End-to-end Management (vor allem auch in die Cloud), Betriebssicherheit (Robuster 24x7 Betrieb), Enterprise Support und Standardisierung (siehe S3 / OpenStack). Gegenüber einer oft skizzierten technologischen Konvergenz (eine einheitliche Plattform) werden sich aus meiner Sicht wohl noch für lange Zeit weiterhin unterschiedliche, herstellerspezifische Plattformen (Software, Hardware, integrierte Stacks) am Markt befinden, da die Anforderungen und Bedürfnisse der Kundenanwendungen und Unternehmensziele doch jeweils sehr spezifisch sein können.

Abb. 2: Bildquelle Red Hat Storage Studie / Vanson Bourne, 2016. Storage and Innovation

Quelle > https://www.redhat.com/de/technologies/storage

Abb. 3: Bildquelle Red Hat Storage Studie / Vanson Bourne, 2016. Are your current (storage) solutions future-proof?