Herr ueber das Datenwachstum

Posted on 2018/09/04

Seit Jahren ist bekannt, dass Daten in Unternehmen mehr und mehr werden. Und mindestens genauso lange ist bekannt, dass diese Entwicklung auf absehbare Zeit kein Ende finden wird. Höher Rechenleistung auf kleinerem Raum erlaubt eine immer feinere und immer schnellere Analyse von Unternehmensdaten. Ein Unternehmen kann mit verbesserten Analysen auf der anderen Seite schneller am Markt agieren und schneller auf Änderungen im Markt reagieren.

Jedoch stellen zunehmende Datenmenge und moderne Möglichkeiten einer umfassenden, schnellen Datenanalyse die IT-Abteilungen vor eine Herausforderung: die Daten müssen gehortet werden, und der Zugriff darauf muss jederzeit schnell erfolgen können. SSD bzw. Flash-Memory ist schon vor etlicher Zeit angetreten, diese Herausforderung anzunehmen.

Flash ist nicht gleich Flash

Häufig zu sehen sind SSDs, die dann aber doch “nur” per SAS/SATA-Schnittstelle kommunizieren. Betrachtet man sich Leistungswerte moderner Flash-Komponenten, wird schnell klar, dass Flash deutlich mehr kann, als SAS/SATA. Eine wesentliche Verbesserung bietet hier NVMe. Flash-Bausteine werden damit direkt an den PCI-Bus eines Servers angebunden. Die Kommunikation darüber ist um ein Vielfaches schneller, als SAS/SATA das leisten könnten. Zudem arbeitete man die jahrelange Erfahrung aus dem Betrieb von SAS/SATA beim Design des NVMe-Protokolls mit ein, so dass verschiedene, bekannte Einschränkungen des SAS/SATA-Protokolls bei NVMe nicht existieren. Viele dieser Einschränkungen kommen aus einer Zeit, in der Protokolle auf drehende Festplatten mit beweglichen Schreib-Lese-Köpfen abgestimmt waren. In einem Flashdrive bewegt sich nichts mehr, außer noch ein paar Elektronen.

Wir haben also jetzt schnelle Flash-Devices an einem schnellen Kommunikations-Bus innerhalb eines Servers. In Cloud-Umgebungen ist es bisher durchaus üblich, dass jeder Compute-Node auch sein eigenes, lokales NVMe-Storage hat. Der Nachteil liegt auf der Hand: die wenigsten lokal angeschlossenen Flash-Module sind vollständig ausgelastet, Kapazität und Performance geht verloren, bezogen auf die gesamte Cloud. Wie wäre es, wenn mehrere Server auf gemeinsames, schnelles Storage zugreifen könnten? Man kann jedes Flash-Modul bis in den hintersten Kapazitätswinkel zuweisen und hat damit kaum noch Verschnitt. Im IT-Betrieb spricht man davon als Storage Disaggregation.

Storage Disaggregation

Durch eine Erweiterung des NVMe-Protokolls um Netzwerkfähigkeit wird genau das möglich, wir sprechen hier über "NVMe over Fabric”, oder kurz NVMe-oF. Man kann sich das ähnlich zu Fiber Channel vorstellen, nur dass als Transportprotokoll hier schnelles Ethernet (40G, 100G) oder Infiniband zum Einsatz kommt. 

NVMe-oF Schema

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 z. B. Datenbanken, sofern sie dieses Feature unterstützen.

Cloud und Automatisierung ersetzt die Serverfarm

Ein weiterer Trend im IT-Betrieb ist der Einsatz von Cloud-Technologie. Anfangs noch belächelt und auch gerne mal als Unsinn abgetan, sind zwischenzeitlich Cloud-Infrastrukturen weit verbreitet im Einsatz. IT-Abteilungen gehen dabei zunehmend dazu über, einen Teil der Cloud auch im eigenen Rechenzentrum zu betreiben, und nicht nur ausschließlich bei einem Cloud-Anbieter zu hosten. Konkurrierten anfangs noch verschiedene Software-Stacks, so hat sich in der Zwischenzeit OpenStack weitgehend durchgesetzt. Ein solcher Cloud-Stack besteht aus vielen verschiedenen Modulen, die irgendwie 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 braucht es auch Switching und Routing zwischen den virtuellen Maschinen und zur Außenwelt. Hier war anfangs viel Handarbeit nebst zugehörigem Detailwissen gefragt. Mit ein Grund, für die zunächst zögerlich verbreitete Adaption privater Cloud-Umgebungen.

Die Situation hat sich mittlerweile rapide verbessert. Mit Kubernetes wird die Administration und automatische Provisionierung von Ressourcen in einer OpenStack-Cloud um ein Vielfaches einfacher, die Komplexität bleibt weitgehend verborgen. Der Administrator kann sich auf Dienste konzentrieren, die das Kerngeschäft des Unternehmens stützen, und muss seine teure, wertvolle Zeit nicht mehr auf Infrastruktur verwenden. Weil in solchen Umgebungen i. d. R. auch der Automationsgrad in der Administration deutlich steigt, steigt ganz nebenbei auch Stabilität, Sicherheit und Zuverlässigkeit der Dienste und der darunter liegenden Infrastruktur. Die Zeiten des Administrator-Handwerkers sind weitgehend vorbei.

Im Umkehrschluss bedeutet das aber auch, dass die einzelnen Komponenten, die in eine solche Umgebung eingebracht werden, 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, nach denen neue VMs bei Bedarf aus einem Template oder einer Maschinenbeschreibung auf Knopfdruck erstellt werden. Ebenso können VMs abgeschaltet und wieder gelöscht werden, wenn sie nicht mehr gebraucht werden.

Die Bereitstellung von Speicherplatz sowohl für virtuelle Maschinen, als auch für die Produktivdaten von Diensten 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 der automatischen 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 also nicht die Provisionierung von Storage-Ressourcen gleich mit automatisieren? Eine neu erstellte virtuelle Maschine bekommt so im Rahmen der Bereitstellung der Compute-Ressourcen auch gleich Plattenplatz für das Betriebssystem und den erforderlichen Plattenplatz für Dienste zugewiesen, formatiert und angebunden. Das alles zusammen mit demselben Knopfdruck, der auch die virtuelle Maschine erzeugt. Nach vorher festgelegten Vorgaben gemäß Dienst, der auf der VM laufen soll, dem Pool oder RZ, in dem die VM laufen soll usw. Die möglichen Bedingungen sind vielfältig.

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. Aber: weil die Software des Herstellers eng mit der Hardware des Herstellers verknüpft ist, und auch nur mit der Hardware des Herstellers zusammenarbeitet, kann ein Austausch oder eine Kapazitätserweiterung außerhalb des Herstellers schwierig werden. Im IT-Betrieb kennt man solche Limitierungen als Vendor Lock-In.

Nicht so mit Toshiba KumoScale. Toshiba verkauft zwar Festplatten und Flash-/SSD-Module, aber keine RAID-Systeme. Das Software Defined Storage arbeitet deshalb 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. 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.

KumoScale Stack

Datenverarbeitung in Echtzeit

Ein wesentliches Design-Ziel der KumoScale-Software war, dem Datenfluss nicht unnötig Latenz hinzuzufügen. Die Latenz im KumoScale-Stack liegt deshalb in jedem Fall unter 20µs, typisch sind 8µs-12µs. Die mittlere Zugriffszeit für ein NVMe-Flash-Modul ist bei ca. 100µs. Bei 4kB Blockgröße bearbeitet die Software dabei mehr als 8 Mio. Lese-Requests (random access). Derzeit lassen sich 384 TB Speicherkapazität mit einer Software-Instanz verwalten.

Als externes Storage-System eignet sich z. B. unser Supermicro BigTwin: in das Gehäuse passen 24 NVMe-Module. Bestückt mit Toshiba BiCS Flash™ Modulen bekommt man darin eine Bruttokapazität von stolzen 182 TB auf kompakten 3 HE. Auf dem Storage-Node läuft Linux und stellt die NVMe-Treiber in Richtung Netzwerk und NVMe-Module bereit. Das darauf installierte KumoScale übernimmt die Verwaltung und Zuweisung von Storage-Kapazität an virtuelle Maschinen, gesteuert und automatisiert per API vom Cloud-Management.

RSS Feed

Sign up to our RSS feed and get the latest news delivered as it happens.

click here

Test out any of our solutions at Boston Labs

To help our clients make informed decisions about new technologies, we have opened up our research & development facilities and actively encourage customers to try the latest platforms using their own tools and if necessary together with their existing hardware. Remote access is also available

Contact us

ISC High Performance 2019

Latest Event

ISC High Performance 2019 | 16th - 20th June 2019, Messe Frankfurt, Germany

ISC is the event for high-performance computing, networking and storage.

more info