Server-Virtualisierung steht für Kostenersparnis sowie eine signifikante Verbesserung der Flexibilität und Agilität im Datacenter. Die Kostenersparnis wird primär durch die Server-Konsolidierung und die damit einhergehenden Einsparungen in den Bereichen Platzbedarf, Hardware-Investitionen, Auslastung sowie geringerer Stromverbrauch im Rechenzentrum erreicht. Flexibilität wiederum entsteht durch die einfachere Zuordnung von Ressourcen für neue Applikationen, kürzere Testzyklen und das schnelle Einbringen neuer Applikationen.
So notwendig Flexibilität, Agilität und Ersparnis im Datacenter sind, die Kehrseite dabei sind gänzlich neue Herausforderungen. Sie gilt es zu meistern. Sonst führt ein Virtualisierungsprojekt schnell zu höheren Betriebskosten und einer Reduzierung der Gesamtverfügbarkeit.
Die Servervirtualisierung selbst stellt neue Anforderungen. Zunächst einmal kommt eine neue Komponente ins Spiel, der so genannte »vSwitch« oder virtual Switch. Dieser wird mit dem jeweiligen Hypervisor wie »vSphere«, »XEN«, »Hyper-V« und »KVM« mitgeliefert. Er stellt sowohl die lokale Connectivity auf dem Server (Host) zwischen virtuellen Maschinen (VM) als auch die Verbindung nach außen zur physischen Infrastruktur sicher. Dabei stellt sich die Frage, wer diese Komponenten konfiguriert – das Server- oder Netzwerkadministrationsteam? Wer stellt sicher, dass die Konfiguration von »vSwitch« und physischen Switch zusammenpassen?
Insbesondere die Dynamik-Funktionen wie automatisches Failover, manuelles Umziehen oder auch die ressourcen- oder stromverbrauchsorientierte, vollautomatische Reallokierung von virtuellen Maschinen auf unterschiedliche Server im Betrieb stellen höchste Ansprüche an die Netzwerkinfrastruktur. Es gibt derzeit zwar einige Projekte mit vorprovisionierten Konfigurationen. Stößt man jedoch in Regionen von hunderten oder tausenden von virtuellen Maschinen (VM), ist das nicht mehr so umsetzbar.
Kommunikationsströme werden immer schwieriger zu monitoren. SOA-basierte Applikationskonzepte in Verbindung mit der hohen Mobilität von VM-Instanzen sorgen dafür, dass der Rechenzentrumsbackbone eine sehr hohe Performance zu jeden Punkt zur Verfügung stellen muss. Delay und Jitter sind zu minimieren, um keinerlei Performanceprobleme auf Applikationsebene zu erzeugen. Um VM- Umzüge zu ermöglichen, müssen wieder größere Layer-2-Netze auch über Rechenzentrumsgrenzen hinweg aufgebaut werden. Durch die Tatsache, dass VM-Mobility nur mit Separierung von Storage und Server funktioniert, kommt hier die nächste Herausforderung auf den Netzwerkadministrator zu.
Die Separierung von Server und Storage und die damit verbundene Frage zur Wahl der Anbindung – NFS, pNFS, iSCSI, FC, FCoE – stellt wiederum neue Anforderungen an das Netzdesign. Welche Technologie, ein Netz oder zwei separate Netze? I/O-Konsolidierung oder nicht? Allein mit diesen Fragestellungen können Bücher gefüllt werden.
Wie kann man nun den Betrieb einer virtualisierten Serverumgebung so organisieren, dass ein hoher Automatisierungsgrad bei gleichzeitiger Erhaltung der Sicherheit und maximaler Visiblität erreicht wird? Zunächst einmal müssen VMs an der Netzwerkinfrastruktur überhaupt erkannt und nachverfolgt werden können. Vielen Installationen allerdings fehlt dazu die Möglichkeit. So kann weder ein aktuelles Bild aller am Netz angeschlossener VMs erzeugt werden, noch ist eine Historie vorhanden. Darüber hinaus stellt es oft sogar eine Herausforderung dar, überhaupt an einem Host zu erkennen, über welches physische Interface eine VM überhaupt kommuniziert. Um zu vermeiden, dass diese unberechtigterweise in die Infrastruktur eingebracht wird, müssen Mechanismen zur Kontrolle etabliert werden, die eine Aufrechterhaltung von Sicherheitszonen ermöglichen.