Virtuelle Switches und kein Ende

Kommentieren Drucken

Die Virtualisierung von Servern war anfangs ein reines Serverthema, getragen und betreut von der für den Serverbetrieb zuständigen Abteilung. Über mögliche Auswirkungen auf das Netzwerk wurde damals überhaupt nicht nachgedacht. Man hatte jetzt einfach die Möglichkeit zwei, drei oder noch mehr Server auf einem einzigen der chronisch unterlasteten Systeme laufen zu lassen. Das Verfahren war (und ist) denkbar einfach: Der physische Host bekommt ein neues, spezielles Betriebssystem, die jetzt virtuellen Anwendungsserver werden betrieben wie bisher, durch die Abstraktionsschicht des Hypervisors jetzt lediglich mit standardisierter „Hardware“.

Die Vereinfachungen und Einsparungen im Betrieb waren schnell unübersehbar und die Technologie äußerst erfolgreich.

Ein, wenn nicht das, zentrale Element eines Virtualisierungshosts ist aber der virtuelle Switch. Ein Switch, im Sinne von IEEE 802.1 eine Ethernet Bridge, also ein Netzwerkgerät! Und dieses Netzwerkgerät wird von der Servertruppe administriert – das geht ja gar nicht.

Das Entsetzen auf der Netzwerkseite war groß, als man feststellte, welcher Vogel da völlig unbemerkt geschlüpft und sich breit gemacht hatte.

Die nachfolgenden Entwicklungen waren daher im Wesentlichen von zwei Vorgaben geprägt:

  1. Das Ding muss weg.
  2. Notfalls kann man damit leben, falls es komplett unter der Kontrolle der Netzwerker steht.

Was dabei herausgekommen ist, ist bekannt:

In einer ersten Entwicklungswelle wurde versucht, die virtuellen Switche in die Netzwerkadministration zu integrieren. Der „Distributed vSwitch“ von VMware oder Ciscos Nexus 1000V sind typische Beispiele für eine zentrale Administration von virtuellen Switches über mehrere Hosts hinweg.

Der Ansatz „weg damit“ kann in letzter Konsequenz aber nur durch einen direkten Zugriff auf die Netzwerkkarte umgesetzt werden. Die aktuellen Prozessorfamilien unterstützen diese Techniken schon seit einiger Zeit durch die Umrechnung von virtuellen Speicheradressen in Speicheradressen der physischen Hardware. Aber die Nachteile aus betrieblicher Sicht sind gewaltig:

  • Sie brauchen jetzt hardwarespezifische Treiber in der VM.
  • Der Hypervisor kann nicht mehr die Datenströme kontrollieren und damit auch nicht mehr die VM während ihres Betriebs in den Suspend-Mode versetzen oder gar verschieben. Wesentliche Kernfunktionen der Server-Virtualisierung sind damit außer Kraft gesetzt.
  • Durch die 1:1-Zuordnung von virtuellen und physischen Netzwerkkarten braucht man schnell mehr Netzwerkschnittstellen als physisch untergebracht werden können.

Zumindest der letzte Punkt wurde durch SR-IOV-Karten aus dem Weg geräumt, aber die beiden erstgenannten bleiben auch damit bestehen, ja schlimmer noch, durch SR-IOV haben Sie plötzlich eine Switching-Funktionalität auf Ihrer Netzwerkkarte!

Das ernüchternde Fazit: Direkter Hardware-Zugriff passt einfach nicht in eine Umgebung, in der alle andere Hardware virtualisiert ist.

Erst eine dritte Entwicklungswelle widmete sich dem Kernproblem: Virtuelle Switche gibt es ursprünglich nur aus einem einzigen, banalen Grund: um eine Kommunikation zwischen virtuellen Maschinen auf demselben Host zu ermöglichen. VEPA (Port Aggregation), standardisiert in IEEE 802.1Qbg, und Port Extension, standardisiert in IEEE 802.1BR ziehen den kompletten Datenverkehr aus dem Host auf den ersten physischen Switch bzw. auf die sogenannte Controlling Bridge, selbst dann, wenn die Datenpakete anschließend wieder auf demselben Weg zum selben Host zurückgeschickt werden müssen.

Der virtuelle Switch verschwindet mit diesen Techniken zwar nicht, wird aber zur einfachen Paketverteilstation. Die gesamte Frame-Verarbeitung von QoS über VLAN-Zuweisung und ACLs bis hin zu Monitoring, Statistiken und Troubleshooting kann außerhalb in einem „ordentlichen“ Netzwerksystem stattfinden.

Ende gut, alles gut? Weit gefehlt, beide Standards werden von den gängigen Hypervisor praktisch nicht unterstützt, man muss also auf passende SR-IOV-Karten ausweichen und dann entweder jeder virtuellen Netzwerkschnittstelle ihren eigenen virtuellen Switch zuweisen oder der VM direkten Zugriff auf die physische Netzwerkkarte gestatten, womit wir wieder beim obengenannten Grundsatzproblem wären. Darüber hinaus erfordert zumindest 802.1BR komplett neue Hardware.

Um aber die Entwicklung völlig auf den Kopf zu stellen, treten jetzt zwei neue Technologien auf den Plan, die quasi alles andere überflüssig (manches sogar inkompatibel) machen und wieder voll auf virtuelle Switches setzen: Netzwerkvirtualisierung und SDN.
Netzwerkvirtualisierung nutzt Overlay-Techniken und Tunnelprotokolle, die zwar nicht notwendigerweise, aber doch in den meisten Realisierungen direkt im Hypervisor angesiedelt sind. VXLAN, NVGRE und STT sind zurzeit die gängigsten Tunnelprotokolle von Netzwerkvirtualisierungsprodukten und in allen dieser Produkte sitzen die Tunnelendpunkte im Hypervisor. Durch die aufgebauten Overlays werden aber die Anwendungsnetze vom eigentlichen, physischen Transportnetz getrennt, die meisten der oben angesprochenen Technologien funktionieren damit einfach nicht mehr.

SDN geht einen ganz anderen Weg und zentralisiert die gesamte Netzwerkintelligenz und die gesamte Entscheidungslogik zur Frame-Bearbeitung und Frame-Weiterleitung an einem Punkt. Damit werden physische wie virtuelle Switche gleichermaßen zu unbedeutenden Paketvermittungssystemen ohne eigenes Mitspracherecht. Dies bedeutet aber schlicht und einfach, dass es gar keinen Sinn macht, sich großartig den Kopf über virtuelle Switches zu zerbrechen – die Steuerung und Administration findet eh im SDN-Controller statt.

Mit SDN und Netzwerkvirtualisierung vollziehen virtuelle Switches also ein fulminantes Comeback und setzten sich in der RZ-Architektur fester als je zuvor fest. Wer in seinem Rechenzentrum auf die Virtualisierung von Server setzt, muss mit virtuellen Switches leben und deren Betrieb regeln – alles andere sind faule Kompromisse. Dies gilt in Zukunft noch mehr als jetzt schon.

Trotzdem bedeutet dies kein Rückschritt. Eine zentral gesteuerte Provisionierung aller Netzwerkdienste direkt am Edge bringt endlich die betrieblichen Vorteile von virtualisierten Umgebungen auch in die Netzwerkabteilung.

Information Security Management mit ISO 27001 und BSI-Grundschutz

08.11. - 10.11.2017 in Stuttgart 1.890,-- € netto

Sicherheit-BSI_research
Dieses Seminar stellt den Aufbau und die nachhaltige Umsetzung eines standardisierten und zertifizierbaren Information Security Management System (ISMS) auf Basis von ISO 27001 und BSI IT-Grundschutz vor.

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.

*

.