Starnberg, 12. Mai 2014 - Worauf bei der Planung von Flash Storage für virtuelle Serversystemen zu achten ist...

Um was er hier geht: IT-Planer müssen das rasche Wachstum von virtuellen Maschinen (VM) auch Speicher- und Netzwerkseitig in Bezug auf einen skalierbaren und berechenbar robusten I/O-Stack berücksichtigen. Effektiv umgesetzt, ist Flash Storage bei I/O-Problemen virtualisierter Anwendungen deshalb zunehmend von Bedeutung... Flash soll dabei möglichst nahtlos in die virtualisierte Infrastruktur einzubinden sein; dies gilt auch für die Ausfallsicherheit und Verfügbarkeit von Anwendungen bei 24 x 7 Workloads innerhalb von Rechenzentrums-Umgebungen. Wenn sehr viele VMs gleichzeitig um die I/O- Ressourcen des Speichers konkurrieren, ist die Skalierbarkeit der Speicher- und Netzwerk-Infrastruktur beim Datendurchsatz entscheidend und weniger dessen Kapazität. Ein Manko, das bei HDD-Storagesystemen bislang öfter auftritt: ein Mehr an I/O bedeutet i.d.R. mehr Kapazität, die jedoch dann nicht immer in dem Maß benötigt wird. Die Granularität und Skalierbarkeit einer Performance-optimierten Speicherlösung stellt also ein wichtiges Beschaffungskriterium dar.

Nachfolgend kurze Übersicht zu den derzeit gebräuchlichen Implementierungen von Flash Storage:

1. All-Flash Arrays:

100% Flash garantiert konstant höchste Anwendungsleistung, allerdings ist die Wirtschaftlichkeit auf Grund der höheren Beschaffungskosten (CAPEX) nicht immer gegeben. Da alle Applikationsdaten auf Flash gespeichert sind, müssen Administratoren nicht ständig aktiv eingreifen und die virtualisierte Applikationen I/O-seitig überwachen (OPEX). Zu beachten: nicht alle VMs benötigen immer die höchste I/O-Performance (Kostenaspekt) oder sie verfügen über Anwendungen, die extrem schreib-intensiv sind (= höhere Belastung der NAND Zellen).

2. Hybrid Arrays:

Flash-Speicher wird mit konventionellen Festplatten gemischt. Das Array verfügt in der Regel über Auto-Tiering Software im Controller (oder Server), um Hot-Files auf schnellen Flash Storage zu migrieren (Caching-Ansatz). 

Beim Cache-Miss (Hot Data sind nicht mehr im Flash) entstehen allerdings negative Auswirkungen auf die Anwendungsleistung. Dies gilt insbesondere, wenn anstelle von 15K RPM SAS-/FC HDDs hochkapazitative SATA Laufwerke zum Einsatz kommen.

3. Server-based Flash:

Je näher Flash an die Anwendung rückt, desto geringer die Latenzzeiten beim I/O. PCIe Flash im Server ist sehr schnell, aber als Direct Attached Device (DAS) wenig skalierbar und bei einem Ausfall des Systems potentiell ein Single-Point-of-Failure. Neuere Lösungen fassen verschiedene PCIe-Flash-Systeme über mehrere Server zu einem logischen Flash-Pool zusammen, was die Ausfallsicherheit und das dynamic Workload-Management deutlich verbessert.

Ein Trend geht zu kommerziellen Clustered-Server-Storage (über RDMA), um einen erweiterbaren Flashpool als Tier-0 Storage über High-Speed-Verbindungen (Memory-zu-Memory Channel) bereitzustellen. Server-based Flash lässt sich, die richtige Software vorausgesetzt, effektiv mit All-Flash, Hybrid-Konzepten oder HDD-Arrays kombinieren.

4. Konvergente Systeme

Durch die Integration von Flash-Speicher-, Netzwerk, Server und Virtualisierung innerhalb einer Box sind diese Angebote bereits ab Werk optimiert für virtuelle Server-Umgebungen. Die Idee dahinter ist, die Komplexität der Infrastruktur und ihre Bereitstellung zu vereinfachen und die Betriebskosten zu reduzieren. Dagegen stehen Herstellerabhängigkeiten, begrenzte Flexibilität bei der Skalierung und je nach Anbieter zum Teil hohe Anschaffungskosten (CAPEX / Lizenzen). Speicherverwaltung und Kosten (OPEX / TCO) bei Flash Storage Systemen.

Unabhängig von den genannten Möglichkeiten bedeutet der Einsatz von All-Flash fast immer auch die Umstellung auf die Storage-Management-Services des jeweiligen Anbieters, also z.T. kostenpflichtige  und herstellerspezifische Dienste wie Replikation, Thin Provisioning, Deduplizierung-/Komprimierung und Snapshots. Speicheradministratoren müssen sich dann von ihrer bislang gewohnten Umgebung verabschieden und ggf. Prozesse (Backup, Disaster Recovery) geändert-/angepasst werden. Auf der Netzwerkseite kann das bedeuten, z.B. Fabric-Switches aufzurüsten, um den zusätzlichen I/O-Traffic bewältigen zu können. Diese Aspekte sollten neben den Beschaffungs- und Betriebskosten bei der Planung eines „balanced systems“ berücksichtigt werden.

• Zusätzlich zu den Kosten für eine neue Storage-Plattform gilt es die Ausgaben für eine Migration auf die neue Architektur zu berücksichtigen - inklusive der Umstellung auf ggf. neue Überwachungs- und Speichermanagement-Tools.

5.  Leistungsaspekte von Flash mit Software Defined Storage (Block)

• Der selektive Einsatz von Flash-Ressourcen auf Hypervisor-Ebene anstelle im SAN ist ein effizienter Weg um Virtual Machine – Umgebungen zu beschleunigen. Es gibt keine zusätzliche Latenzen wie beim Durchlaufen des I/Os im Speichernetzwerk. Falls Flash in bestimmten Konfigurationen allerdings nur sehr selten benötigt wird, ist der Ansatz aus Kostensicht suboptimal; wünschenswert ist eine Aufteilung der Flash-Ressourcen über alle betroffenen Server, um eine gleichmäßige Auslastung zu erreichen.
• Eine Storage Management Software direkt auf dem Hypervisor, die den I/O-Stream zwischen VMs und den Backend -Speicher-Arrays kontrolliert und die am häufigsten zugegriffenen Daten auf den lokalen Flash-Systemen speichert, hat folgenden Vorteil: die Speicherleistung wird (virtualisiert) von Speicherkapazität getrennt, d.h. I/O-kritische Read-/Writes werden über die jeweils lokalen Flash Cache Storage Systeme ausgeführt (Performance- Pool), während die bisherigen HDD Storage Arrays (Capacity-Pool) mit kostengünstigen SATA-/SAS Drives für nicht-zugriffskritische I/O’s verwendet werden.

Die Verfügbarkeit im Falle von Server- und/oder Flash – Ausfällen ist ein weiterer kritischer Punkt: Daten müssen in diesen Fällen trotzdem allen (virtuellen) Cluster-Nodes weiter zugreifbar sein; dies gilt sowohl für Reads- als auch für Writes in gemischten Workloads. In diesem Zusammenhang ist es wichtig, wie die Storage Virtualisierung für Flash implementiert ist: a) als Virtual Appliance b) im einzelnen Gast-O/S oder c) direkt im Hypervisor-System. Während die ersten beiden Implementierungen CPU- und Speicherintensiv sind, besitzt die Hypervisor-integrierte Lösung den Vorteil, Server-übergreifend zu skalieren (keine Performance-Inseln) und damit einen Scale-out-Ansatz ermöglicht. Eines der Hauptprobleme, die bislang bei I/O-Engpässen auftreten – es können dadurch keine weiteren VMs mehr erzeugt werden - können, ist damit gelöst; die Speicherleistung nimmt parallel zum weiteren Ausbau von Server- und VM–Kapazität zu, ohne im Backend-Storage wesentliche Änderungen durchführen zu müssen.

Wichtig ist, die Flash Storage Virtualisierung transparent für das Hypervisor-System zu implementieren; vorhandene Management-Tools sollten nach Möglichkeit direkt integriert werden können.

Mehr dazu erfahren Sie auch am 22. Mai 2014 in Kronberg unter :

http://www.storageconsortium.de/content/content/fachkonferenzen-des-storage-consortium