Virtual I/O

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

Unsere Kernfrage ist immer: was bedeutet Virtualisierung für RZ- und Corporate Networks? Heutige virtualisierte Systeme haben oftmals noch deutliche Grenzen hinsichtlich ihrer I/O-Fähigkeit. Das wird sich aber sehr schnell ändern und sie werden ebenfalls 10- oder 40-Gb-Anschlüsse nutzen können. Das liegt einerseits an der Schaffung virtualisierungsbewusster Prozessorarchitekturen und andererseits an geschickten funktionellen Verlagerungen. Wir werden das nicht nur abstrakt diskutieren, sondern konkrete, jetzt erhältliche Systeme und neue Standards vorstellen, die ein wesentlich höheres Leistungsniveau erreichen, um die Dramatik der Entwicklung zu unterstreichen.

Für 2011/2012 sind folgende Trends zu erwarten: Die Konsolidierung auf dem Production-Level wird sich fortsetzen und sich auf die meisten missionskritischen und leistungssensitiven Anwendungen ausdehnen. Die Virtualisierung dieser Anwendungen setzt virtualisierungsoptimierte Hardware zur Reduktion des Hypervisor-Overheads voraus und adressiert hierbei besonders die Bereiche I/O-Latenz und Durchsatz. Außerdem werden die Anzahl der Cores in einer CPU sowie die Speichergrößen ansteigen. Dadurch wird die Dichte von VMs in einem Server zunehmen, wodurch wiederum die Anforderungen hinsichtlich Hochverfügbarkeit und Fehlertoleranz steigen. Neben der eigentlichen Konsolidierung werden Unternehmen vermehrt dazu tendieren, den Hypervisor für neue Aufgabenbereiche wie Hochverfügbarkeit, Disaster Recovery und Ressourcen-Optimierung einzusetzen. Virtualisierung eröffnet preiswertere und oftmals bessere Wege für diese Bereiche, besonders durch Instant Provisioning und Live Migration. So schön das auch alles ist, eines ist sicher: die Anforderungen an die I/O steigen dramatisch, je dynamischer man es möchte, desto dramatischer wird es.

Der Knackpunkt ist eine Verbesserung der I/O in einer virtualisierten Umgebung, sonst macht es in vielen Fällen nämlich einfach keinen Sinn. Wenn viele VMs um die Bandbreite wetteifern, reicht es nicht nur, die aggregate Bandbreite zu erhöhen, sondern auch den Mechanismus für den Zugriff einer individuellen VM auf die I/O-Ressourcen zu verbessern.

Neben Herstellerinitiativen gibt es auch Standardisierungsbestrebungen wie SR-IOV von PCI-SIG für diese Problemstellung. Darauf kommen wir später.

Wir können aber jetzt schon sagen, dass die Virtual I/O, die dadurch entsteht, die Anwendungen der nächsten Generation wesentlich besser unterstützen wird als konventionelle I/O-Komponenten.

Das Versprechen von „Virtual I/O“
In heutigen Rechenzentren fördert die Virtualisierung die Nutzung von Speicher-, Server- und Netzwerkressourcen vor allem dadurch, dass die Systeme viel schneller und mit viel höherer Flexibilität entwickelt und genutzt werden können. Andererseits ist die Konnektivität von Servern noch auf dem konstruktiven Stand von vor zehn Jahren, lediglich Datenraten haben sich erhöht. Es gibt immer noch eine Unmenge von Karten und Kabeln, Switches und Routern und eine hohe Komplexität für das Management-System, was das alles verwalten soll. Diese inflexible I/O-Infrastruktur treibt die Kosten hoch und sorgt für lange Zeiträume, die benötigt werden, um ein System bereitzustellen.

Nun gibt es ja schon seit einiger Zeit die Idee der virtuellen Switches, wie sie z. B. durch den Nexus 1000V von Cisco manifestiert wird. Bei genauerer Betrachtung fügt dieser Weg noch mehr Komplexität hinzu: der Hypervisor implementiert neben seinen vielen anderen Aufgaben eine weitere, ziemlich umfangreiche Komponente, den virtuellen Switch. Damit nicht genug fügt das Konzept den bisherigen Komponenten noch die Ebene der virtuellen Switches hinzu, die noch zusätzlich verwaltet werden müssen. Außerdem muss man sich genau überlegen, wie man diese virtuellen Switches denn konfiguriert und sie korrekt in Beziehung zu den bereits installierten realen Switches setzt. Das kann knifflig sein und wird in vielen Fällen Rückwirkungen auf die bestehende Netzwerk-Infrastruktur haben, die es eigentlich zu vermeiden gilt. Andererseits sind die virtuellen Switches nicht in der Lage, an einer anderen Stelle Komponenten überflüssig zu machen.

Dann gibt es den Gedanken der sogenannten I/O-Konsolidierung. Hier steht der Transport von FC-SAN-Daten und Ethernet-Verkehr über ein gemeinsames konvergiertes Ethernet-System im Vordergrund.

Analysiert man das aber genau, wird man feststellen, dass dieser Ansatz den Hypervisoren bei ihrer Leistungsproblematik in keiner Weise hilft.

Der Ansatz der „Virtual I/O“ ändert wirklich etwas. Er sieht vor, reale, feste I/O-Karten auf virtuelle I/O-Ressourcen abzubilden und diese im Rahmen einer optimierten Prozessorarchitektur ganz anders als bisher mit den VMs zu verbinden. Dazu müssen mehrere, neuartige Komponenten auf verschiedenen Ebenen zusammenwirken.

Vorteile sind:

  • weitgehender bis völliger Wegfall des virtuellen Switches im Hypervisor,
  • extreme Entlastung des Hypervisors von Kommunikationsaufgaben,
  • I/O-Leistungen in der Größenordnung von 10-GbE auch für relativ kleine Server-Konfigurationen.

Virtual I/O ist ein Gesamtbild, welches sich nur dann vollständig erschließt, wenn man die Komponenten auf den unterschiedlichen Ebenen (Prozessoren, physikalische Adapter, logische Adapter, Interrupts, Warteschlangensteuerungen, virtualisierungsbewusste I/O-Steuerungen und Hypervisoren im Server, Netzwerkfunktionalitäten im Rack-Bereich sowie Netzwerkfunktionalitäten außerhalb des Rack-Bereichs) einzeln und im Zusammenwirken betrachtet.

Probleme mit Virtualisierung und heutiger I/O

Server I/O ist ein absolut essentieller Kernbereich der Virtualisierung. Virtualisierte Server benötigen mehr Bandbreite und Verbindungen zu mehr Netzen und Speichern als nichtvirtualisierte Systeme, um den VMs, die sie beherbergen, ein gutes Arbeiten zu ermöglichen. Herstellerempfehlungen wie die „Best Practices“ von VMware empfehlen dedizierte Konnektivität für kritische virtuelle Maschinen. Nach einer neueren Umfrage unter Benutzern von Virtualisierungssoftware hat ein typischer virtualisierter Server 7 oder mehr I/O-Verbindungen, mit einer starken Tendenz zu 16. Außerdem muss er viel häufiger neu konfiguriert werden, wenn sich die Anforderungen durch die VMs ändern. Das steht natürlich in krassem Gegensatz zu den Erwartungen, die man an Vereinfachungen durch die Beweglichkeit virtueller Maschinen von der einfachen Lastverteilung über den unterbrechungsfreien Betrieb bis hin zur Disaster Recovery mit wandernden virtuellen Maschinen eigentlich hat.

Natürlich hat der aufmerksame Leser sofort eine Frage: Wenn alle I/O-Ressourcen durch eine Virtualisierung geshared werden, wie kann man dann Leistung und Sicherheit für eine spezifische Anwendung sicherstellen? Keine Angst, darauf kommen wir noch.

Traditionelle Server haben nicht notwendigerweise die gleichen Anforderungen wie virtualisierte Server. Sie sind oft nach den Maßgaben des bekannten dreilagigen RZ-Modells angeordnet, nach dem Server hinsichtlich ihrer I/O exakt so konfiguriert werden, wie es die Anwendungen auf ihnen erfordern.

Server-Virtualisierung ändert dieses Modell dramatisch. Das Ziel ist es ja, die Ausnutzung von Servern dadurch zu verbessern, dass man einen dynamischen Pool von Computing Ressourcen schafft, die so benutzt werden können, wie man es braucht. Um dieses Ziel erreichen zu können, müssen verschiedene Anforderungen erfüllt werden:

  • Flexible Verteilung von Anwendungen: die meisten Anwendungen sollten auf einem beliebigen Rechner des Pools laufen können
  • Multiple Anwendungen pro Server: ist ein Server nicht richtig ausgelastet, soll man weitere Anwendungen dazu packen können, um ihn besser auszunutzen
  • Mobilität von Anwendungen: Anwendungen sollten über möglichst alle Server portierbar sein, um Hochverfügbarkeit oder Load Balancing zu erreichen.

Diese Anforderungen haben erhebliche Implikationen auf die Server I/O:

  • Erhöhtes Verlangen nach Konnektivität. Um sich flexibel entfalten zu können, benötigen Server Konnektivität zu allen Netzen. Er muss an das SAN genauso wie an die DMZ kommen, und an alle Netze dazwischen. Um nach wie vor eine Isolation zu erreichen, verlangen viele Nutzer separate physikalische Verbindungen zu diesen getrennten Netzen, was in zahlreichen Verbindungselementen in einem Server führt, besonders dann, wenn man aus Sicherheitsgründen Redundanz verlangt.
  • Management Networks. Die Verwaltung der virtualisierten Umgebung führt zu zusätzlichen Anforderungen an die Konnektivität. So empfiehlt VMware z. B. dedizierte Konnektivität für das vMotion-Netzwerk.
  • Bandbreite. Konsequent zu Ende gedacht, erhöht Virtualisierung den Bandbreitebedarf für Server I/O. Normale Server arbeiten oft nur mit 10% Auslastung, virtualisierte Server kommen leicht auf 50% oder mehr. Bei der I/O-Auslastung haben wir ein ähnliches Wachstum. Dies kann zu Engpässen auf dem I/O-Pfad führen.

Die traditionelle I/O wurde für Umgebungen entworfen, bei denen auf einem Server im Wesentlichen nur eine Anwendung läuft. Sie kann zwar für virtualisierte Server wiederverwendet werden, es gibt aber deutliche Grenzen. Eine nahe liegende Option ist es, die bestehende I/O um ein paar Karten (NICs, HBAs) aufzurüsten und diese unter den VMs zu sharen. Das funktioniert nicht wirklich gut, denn bei Lastspitzen, wie sie z. B. bei VM Backups auftreten, können die Anwendungen Congestion erzeugen und sich gegenseitig behindern. Treten in einem solchen Zusammenhang Leistungsprobleme auf, sind sie schwierig zu finden, weil Diagnosetools für VMware noch wenig entwickelt und verbreitet sind. Selbst wenn ein Administrator den Grund für einen Engpass findet, wird ihm oft nichts anderes übrig bleiben, als eine neue Adapterkarte zu kaufen, oder die Anwendungs-Workloads auf den VMs anders zu verteilen. Ein anderes Problem der konventionellen I/O ist die schiere Masse der Verbindungen, die benötigt werden. Neben den Verbindungen zu den verschiedenen Datennetzen werden auch Verbindungen für das VM-Management und die Migration virtueller Maschinen benötigt. Gibt es im RZ auch ein SAN, muss jeder Server auch noch mit FC-HBAs ausgestattet werden.

Alle diese Probleme sind bekannt und haben ja grade zu Entwicklungen wie FCoE geführt. Was ist mit Blade Systemen? Server-Blades reduzieren das Kabelproblem durch einen internen Backplane. Hier gibt es aber deutliche Beschränkungen für die Anzahl möglicher Verbindungen, was für die Virtualisierung wieder problematisch sein kann. Eine Aufhebung oder Milderung der Beschränkungen ist entweder teuer (manchmal benötigt man ein Expansions-Blade, welches wieder Geld kostet und einen extra Slot belegt) oder gar nicht möglich.

Das Intra-Server-Problem auf den Punkt gebracht

Eine VM benutzt virtuelle NICs oder virtuelle HBAs. Diese werden im Rahmen der Erzeugung der VM (was ja nichts weiter als eine Laufzeitumgebung ist) vom Hypervisor erzeugt. Diese virtuellen Einheiten müssen auf reale physikalische NICs oder HBAs abgebildet werden. Diese Abbildung macht der Hypervisor durch Software, was die Sache erheblich verlangsamt und den Hypervisor erheblich belastet. Ein vergleichbares Problem entsteht bei der Abbildung der virtuellen Speicher der VMs auf den virtuellen Speicher des Basis-Betriebssystems. Das Problem wird jetzt dadurch verschärft, dass die Anzahl der VMs auf einem Server stark ansteigt. In 2008/2009 hat IDC durchschnittlich 6 VMs auf einem Server gezählt. Mit der Einführung neuer HW-Plattformen (8,16 oder mehr Cores) steigt das aber (jetzt – bald) auf 20 – 30 VMs pro Server. Heutige Server haben typischerweise oft 6 1-GbE-NICs, je zwei für Live Migration, für die Service Console und für die tatsächlichen VMs. Dazu ggf. noch zwei für FC-SAN. Die I/O-Konsolidierung auf Basis von 10-GbE und standardisierten Verfahren wie DCE oder proprietären wie Flex-10 sowie die Einführung von 8/16 GFC wird zu „dicken Pipes“ führen, deren Leistung besser als bisher auf die VMs verteilt werden kann und muss. Server-Virtualisierung benötigt eine höhere und engere Integration mit Netz, I/O und Speicher. Kurzum: Der „Softswitch“ im Hypervisor muss dringend ersetzt werden.

Taxonomie und Begriffsbildung
Hersteller, Gremien und Dritte sprechen zuweilen eine unterschiedliche Sprache, wenn es um I/O-Virtualisierung geht. IDC hat eine sehr deutliche Taxonomie entwickelt, an der wir uns auch hier orientieren wollen:

Software IOV (Hypervisor, software-emulierte I/O, paravirtualisierte I/O) ist die default Konfiguration für die aktuelle Virtualisierungsgeneration. Hypervisor virtualisieren einen Server einschließlich I/O komplett durch Software. Das ist hochgradig kompatibel (zu existierenden Geräten) und flexibel, erzeugt aber generell signifikanten Overhead.

Intraserver IOV bezeichnet einen Bereich hardware-basierender Technologien für die Virtualisierung der I/O von VMs, die auf einem Server gehostet werden. Die meisten Lösungen sind rund um den Standard PCI-SIG SR-IOV gebaut. Komponenten sind:

  • Plattformtechnologie (z. B. Intel VT-d oder ATS-Fähigkeit),
  • I/O-Adapter-Technologie (Multiqueue, SR-IOV virtuelle Funktionen),
  • passendes BIOS und Treiber.

IOV-Switches sind entweder proprietäre oder PCI-SIG Multi-Root Virtualization (MR-IOV)-kompatible I/O-Direktoren, die die I/O über multiple Server in einem Rack oder einem Blade Chassis hinweg virtualisieren und generell für Konsolidierung, Bandbreite Sharing, flexibles Provisioning und vereinfachte Verkabelung benutzt werden. Der Xsigo Director fällt z. B. in diese Klasse.

Konvergierte Fabrics. Diese Technologien können multiple I/O-Protokolle über eine einheitliche Fabric abwickeln. FCoE Fabrics wären ein Beispiel dafür.

Diese Taxonomie schafft endlich auch eine gewisse Abgrenzung von Systemen untereinander, die in der hitzigen Diskussion oft verloren geht:

  • Intraserver I/O gehört in einen Server (egal ob Rack- oder Blade-Server).
  • IOV-Switches gehören im Wesentlichen Top of Rack.
  • Konvergierte Fabrics bilden im Wesentlichen das eigentliche Infrastruktur-Netz.

Nur durch eine geeignete Eingrenzung können wir sinnvoll darüber diskutieren, welche Funktionen wo und in welchem Umfang sinnvoll sind. Das heutige Durcheinander kommt von den Herstellern. So platziert z. B. HP mit Flex-10 die Funktion eines proprietären IOV-Switches mitten in den Blade-Server. Das funktioniert zweifelsohne, hat aber z. B. den Nebeneffekt, dass die Diskussion über FCoE und vergleichbare Verfahren verharmlost wird, weil das ja nur auf einem sehr kurzen Stück zwischen Blade System und ToR-Switch stattfindet. Xsigo kann mit seinen Directors ein komplettes Netz zur I/O-Versorgung aufbauen, was aber dann technisch auf InfiniBand basiert. Die Frage ist doch immer, was passiert, wenn man solche Konfigurationen in größerem Maßstab ändern oder erneut konsolidieren möchte. Andererseits wird auch die Tragweite der Diskussion um FCoE klar: Es ist nicht für Einzelverbindungen, sondern es wird ggf. das Infrastruktur-Netz bilden.

« Teil 11: Virtualisierung und I/O: die Grenzen des HypervisorsTeil 13: SR-IOV »


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.

*

.