Ende des Server-Access-Bereiches sichtbar?

Kommentieren Drucken

Viele aktuelle Diskussionen drehen sich um die Frage, wer in Zukunft die Kontrolle hat. Bleibt das Netz wie bislang neutral oder wird es gar aus VMware gesteuert? Es ist sinnvoll, einige Entwicklungen zu skizzieren, die die Gestalt der privaten Netze in den nächsten Jahren massiv verändern werden. Verschiedene Aktivitäten, z.B. die Definition von Tunnel-Systemen, basieren auf der Annahme, dass auch weiterhin im Netz veraltete Technik eingesetzt wird. Was ist aber, wenn sich alles systematisch weiterentwickelt?

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.

Die Konsolidierung auf dem Production-Level wird sich fortsetzen und sich auf die meisten missionskritischen und leistungssensitiven Anwendungen ausdehnen. Die Virtualisierung dieser Anwendungen setzt virtualisierungs-optimierte 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 Ressorcen-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.

Marktforschungsunternehmen gehen davon aus, dass schon in 2015 eine durchschnittliche Anzahl von 30 VMs pro Server erreicht sein wird.

Der Knackpunkt dafür ist aber 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 vor allem muss der Mechanismus für den Zugriff einer individuellen VM auf die I/O-Ressourcen verbessert werden.

Nun gibt es ja schon seit einiger Zeit die Idee der Virtuellen Switches, wie sie z.B. durch den Nexus 1000 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.

Auf den Punkt gebracht kommen die heutigen Probleme wie folgt zustande:

  • Die VMs müssen immer indirekt und geshared auf die physikalische Übertragungsressource zugreifen
  • Die Hersteller von Virtualisierungssoftware verstehen nicht wirklich etwas von Netzen und erzeugen unnötige Komplikationen

Eine mögliche Lösung ist: direkter Zugriff der VMs auf die physikalischen Übertragungs-Ressourcen!

Dafür gibt es seit Jahren einen Standard, nämlich SR-IOV, der im Markt noch zu wenig verstanden wird. SR-IOV ist die Basis für die notwendige Hardware-Unterstützung der VM-Kommunikation. Vorteile sind:

  • Völliger Wegfall des Virtuellen Switches im Hypervisor
  • Extreme Entlastung des Hypervisors von Kommunikationsaufgaben
  • I/O-Leistungen in der Größenordnung von 10, 40 oder 100 GbE auch für relativ kleine Server-Konfigurationen

Ziel der Server-Virtualisierung 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.

IO-Virtualisierung ist einfach die Abstraktion der logischen Details der I/O von den physikalischen Details. Das ist wichtig, um die höheren Protokolle von den physikalischen Verbindungs- oder Transportdetails zu befreien. Es gibt hier eine Reihe von Ansätzen, wir beschränken uns aber hier auf die, die mit Server-Virtualisierung zu tun haben, also besonders auf den SR-IOV-Standard. SR-IOV ist ein PCI-SIG-Standard, der das effiziente Sharing von PCI-Geräten unter VMs ermöglicht und in Hardware implementiert wurde, um in der Leistung möglichst nahe an nativer I/O-Leistung zu liegen. SR-IOV erzeugt eine Menge von Virtuellen Funktionsschnittstellen in der Hardware eines physischen PCI-Geräts. Die Virtuellen Funktionsschnittstellen sind im Wesentlichen Virtuelle Instanzen des physischen Geräts. Sie können den VMs unmittelbar zugeordnet werden und erlauben es, dass das physikalische Gerät von den VMs gemeinsam benutzt wird, z.B. zur I/O, OHNE dass ein Hypervisor dabei eingreifen müsste.

Damit SR-IOV funktioniert, müssen eine Reihe von Komponenten auf einem Server zusammenspielen:

  • Ein System-Chipsatz, der I/O-Isolation und direkte Zuordnung unterstützt, wie z.B. Intel ® Virtualization Technology for Directed I/O (Intel ® VT-d)
  • Eine SR-IOV-fähige NIC (oder ein anderes I/O-Gerät) mit eingebauten (Hardware) Funktionen für die Virtualisierung
  • Ein BIOS, welches den Chipsatz und die SR-IOV-Adapter erkennt
  • Ein Hypervisor, der dahingehend modifiziert sein muss, dass er die Möglichkeiten von SR-IOV nutzen kann und für den Nutzer einen Treiber installieren müssen, damit er SR-IOV-Geräte erkennt
  • Ein Treiber für das Basis-Betriebssystem, der es ermöglicht, I/O direkt mit dem SR-IOV-Gerät auszuführen.

SR-IOV bietet eine Menge von Vorzügen auf den Bereichen Leistung, I/O-Konsolidierung, Skalierbarkeit und Datenschutz:

  • Durch die unmittelbare Zuordnung virtueller Funktionen eines I/O-Gerätes wird nahezu dessen native Leistung erreicht. Der Gesamt I/O-Durchsatz steigt enorm und die Latenz sinkt durch die Beseitigung des Software-Overheads.
  • Durch die Entlastung des Hypervisors kann sich die CPU wieder vermehrt produktiven Aufgaben widmen.
  • Es wird ein effizientes, hardware- unterstütztes Sharing von I/O-Ressourcen ermöglicht.
  • Die I/O-Konsolidierung erlaubt den System-Verwaltern die Benutzung virtueller Funktionen anstelle von multiplen physischen Geräten für die Separierung von I/O-Funktionen. Das umfasst nicht nur Netzwerk-Komponenten, sondern auch Speicher.
  • Die I/O Geräte können effektiver genutzt werden.
  • Man spart HW-Kosten, vereinfacht die Verkabelung, reduziert die Anzahl von benötigten Switch Ports und senkt somit den Verwaltungsaufwand.
  • Durch die systematische Benutzung EINER leistungsfähigen Schnittstelle statt vieler kleinerer steigt die Skalierbarkeit des gesamten Systems.
  • Datenschutz und Datensicherheit werden alleine dadurch erhöht, dass man Hardware anstelle von Software dazu benutzt, die I/O Datenströme zwischen virtuellen Maschinen zu kreieren und zu isolieren.

Dadurch entstehen auch handfeste wirtschaftliche Vorteile:

  • Höherer Konsolidierungsgrad mit gesteigerter Ersparnis bei Server-HW
  • Ausdehnung der Spareffekte durch Virtualisierung auf Anwendungen, die bisher nicht virtualisiert werden konnten
  • Ausdehnung der verbesserten Effizienz bei der Verwaltung von Systemen auch auf diese neue Klasse von Anwendungen
  • Verbesserte Antwortzeiten und QoS für Anwendungen
  • Kostenersparnis durch Reduktion von Adaptern, Kabeln, Switch Ports und Stromverbrauch sowie Management-Punkten

Der Hersteller Mellanox hat vor kurzem eine Referenzarchitektur für die Implementierung der Open Stack Architektur vorgestellt, siehe Bild 1. Besonders spannend ist, dass die Adapterkarten kleine Switches enthalten, deren Aufgabe es ist, den VMs eine unmittelbare Hardware-Schnittstelle zu geben. Fast schon zum netten Detail gerät die Tatsache, dass das Ganze mittels Open Flow und eines entsprechenden Controllers gesteuert werden kann. (siehe Bild 2) Die Lösung ist nicht auf pures SR-IOV beschränkt, HVs können ebenfalls eingebunden werden.

Das ist der Anfang vom Ende der ToR, EoR- und sonstiger Switches des Access-Bereiches, den man in Bild 1 auch schon gar nicht mehr sieht. Durch die Fortschritte in der Standardisierung und durch erhebliche Leistungssteigerungen bei den Prozessoren kann ein Server, der z.B. 30 VMs beherbergt nunmehr mit dieser Konstruktion via einer hoch konzentrierten und konvergierten 40 oder 100 GbE-Leitung direkt mit einem Core-Switch verbunden werden. Alles, was an Steuerung noch notwendig ist, wird von einer Software erledigt, die problemlos mit einer oder zwei VMs, von denen es ja genug gibt, implementiert werden kann.

Man kann es auch so formulieren, dass mit Hilfe der entsprechenden Hardware-Unterstützung direkt in den Servern Virtuelle Switches entstehen, die auf das Leistungsprofil der Server optimal abgestimmt werden können und auch sonst die üblichen Vorzüge virtualisierter Lösungen, wie unterbrechungsfreien Betrieb, mit sich bringen können. Infonetics erwartet ein massives Wachstum derartiger Lösungen ab 2015, eben abhängig von der Entwicklung der Server.

Es gibt oftmals die Aussage, dass man pro VM eine Kommunikationsleistung von z.B. 1 GbE vorsehen möchte. Das geschieht meistens mangels der Möglichkeit einer dynamischeren Konfigurierung. Ein Virtueller Access Switch kann hier ganz anders agieren und die Last elegant vor Ort auf die physikalische Hochleistungsschnittstelle abbilden. Das ist heute eine 10 oder 40 GbE-Schnittstelle, in zwei Jahren hat sie 40 oder 100 GbE.

Fazit

Fortschritte in der Hardware ermöglichen mehr VMs pro Prozessor und in die Adapterkarten integrierte Switch-ASICs. Diese sorgen für eine unmittelbare Anbindung der VMs an das Netz. Die Steuerung der Gesamtstruktur kann durch eine oder zwei VMs erledigt werden. Die so entstandenen Virtuellen Access Switches haben erhebliche betriebliche Vorteile. Wir haben das hier nicht weiter thematisiert, aber natürlich können auf dieser Ebene auch Quality- und Traffic Engineering Verfahren ein- und durchgesetzt werden. Die DCF-Funktionen sind hier ein übliches Mindestmaß. Die gesamte Konstruktion basiert auf bewährten Standards. Es gibt aktuell mindestens ein Muster, damit ist die technische Machbarkeit hinreichend belegt.

Wichtige Konsequenzen sind:

  • die Weiterentwicklung privater Netze kann rein auf der Basis von Standards geschehen, proprietäre Lösungen sind nicht nötig
  • Private Netze können auch in Zukunft unabhängig von speziellen Funktionen aus der Virtualisierungssoftware gestaltet werden
  • Die privaten Netze können sich allerdings dem allgemeinen Konzentrationstrend nicht entziehen. Es wird in Zukunft immer weniger individuelle Geräte geben, die allerdings jeweils erheblich mehr leisten.
zugeordnete Kategorien: LAN, 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.

*

.