Was lange währt, wird endlich gut: OSL wird zur am 26. Mai hoffentlich stattfindenden Frühjahrsveranstaltung „OSL Aktuell“ seine OSL Virtual Storage Domains zeigen, die Kern einer neuen Produktgeneration für das softwaredefinierte RZ sein werden. Wir geben mit diesem Artikel bereits vor der Veranstaltung einen ersten Einblick in die neue Technologie.
Abseits der Marketing- und Ressourcen-Schlachten der Branchengiganten hat sich OSL den Zweifel, die Suche nach durchgreifend anderen Denkansätzen und den Mut zu radikaler Vereinfachung zum Prinzip gemacht und konnte in der Vergangenheit bereits mehrfach mit innovativen, funktionalen und überraschend kompletten Lösungen überzeugen, die den Anwendern effiziente und langlebige RZ-Prozesse ermöglicht haben:
| 2002 | OSL bringt mit dem OSL Storage Cluster eine Clustersoftware auf den Markt, die zugleich clusterfähige Speichervirtualisierung, Hochverfügbarkeitslösung, globale Managementplattform und adaptiver Ressouren-Controller ist. Nie war das Management von Disk-Ressourcen einfacher, nie das Thema Hochverfügbarkeit leichter zu handhaben. |
| 2010 | OSL stellt mit OSL RSIO (Remote Storage I/O) ein Block-I/O-Protokoll für das Rechenzentrum vor: Skalierbarkeit, Multipathing, Clusterfähigkeit auf Server- und Clientseite sind herausragende Merkmale. In Sachen Durchsatz wird iSCSI bei wesentlich niedrigerem CPU-Bedarf deutlich übertroffen. OSL ermöglicht damit konvergente Netzwerke (I/O + klassische TCP/IP-Netzwerk) über Standard-Netzwerkinfrastrukturen (Ethernet, aber auch Infiniband). |
| 2013 | Mit dem OSL Unified Virtualisation Environment bietet OSL eine Technologie an, die später, als erste Anbieter aus Übersee mit teilweise Vergleichbarem erste Markterfolge haben, als HCI (Hyperconverged Infrastructure) bezeichnet wird. OSL bietet dabei für den Betrieb von virtuellen Maschinen eine radikale Vereinfachung und Kostensenkung bei der physischen Infrastuktur, V3-Virtualisierung (Virtual Host, Virtual Storage, Virtual Network) und natürlich eine softwarezentriertes, flexibles Gesamtkonzept. |
Seit 2015 nun arbeitet OSL an der Konzeption und der Umsetzung der Virtual Storage Domains. Das für das Unternehmen dringend notwendige Business Reengineering, einige Schicksalsschläge bzw. schicksalhafte Wendungen und ein immens steigender Aufwand für immer ISV-unfreundlichere und zugleich fehlerträchtigere OS-Plattformen haben diesen Prozess in einem auch für OSL schwer erträglichen Maß verlangsamt. Andererseits gaben uns immer neue Verzögerungen auch die Möglichkeit, neue Entwicklungen mit zu verarbeiten, so dass wir heute, in einer Zeit des Umbruchs bei ultraschnellen SSD-Speichern und Netzwerkkomponenten mit einer zukunftstauglichen, erweiterungsfähigen Architektur und Softwaretechnologie auf der Höhe der Zeit aufwarten können.
Bei den OSL Virtual Storage Domains (VSD) geht es natürlich um Speichervirtualisierung, genau den Bereich, der z. B. bei den im Markt bekannten VM-Frameworks noch immer die meisten Wünsche offenläßt. Wesentliche Zielstellungen unserer neuen Technologie sind:
Damit wollen wir eine Rückkehr zu einem dynamischen Entwicklungsprozess ermöglichen und die Auswirkungen der für die nächste Zukunft bereits absehbaren durchgreifenden Änderungen (Instabilitäten?) wichtiger Schnittstellen im I/O-Bereich beherrschbar machen, zugleich natürlich auch die Tür zur Nutzung der sich daraus ergebenden neuen Möglichkeiten sowie zur Umsetzung vieler Vorhaben weit öffnen.
OSL Virtual Storage Domains (VSD) sind nicht nur für den Betrieb virtueller Maschinen geeignet. Dennoch: Auf der Suche nach Analogien für diese neue Technologie bietet sich in Vergleich mit der Netzwerkanbindung von virtuellen Maschinen an:
Virtuelle Maschinen laufen zumeist in einem eigenen Ausführungskontext im User-Space und können vergleichsweise einfach und performant über (virtuelle) Bridges des Hypervisors mit der Außenwelt verbunden werden. Damit gelingen auch Hardwareabstraktion und Isolation in einem gewissen Umfang. Weitergehende, komplexe Funktionen im virtuellen Netzwerkstack sind damit jedoch nicht möglich. Hier genau setzt Open vSwitch an und liefert ein beeindruckendes Gesamtpaket an Netzwerk- und Managementfunktionen, ohne dass dafür gesonderte, externe Hardware vonnöten wäre.
Analog verhält es sich mit den VSD. Genügen die grundlegenden I/O-Funktionen des Hypervisors nicht, so kann man über VSD zusätzliche Funktionen (eine weitergehende Speichervirtualisierung) realisieren. Eine Besonderheit der VSD ist, dass abgesehen vom Micro-Kernel-Modul, das die gewohnten Schnittstellen für das Betriebssystem, Applikationen und VMs bedient, alle wesentlichen Teile der Virtualisierung im User-Space implementiert sind. So kann für jede VM ein separater Ausführungskontext erzeugt werden, im Falle von Containern bzw. Zonen ist sogar eine Ausführung in diesen selbst möglich. Zugleich kann jede VSD als vollvirtualisierter Storage-Hypervisor verstanden werden, der entsprechend den Anforderungen seiner Clients (VMs, Applikationen) konfigurier- und skalierbar ist.
Konventioneller I/O-Stack mit Virtualisierung
Setzt man sich tiefer mit der Funktionsweise auseinander, so ist zunächst ein Blick auf den heute typischen Block-I/O-Stack im Rechenzentrum angezeigt. Jenseits der OSL-Lösungen wird Speichervirtualisierung mit einem größeren Funktionsumfang zumeist in separater Hardware implementiert, sei es im RAID-System oder in Virtualisierungs-Controllern.
Aber selbst bei einer HCI-Lösung oder einem virtuellen SAN (Einbindung entfernter Disk-Ressourcen) liegen oft wesentliche Teile der Speichervirtualisierung außerhalb des lokalen Hosts, was prinzipbedingt höhere Latenzen und mitunter auch Probleme in der Fehlertoleranz bedeutet. So hat die Praxis gezeigt, dass z. B. der Einsatz von SSD/NVMe-Speicher in externen (RAID-)Systemen zwar durchaus Verbesserungen in der I/O-Performance ermöglicht, ein Vorstoß in völlig neue Performance-Dimensionen aber oft nicht gelingt.
Ein Blick auf die nebenstehende Skizze veranschaulicht die Ursachen. In Zeiten, in denen moderne Speichermedien bereits Latenzen unter 10µs bieten, ist jeder Zugriff auf ein externes System mit einer zusätzlichen Latenz, u. U. in der gleichen Größenordnung natürlich ein erheblicher Nachteil. Und dieser Effekt verstärkt sich natürlich dann, wenn hinter einem In-Band Storage Virtualization Controller weitere RAID-Systeme angebunden sind. Demgegenüber sind host-interne Kommunikationsverfahren mit der Geschwindigkeit eines Hauptspeicher- oder gar Cache-Zugriffs natürlich deutlich im Vorteil.
Die OSL VSD bieten uns die Möglichkeit, den Storage Virtualization Controller sozusagen als Softwaremodul auf den Host bzw. den Hypervisor zu holen und so von der Performance und Robustheit lokaler (Hauptspeicher-)Kommunikation zu profitieren.
Optimierter I/O-Stack mit Virtual Storage Domains
Die nebenstehende Skizze veranschaulicht dies am Beispiel eines Hypervisor-Knotens, ist aber analog auch auf einen Datenbank-Server anwendbar. Die Virtualisierungsengine ist mit kurzer Latenz direkt auf dem Rechner erreichbar, der Zugriff auf lokale Speichermedien mit hoher Geschwindigkeit möglich und selbst der Zugriff auf externe Speicherkapazitäten erfolgt vergleichsweise direkt. Auf den ersten Blick nicht sichtbar: Nur noch die nach Verarbeitung durch die Virtualisierungsengine notwendigen I/O-Aufträge verlassen den Host, was u. U. eine deutliche Entlastung externer Systeme bedeuten kann.
Und eine weitere, vielversprechende Möglichkeit tut sich auf: Über ein Low-Latency-Netzwerk läßt sich ein High-Performance-I/O-Server anschließen, der ohne weitere Umwege (etwa über den Betriebssystemkern, diverse I/O-Protokolle etc.) I/O-Requests mit kurzer Latenz und hoher Bandbreite verarbeiten kann.
Es scheint also vieles für einen hostbasierten (hypervisor-internen) Ansatz in der Speichervirtualisierung zu sprechen. Der Grund, warum dieser Weg neben OSL nur von wenigen verfolgt wird, liegen z. B. in der Kapselung, in der einfachen Einbindung mehrerer Host und vor allen Dingen in der Komplexität. Da Treiber typischerweise im Betriebssystemkern implementiert werden, ist letztere ein großes Problem. Darauf hat OSL mit seinen VSD nun eine adäquate Antwort gefunden, die herausragenden Multinode- und Clusterfähigkeiten bereits in der Vergangenheit unter Beweis gestellt.
Diese kurzen, vereinfachten Beispiele sollen nur eine grobe Vorstellung von den Möglichkeiten vermitteln, die wir uns von dieser Technologie versprechen. Zugleich sollte mit der enormen Verbesserung der Portabilität die Implementierung neuer Funktionen deutlich leichter möglich sein als mit den In-Kernel-Implementierungen der Vergangenheit. Es wird also in der nächsten Zukunft vor allem darum gehen, das enorme Wissen und Erfahrungspotential, das in der Solaris-Kernel-Implementierung unserer 2.x - 4.x-Speichervirtualisierung steckt, in die neue Welt zu übertragen und neue Funktionen zu erschließen.
Im Teil I unseres “Aktuellen Themas” zu den OSL VSD soll natürlich auch ein Einblick in die praktische Handhabung gegeben werden.
Während OSL Storage Cluster und die OSL Unified Virtualisation Environment wie bisher auch auf dem Konzept von (virtuellen) Application Volumes fußen, stellt der neue ovvemu-Treiber der VSD zusätzlich eine Basis-Schnittstelle für einfache Volumes – Simple Volumes, kurz: SVOLs bereit. Diese soll im folgenden kurz anhand von Beispielen gezeigt werden. Dabei steht die Technologie sowohl für Solaris (primäre Entwicklungsplattform) als auch Linux (Plattform der Wahl für aktuelle Hardware und High-Performance-Komponenten) zur Verfügung.
Zunächst erzeugen wir eine virtuelle Storage-Domain vom Typ ovvemu, weisen dieser zwei virtuelle I/O-Controller zu und starten die Domain. Die neue Domain soll den Namen “VIRTUAL” tragen. Nach dem Erzeugen lassen wir uns die Domain anzeigen. Das Vorgehen unterscheidet sich zwischen Solaris und Linux nicht, unser Sitzungsmitschnitt zeigt das Linux-System:
linux # vsdctl -c VIRTUAL -t ovvemu -C 2 linux # vsdctl -lvvv idx name state type aid 0 SYS unconf unknown(0) 0 1 VIRTUAL stopped ovvemu 0 linux # vsdctl start VIRTUAL linux # vsdctl -lvvv idx name state type aid 0 SYS unconf unknown(0) 0 1 VIRTUAL running ovvemu 0
Mit der neuen VSD “VIRTUAL” steht uns ein eigener, wenn wir so wollen, applikationsspezifischer Namensraum zur Verfügung, in dem wir nun unsere Volumes erzeugen können. Wir erzeugen auf Linux und Solaris jeweils eine RAM-Disk und ein auf einer realen Partition einer Festplatte befindliches Simple Volume, sozusagen ein Ausschnitt bzw. eine virtuelle Partition:
linux # vsdctl -a VIRTUAL::ramvol ram:0:1g volume VIRTUAL::ramvol attached linux # vsdctl -a VIRTUAL::realvol /dev/sdb1:0:1g volume VIRTUAL::realvol attached linux # vsdctl -q VIRTUAL::ramvol 2097152 blocks, unit 256 DISK|MEM|SIMPLE VIRTUAL::realvol 2097152 blocks, unit 257 DISK|BLK|SIMPLE
Auf unserem Solaris-System ist das Vorgehen prinzipiell identisch. Lediglich das Block-Device hat natürlich die Unix-typische Notation und es ist das zeichenorientierte (raw) Gerät anzugeben (fast alle Unix-Systeme unterstützen Raw- und Block-Modes für Plattengeräte).
solaris # vsdctl -a VIRTUAL::ramvol ram:0:1g volume VIRTUAL::ramvol attached solaris # vsdctl -a VIRTUAL::realvol /dev/rdsk/c2t1d0s2:0:1g volume VIRTUAL::realvol attached solaris # vsdctl -q VIRTUAL::ramvol 2097152 blocks, unit 256 DISK|MEM|SIMPLE VIRTUAL::realvol 2097152 blocks, unit 257 DISK|BLK|SIMPLE
Als Backend-Geräte für SVOLs kommen derzeit RAM, Blockgeräte oder Dateien im Dateisystem in Frage. So ist es z. B. möglich, auf einer einzelnen Datei etwa 40 Blockgeräte zu hinterlegen.
Die so erzeugten Volumes können wie gewöhnliche Blockgeräte genutzt werden. Wir zeigen dies mit einem Dateisystem:
linux # mkfs -t ext4 /dev/vsd/VIRTUAL/ramvol
mke2fs 1.45.6 (20-Mar-2020)
Creating filesystem with 262144 4k blocks and 65536 inodes
Filesystem UUID: fe6ef0e2-f60d-4de3-b76c-38229434dedf
Superblock backups stored on blocks:
32768, 98304, 163840, 229376
Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done
linux # mount /dev/vsd/VIRTUAL/ramvol /mnt
linux # df -h /mnt
Filesystem Size Used Avail Use% Mounted on
/dev/b00100 976M 2.6M 907M 1% /mnt
Wir haben gesehen, wie wir mit wenigen Schritten eine neue Virtual Storage Domain und in dieser Volumes erzeugen können. Natürlich gibt es noch vieles mehr zu berichten, erste Konturen des neuen Systems sollten damit jedoch bereits erkennbar geworden sein.
Performance ist immer ein heikles Thema, denn die Welt ist voll von mehr oder weniger praxistauglichen Tests, Rekorden, enttäuschten Anwenderberichten. Viel hängt von den konkreten Konstellationen, Anforderungen der Anwendungen ab.
Die OSL VSD sind nicht dafür entworfen worden, mit möglichst hardwarenahen Sonderkonstruktionen das absolute Minimum bei Latenzen herauszukitzeln. Vielmehr stehen Komfort, Flexibilität, Sicherheit und optimale RZ-Prozesse im Mittelpunkt. Und ja, zusätzliche Instruktionen im I/O-Stack kosten auch etwas. Unsere Tests legen bisher jedoch den Schluss nahe, dass dies in einem für den normalen RZ-Betrieb nicht relevanten Bereich liegt, mehr noch, dass die neuen Möglichkeiten oft deutliche Performancesteigerungen erlauben werden.
Daneben ist z. T. auch aus rechtlichen Gründen die Veröffentlichung von Testergebnissen bisweilen problematisch. Dennoch möchten wir einen Eindruck vermitteln: Im Single-Thread-Modus und Queue-Tiefe 1 ist es unter Linux möglich, mit 4k-Requests deutlich über 250.000 IOPS zu erreichen. Höhere Werte lassen sich dann, zumindest auf kleineren Systemen nur noch mit Multithread-Verfahren und asynchroner Einlieferung der Requests erreichen. Bereits mit einem 4-Core-System ohne Hyperthreading konnte OSL damit die 1 Million IOPS knacken. Dabei sind dann jedoch bereits 2 Cores allein mit der Dateneinlieferung durch das Benchmarkprogramm ausgelastet. Im Gesamtdurchsatz erreicht die Engine auf modernen Xeon-Server-Systemen sicher über 10GiB/s Durchsatz, z. T. auch deutlich mehr. Möglich wird dies durch die moderne, skalierbare Softwarearchitektur der OSL Virtual Storage Domains.
Wir sind also sicher, dass wir unseren Anwendern auf der Basis dieser neuen Technologie sowohl neue technische Möglichkeiten als auch eine ausgezeichnete Performance bieten können.
Die OSL Virtual Storage Domains laufen, und zwar unter Solaris und Linux. Auch wenn noch viel zu tun ist und viele Ideen noch umzusetzen sind: Wesentliche Ziele des Projektes, wie etwa Portabilität, Performance, Isolation und eine moderne modulare Struktur sind bereits erreicht worden. Weitere Details und Ankündigungen zum neuen Produktportfolio wird es mit der Veranstaltung „OSL Aktuell“ am 26. Mai in Schöneiche geben. Wir werden diesen Artikel dann fortsetzen.