Performanter Storage im Jahr 2019
Performanter Storage ist im Zusammenspiel mit dem unterliegenden (Speicher-)Netz das Rückgrat nicht nur von High-Performance-Computing-, sondern auch von Virtualisierungs- und Cloud-Computing-Clustern. Dieser Artikel stellt einen Ansatz für Enterprise-Storage vor, mit dem fast 50 GB/s gelesen und geschrieben werden können – auf bis zu 500 TB auf einer Höheneinheit. Kern dessen sind NVMe-SSDs im NF-1 oder M.3-Format.
Anforderungen an Storage-Systeme heute
So unterschiedlich die Anwendungen in High-Performance-Computing und Virtualisierungs-Umgebungen auch sein mögen – aus Sicht des Speichers verhalten sie sich sehr ähnlich: Hunderte und teilweise tausende Prozesse greifen parallel auf ein teilweise sehr begrenztes Set an Daten auf dem Storage zu. Und dieser Storage ist im Praxiseinsatz allzu häufig fehl dimensioniert – mit hohen Kosten.
Denn wer seinen Storage-Cluster beim "IT-Discounter um die Ecke" kauft, bekommt dort meist präsent eben nur die oberen zwei Werte genannt: Den verfügbaren Speicherplatz und eventuell noch die (theoretische) Bandbreite, die das System schreiben und lesen kann. Doch eigentlich sind gerade im Enterprise-Umfeld andere Faktoren genauso wichtig. Dazu zählen:
- Eine niedrige Latenz – das Storage-System muss schnell antworten, denn die Latenz beim Storage ist Totzeit für Prozesse und virtuelle Maschinen, die auf den Storage warten.
- Eine hohe Anzahl an (parallelen) Schreib- und Lesezugriffen – während das NAS "daheim" wohl nur selten von vielen Nutzern gleichzeitig beschrieben wird, sieht es bei einem Virtualisierungs- oder HPC-Cluster ganz anders aus; hier kommen schnell einige hundert oder tausend parallele Schreib- und Lesezugriffe zusammen.
- Eine gute Netzwerkanbindung – 50 GB/s intern auf die Disks schreiben zu können, hilft nicht, wenn das Storage-System nur mit 4x1 GbE angebunden ist. Damit aus einem Storage das Maximum heraus geholt werden kann, muss das Netzwerk den verwendeten Speichermodulen entsprechen.
- Eine große Packungsdichte und ein niedriger Energieverbrauch – gerade bei der Einmietung in Rechenzentren macht es einen Unterschied, ob der Storage eine, zwei oder zwölf Höheneinheiten belegt.
Sonderfall Cloud-Storage
Einen Sonderfall bei der Konzeptionierung von Storage stellt der Cloud-Storage dar – nicht zuletzt, weil dieser durch die Diversität von Cloud-Anwendungen nicht trennscharf definierbar ist. Häufig dient Cloud-Storage dem einfachen Upload von Nutzerdaten (die berühmten "Urlaubsfotos", aber auch die Zeichnungen eines abgeschlossenes Projektes), die gemeinsam haben, dass sie erstens nach einem ersten Anlegen in der Regel häufig nur noch gelesen und zweitens nach kurzer Zeit gar nicht mehr berührt werden. Daher gelten für die Konzeptionierung von Cloud-Storage-Clustern häufig andere Regeln, als für hochperformanten Storage und sie werden im Zuge dieses Artikels nur peripher betrachtet.
All-Flash?
Kurzform: Ja! Wer höchste Performance nach obigen Anforderungen (niedrige Latenz, hohe Anzahl von parallelen Lese- und Schreibzugriffen und hohe Packungsdichte) möchte, kommt heute um Flashspeicher so sehr herum, wie Business-Internet um Glasfaser-Anschlüsse: Gar nicht. Vor allem im Hinblick auf das NVMe-Protokoll und die damit einhergehenden, massiven Verbesserungen bei allen drei Kernanforderungen.
NVMe steht für Non-Volatile-Memory-Express und beschreibt erst einmal lediglich ein herstellerunabhängiges Protokoll, um SSDs anzusprechen. Dieses zeichnet sich in Kurzform durch einige wesentliche Neuerungen aus:
- Jede SSD ist ein PCIe-Device – der Flaschenhals von I/O-Bussen entfällt. Gleichzeitig steht dem Hersteller durch die Anzahl der zu verwendenden PCIe-Lanes eine Möglichkeit offen, die Schnittstelle nach außen der tatsächlichen Leistungsfähigkeit intern anzupassen.
- Durch ein angepasstes und (gegenüber AHCI verringertes) Set an Kommandos ist eine starke Parallelisierbarkeit bei gleichzeitig geringer Latenz gegeben.
- Im Zusammenspiel einem RDMA-fähigen Netzwerk erlaubt die Erweiterung NVMe-over-Fabrics (NVMe-oF) den Export von lokalen Platten und sogar (Software-)RAIDs als latenzarmes Blockdevice.
Formfaktoren
Flashspeicher (und so auch NVMe-SSDs) sind wesentlich unabhängiger in der Bauform, als konventionelle Magnetfestplatten – ein Fakt, den man sich beim NF-1-Format, wie bei allen Next-Generation-Small-Form-Faktoren (NGSFF), zu Nutzen gemacht hat: Das Modul misst etwa 110 x 30,5 x 4,5 mm, mit Tray wird es etwa 36 mm hoch und 10 mm breit – und passt somit aufrecht in eine Höheneinheit – hotplug-fähig von vorne eingeschoben. Das ermöglicht es, bis zu 36 NVMe-SSDs in einen Server zu verbauen. Damit ergeben sich nach Herstellerrechnung bis zu 36 x 16 TB = 576 TB Storage. Mit einer Rechnung in TiB und in der Realität unter Verwendung von mindestens einem RAID6 werden daraus dann etwa (36 - 2) x 15,36 TiB = 522 TiB. Immer noch ein imposanter Wert – den entsprechenden Geldbeutel vorausgesetzt.
Apropos Geldbeutel: Eine 3,84-TB-SSD (NF-1/PM983) kostet derzeit etwa 900 € netto und ist damit etwa 75 Prozent teurer als die nächste SATA-SSD (PM883).
Die Sache mit den PCIe-Lanes
Einen Nachteil hat die Verwendung von NVMe-SSDs: Pro Device wird eine Anzahl PCIe-Lanes "verbraucht", in der Regel sind dies vier oder seltener auch acht Lanes. Intels Cascade-Lake-Prozessoren verfügt über je 48 Lanes – ein Dual-Sockel-System (im heutigen Serverumfeld wahrscheinlich der gebräuchlichste Aufbau) hat demzufolge nicht mehr als 96 PCIe-Lanes, an die Peripherie angeschlossen werden kann. 36 NVMe-SSDs mit je 4 Lanes benötigten allerdings schon alleine 144 Lanes. Die Netzwerkkarten, die in der Regel noch einmal mit 16 (eine Karte) oder gar 32 Lanes (zwei Karten) zu Buche schlagen mit eingerechnet, kommt man am Schluss auf bis zu 176 benötigten PCIe-Lanes. Lösen kann man dieses Dilemma leider nur mit PCI-Switches – und den damit einhergehenden Performance-Nachteilen: Bei 144 benötigten Lanes auf 96 – 32 = 64 verbleibenden Lanes bleiben pro Device bei Vollauslastung nur noch etwa 45 Prozent der maximalen Performance pro Lane bestehen. Hier dürften in naher Zukunft die AMD-Epyc-Systeme mit ihren 128 Lanes pro Prozessor erheblich punkten können.
Das Netzwerk
– Oder warum für Storage 25 GbE häufig cooler ist als 40 GbE.
In vielen Umgebungen findet man heute noch FibreChannel als dominierendes Speichernetz. Doch Ethernet – und in der HPC-Welt in Infiniband – holen aus eigener Erfahrung stark auf. Das hat aus unserer Sicht zwei Gründe:
- Während bei FibreChannel noch Bandbreiten von 16 respektive 32 Gbit/s üblich sind, ist Ethernet bereits bei 100 Gbit/s in der Breite angekommen – im HPC-Bereich findet bereits der Schwenk zu 200 Gbit/s statt. Und auch in puncto Zuverlässigkeit und Latenz bietet FibreChannel heute gegenüber Enterprise-Ethernet-Hardware (wenn überhaupt) nur noch marginale Vorteile.
- Fast jede/r Administrator/in kann jedoch mit Ethernet als Konzept umgehen. Dabei ist es grundsätzlich egal, ob es sich um 1 Gbit/s oder 100 Gbit/s handelt.
Neben der strikten Trennung zwischen Speicher- und Anwendernetz (auch 100 Gbit/s helfen nicht, wenn die Leitung überbucht oder gar unkontrollierbar ist!), gibt es einen weiteren Punkt, der bei der Planung eines neuen Speicher-Netzes bedacht werden sollte, sollte es auf Ethernet beruhen: Die Latenz, die gerade bei kleineren Dateizugriffen wichtiger ist, als die schiere Bandbreite. Da 40 GbE aus vier parallelen Verbindungen á 10 GbE, die in einem QSFP-Adapter münden, besteht, 25 GbE hingegen aber nur aus einer Verbindung, die in SFP28-Adaptern mündet, sollte regelmäßig dem 25-GbE-Netz der Vortritt gegeben werden – falls es sonst keine Faktoren gibt, die für das eine oder andere sprechen.
Eine Hardware-Umgebung, viele Anwendungen
Alle Hardware bringt nichts ohne die richtige Software-Unterstützung. Als Spezialisten für hochperformante Cluster unter Linux haben wir vier interessante Szenarien identifiziert, in denen wir diese Systeme sehen.
- Als NVMe-oF-Target – Ähnlich, wie bei iSCSI werden hier die SSDs (und auch Software-RAIDs) als Blockdevices exportiert. Zusammen mit NFS oder NFS-over-RDMA lässt sich hier ein gut skalierbarer Storage aufbauen.
- Als Virtualisierungs- und Cloudstorage mit GlusterFS – GlusterFS ist ein verteiltes Dateisystem, das primär von RedHat gepflegt wird. Es besitzt verschiedene Modi, unter anderem als replicated storage, mit dem sich eine sehr performante und trotzdem n-fach ausfallsichere Basis für Virtualisierungsumgebungen aufbauen lässt. GlusterFS beherrscht RDMA-Funktionialitäten, was dem Netzwerkdurchsatz und der Latenz zu Gute kommt.
- Als fast pool im BeeGFS-Dateisystem – In HPC-Umgebungen ist BeeGFS neben Lustre der Standard für Storage-Systeme. Ein Phänomen von HPC-Umgebungen ist, dass zwar viele Daten aus Simulationen aufbewahrt werden, häufig jedoch nur auf einem verhältnismäßig kleinen Datenset aktiv gearbeitet wird, das vor Simulation bekannt ist. Seit einiger Zeit bietet daher BeeGFS die Möglichkeit, neben dem bulk pool einen fast pool aufzubauen. Über wenige einfache Kommandos werden die notwendigen Daten dann vor der Simulation vom bulk pool auf den fast pool kopiert – für die Clients (Rechenknoten) liegen sie jedoch weiterhin im gleichen (virtuellen) Verzeichnis.
- Als Caching-Storage für Content-Delivery-Netzwerke – CDNs sind aus dem heutigen Internet nicht mehr wegzudenken; sie speichern global verteilt Daten zwischen – von CSS-Files bis hin zu Videos. Aus Storage-Sicht sind die Zugriffe insbesondere hierbei hochgradig randomisiert.
Testing
Als Testsetup dienten uns zwei Server von Supermicro mit je 16 x 3,84 TB NF1-SSD (32 NF1-Devices möglich), auf denen ein CentOS 7.7 auf einem dedizierten Bootdevice lief. Jeder der Server war mit zwei 20-Kern-CPUs und 192 GB RAM, sowie 2x 100 GbE-Dual-Netzwerkkarten ausgestattet. Als Basis für die Tests diente das Linux-Tool fio, bei dem sowohl das betriebssystemseitige Caching komplett deaktiviert, als auch die Puffer nach jedem Test neu beschrieben wurden. So stellen wir sicher, dass wir möglichst genau die unverfälschten Werte der Devices ermitteln können – leider zu dem Preis, dass wir hin und wieder signifikant schlechtere Werte ermitteln, als vom Hersteller angegeben. Wir haben auf diesen Systemen knapp 7.000 Messungen durchgeführt – die wichtigsten Ergebnisse sind unten vorgestellt.
Test 1: Lokale Lese- und Schreibraten
Beim sequentiellen Lesen kommen die Server auf 48,5 GiB/s bei einer Blocksize von 1M – das ist ein imposanter Wert. Daneben sehen die Werte bei random read-write, also den Leseraten, während parallel zufällig geschrieben wird mit über 21 GiB/s fast schon gering aus – doch im Vergleich zu einem knapp 5 Jahre alten Storage mit 45 HDDs liegt man hier fast um den Faktor 60 höher. Diese Messung random read-write ist übrigens die der reellen Nutzung wohl am nächsten kommende.
Auch bei den Schreibraten kamen wir mit bis zu 46 GiB/s auf beachtliche Werte. Die IOPS lagen sogar bei über 2,55 Mio. – durchaus etwas weniger, als vom Hersteller als Maximum angegeben, aber nichtsdestotrotz ein mehr als respektabler Wert.
Test 2: RAID-Level
Dass RAID-Verbünde, bei denen Paritäts-Informationen berechnet werden müssen (etwa RAID5/6), in der Regel erheblich langsamer schreiben, als solche die für Schreiboperationen "nur" kopieren (RAID1/10) gilt auch hier. Ein solches System sollte man nur einsetzen, wenn man sehr viel mehr liest, als man schreibt. Einsatzzwecke sind nicht nur unter Umständen Cloud-Storage-Anwendung, wie oben beschrieben, sondern vor allem auch Caching-Umgebungen, etwa für CDNs. Hier stehen dann eine etwa 1,5 Prozent schlechtere Leserate (random read) einer bis zu 87,5 Prozent höheren Packungsdichte (RAID10 vs RAID6 im Vollausbau) entgegen.
Test 3: NVMe-over-Fabrics
NVMe-over-Fabrics oder kurz NVMe-oF kombiniert die Technologien NVMe und RDMA, in dem es die NVMe-SSDs des Servers (Target) einzeln oder als RAID kombiniert über ein RDMA-fähiges Netzwerk einem Client (Initiator) als Blockdevice zur Verfügung stellt. Wer mit iSCSI vertraut ist, dem lässt sich NVMe-oF als ein "iSCSI auf Steroiden" vielleicht ganz gut nahe bringen.
Wichtig zu wissen ist, dass NVMe-oF zwar bonding via LACP unterstützt, für eine einzelne Verbindung allerdings immer nur einen physischen Link benutzt – bei einem 100-GbE-Ethernet-Netzwerk ist also bei 12,5 Gbit/s netzwerkseitig Schluss.
Fazit
Wer heute zuverlässigen Storage bei höchster Performance haben möchte, kommt an NVMe-Speichern kaum vorbei. Ist dann noch eine hohe Packungsdichte gefragt, sind die NF-1-Systeme durchaus mehr als einen Blick wert, herstellerabhängige Komplettlösungen mit Lockin-Effekt nicht notwendig. Bei der Planung ist allerdings wichtig, auch das unterliegende Netzwerk auf den Storage anzupassen – viele PS im Auto bringen nichts, wenn man sie nicht "auf die Straße" bringen kann.
