Von Wolfgang Stief, Boston Server & Storage Solutions

Das stellt IT-Abteilungen vor eine neue Herausforderung: Der Zugriff auf immer größere Datenmengen muss jederzeit schnell erfolgen. SSD bzw. Flash-Memory sind angetreten, diese Herausforderung anzunehmen.

Flash ist nicht gleich Flash

Häufig findet man SSDs, die noch per SAS/SATA-Schnittstelle kommunizieren. Moderne Flash-Komponenten können allerdings deutlich mehr als SAS/SATA. Eine wesentliche Verbesserung bietet NVMe. Flash-Bausteine werden direkt an den PCI-Bus des Servers angebunden. Bekannte Grenzen des SAS/SATA-Protokolls existieren bei NVMe nicht. Viele dieser Einschränkungen kommen aus einer Zeit, in der Protokolle auf sich drehende Festplatten mit beweglichen Schreib-Lese-Köpfen abgestimmt waren. In einem Flash-Drive bewegt sich nichts mehr – außer noch ein paar Elektronen.

Wir haben also jetzt schnelle SSDs am schnellen Kommunikations-Bus innerhalb des Servers. Nun ist es aber selbst in Cloud-Umgebungen durchaus üblich, jeder Compute-Node noch sein eigenes, lokales (NVMe-)Storage zuzuweisen. Der Nachteil liegt auf der Hand: Lokal angeschlossene Flash-Module sind selten vollständig ausgelastet. Kapazität und Performance gehen verloren.

Warum also greifen mehrere Server nicht auf ein gemeinsames Storage zu? So ließe sich jedes Flash-Modul bis in den hintersten Kapazitätswinkel auslasten. Im IT-Betrieb spricht man davon als Storage-Disaggregation.

Grafik: Toshiba Memory

Eine Erweiterung des NVMe-Protokolls um Netzwerkfähigkeit ermöglicht genau das: NVMe-over-Fabric (NVMe-oF). Das ist vergleichbar mit Fiber-Channel, nur dass als Transportprotokoll hier schnelles Ethernet (40G, 100G) oder Infiniband genutzt wird.

Für Infiniband gibt es zudem Protokollerweiterungen, die es ermöglichen, Daten direkt über eine entfernte Netzwerkkarte in den Hauptspeicher des zugehörigen Servers zu schreiben. Das Verfahren nennt sich RDMA bzw. ausgeschrieben Remote-Direct-Memory-Access. Davon profitieren beispielsweise Datenbanken, sofern sie dieses Feature unterstützen.

Cloud und Automatisierung ersetzt die Serverfarm

Ein weiterer Trend im IT-Betrieb ist der Einsatz von Cloud-Infrastrukturen. IT-Abteilungen gehen dabei zunehmend dazu über, einen Teil der Cloud auch im eigenen Rechenzentrum zu betreiben (Hybrid-Cloud).

Ein Cloud-Stack besteht aus vielen verschiedenen Modulen, die zum Zusammenspiel konfiguriert werden müssen. Zentrale Komponenten sind die Verwaltung und das Deployment virtueller Maschinen, die Verwaltung des zugehörigen Storage, und natürlich das Switching und Routing intern und extern. Hier war anfangs viel Handarbeit nebst zugehörigem Detailwissen nötig – wesentliche Gründe für die zunächst zögerliche Verbreitung privater Cloud-Umgebungen. Zudem konkurrierten anfangs noch verschiedene Software-Stacks. Hier hat sich OpenStack weitgehend durchgesetzt. Mit Werkzeugen wie Kubernetes wird die Administration und automatische Provisionierung von Ressourcen in einer OpenStack-Cloud um ein Vielfaches einfacher. Administratoren können sich auf Dienste konzentrieren, die das Kerngeschäft des Unternehmens stützen. Der steigende Automationsgrad erhöht auch Stabilität, Sicherheit und Zuverlässigkeit der Dienste bzw. der darunter liegenden Infrastruktur.

Im Umkehrschluss bedeutet das aber auch, dass die einzelnen Komponenten diese Methoden unterstützen müssen. Zu Beginn war das die Verwaltung von virtuellen Maschinen und des zugehörigen, internen Netzwerks. Dafür gibt es schon sehr lange Automatismen: Neue VMs werden bei Bedarf aus einem Template oder einer Maschinenbeschreibung auf Knopfdruck erstellt, abgeschaltet und wieder gelöscht. Die Bereitstellung von Speicherplatz war bislang manuelle Tätigkeit eines Administrators: RAID-Systeme waren einzurichten, LUNs zu provisionieren, an den passenden physischen Host und schließlich an die virtuelle Maschine zu mappen. Auf Hostseite musste die LUN in das Betriebssystem eingebunden und ein Dateisystem darauf erstellt werden. In Zeiten automatischer Provisionierung von virtuellen Maschinen dauert ein solcher manueller Vorgang zu lange und ist fehleranfällig. Erst recht, wenn womöglich mehr als eine Person daran beteiligt ist, und der Auftrag über Abteilungsgrenzen hinweg bearbeitet werden muss.

Warum wurde nicht die Provisionierung von Storage-Ressourcen automatisiert? Eine neu erstellte virtuelle Maschine bekommt im Rahmen der Bereitstellung der Compute-Ressourcen gleichzeitig erforderlichen Plattenplatz für Betriebssystem und Dienste zugewiesen, formatiert und angebunden.

Software als Kleber

Eine Reihe Hersteller von Storage-Systemen und -Software liefert unter dem Begriff Software-defined Storage Kleber-Software für die Schicht zwischen Cloud-Verwaltung und Storage-System. Damit wird es aus der Cloud-Verwaltung heraus möglich, zusammen mit einer virtuellen Maschine auch die zugehörige Storage-Kapazität zu provisionieren. Natürlich im richtigen Storage-System im richtigen Disk-Pool auf dem richtigen RAID. Nun ist oft noch die Software eng mit der Hardware eines Herstellers verknüpft. Ein Austausch oder eine Kapazitätserweiterung außerhalb des Herstellers ist schwierig. Im IT-Betrieb kennt man solche Limitierungen als Vendor Lock-In.

Nicht so mit KumoScale von Toshiba Memory. Das Software-defined Storage arbeitet im Storage-Backend mit jeder Hardware zusammen, die NVMe-oF spricht. Das REST API kann gleichermaßen angesprochen werden von OpenStack, Kubernetes, Lenovo XClarity und Intel RSD.

Grafik: Toshiba Memory

Die Software kümmert sich dabei um das Management und die Abstraktion bzw. Virtualisierung der NVMe-Ressourcen im externen Storage-System. Natürlich ist auch die Administration per WebGUI möglich.

Datenverarbeitung in Echtzeit

Ein wesentliches Design-Ziel der KumoScale-Software war, dem Datenfluss nicht unnötig Latenz hinzuzufügen. Die Latenz im KumoScale-Stack sind 8µs bis 12µs, in jedem Fall unter 20µs. Zum Vergleich: Die mittlere Zugriffszeit für ein NVMe-Flash-Modul ist ca. 100µs. Bei 4kB Blockgröße werden mehr als 8 Mio. Lese-Requests/s (random) verarbeitet. Derzeit lassen sich mit einer Software-Instanz 384 TByte verwalten.

Grafik: Toshiba Memory

Auf dem Storage-Node läuft Linux und stellt die NVMe-Treiber für Netzwerk und NVMe-Module bereit. KumoScale übernimmt die Verwaltung und Zuweisung von Storage-Kapazität an virtuelle Maschinen – gesteuert und automatisiert per API vom Cloud-Management. Als externes Storage-System eignet sich zum Beispiel der Supermicro BigTwin: in das Gehäuse passen 24 NVMe-Module. Damit lässt sich derzeit je nach Hersteller eine Bruttokapazität von 367 TByte in 2HE erreichen.