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 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 fehldimensioniert – mit hohen Kosten.

Denn wer seinen Storagecluster 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 Enterpriseumfeld andere Faktoren genauso wichtig. Dazu zählen:

1. Eine niedrige Latenz – das Storagesystem muss schnell antworten, denn die Latenz beim Storage ist Totzeit für Prozesse und virtuellen Maschinen, die auf den Storage warten.
2. 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.
3. Eine gute Netzwerkanbindung – 50 GB/s intern auf die Disks schreiben zu können, hilft nicht, wenn das Storage-System nur mit 4×1 GbE angebunden ist. Damit aus einem Storage das Maximum heraus geholt werden kann, muss das Netzwerk den verwendeten Speichermodulen entsprechen.
4. Eine große Packungsdichte und ein niedriger Energieverbrauch – gerade bei der Einmietung in Rechenzentren macht es einen Unterschied, ob der Storage 1, 2 oder 12 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 Cloudstorage dem einfachen Upload von Nutzerdaten (die berühmten „Urlaubsfotos“, aber auch die Zeichnungen eines abgeschlossenes Projektes), die gemeinam 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 in weiten Strecken andere Regeln, als für hochperformanten Storage und sie werden im Zuge dieses Artikels nur periphär 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:

1. Jede SSD ist ein PCIe-Device – der Flaschenhals von I/O-Bussen entfällt. Gleichzeitig steht durch die Anzahl der zu verwendenden PCIe-Lanes dem Hersteller eine Möglichkeit offen, die Schnittstelle nach außen der tatsächlichen Leistungsfähigkeit intern anzupassen.
2. Durch ein angepasstes und (gegenüber AHCI verringertes) Set an Kommandos ist eine starke Parallelisierbarkeit bei gleichzeitig geringer Latenz gegeben.
3. 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 konventielle 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×30,5×4,5mm, mit Tray wird es etwa 36mm hoch und 10mm breit – und passt somit aufrecht in eine Höheneinheit – hotplugfä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% teuerer 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% 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:

1. 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.
2. 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, 25 GbE hingegen aus nur einer Verbindung, die in SFP28-Adaptern mündet, besteht, 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.

1. 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.
2. 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 nfach ausfallsichere Basis für Virtualisierungs-umgebungen aufbauen lässt. GlusterFS beherrscht RDMA-Funktionialitäten, was dem Netzwerkdurchsatz und der Latenz zu Gute kommt.
3. 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 aufbwahrt 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.
4. 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 wie in unserem Hause üblich 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 7000 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.