Starnberg, 29. Jan. 2018 - Weshalb der Einsatz von SSD-Laufwerken im klassischen RAID-5/6-Verbund nicht immer automatisch zu einer höheren Anwendungsleistung führt...

Um was es hier geht: SSD-Drives auf Basis NAND Flash anstelle von schnellen 2.5“ / 15k Festplatten (dieser Typ Laufwerk geht langsam aber sicher auf Grund der begrenzten Kapazität und Leistung aus dem Markt...) sind heute Standard und es gibt gute Gründe dafür: Die Flash-SSD ist im direkten Vergleich einer 15k HDD in allen Punkten überlegen, insbesondere natürlich in Bezug auf IOPS-  bzw. Durchsatzraten (Gbps) sowie der Energieaufnahme (Watt). Also ein „no-brainer“ und bei Performance-Problemen im Rahmen vorhandener Speicher-Subsysteme eine relativ simple Upgrade-Lösung dazu, zumindest auf den ersten Blick. Doch ganz so einfach ist die Sache nicht und ich möchte Sie deshalb hier für einige Randbedingungen im Zusammenhang mit dem I/O-Profil der Anwendung sensibilisieren.

Warum können RAID-5 oder RAID-6 Arrays, vollgepackt mit SSDs anstelle von HDDs, bei Applikationen mit Random (Small-Block-) Writes ihre volle Leistung (laut Drive-Specs) nicht abrufen? Dazu sollten wir uns ansehen, was eigentlich passiert wenn Daten in Form von kleineren Blöcken auf ein RAID-Array geschrieben werden: Das Array muss zuerst den Block aktualisieren, der gerade geschrieben wurde und dabei auch den "Parity"-Laufwerksblock aktualisieren, der mit dem Schreibzugriff verbunden ist. Um das Parity-Laufwerk zu aktualisieren, müssen die Paritätswerte neu berechnet werden. Parität in RAID-5 ist eine XOR (Exclusive OR) Operation, die zwar sehr schnell ausgeführt wird (bit-level), aber um die Parität zu berechnen, müssen die zugehörigen Blöcke aus dem Array gelesen werden, das neue Update in den Datensatz einfügt und schließlich der Paritätsblock aktualisiert werden. Ein einzelner zufälliger Schreibzugriff besteht jetzt aus vielen einzelnen Lese- und Schreibzugriffen: z.B. wird ein einzelner Random Schreibzugriff zu vier Random Reads, gefolgt von zwei Random Writes; das macht RAID-5 langsam und bei RAID-6 wird es noch komplexer, da im Gegensatz zu RAID-5 noch weitere Random Writes Operationen beteiligt sind.

Im Gegensatz zu Random Reads, wo Flash seine volle Leistung ausspielen kann, sind Random Writes bei schreibintensiven Anwendungsprofilen für SSD-basierte RAID-Konfigurationen eine Herausforderung und begrenzen die mögliche Leistung des Subsystems, oder anders formuliert: ein RAID-5 SSD Arraycontroller muss ein Vielfaches der IOPS-Leistung bereitstellen, um mit der Drive-Leistung linear mithalten zu können. Dies gilt übrigens genauso für den Host (inkl. Schnittstellen), der auf Grund von Interrupts IOPS-seitig extrem gefordert wird. Sowohl Controller als auch Hostsystem sind damit gefordert, einen extrem hohen I/O-Overhead verarbeiten zu können, der mit neuen, ultraschnellen NVMe-Devices nochmals deutlich ansteigen wird. Hohe Durchsatzraten (Gb/s) bei Random Writes auf Standard RAID-5/6 zu erzielen, kann damit problematisch sein. Konsequenz: nicht jedes Anwendungsprofil profitiert automatisch nur von schnellen Laufwerken, in diesem Beispiel Flash SSDs.

Zur Zukunft von RAID / weitere Verfahren

Ein weiterer Punkt betrifft RAID generell: auf Grund ständig größerer Disk-Kapazitäten, auch mit NAND Flash sowie komplexen Storage-Konfigurationen kostet Verfügbarkeit auf Drive-Ebene sowohl Leistung als auch beim Rebuild mehr Zeit. Verfahren wie FAST-RAID oder Software RAID bieten zwar gewisse Workarounds, erhöhen aber auch die CPU-Belastung bzw. sind nicht für alle RAID-Level verfügbar. RAID wird damit natürlich nicht überflüssig, jedoch im Kontext bestimmter Anwendungen und zunehmend verteilter Architekturen (Cloud) für umfangreiche Unternehmensspeicher durch besser skalierende Lösungen ersetzt werden. Erwähnenswert im Kontext gestiegener Anforderungen durch NAND Flash und der weiteren Entwicklung von RAID ist RAIN (Redundant Array of Independent Nodes), eine offene Entwicklungsumgebung um einzelne RAID Nodes zu einer größeren logischen Einheit zusammenzufassen (Ausfallsicherheit / Skalierbarkeit). Anmerkung: im Downloadbereich finden Sie als registrierter Benutzer der Webseite hierzu weitere Informationen.

Verteilte Storage Filesystem Lösungen (Sofware Defined Storage, SDS) wie GlusterFS, Ceph, XtreemFS oder z.B. Hedwig (Block SDS) stellen hinsichtlich transparenter Skalierung einen Entwicklungstrend dar, der fast immer auf einer verteilten Clusterarchitektur aufbaut und im Gegensatz zur nur begrenzt skalierbaren, direkten physikalischen Beziehung „Controller RAID - angeschlossene Disks“ einen dezentralen „distributed storage“ Datenschutz für Cloud-Scale Storage bietet. Erhoffte Entwicklungen im Bereich Erasure Coding für Scale-out NAS und Object Storage werden aus meiner Sicht im Bereich von Software Defined Storage jedenfalls zu weiteren Verbesserungen im Zusammenhang mit der Verfügbarkeit und Performance führen.

Kurzes Fazit

1. Achten Sie bei RAID auf ein ausgewogenes Gesamtsystem, d.h. die IOPS-Leistung auf der Controller-/Laufwerksseite muss mit der CPU-Leistung des Host-Systems zusammenpassen (balanced system) und auf Grund von >> I/O-Interrupts sollte stets genügend CPU-Leistung vorhanden sein, dann ist Direct-Attached-Storage im Server mit modernen RAID-Controllern für die meisten Anwendungsprofile weiter performant.

2. Nein, DevOps-inspirierte Storage Ansätze a la Kubernetes (Container-Orchestrator) als intelligenter "Load Balancer" zwischen Cluster-Nodes plus Object Storage sind wie von manchen vorgeschlagen nicht die allgemeine Storage-Zukunft **. Object Storage ist nicht Block-Storage oder NAS, sondern wurde konzipiert für große Mengen von unstrukturierten Daten und verlangt nach optimierten Anwendungen (API-Ansatz); ein Re-write kommerzieller Kernanwendungen hierfür wäre zur Zeit wenig realistisch.

3. Verwenden Sie Storage Betriebs- bzw. Filesysteme, die intern in der Lage sind - unterstützt durch entsprechendes Caching (DRAM / NAND) - möglichst Random I/O’s in sequentielle E/A-Operationen mit geringem Overhead für Parity-Informationen (Metadaten) zu wandeln und beherzigen Sie ganz generell den alten Satz erfahrener Systementwickler „The best I/O is no I/O.“

Einige Links zum Thema:

Link > Wiki ZFS Storage Filesystem

Link > Quobyte: What’s Erasure Coding and When to use it in Production

** Forget the File System: The Future of Scalable Cloud Storage Will Be Objects

Link > Scality RING 7 Software Defined web-scale Storage: Technisches Datenblatt

Link >The definitive guide to Cloud Object Storage System Dispersed Storage. Modernize your data center storage for efficiency, IBM Whitepaper, 2017

Link > NVMe und NVMe over Fabrics - Eine Standortbestimmung

Link > Quantum StorNext 6 Data Management für Quantum Xcellis Scale-out Storage Appliances