Starnberg, 27. Aug. 2015 - Flash-Storage ist die erste Wahl bei der Servervirtualisierung; Robuste Speicher-Services und Ausfallsicherheit sind so wichtig wie I/O-Performance...

Um was er hier geht: IT-Planer müssen das rasche Wachstum von virtuellen Maschinen (VM’s) Speicher- und Netzwerkseitig in Bezug auf einen skalierbaren und berechenbare robusten I/O-Stack berücksichtigen. Effektiv umgesetzt, ist Flash Storage bei I/O-Problemen virtualisierter Anwendungen jedenfalls eine große Hilfe und auch das primäre Anwendungsszenario von NAND Storage (siehe hierzu auch: Enterprise Use Cases for Solid State Storage / Flash Memory, An Outlook from Storage Strategies NOW, Sept. 17, 2013).

Flash muss möglichst nahtlos und hochverfügbar in die virtualisierte Infrastruktur einzubinden sein; dies gilt natürlich besonders im Zusammenhang der 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-Storagesysteme öfter auftritt: Das Mehr an I/O bedeutet auch mehr Kapazität (Drives), die aber hier selten benötigt wird.

Übersicht zu aktuellen Implementierungen von Flash Memory / SSD Storage

1. All-Flash Array (AFA):

• 100% Flash garantiert konstant höchste Anwendungsleistung / QoS, allerdings ist die Wirtschaftlichkeit auf Grund der höheren Beschaffungskosten (CAPEX) derzeit noch 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 mit z.B. Iometer überwachen (OPEX). Zu beachten: nicht alle VMs benötigen immer die höchste I/O-Performance (Kostenaspekt) oder sie verfügen über Anwendungen, die sehr schreib-intensiv sind (= höhere Belastung der NAND Zellen); NAND ist hier technologisch bedingt auch nicht so schnell, weshalb von einigen Anbietern ein Controller- Caching vorgeschaltet wird, um zum Backend sequential reads zu liefern.

• In Verbindung mit Deduplizierung, intelligenten Caching und Komprimierung ist es bereits heute möglich, mit AFA den Preispunkt (CAPEX) von HDD-Arrays zu erreichen. Diese kapazitätsreduzierenden Massnahmen gelten natürlich auch für HDDs, allerdings leidet die Performance bei der Deduplizierung, so dass AFA die bessere Wahl darstellt (vorausgesetzt die Anwendung profitiert von diesen Verfahren und die Leistung wird benötigt).

2. Hybrid Arrays:

• Flash-Speicher wird mit Festplatten gemischt. Das Array verfügt in der Regel über Auto-Tiering Software im Controller bzw. Server, um Hot-Files oder gesamte Anwendungsdaten nach Bedarf auf schnellen Flash Storage zu migrieren.

• Bei einem 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 preiswerte SATA Laufwerke mit hoher Kapazität zum Einsatz kommen.

3. Server-Flash:

• Je enger Flash an die Anwendung rückt, desto geringer sind die Latenzzeiten. PCIe Flash im Server ist zwer sehr schnell, aber als Direct Attached Device (DAS) wenig skalierbar und bei einem Ausfall des Systems potentiell ein Single-Point-of-Failure. Alternativ fassen verschiedene Anbieter deshalb PCIe-Flash-Systeme über mehrere Server zu einem logischen Flash-Pool zusammen, was die Ausfallsicherheit und das dynamic Workload-Management verbessert (Scale-out Flash).

• Ein weiterer 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. Flash mit Software Defined (Block) Storage

• Der Einsatz von Flash-Ressourcen auf Hypervisor-Ebene anstelle im SAN ist ein weiterer Weg um Virtual Machine – Umgebungen zu beschleunigen. Es gibt keine zusätzliche Latenzen wie beim Durchlaufen des I/Os im SAN. Falls Flash in bestimmten Konfigurationen allerdings nur sehr selten benötigt wird, ist der Ansatz aus Kostensicht derzeit nicht optimal; sinnvoll ist eine Aufteilung der Flash-Ressourcen über alle beteiligten Server, um eine gleichmäßige Auslastung zu erreichen.

• Eine Storage Software direkt beim 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 Systeme ausgeführt (Performance- Pool), während die bisherigen HDD Storage Arrays als Capacity-Pool mit kostenoptimierten SATA-/SAS Drives für nicht-zugriffskritische I/O’s verwendet werden.

5. Eine weitere Entwicklung bei Server-Flash ist NVMe – Non Volatile Memory Express

• NVMe (aktuell v.1.2) ist eine neue standardisierte Schnittstelle (Protokoll) für PCIe SSDs. Es wurde entwickelt, um die spezifischen Leistungsmerkmale von Flash und NVM Technologien bei Serversystemen besser nutzen zu können (Latenzzeiten, Performance, Skalierbarkeit, Protokoll-Umfang und Effizienz).

• Während Standard HDD-Arrays das bewährte Standard-SCSI-Protokoll verwenden, arbeitet NVMe unter Umgehung des SCSI-Stacks. Command Queuing bei SCSI unterstützt z.B. nur eine Warteschlange für I/O-Befehle, während NVME bis zu 64.000 erlaubt. Dabei kann jede Warteschlange ihrerseits bis zu 64.000-Befehle gleichzeitig bedienen. Zusätzlich vereinfacht NVME die Befehle auf der Grundlage von 13 spezifischen NVMe Command-Sets, die auf die besonderen Anforderungen von NVM-Devices hin entwickelt wurden.

• NVMe mit Flash kann auf Grund seines Designs damit sehr hohe I/O-Werte mit niedrigsten Latenzen bereitstellen, die deutlich über den aktuellen Leistungswerten von Flash mit SAS (SCSI-basierend) liegen.

Bislang publizierte Latenzzeiten liegen bis zu 200 Mikrosekunden unter denen von 12 Gbps SAS. Zudem soll sich die CPU-Belastung um bis zu 50% durch den effizienteren Befehlssatz gegenüber SCSI reduzieren. Die SNIA hat hierzu folgende Zahlen veröffentlicht (http://www.snia-europe.org/):

Random Read-/Writes:

• For 100% random reads, NVMe has 3x better IOPS than 12Gbps SAS
• For 70% random reads, NVMe has 2x better IOPS than 12Gbps SAS
• For 100% random Wirtes, NVMe has 1.5x better IOPS than 12Gbps SAS SAS

Ähnlich verhält es sich demnach bei sequential Read-/Writes (siehe auch meinen Blog zu NVMe vom 12. März 2015)

Fazit: 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 zur 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. Das gilt allerdings auch der Umstellung von Array-Controlled auf Software Defined (controlled-) Storage, SDS. Auf der Netzwerkseite wiederum kann es bedeuten, 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 neue Überwachungs- und Speichermanagement-Tools.