Starnberg, 23. Mai 2013 - Wie grenzt sich Software Defined Storage (SDS) von den bisherigen Storage Software Lösungen ab und wo liegen die Vor- und Nachteile...
Um was geht es? SDS als Begriff ist interpretationsbedürftig und deshalb hier der Versuch einer objektiven Klärung: Storage-Services, die sich bislang im Microcode des Arraycontrollers befinden, werden nun auf eine plattformunabhängige Storage Software - Kontrollebene verlagert. Die Software läuft dann entweder auf einem dedizierten x86(Storage-) Server als Appliance (Software-based Storage) oder als Storage Hypervisor und Software Defined Storage (SDS) direkt beim Hypervisor der Servervirtualisierungs-Software (VMware / Microsoft Hyper-V). Letztgenannte Lösungen benötigen dann allerdings diese Hypervisor-Technologien - sprich hochgradig virtualisierte Server - während Hardware-Arrays und Software-based Storage-Lösungen natürlich darauf nicht angewiesen sind. Übrigens ist die Sache nicht neu: die erste kommerziell stark verbreitete Software-Storage Lösung war der Veritas Volume Manager für Sun Solaris, u.a. auf Grund verschiedener Subsystem-unabhängigen Leistungsmerkmale.
In einem konsequent Software-definierten Rechenzentrum jedenfall entsteht mit Hilfe SDS oder Software-based-Storage eine zentrale systemweite Speicher-Verwaltungsinstanz, die nun nicht mehr von spezifischen Funktionen einzelner Storage-Subsysteme abhängig ist. Die „Control Plane“ regelt das Management (Provisioning, LUN configuration, Tiering, Deduplizierung, Snapshots, Replikation usw.) aller in dieser Umgebung angeschlossenen Speichersysteme wie RAID-Arrays, JBODs oder auch in Servern angeschlossener Storage (SSD, Caching). Software-based Storage ist derzeit überwiegend mittels heterogener Storage Virtualisierung auf Storage Servern oder Appliances wie z.B. IBM SVC (Block), Red Hat Storage Server (File, Object), Datacore (Block) oder FalconStor NSS im Einsatz (während der Fokus hier auf Block- bzw. Dateiebene liegt, soll eine erweiterte SDS-Architektur in Zukunft jedoch davon unabhängig alle Typen wie File, Object, Block, SAN, NAS, DAS) zu transparenten Ressourcenpools aggregieren können).
Aus Sicht des Server-/System-Managements wird in einem hochgradig virtualisiertem RZ mit SDS das Storage Management natürlich dann beim Virtualisierungs- und Verwaltungslayer wie z.B. VMware vSphere, Hyper-V oder entsprechenden Linux-Varianten angesiedelt (Integrationsaspekte). Storage Verantwortliche sehen das (je nach RZ-Umgebung) anders und diese Divergenz trotz techn. Konvergenz wird uns in Zukunft aus betrieblich-/organisatorischer Sicht noch beschäftigen. Jedenfalls: wie gesehen wird durch das Zusammenfassen von z.B. externen und internen Storage Ressourcen-/Serverfestplatten die Speicher- und CPU-Ressourcen gemeinsam verwaltet; das Data Management erfolgt auf Appliance- oder direkter Virtual Machine - Ebene. Die Herausforderung liegt bei letzterem im I/O-intensiven und datenseitig schnell wachsenden Anwendungsbereichen und beim Server-I/O und Netzwerk. Stichwort: skalierbares Workload-Management (balanced I/O) - weshalb derzeit Infrastrukturseitig (clustered SANs) und die neuen Ethernet-Fabrics (8/16 G FC, 10 GBE) in Bezug auf Leistung, Skalierbarkeit und Flexibilität im Configuration-/Change Management punkten (s.a. TCO).
Wir sprechen in dem Zusammenhang meist von traditionellen Workloads - sprich Standard-Unternehmensanwendungen im SAN-NAS-Unified, die im Bereich des Datenwachstums noch relativ moderat agieren (25% - 35% p.a.). Rein unstrukturierte sehr große Datenpools, die mit 50% p.a. oder deutlich mehr wachsen, benötigen andere Ansätze wie (Cloud-) Object Storage, der in einem der nächsten Blogs diskutiert werden soll.
Unterschiedliche Ansätze bei der Storage Virtualisierung:
1. Wie bisher das klassischer Array- oder Appliance-basierte Konzept etablierter Hersteller wie EMC, NetApp, IBM, Oracle (Pillar, ZFS), Dell, HDS, HP etc., bei dem das Storage Management im Subsystem-Controller (Paare oder n-node Cluster / SAN-NAS-Unified) oder in einer dedizierten, herstellerspezifischen Appliance-Hardware angesiedelt ist (z.B. IBM SVC, Oracle).
2. Das rein Software-basierte Modell von Anbietern wie Red Hat, Nexenta (ZFS), Datacore, FalconStor etc., welches auf Standard x86-Servern (Windows, Linux) läuft.
3. Das SDS-Modell von Herstellern wie VMware (Virsto) bei denen die Controlplane im Hypervisor liegt. Eine weitere Variante stellt die neue EMC ViPR Software-Defined Storage Platform dar:
Anders bei der Virsto - Hypervisor-Lösung ist aus Storagesicht das Management auf VMDK/VHD- und nicht LUN-Ebene mittels dem "virtual machine aware Storage Hypervisor" (hier: ein log-based Filesystem). Bei den genannten Punkten 1) und 2) sind zwei weitere „Geschmacksrichtungen“ zu unterscheiden: a) Auf offenen Standards wie OpenStack basierende neue Lösungen und b) herstellerspezifische Storage-Software Implementierungen: während auf Array-Controllerseite bekanntermaßen eigene Storage Betriebssysteme-/Services mit APIs (SMI-S, VAAI etc.) zum Einsatz kommen (z.B: EMC Enginuity, NetApp OnTap, HP, IBM, Dell, HDS etc.), ist auf der open Software-Seite mit OpenStack zwischenzeitlich ein Linux-basierter, offener Ansatz verfügbar. In Verbindung mit Standard-Server- und preiswerter Storage Hardware lassen sich so je nach Software-Architektur flexible und skalierbar verteilte (scale-out clustered NAS) Speicherlandschaften aufbauen (siehe Red Hat Storage Server). Das Pendant auf der herstellerspezifischen SAN-/NAS-Seite wäre z.B. NetApp OnTap Cluster, IBM Scale-out-NAS / SONAS) oder EMC Isilon.
Es ist zu berücksichtigen, dass aktuell nicht alle SDS-Lösungen hinreichend für alle Anwendungsbereiche gleich gut skalieren (Designaspekte wie Scale-out, Clustering, Latency-/Performance). Manche Systeme sind entwicklungsseitig klar auf ein Scale-Out-Modell und unstruktrierte Daten-/Objekte ausgerichtet (z.B. Red Hat Gluster, IBM GPFS-/SONAS), während andere sich aus der Historie heraus an kommerzielle Workloads im NAS- oder Blockbereich mittels Standard x86 Server-Appliances orientieren (z.B. DataCore, Nexenta ZFS).
VMware Virsto ist als im Hypervisor ablaufende Storage Software in Bezug auf die Flexibilität und Integration mit vorhandenen virtual machine – Umgebungen ein aus meiner Sicht hochintegrierter SDS-Ansatz mit Block-Storage im Backend (low latency), obwohl das Provisioning von VMware-Storage auch mittels NFS Filesystem möglich ist. Detailliertes Know-How beim Management und den Sizing der I/O-Leistung bei unternehmenskritischen Applikationen auf Grund der Komplexität vieler VM-Installationen ist jedoch Anwenderseitig notwendig.
Der Vorteil von Virsto liegt vor allem in der Performance-Verbesserung vorhandener Storage-Ressourcen besonders bei vielen kleinen Random-IO Workload-Profilen bzw. wenn vorhandene Arrays damit an ihre Leistungsgrenzen kommen (Software-only Boost der Anwendung). Applikationen mit überwiegend Random read-/writes oder nur sequential read-/writes hingegen profitieren nicht von der neuen Architektur.
Fazit: über Begriffsdefinitionen lässt sich trefflich diskutieren, aber wenn man schon klassifizieren muss ist aus meiner Sicht der Begriff SDS besser bei Hypervisor-Lösungen aufgehoben, während der Terminus Software-based Storage eigentlich für alle anderen Bereiche gilt. Alles in allem vielleicht keine sehr glückliche Beschreibung, aber wohl im Zeitalter des Software Defined Datacenter nicht zu vermeiden... Aber vielleicht haben Sie ja auch eine Idee zur Positionierung?!
Nachfolgend einige Links zum Thema:
http://de.redhat.com/products/storage-server/
http://www-03.ibm.com/systems/de/storage/software/virtualization/svc/index.html
http://www.nexenta.com/corp/products/what-is-openstorage
http://www.netapp.com/de/products/platform-os/data-ontap-8/enterprise-scale.aspx