VLANs gegen statische Lastverteilung

Installationen mit mehreren NICs im Virtualisierungs-Host teilen die virtuellen Maschinen häufig auf verschiedene physische Netzwerke auf. Jedes virtuelle Netz bekommt einen virtuellen Switch innerhalb der Virtualisierung und bindet eine dezidierte NIC an. Diese statische Lastverteilung ist schon mal ein erster Ansatz, aber er hat Tücken. Es kann dazu kommen, dass die VMs einer Gruppe bei hoher Last in Engpässe geraten, während die VMs der anderen Gruppe ihre NICs langweilen.

Der Core-Switch S4 von Enterasys machte im Test einen guten Eindruck.

Dynamischer lassen sich Lasten über VLANs verteilen. Dabei weist der Verwalter alle freien NICs einem einzigen virtuellen Switch zu. Dieser Switch wiederum beherbergt mehrere LAN-Gruppen, welche jeweils einem VLAN zugeordnet wurden. Damit kommen sich die IP-Pakete der getrennten VLANs nicht in die Quere. Jedoch kann jedes VLAN im Zweifelsfall die komplette Bandbreite aller NICs nutzen. Die Verbindung zwischen Switch und Virtualisierungs-Hosts arbeitet dann mit VLAN-Tags.

Der Switch dann sortiert die ankommenden Netzwerke aus und leitet sie entsprechend der Admin-Vorgaben weiter. Durch die Verwendung von VLANs garantiert der Verwalter zudem, dass die Trunk-Verbindungen zwischen Switches ausbaufähig sind und sich möglichst gut auslasten lass

Anpassungen für Vmware-Vsphere

In der Regel erstellt ein Vmware-Host automatisch einen Vswitch auf dem ersten LAN-Adapter und weist diesem ein Management-, ein Kernel-Interface sowie den ersten Vswitch zu. Das Basis-Setup sieht dafür Untagged-Ports ohne VLAN vor.

Setzt der Verwalter einen Host mit einer ausreichenden Zahl an NICs ein, fällt die weitere Konfiguration recht leicht: Der primäre NIC bleibt, wie erstellt für die Konsole und Vmotion. Den Vswitch für die VMs hingegen legt der Verwalter auf einer Trunk-Gruppe von vier Ports an. Dieser eine Vswitch erhält dann die verschiedenen Netzwerkgruppen mit VLAN-Zuweisung.

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.

Behutsame Konfiguration für Xen

Vmware offeriert deutlich leistungsfähigere Funktionen für die LAN-Anbindung der VMs als dass bei Citrix der Fall wäre. Hier muss der Verwalter höllisch aufpassen, welche Adapter er zu einem Bonding zusammenlegt. Im beschrieben Setup für Vmware spielt es bei der Konfiguration mit sechs NICs keine Rolle, ob der Verwaltungsadapter eth0 oder eth5 heißt.

Es macht zudem keinen Unterschied, ob ein anderer Server im Vmware-Cluster dafür die Interfaces eth2 und eth4 einsetzt. Xen ist da sehr viel restriktiver. Ein Trunk kann hier nur aus zwei Interfaces bestehen. Im Labor hat sich zudem gezeigt, dass diese beiden Interfaces nicht von verschiedenen LAN-Adaptern stammen dürfen.

Der Verwalter wird dabei jedoch nicht daran gehindert, einen Bond aus einem Broadcom-Onboard-NIC eth1 und dem Intel-NIC eth2 auf einer PCIe-Karte zu bilden. In der Praxis haben herstellerübergreifende Bonds jedoch nie richtig funktioniert.

Erstellt der Verwalter einen Bond aus eth0 und eth1 auf dem ersten Xen-Server, so darf derselbe logische Trunk auf dem zweiten Xen-Server nicht aus eth1 und eth2 bestehen. Gleiche Bonds auf verschiedenen Servern müssen immer die identischen NIC-Nummern besitzen.

Das Labor-Setup gestaltet sich daher sehr problematisch. Zwei Xen-Testserver verfügen über drei NICs: jeweils einen Onboard- und zwei Adapter auf einer PCIe-Karte. Dabei soll eth0 als Verwaltungsinterface dienen und ein Trunk aus eth1 und eth2 für die VMs bereit stehen. Der dritte Server des Labors setzt jedoch vier NICs ein, zwei onboard, zwei auf der Erweiterungskarte.

Der Bond aus eth1 und eth2 würde dabei ein Onboard- und ein PCI-Interface enthalten – was in der Praxis jedoch nicht funktioniert. Nach einigem Tüfteln schafft es die Labor-Crew, mit Hilfe von udev-Regeln die Benennung der Interfaces zu ändern. Die Onboard-Adapter heißen dann eth0 und eth3, während die NICs der PCIe-Karte eth1 und eth2 sich zum funktionierenden Bond zusammenfassen lassen.

Stimmt die Basiskonfiguration, kann der Verwalter die logischen Netzwerke mit VLAN-Tagging erstellen und dem Bond0 als physischen NIC zuweisen. Die Beschränkung auf lediglich zwei NICs pro Trunk, die noch dazu von einer LAN-Karte stammen müssen, schränkt die Ausbaufähigkeit des Citrix-Hypervisors merkbar ein. Sollten die 2 GBit/s hier nicht genügen, muss der Verwalter weitere Trunks erzeugen und die VMs statisch verteilen.

Integration von NAC über S4-Switch von Enterasys

Im Labor-Setup setzt Network Computing den S4-Switch von Enterasys ein. Das NAC-Management identifiziert Endgeräte anhand ihrer MAC-Adresse oder einer 802.1x-Authentisierung.

Eine Policy-Engine weist authentifizierte Endgeräte einem Regelwerk zu. Das wiederum legt fest, welche Protokolle und Ports das jeweilige Device nutzen darf oder nicht. Der S4 beschränkt NAC-Regeln dabei nicht auf einen physikalischen Switch-Port. Somit lassen sich virtuelle Maschinen ebenfalls regulieren und im Zaum halten.

Der Verwalter kann beispielsweise den virtuellen Desktops der Anwender sowie die unerwünschten Chat- und Peer-to-Peer-Ports sperren und den POP/IMAP-Zugriff auf private Mail-Accounts unterbinden. Das sorgt für interne Netzwerksicherheit und verringert zudem den LAN-Traffic auf die ohnehin hoch belasteten Vmware-Server.

Enterasys offeriert dabei eine besondere Unterstützung für NAC in virtualisierten Landschaften. Neue Softwaremodule für den Netsight-Manager vermitteln zwischen Switch- und VM-Management. Ein Tool fragt den Switch beispielsweise, an welchem Port welche VM hängt. Diese Informationen schreibt das Tool direkt in das Informationsfeld des VM-Managements.

Klickt der Verwalter bei Vmware oder Xen auf eine Maschine findet er in den Anmerkungen die Informationen, an welchem Switch und Port diese Maschine zu sehen ist und welchem NAC-Regelwerk sie angehört. Der Informationsaustausch findet in beide Richtungen statt. Enterasys gleicht die auf Vmware oder Xen deklarierten Netzwerkgruppen mit den Policy-Gruppen ab.

Der Verwalter weist diesen Gruppen später ein NAC-Regelset zu. Sollen sich die Rechte einer VM ändern, braucht der Verwalter nur an einer Stelle tätig zu werden. Verschiebt er in Vsphere beispielsweise eine VM von einer in eine andere Netzwerk-Gruppe, ändert sich automatisch die NAC-Policy auf dem Switch.

Das NAC-Regelwerk des S4 lässt sich problemlos über die Grenzen des Enterasys-Switches durchsetzen. Dazu muss der Verwalter lediglich den NAC-Policies eigene VLANs zuordnen.

Im Test-Setup verbindet Network Computing die Port-Gruppe eines Vmware-Servers mit einem 3Com-Switch im Labor. Das Enterasys-Management sperrt Test-VMs in eigene, isolierte VLANs aus, welche über den Uplink vom 3Com- zum Enterasys-Switch gelangen. Dort setzt der S4 die NAC-Policy durch und routet den erlaubten Verkehr weiter.

Fazit

Mit ein paar zusätzlichen LAN-Adaptern in den Virtualisierungs-Hosts sorgt der Verwalter für die nötige Bandbreite. VLANs helfen dabei, die gesamte Kapazität dabei möglichst dynamisch zu verteilen und auch die Inter-Switch-Links möglichst gut auszulasten. Die Integration in das NAC-Management hilft dem IT-Manager zudem, den LAN-Traffic zu verringern, indem das NAC unerwünschte LAN-Pakete blockiert.

Testverfahren bei Vsphere 4

Vier Server gehören derzeit dem Vmware-Cluster von Network Computing an. Zwei Supermicro-Maschinen arbeiten mit Dual-Quad-Core-Xeons vom Typ E5427, 8 GByte RAM aber nur zwei LAN-Adaptern. Der einzige Steckplatz der kompakten Maschinen – beide Server stecken in einem einzigen 1-HE-Case - ist durch den FC-HBA belegt.

Der dritte Server, ein Wortmann-Terra mit Intel-Board, verfügt über zwei Quad-Core-Xeons E5420, ebenfalls 8 GByte RAM und FC-HBA (Fiber-Channel-Host-Bus-Adapter). Dieser Rechner verfügt anfangs über nur zwei NICs und wird im Laufe der Tests zuerst auf vier, dann auch sechs HBAs aufgerüstet.

Die vierte Maschine gehört normalerweise nicht zum Cluster. Der Eigenbau-Server auf Basis Supermicro-Board mit Core-Quad 6600 und 8 GByte RAM verrichtet in der Regel andere Dienste. Das Stepping des Q6600' passt nicht zu den Xeons im Cluster, daher funktioniert keine Live-Migration.

Da der Host im geräumigen Tower steckt und viele PCIe- und -X-Steckplätze offeriert, rüstet Network Computing die Maschine für den Test mit neun NICs und einem FC-HBA aus.

Testverfahren bei Xen 5.5

Drei Server nehmen an den Xen-Experimenten teil. Als regulärer Xen-Server arbeitet im Labor ein Thomas-Krenn-Opteron-Server mit zwei Dual-Core-CPUs und 8 GByte RAM. Die Maschine verfügt über zwei On- und zwei Offboard-NICs und einen FC-HBA.

Während des Tests packt Network Computing zwei experimentelle Server dazu. Beide basieren eigentlich auf Client-Hardware, welche sich aber als erstaunlich Server-tauglich zeigen. Die baugleichen Systeme setzen Asrock-SLI-Boards mit AMD-785-Chipset, Quad-Core- CPUs Athlon-II-X4-620 und 8-GByte-DDR3-1333-Speicher ein.

Neben der Onboard-Grafikkarte verfügen die Boards über drei SLI-Steckplätze, die eigentlich für weitere Grafikkarten konzipiert sind. Rein technisch arbeiten zwei der Slots als PCIe-x8- und einer als PCIe-x4-Steckplatz. Network Computing zweckentfremdet die PEG-Slots für SAS-Raid-Controller, FC-HBAs von Emulex oder Qlogic und natürlich Multiport-NICs mit zwei, drei oder vier Ethernet-Schnittstellen.

Netzwerk-Konfiguration in den Real-World Labs Poing

Vom Cisco-Switch des Internet-Providers führt eine 100-MBit/s-Leitung zu einem Enermax-Medien-Konverter. Dieser spricht den baugleichen Konverter zwei Stockwerke tiefer über eine Glasfaserleitung an. Von dort geht es in den WAN-Port der Astaro-Firewall. Diese verwaltet drei interne Netzwerke:
Das Labornetzwerk »NWC«, an dem alle Test-Server und -Clients im Adressbereich 10.11.0.0/16 hängen,
einen Teil des Produktivnetzwerkes »CMP« mit einer B-Klasse-Adressierung 172.29.0.0/16 und
die demilitarisierte Zone »DMZ« mit C-Klasse-Adressierung 192.168.99.0/24, welche Mail- und Webserver beherbergt.

Die Netzwerk-Konfiguration in den Real-World Labs Poing

Das Setup der Firewall ist noch aus der Zeit, bevor das Laborteam VLANs einführte. Daher gehen alle drei internen Netzwerke über eigene 100-MBit/s-NICs untagged auf einen 100/1000-MBit/s-Powerconnect-Switch von Dell. Dieser weist folgende VLAN-IDs zu: NWC=11, CMP=29 und DMZ=99.

So getagged, gehen die Netzwerke über einen 1-GBit/s-Uplink zum Labor-Edge-Switch »HP Procurve 5604zl« mit 72 Ports. Eine Gruppe mit 24 Ports verwaltet das VLAN 11 (NWC) untagged. Daran hängen prinzipiell alle simplen Netzwerkserver, aktive Komponenten (Webcams, WLAN-APs) und die Clients.

Die zweite Gruppe mit 24 Ports verwaltet alle VLANs tagged. Hier hängen unter anderem die Trunk- und Uplinks zu anderen Labor-Switches. Zu den drei von der Firewall übermittelten VLANs stoßen hier das iSCSI-Netzwerk ID=111 mit dem Adressbereich 10.111.0.0/16 und zwei rein für Vmware reservierte VLANS 22 und 23 hinzu.

Die dritte Portgruppe mit 24 Ports verwaltet das VLAN 111 untagged für das iSCSI-SAN. Vier 1-GBit/s-Links verbinden den HP-Procurve mit dem aktuellen Core-Switch S4 von Enterasys mit 96 Ports. Hier arbeitet Network-Access-Control (NAC), um Maschinen in Abhängigkeit ihrer MAC-Adresse eine Policy zuzuweisen. Auch hier finden sich die drei Portgruppen: untagged 11 (NWC), untagged 111 (iSCSI-SAN) und »tagged all« wieder.

Der S4 verwaltet dabei eine ganze Serie von zusätzlichen VLANs mit Nummern größer 2000. Hier weist das Laborteam komplexe NAC-Regelwerke einzelnen VLANs zu, so dass diese Regelwerke auch über Switch-Grenzen hinaus im LAN bestehen.

An der NWC-Portgruppe hängen die jeweiligen Management-Ports der Virtualisierungs-Server, die iSCSI-Portgruppe stemmt das IPSAN mit zwei Speicherservern von Dell/Equallogic. An der Portgruppe mit VLAN-Tagging hängen schließlich die vielen NICs, über die zwei Xen- und vier Vmware-Server die virtuellen Maschinen an das LAN ankoppeln.

Zu Testzwecken verbinden zwei Trunk-Ports den S4 mit einem 3Com-8800. Diese Anbindung dient dazu, das Mapping von Enterasys-NAC-Policies zu VLANs zu prüfen. Jeweils einer der Xen- und Vmware-Server kann daher VMs auf den 3Com-Switch schalten.