Virtualisierung und I/O: die Grenzen des Hypervisors

Kommentieren Drucken
Teil 11 von 19 aus der Serie "Virtualisierungstechniken"

Bisher hatten wir die Kommunikation von VMs dadurch realisiert, dass ein virtueller Switch die Aufgaben erledigt. Das ist auch schön und gut, bedeutet aber in der Praxis, dass die gesamte Kommunikation durch den Hypervisor laufen muss. Dieser hat aber eigentlich schon genug zu tun und kommt durch zu viele Aufgaben schnell an seine Leistungsgrenzen. Also sind in der Zukunft Konzepte gefragt, die den Hypervisor erheblich entlasten oder ganz umgehen.

Virtualisierung ist ein allgemeiner Trend. Es gibt einfach eine Reihe überzeugender Vorzüge und die Produkte der bekannten Hersteller wie VMware, Citrix oder Microsoft leisten jeden Tag anständige Arbeit. Besonders hervorzuheben sind die Möglichkeit einer letztlich übersichtlicheren Systemsteuerung und vor allem Funktionen für die Desaster Recovery. Mittlerweile stellen ja auch Software-Hersteller, die bislang recht zurückhaltend waren, wie SAP, ihren Kunden die Möglichkeiten der Virtualisierung grundsätzlich zur Verfügung. Blickt man einmal auf Projekte mit Virtualisierung, die von diesem Hersteller oder Partnern erfolgreich abgewickelt wurden, ist die Desaster Recovery an vorderster Front bei der Wunschliste an die neue Lösung.

Leistungssteigerungen bei Datenbanktransaktionen hingegen werden kaum als Motivation angegeben und sind auch nicht dokumentiert. Das ist eigentlich auch nicht verwunderlich, denn die Vielfalt der mit Virtualisierung möglichen Sonderfunktionen hat ihren Preis:

Allgemein ist man sich in der Literatur für die bestehenden Systeme darüber einig, dass bei Einführung der Virtualisierung ein „Virtualisierungsverlust“ auf einem System gegenüber dem identischen System ohne Virtualisierung von grob circa 20% entsteht, unabhängig von der Leistungsklasse, Taktrate, Prozessor- oder Core-Anzahl und Ausbaustufe des betrachteten Rechner und unabhängig vom eingesetzten Virtualisierungsprodukt. Für ganz neue Produkte werden 5 bis 10% Verlust angegeben. Bei der Netzwerkplanung kann man sich aber nicht darauf verlassen, dass immer nur neue Systeme ans Netz gebracht werden.

Hersteller von Virtualisierungssoftware geben zwar immer wieder irgendwelche tollen Transaktionsraten in der Werbung an, den Beweis dieser Wunderzahlen unter alltäglichen Bedingungen bleiben sie jedoch bislang schuldig.

Außerdem wird in der Reklame nicht erwähnt, ob ein System, auf dem virtuelle Maschinen laufen, außer Transaktionen oder I/O noch etwas anderes macht, oder ob es vielleicht damit vollständig ausgelastet ist.

Es kann tatsächlich der Fall sein, dass ein virtuelles Betriebssystem an bestimmten Stellen an erhebliche Leistungsgrenzen stößt. Die Lösung dafür wäre einfach das Warten auf neue Server-Hardware, die so schnell ist, dass es irgendwann wieder funktioniert. Bedenklicher wäre allerdings ein echtes konstruktives Hindernis. Das kann dann nämlich durch schnellere Hardware auch nicht beseitigt werden.

Mit 10-, 40- oder gar 100-GbE kann man beliebig leistungsfähige Netze bauen. Aber sind die virtuellen Betriebssysteme heute schon dafür bereit, mit dieser Last auch ordentlich umzugehen?

Um uns der Thematik zu nähern, müssen wir einfach tiefer in die Aufgaben eines virtuellen Betriebssystems einsteigen und sehen, wie es sie löst. Dann sehen wir auch die Probleme, die es haben könnte, deutlicher. Ich mache das hier natürlich so, dass es hoffentlich für jeden Interessenten nachvollziehbar bleibt. Ab und an werden auch Produkte genannt, einfach um ein Beispiel zu bilden. Das heißt dann aber in keinem Fall, dass ein in dem Zusammenhang nicht genanntes Produkt schlechter wäre.

Zu Beginn der Betrachtungen hatte ich gedacht, eine Nadel im Heuhaufen zu suchen. Es stellt sich aber heraus, dass die konsequente Suche ein Stich ins Wespennest ist: Je länger man bohrt, desto schlimmer wird es.

Damit es überhaupt noch in einen Absatz zu fassen ist, muss ich Einschränkungen vornehmen:

  • Es geht hier ausschließlich um Server-Virtualisierung, Desktop-Virtualisierung ist ein völlig anderer Themenbereich.
  • Wir konzentrieren uns auf den Verkehr zwischen Server und externem Speichersystem. Ohne ein solches ist ein virtuelles System nicht wirklich sinnvoll zu betreiben.
  • Ziel ist keineswegs die Bewertung bekannter Virtualisierungsprodukte, sondern einzig und allein die Herausarbeitung von Implikationen auf das Netzwerkdesign.

Folgendes kann man schon absehen:

  • Die bestehenden Virtualisierungsprodukte können in keinem Fall so bleiben, wie sie jetzt sind. Hier sind konstruktive Verlagerungen in die Hardware nötig.
  • Die heutigen Probleme lassen sich nicht durch das Abwarten auf das Zuschlagen von Moores Law beseitigen.
  • Die Veränderungen werden in den nächsten 2 bis 5 Jahren stattfinden.
  • Die Veränderungen betreffen also den Life-Cycle eines jetzt neu zu planenden RZ-Netzes.
  • Dennoch: Im gleichen Zeitraum wird die Virtualisierung so allgegenwärtig und selbstverständlich, dass wir uns fragen, wie wir vorher ohne sie einen sinnvollen RZ-Betrieb gewährleisten konnten.

Grenzen des Hypervisor-Konzepts

Die von den Herstellern angegebenen Zahlen für irgendwelche I/O-Leistungen oder Transaktionsraten sind definitiv nicht brauchbar, weil man offensichtlich dabei immer davon ausgeht, dass ein System sonst nichts tut.

Leider ist die Suche nach stichhaltigen Zahlen darüber, wie viel Prozent CPU-Leistung Aktionen wie die Aufrechterhaltung der Laufzeitumgebungen der virtuellen Maschinen oder die Bereitstellung der virtuellen Speicher für die virtuellen Maschinen nach sich ziehen, etwa so wie die Suche nach der Nadel im Heuhaufen. Die Hersteller sind hier gar nicht auskunftsfreudig und veröffentlichte Messungen gibt es dafür auch nicht.

Dennoch kann man sich der Grundlast nähern und zwar auf der Basis dessen, was teilweise seit Jahrzehnten über zunächst konventionelle Betriebssysteme bekannt ist.

Wesentliche Aufgaben eines Betriebssystems sind Dispatching und Scheduling im Rahmen der Bereitstellung der Laufzeitumgebungen sowie die Bereitstellung des virtuellen Speichers. Über die Jahrzehnte sind die hierbei zugrunde liegenden Algorithmen zwar ständig verbessert worden und wurden vor allem hinsichtlich der Zeiten für die Bereitstellung von Ergebnissen für die Laufzeitumgebungen permanent optimiert, dennoch ist es aber so, dass alle Verfahren einer bestimmten Komplexitätsklasse angehören, die man nicht verlassen kann. Das bedeutet, dass für die Erzielung eines Ergebnisses seit Jahrzehnten im Grunde genommen eine vergleichbare Anzahl von Schritten durchlaufen werden muss.

Eine Hilfe dabei ist oftmals die Möglichkeit der Zerlegung einer Aufgabe in parallele Tasks, die mittels eines entsprechenden Tasksystems vor allem dann beschleunigt ausgeführt werden können, wenn dafür tatsächlich auch multiple physikalische Prozessoren bereitstehen. Dummerweise sind aber die angegebenen Kernaufgaben nur teilweise zu zerlegen, so dass sich eine wesentliche Leistungssteigerung auf diesem Wege nicht erzielen lässt.

Nehmen wir dafür ein nahe liegendes Beispiel. Bei PCs und Notebooks erfreuen wir uns seit längerer Zeit am echten Multitasking auf Anwendungsebene. Das ermöglicht uns z. B. gleichzeitig einen Text auszudrucken und im Internet zu surfen, ohne dass eine dieser Aufgaben die andere behindern würde. Haben wir im PC oder Notebook zwei oder vier Prozessoren, geht alles noch viel glatter als mit nur einem. Die Leistungssteigerung von einem auf zwei Cores ist sehr deutlich spürbar, die von zwei auf vier aber nicht mehr so sehr. Das liegt daran, dass das Betriebssystem den 3. und 4. Core gar nicht mehr so gut nutzen kann, es sei denn, wir verwenden spezielle rechenaufwändige Anwendungen wie sie im Rahmen der Video-Bearbeitung oder bei Spielen vorkommen. Dann sind es aber die Anwendungen, die schon so geschrieben wurden, dass sie sich selbst in Teile zerlegen, die unabhängig auf den einzelnen Cores laufen können.

Dem Betriebssystem selbst nutzen die zusätzlichen Cores wenig, wenn man die Kernaufgaben betrachtet.

Diese Verhältnisse lassen sich auch auf beliebig große und schnelle Rechner übertragen, weil sie letztlich immer prozentual sind.

Auch wenn ich mir jetzt den Zorn der Hersteller und Fans zuziehe: Ein Hypervisor macht im Grunde genommen nichts anderes als der Kern eines Multitasking-Systems! Der Unterschied liegt lediglich darin, dass er statt der üblichen Laufzeitumgebungen für die Anwendungen die sogenannten virtuellen Maschinen erzeugt, die aber rein faktisch gesehen auch nichts weiter als komfortable Laufzeitumgebungen sind, die sich aus der Perspektive von Anwendungen eben so verhalten wie einzelne physikalische Maschinen.

Dadurch ergibt sich letztlich eine andere Organisationsform auf einem Rechner, die für viele Betreiber teilweise erhebliche Vorteile nach sich ziehen kann. Diese Vorteile haben aber einen Preis, der darin besteht, dass ein Hypervisor wesentlich mehr Systemleistung für sich verbraucht als ein herkömmliches Multitasking-Betriebssystem.

„Was soll‘s?“ werden Sie jetzt fragen, “Dann kaufen wir eben schnellere Rechner“. Das ist natürlich immer eine Lösung, aber wir wollen ja hier abschätzen, was wirklich passiert.

Fahren wir zurück in die Vergangenheit, zu VM. Eine damalige IBM-Umgebung bestand aus den Hosts und den SNA-Komponenten. Die SNA-Komponenten haben die gesamte Kommunikation zwischen Hosts und Benutzern abgewickelt und auch eine eingeschränkte Kommunikation zwischen den Hosts ermöglicht. Die wichtigste SNA-Komponente war der Kommunikations-Vorrechner, der den überwiegenden Teil der Kommunikationsaufgaben im Offload bearbeitet hat. Genau so waren Speicherumgebungen konstruiert. Auch sie hatten eigene Vorrechner, so dass für das eigentliche Betriebssystem der Zugriff auf den externen Speicher genau so einfach war wie auf internen Speicher.

Das damalige VM war fast vollständig von Aufgaben um Kommunikation und Speicherzugriff entlastet. Trotz dieser Hilfen hat ein VM-Betriebssystem circa 50% der gesamten Systemleistung benötigt, um überhaupt arbeiten zu können!

Ein heutiger Hypervisor, ob nun von VMware, Citrix oder Microsoft, hat zunächst einmal mindestens die gleichen Aufgaben wie VM, nämlich die Bereitstellung der virtuellen Maschinen. Darüber hinaus muss er aber noch mehr machen, wie z. B. die Unterstützung der Wanderung virtueller Maschinen, die Abwicklung der I/O (er hat keinen SNA-Vorrechner als Hilfe) und die Abwicklung der Funktionen, die für einen Zugriff auf externe Speicher benötigt.

Selbst wenn wir davon ausgehen, dass die Hersteller von Virtualisierungssoftware im Laufe der Jahrzehnte wirklich alle Neuentwicklungen und Optimierungsmöglichkeiten ausgeschöpft haben, können diese wegen der geschilderten Verhaftung von Grundfunktionen in Komplexitätsklassen den grundsätzlichen Aufwand nicht wirklich senken. Auch die Verfügbarkeit einer Multi-Core-Architektur hilft an dieser Stelle kaum, weil verschiedene Aufgaben eben algorithmisch nicht zerlegt werden können, im einfachsten Falle haben sie überlappende Vor- und Nachbereiche.

Fassen wir das zusammen:

  • Ein Hypervisor kann eine Multicore-Architektur für die Erledigung seiner eigenen Aufgaben nur eingeschränkt nutzen, weil der hier erzielbare Multiprogammiergrad gering ist.
  • Die Belastung eines Cores, auf dem der Hypervisor läuft, kann dabei durchaus 50% oder mehr dieses einzelnen Cores betragen.
  • Dennoch führt das durchaus zu einem befriedigend laufenden System, wenn die freien Cores komfortabel für die virtuellen Maschinen genutzt werden können.

Bis jetzt mussten wir eine Art Indizienbeweis führen, weil veröffentlichte Messergebnisse fehlen.

Für den Abschluss der Argumentation gibt es aber Messergebnisse. Sie betreffen die Belastung eines Prozessors durch die Ausführungen von Aufgaben, die bei der Nutzung von iSCSI anfallen. So zitieren wir ein von HP und Tolly veröffentlichtes Ergebnis. Gemessen wurde die CPU-Auslastung eines HP ProLiant DL380 G5-Servers mit einem HP NC 373i LOM Adapter beim Zugriff auf ein HP Storage Works MSA 2012i NAS-Speichersystem mit iSCSI.

Bei Software-basierendem iSCSI und kurzen (512, 2K großen) Blöcken kann die CPU-Auslastung knapp 40% betragen!

Dabei handelte es sich um ein „harmloses“ iSCSI mit 2 Gbit/s. Die Ergebnisse dienten als Argumentation für eine Hardware-Beschleunigung des iSCSI.

Wir haben ja versucht, eine Antwort auf die Frage zu finden, ob ein 10-GbE/FC-Anschluss ein bislang zufriedenstellend laufendes System mit Hypervisor in die Knie zwingen kann (anstatt es wie erwartet zu beschleunigen).

Die Antwort ist: bei ungünstigen Voraussetzungen: Ja.

Dazu benötigt man eigentlich noch nicht einmal 10-GbE/FC, eine einfache Verdoppelung der Datenrate kann auch schon reichen.

Gehen wir einmal von einem Server aus, der mit einer 1-GbE-Schnittstelle versorgt ist. Auf einem Core läuft der Hypervisor und lastet diesen Core zu sagen wir 50% – 60% aus. Das System befindet sich dann hinsichtlich des Hypervisors in einer Grenzsituation, die der Betreiber aber nicht unbedingt bemerkt, weil es ja insgesamt gut läuft und die anderen Cores die virtuellen Maschinen prima unterstützen. Das System benutzt auch ein iSCSI-NAS mit NFS und das trägt zu circa 10 – 15% der Auslastung des Hypervisor-Cores bei. Jetzt meint der Betreiber es gut und kauft ein 4-GbE-iSCSI NAS und natürlich auch passende 10-GbE-HBAs. Plötzlich muss der Hypervisor viermal so viele Daten in der gleichen Zeit bearbeiten. Da lässt sich auch nichts parallelisieren und alleine der NAS/iSCSI-Zugang kostet circa 40 – 60% der Core-Leistung. Der Hypervisor hat keine Möglichkeit, das einzudämmen, sondern muss den Speicherverkehr im Gegenteil auch noch bevorzugt behandeln. Das System kommt dadurch in einen absoluten Grenzbereich. Entweder läuft es weiter, aber die Bedienung der virtuellen Maschinen auf den anderen Cores verlangsamt sich erheblich oder der Hypervisor nimmt sein Hütchen und verabschiedet sich.

Eine vergleichbare Situation haben wir schon alle auf dem privaten PC oder Notebook erlebt, und zwar dann, wenn zu wenig Hauptspeicher vorhanden ist. Das System läuft friedlich vor sich hin, bis wir eine neue Anwendung installieren, die hauptspeicherintensiv ist, jedenfalls relativ zu allen anderen bisher installierten Anwendungen. Dem Betriebssystem bleibt in dieser Situation nichts anderes übrig, als permanent auf die Festplatte zu swappen. Dadurch bleibt der Rechner faktisch stehen. Wir kaufen dann entweder neuen Speicher oder einen neuen Rechner.

Leider ist es im Falle des klemmenden Hypervisors damit nicht getan, weil es sich hier um ein grundsätzliches, konstruktiv bedingtes Problem handelt.

Dem einen oder anderen Leser mag die Argumentation zu fundamental sein. Für die haben wir auch etwas. Es gibt bei VMware einen Leistungstest, den sogenannten VMmark. Das ist ein Lastmix, der auf eine Konfiguration gegeben wird und man misst dann mit einem vom Hersteller vorgegebenen Verfahren, wie sich das System verhält. Die Ergebnisse werden dann in einer Art Hitliste veröffentlicht.

Anfang September 2009 war der HP ProLiant DL 785 G6 mit 48 Cores der deutliche Sieger unter ESX 4.0. Wir wollen gar nicht über die Sinnfälligkeit des Testes diskutieren. Interessant ist aber, dass es eine Parameterliste gibt, in der u.a. ein Wert für MaxDataRate gibt. Geht man dem jetzt genauer nach, stellt man fest, dass man das System hier offensichtlich abregeln kann, allerdings nur relativ.

Das System hatte beim Test einen 10-GbE-Adapter. Um zu gewinnen, war es offensichtlich nötig, dessen Leistung zu drosseln.

In der Literatur und weiteren Quellen geht man i. A. davon aus, dass die Leistungsgrenze für ein ESX-System bei 3-Gb-iSCSI liegt. Selbst wenn es das Doppelte wäre, liegen wir noch weit unter dem, was eine10-GbE-Infrastruktur kann.

Leider müssen wir Folgendes festhalten

  • I/O und besonders die Kommunikation mit externen Speichersystemen können einen Hypervisor unter ungünstigen Bedingungen in die Knie zwingen
  • In dieser Situation fällt das gesamte System ins Koma und tut gar nichts mehr, weil die I/O die höchste Systempriorität hat
  • Eine Verlagerung der diese Situation auslösenden VMs z. B. durch HA bringt gar nichts, weil sie im Ziel-Server wieder das Gleiche anstellen.
  • Die Grenze liegt ohne Hardware-Auslagerung heute bei circa 3 Gb/s
  • Der Hypervisor kann sich (heutiger Stand) nicht selbst wirkungsvoll vor dem Eintritt einer solchen Situation schützen.

« Teil 10: I/O-KonsolidierungTeil 12: Virtual I/O »


zugeordnete Kategorien: Virtualisierung
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.