Die Parallelisierung von I/Os ist eine Architekturfrage Virtuelle Maschinen bekommen nicht genug zu verarbeiten

Storage-Insider unterhielt sich mit Ralf Colbus und Klaus Gottschalk von IBM über die Herausforderung der Parallelisieung von I/Os. Je mehr, desto RoI von x86-Server lautet die Devise. Noch beherrscht nur der Mainframe die notwendige Techik.

Anbieter zum Thema

PoINT Software & Systems GmbH

DataCore Software GmbH

Fujitsu Technology Solutions GmbH

IBM Deutschland GmbH

IBM Forum Ehningen

Flash-Speicher werden immer leistungsfähiger bei Bandbreite und I/O-Performance. Können Anwendungen daraus überhaupt Nutzen ziehen, wenn diese schon mit 20.000 IOPS vollständig überfordert sind?

IO, Bandbreite und Latency beschreiben die herausragenden Systemparamter, den Nutzen bestimmt aber die Applikation. Datenbanken, VDI-Umgebungen, ERP-Systeme, Backup, Media/Streaming profitieren enorm durch den Einsatz von Flash-Technik. Schon heute werden 10 Prozent aller gelieferten Disk-Kapazitäten durch Flash ersetzt, die Tendenz ist sehr schnell steigend!

Tritt nun bei (PCIe-)Flash dasselbe Problem auf wie bei der CPU? Ist nun auch der Speicher unterausgelastet?

In der Tat, das kann passieren! Durch den Einsatz von Flash kann sich das Bottleneck nach "oben", das heißt in Richtung Server/Applikation hin verschieben. Indikator dafür ist, dass bei Kunden plötzlich CPU-Utilisierungsgrade von 90 Prozent erreicht werden.

Ließe sich durch die Parallelisierung von I/Os der RoI (Return on invest) von x86-Systemen verbessern?

Die heutigen x86-Prozessoren und die x86-Systemarchitektur besitzen aus jedem Prozessorsockel heraus eine Verbindung zu Memory- und PCIe-Bus. Bei einem Zwei-Sockelsystem sind damit zwei Memory-Pfade und zwei parallel I/O-Busse vorhanden.

Das ist aber auch ein Problem. Wenn ein Prozessor auf eine I/O-Karte zugreifen muss, die am PCIe-Bus des anderen Prozessors hängt, dann ist der Zugriffsweg länger und langsamer. Auch x86-Server haben grundsätzlich eine parallele I/O-Verabeitung.

Anders gefragt: Wenn x86-Server mehr parallele I/O-Kanäle hätten, könnte man mehr virtuelle Images auf eine x86 Architektur bringen und dann ließen sich die Betriebskosten pro Image senken?

Theoretisch ja. Praktisch funktioniert durch die Verlinkung Mem == CPU === PCIe pro Sockel der Parallel-I/O nur gut, wenn der Speicher, der Prozess und die I/O-Kanäle alle am gleichen Sockel hängen.

Solange die gemeinsame Nutzung aller Ressourcen im System nur gebremst funktioniert, werden die Kosten pro virtuelles Image konstant sein, weil auch die Images an Mem == CPU == PCIe gebunden sind.

Das große Vorbild bei der Parallelisierung von I/Os ist der Mainframe. Ist das Architekturmodell auf x86-Systeme übertragbar?

Nein. Ein Mainframe ist ein echter symmetrischer Multiprozessor (SMP) mit einer komplett anderen I/O-Architektur. Hier werden alle Ressourcen von allen Prozessoren gemeinsam genutzt und der einzelne I/O wird von einer I/O Einheiten verwaltet und freien Ressourcen zugeteilt.

Bei x86 übernimmt die CPU auch die Verarbeitung des I/O-Zugriffs.

In der aufwändigen Systemarchitektur des Mainframes stecken dann auch die Kosten, die die Mainframe-Hardware für x86-Anwender so teuer erscheinen lassen. Man muss die Parallelität und die gemeinsame Nutzung aller Ressourcen auch in der Hardware umsetzen.

Auf einem Mainframe laufen einige zigtausend VMs mit Linux-Betriebssystem. Eigentlich scheinen Intel CPUs leistungsfähiger als Mainframe-Prozessoren. Wieviel Linux-VM könnte man auf einen in der CPU-Kernzahl mit dem Mainframe vergleichbaren x86-System laufen lassen?

Intel möchte heute die Bewertung von CPUs und Systemarchitekturen auf einige wenige Parameter reduzieren: Taktrate, Anzahl der Prozessorkerne, FLOPS (Gleitkommazahlberechnungen).

Das Beispiel Linux auf dem Mainframe zeigt, dass diese Angaben nicht die reale Anwendungsleistung wiedergeben. Eine schnell getakteter Prozessor, der auf Daten aus dem Hauptspeicher wartet oder darauf wartet, dass I/Os durchgeführt werden, trägt nichts zur beobachteten Anwendungsleistung bei.

Im Endeffekt spielt die gesamte Systemarchitektur eine Rolle. Der Prozessor ist nur ein Rad im Getriebe eines Computers oder wenn man im Bild eines Orchesters bleibt, eine wohlklingende 1. Geige geht im Klangkörper eines Symphonieorchesters einfach nur unter, wenn das den Takt nicht halten kann.

Deshalb sprechen wir davon, dass die echte Anwendungsleistung eines Systems für die Bewertung der TCO herangezogen werden muss. Nur dann sehe ich wirklich was die Kosten sind und was hinten herauskommt.

Was läuft bei der Intel-Architektur falsch? Kann man die schlechtere VM-Performance durch Änderungen der Hypervisor-Software (Programmed-IO) aufbessern?

Für HPC auf x86 wird immer diese Einheit aus Memory == CPU == PCIe für die Anwendungen durch Techniken wie Memory Pinning, Process Binding erzwungen. Im "worst case" greift ein Prozess oder virtuelle Maschine auf Speicher zu, die an einem anderen Prozessor hängt und organisiert I/Os über eine Netzwerkkarte oder einen FC-Adapter am PCIe Bus eines anderen Prozessors.

Diese bei HPC genutzten Techniken kann man sicher auch in einem Hypervisor nutzen. Aber das sind nur Krücken-Lösungen für ein grundlegendes Problem in der x86-Systemarchitektur. Abstrakt gesprochen macht man damit aus einem Mehrsockelsystem wieder ein 1-Sockelsystem, um das Problem des I/O zu umgehen. Damit ist man wieder zurück an den prinzipiellen Limits der 1-Sockelsysteme.

(ID:43863472)