Startseite > Software & Services > Schritt für Schritt: Mehr Netzwerkperformance bei Virtualisierung

Bei Vmware einfacher als bei Citrix

Schritt für Schritt: Mehr Netzwerkperformance bei Virtualisierung

25. März 2010, 16:14 Uhr | Werner Veith

Fortsetzung des Artikels von Teil 2

Nicht immer sind sechs Netzwerk-Interfaces möglich

Muss der Vmware-Host über NFS oder iSCSI auf Shared-Storage zugreifen, sollte der Verwalter dafür einen eigenen LAN-Adapter oder -Trunk mit einem eigenen Konsole- und Kernel-Interface abstellen. Diese LAN-Anbindung mit insgesamt sechs Interfaces sorgt für ausreichend Geschwindigkeit bei der VM-Anbindung (Virtual-Machine) und trennt zudem administrative Host-Verbindungen vom VM-Traffic. Ein siebtes Interface kann die IP-SAN-Anbindung beschleunigen oder für die Fault-Tolerance-Funktion dienen.

Einige Server können leider keine sechs Interfaces aufnehmen. Im Labor von Network Computing gibt es beispielsweise 1-HE-Maschinen, die auf Grund der wenigen Steckplätze und des engen Formfaktors nur vier NICs verwalten. In dieser Szenerie wäre es dann fast schon verschwenderisch, würde der Verwalter zwei von vier NICs rein für administrative Funktionen reservieren und den VMs vorenthalten.

Hier gibt es die Option, alle vier NICs zu einem Verband zusammenzufügen und auch die administrativen Verbindungen über Netzwerk-Gruppen mit eigenen VLANs auszulagern. Das Problem bei diesem Setup ist die Umstellung einer bestehenden Konfiguration, welche das erste Interface bereits untagged für die Konsole verwendet.

Im Labor von Network Computing hat das Team auf einem Vmware-Server daher zunächst einen Trunk mit drei Adaptern gebildet. Dieser bekommt alle LAN-Gruppen mit den VMs und verbindet sich mit getaggten VLAN-Paketen mit dem Switch. Danach erhält der Kernel einen neuen Port mit VLAN-Konfiguration auf dem Tri-NIC-Vswitch. Das Problem, welches sich nun dem Verwalter stellt ist, dass das bestehende primäre Managament-Interface nicht so ohne weiteres umziehen möchte.

Im Labor erstellt Network Computing zuerst einen weiteren Management-Adapter mit neuer IP auf dem getaggten Switch. Dann muss der Host kurzfristig den verwalteten Bereich des Vshpere-Servers verlassen. Da sich der bestehende Konsole-Adapter nicht über das grafische Interface entfernen lässt, muss der Verwalter hier die Kommandozeile des Vmware-Servers bemühen.

Das neue Konsole-Interface bekommt eine VLAN-Gruppe zugewiesen und lebt fortan ebenfalls auf dem virtuellen Switch mit den drei NICs. Jetzt lässt sich der Server wieder beim Vsphere-Management - über die neue IP-Adresse - anmelden. Abschließend löscht die Labor-Crew alle Reste des alten Vswitches und weist den nun frei gewordenen ersten NIC dem bestehenden Dreierteam mit dem zweiten Vswitch zu.

Zuvor muss natürlich der passende Switch-Port von Untagged auf Tagged-VLAN umgeschaltet werden. Am Ende teilen sich alle VMs und die Verwaltungsnetzwerke einen Vswitch mit vier NICs. Sollten in einer ungünstigen Szenerie die Verwaltungsnetze eine Last von je 1 GBit/s erzeugen, bleiben den VMs dennoch 2-GBit/s zur Verfügung. Im Regelbetrieb mit mäßigem Verwaltungsverkehr stehen den VMs alle vier NICs zur Verfügung. Bei diesem NIC-Limit darf der Verwalter auch Fault-Tolerance-Ports als eigene VLAN-Gruppe auf dem gemeinsamen Switch einsetzen.