Ratgeber - Virtualisierung im Netz (Teil 2)

Netz-Know-how fürs Data Center

31.01.2011 von Markus Nispel
Aus der Diskussion über virtuelle Rechenzentren werden potenzielle Netzprobleme häufig ausgeklammert. Wir zeigen, worauf Administratoren achten sollten.
Bei der Virtualisierung der Server-Systeme wird häufig das Netz vergessen.
Foto: 1&1

Höhere Anforderungen - weniger Budget: Unter diesem Druck steht heute auch die Unternehmens-IT. Für weniger Geld soll sie ihre Dienstleistungen agiler und zuverlässiger erbringen, und zwar mit gleicher oder höherer Sicherheit. Nach Schätzungen aus der Branche werden mehr als 80 Prozent von IT-Budgets zur Erhaltung bestehender Applikationsumgebungen innerhalb des Data Centers eingesetzt.

Um diese Kosten in den Griff zu bekommen, mehr Flexibilität zu gewinnen und die Administration zu vereinfachen, werden nun Virtualisierungstechniken eingesetzt. Sie sollen Server und Speicher effizienter machen.

Das vergessene Netz

Leider bleiben mögliche Probleme wie die Sicherheit oder der Einfluss auf die Netzinfrastruktur aus der Diskussion um eine Virtualisierung der Server-Systeme häufig ausgeklammert. Schließlich lässt sich ja alles "virtuell" managen. In der Realität treffen dann Welten aufeinander, die abgestimmt operieren müssen. Schon die Frage, wer (virtuelle) Switches konfiguriert, birgt ein ähnlich explosives Potenzial wie in der Vergangenheit die Frage, ob Sprach- oder Datenübertragung "gewinnt".

Ferner können die integrierten Switches der am Markt verfügbaren Virtualisierungslösungen nicht als reif betrachtet werden, sowohl was die Features als auch was die Stabilität angeht. Der erfahrene Netzwerker fragt sich außerdem, wie es um die Performance und das Monitoring dieser softwarebasierenden Komponenten bestellt ist und wie es sich auf den Host auswirkt, wenn zusätzliche Features eingeschaltet werden.

Checkliste Virtualisierung

Diese Fragen sollten Sie stellen

Durch die Hypervisor-Technik und die integrierten virtuellen Switch-Funktionen ergeben sich für den traditionellen Netz- und Sicherheitsverantwortlichen folgende Fragen:

  • Wer sorgt für die Sicherheit der neuen Software-Applikation Hypervisor? Das Patch-Management oder andere?

  • Wer sorgt für die mit der physischen Netzinfrastruktur und deren Sicherheitsmechanismen (Firewall, VLAN, Access-Listen, Virtual Routing and Forwarding = VRF etc.) abgestimmte Konfiguration der virtuellen Switches auf den Hosts, um Sicherheitslücken zu vermeiden?

  • Wer ist für das Change-Management auf der Server- und Netzseite zuständig?

  • Wie kann man Virtual Machines (VMs) überhaupt in der Infrastruktur erkennen und tracken (aus Compliance-Anforderungen heraus und für das Troubleshooting)?

  • Wer plant die Kapazitäten der physischen Infrastruktur, um in allen Virtual-Machine/Host-Kombinationen ausreichend Bandbreite zur Verfügung zu stellen? Die Inter-VM-Kommunikation auf dem gleichen Host ist ja zunächst nicht sichtbar.

Virtuelle Switches einbeziehen

Man kann die virtuellen Switches nicht ausblenden, sondern sollte sein Betriebskonzept darauf abstimmen und sie integrieren, ohne zu viele Funktionen hineinzuverlagern: Das würde die Betriebskosten und die Komplexität erhöhen und eventuell zu nicht erwünschten Effekten führen.

Virtuelle Maschinen lassen sich durch Sicherheitselemente auf Switch-Ebene kontrollieren.
Foto: Enterasys

Ein großer Netzhersteller verfolgt den Ansatz, den virtuellen Switch durch einen eigenen zu ersetzen, um das "Command Line Interface" (CLI) identisch zu gestalten und so die Konfiguration zu vereinfachen. Damit bindet sich der Anwender allerdings komplett an die Anbieterkombination aus Netz- und Virtualisierungstechnik. Dies ist erfahrungsgemäß nicht erstrebenswert. Ein immer wieder auftretendes Problem sind etwa die "Version Lock-ins": Zieht ein Partner nicht rechtzeitig mit, kann eine neue Version aus Kompatibilitätsgründen eventuell nicht eingespielt und genutzt werden.

Management-Systeme als Alternative

Einen grundlegend anderen Ansatz verfolgt dagegen Enterasys. Dabei ist die Integration über Management-Systeme eine Variante. Eine andere sieht die vollständige Unabhängigkeit von der Virtualisierungstechnik als primäres Ziel.

Wie dies konkret aussehen könnte, lässt sich an einigen Beispielen verdeutlichen. Eine Vorgehensweise ist die Reduktion der Integration auf ein Minimum. Jede neue VM wird dabei durch Sicherheitsmechanismen auf Virtual-Switch-Ebene wie Protected Ports oder Private VLANs vom Server-Administrator separiert. Für die gesamte Zuordnung von VLAN, Access-Listen, Quality of Service etc. (eine so genannte Policy) sorgt die Netzinfrastruktur. Das hat den Vorteil, dass wirklich nur an einer Stelle eine komplexere Konfiguration erfolgen muss.

Die Netzinfrastruktur und ihr Management sollten diese Konfiguration dynamisch an die VM-Identität (MAC-Adresse, IP, Host-Name oder ein digitales Zertifikat auf der VM) binden, damit beim "Umzug" einer VM aus Redundanz- oder Lastverteilungsgründen der Netzadministrator nicht eingreifen muss. Die Netzkomponenten müssen speziell darauf ausgelegt sein und beispielsweise die unterschiedlichen Policies pro VM und Port in entsprechender Skalierung unterstützen. Die Policies werden dann dynamisch nach einer VM-Identifizierung beziehungsweise Authentifizierung an diesem Port der entsprechenden VM zugeordnet. Damit kann dann auch das Tracking der VM erfolgen. Dafür werden Basistechniken aus dem NAC-Bereich (NAC= Network Access Control) genutzt wie etwa die Erkennung neuer Endpunkte, deren Identifzierung und Authentifizierung sowie die nachfolgende Autorisierung.

Virtualisierungsvarianten

Virtuelle Rechenzentren können per NAC über Policies administriert werden.
Foto: Enterasys

Eine weitere Variante ist die Integration über die bestehenden APIs der Virtualisierungsanbieter und ihre Management-Systeme wie etwa XenCenter oder vCenter. Dabei kommen Web-Services via XML zum Einsatz, um Daten zwischen VM- und Netz-Management auszutauschen und zu synchronisieren. Das VM-Management bekommt vom Netz-Management in Echtzeit den Status, die zugewiesene Policy und die Lokation, also den physischen Switch-Port, der VM übermittelt. Diese Informationen werden automatisch ins Netz-Management synchronisiert und an eine netzspezifische Policy gebunden, wenn neue VMs erzeugt und einem VLAN zugewiesen werden. So braucht der Netzadministrator nicht selbst einzugreifen, hat aber direkten Zugriff auf alle Daten einer VM. Diese benötigt er beispielsweise für das Troubleshooting, die Kapazitätsplanung oder ein (Compliance-)Reporting. Je nach den Möglichkeiten der API kann man dieses Konzept ausbauen und vom Netz-Management aus die Virtual-Switch-Konfiguration wieder überschreiben - abhängig davon, wer die Kontrolle über die Gesamtkonfiguration haben soll.

Besonderes Augenmerk sollte in einer virtualisierten Server-Umgebung dem Monitoring der jetzt und früher genutzten Bandbreite gelten. Durch die potenzielle Verschiebung von Server-Ressourcen auf neue oder wenig genutzte Hosts kann sich das gesamte Verkehrsprofil im Data Center schlagartig ändern. Dem Administrator muss dies nicht nur bewusst sein, sondern er sollte sich entsprechend auch wappnen. Transparenz hat hier oberste Priorität: Verkehrsstatistiken pro VM sollten über präzise Techniken wie zum Beispiel Netflow erhoben werden und auf Abruf bereitstehen. Damit kann man nicht nur Tendenzen erkennen beziehungsweise Verhalten vorhersagen, vielmehr eignen sich Flow-Daten auch gut, um Angriffe auf die VM-Infrastruktur zu erkennen. Network Behavior Analysis (NBA) ist hier das Stichwort. Wird auch die aktuelle Gerätegeneration gut überwacht, dann hat die IT-Mannschaft das gesamte Data Center und die dort zur Verfügung gestellten Applikationen sicherheitstechnisch im Griff.

Fazit

Unter dem Strich können Web-Services und SOA-basierende Management-Konzepte den Betrieb einer Virtual-Data-Center-Umgebung deutlich vereinfachen und einen hohen Automatisierungsgrad bewirken. Damit lassen sich der Betrieb transparent und sicher gestalten und die Kosten senken.

Mehr zu diesen themen finden Sie auch hier:
Virtualisierung im Netz(1) - Flexibel mit virtuellen Routern
Virtualisierung im Netz (3) - Standards für RZ-Virtualisierung stehen vor der Marktreife
Virtualisierung im Netz (4) Unterwegs zur Unternehmens-Cloud