von Redaktion IT-A…
Lesezeit
2 Minuten
vSphere: Best Practices für Infrastruktur, Betrieb & Troubleshooting (2)
In den letzten 20 Jahren hat sich VMware zum Quasi-Standard
virtualisierter Rechenzentren entwickelt. Sicherlich auch deshalb, weil
die Installation eines ESX-Servers geradezu trivial ist. Datenträger
einlegen, booten, Systemdisk auswählen, Name, IP-Adresse und Passwort
eingeben, und schon haben Sie einen lauffähigen ESX-Server. Die
Hindernisse, die es zu umschiffen gilt, liegen in der Planung, im
Betrieb und der Erhaltung. Auch wenn Sie einen Cluster sehr leicht
produktiv zum Arbeiten bekommen, liegt die Kunst darin, diesen auf
Leistung und Fehlertoleranz zu optimieren. In der zweiten Folge schauen wir uns die Erzeugung von vSwitches und Distributed Switches an und erklären das Ressourcen-Pool-Paradoxon.
vSwitch für vMotion erzeugen
Wir legen nun einen neuen virtuellen Standard-Switch mit Namen "vSwitch2" und den Uplink-Ports "vmnic1" und "vmnic2" an:
Distributed vSwitches
Das Verfahren ist bei Distributed vSwitches (dvSwitches) ähnlich. Es wird nur nicht auf der Ebene des Hosts konfiguriert, sondern auf dem Datacenter. Zunächst erzeugen wir einen neuen dvSwitch mit Namen "vMotion" im Datacenter "my-Datacenter". Darin erstellen wir zwei verteilte virtuelle Portgruppen (dvPG) "vMotion1" und "vMotion2". Dem verteilten vSwitch fügen wir ESX-Hosts hinzu und definieren physische Uplink-Ports für diesen Host (vmnic1 und vmnic2). Die Uplink-Teaming-Policy bestimmt, dass Portgruppe "vMotion1" jeweils "Uplink1" als aktiven Port verwendet und "Uplink2" als Standby-Port. Die Portgruppe "vMotion2" verwendet diese umgekehrt (siehe Listings 1 und 2).
Ressourcen weiterreichen
Damit Virtualisierung funktioniert, müssen die Host-Ressourcen Arbeitsspeicher, CPU, Netzwerk und Disk an die virtuellen Maschinen weitergereicht werden. Solange es viele Ressourcen und wenige Konsumenten (VMs) gibt, erhält jede VM, was sie anfordert. Fordern aber zu viele VMs gleichzeitig eine begrenzte Ressource an, kommt es zu Engpässen und keine der VMs erhält ausreichend große Anteile der geforderten Ressource. Nun ist in einem Cluster aber nicht jede VM gleich wichtig. Der Webserver der Kantine ist vielleicht nicht unternehmenskritisch. Dienste wie Domänencontroller, Mailserver oder Datenbanken dagegen schon. Damit Sie in Spitzenzeiten einigen Kernanwendungen mehr Ressourcen zuteilen können als anderen, wurden Ressourcen-Pools entwickelt.
Deren Einrichtung ist leider zu einfach und die Standardvorgaben von VMware sind zu verlockend, sodass sie oft falsch verwendet werden. Im Standard gibt es drei mögliche Vorgaben: High, Normal und Low. Diese teilen die Ressourcen (RAM oder CPU) im Verhältnis 4:2:1. Dies bedeutet, dass wenn sich ein Pool High neben einem Pool Low befindet, erhält dieser bei Verknappung viermal so viele Ressourcen. Das klingt zunächst gut und der Administrator ist versucht, all seine kritischen Produktivsysteme in den Pool High zu werfen und die weniger kritischen Testsysteme in den Pool Low. Dabei gerät aber schnell in Vergessenheit, dass meist wesentlich mehr Produktivsysteme als Testmaschinen in Betrieb sind. Im Fall einer Verknappung macht der Administrator nun unfreiwillig Bekanntschaft mit dem "Ressourcen-Pool-Paradoxon": Er wird feststellen, dass seine Testmaschinen besser laufen als seine Produktivsysteme.
Seite 2: Das Ressourcen-Pool-Paradoxon
dr/ln/Dr. Jens Söldner und Dr. Michael Schröder
Wir legen nun einen neuen virtuellen Standard-Switch mit Namen "vSwitch2" und den Uplink-Ports "vmnic1" und "vmnic2" an:
New-VirtualSwitch -VMHost esx1.mydomain.com -Name "vSwitch2" -Nic vmnic1,vmnic2Dem vSwitch2 fügen wir zwei Portgruppen im VLAN 500 hinzu:
New-VirtualPortGroup -VirtualSwitch "vSwitch2" -Name "vMotion1" -VLanId 500 New-VirtualPortGroup -VirtualSwitch "vSwitch2" -Name "vMotion2" -VLanId 500Jede der Portgruppen "vMotion1" und "vMotion2" erhält einen Kernel-Port, der für vMotion aktiviert ist:
New-VMHostNetworkAdapter -VMHost esx1.mydomain.com -VirtualSwitch "vSwitch2" -PortGroup "vMotion1" -IP 10.10.0.11 -SubnetMask 255.255.255.0 -VMotionEnabled:$true New-VMHostNetworkAdapter -VMHost esx1.mydomain.com -VirtualSwitch "vSwitch2" -PortGroup "vMotion2" -IP 10.10.0.12 -SubnetMask 255.255.255.0 -VMotionEnabled:$trueZur logischen Trennung des vMotion-Datenverkehrs wird nun die Failover-Richtlinie für die Portgruppen und die Uplinks definiert. Portgruppe vMotion1 verwendet vmnic1 als aktiven Port und vmnic2 als Standby-Port. Portgruppe vMotion2 nutzt vmnic2 als aktiven Port und vmnic1 als Standby-Port. Im Falle eines Pfadausfalls bleibt die Konnektivität der vMotion-Portgruppe erhalten, nur der effektive Durchsatz halbiert sich.
Get-VirtualPortGroup -VMHost esx1.mydomain.com -Name "vMotion1" | Get-NicTeamingPolicy | Set-NicTeamingPolicy -MakeNicActive vmnic1 -MakeNicStandBy vmnic2 Get-VirtualPortGroup -VMHost esx1.mydomain.com -Name "vMotion2" | Get-NicTeamingPolicy | Set-NicTeamingPolicy -MakeNicActive vmnic2 -MakeNicStandBy vmnic1Zum Abschluss dürfen Sie nicht vergessen, vMotion auf dem Managementnetzwerk zu deaktivieren, falls es dort gesetzt war.
Distributed vSwitches
Das Verfahren ist bei Distributed vSwitches (dvSwitches) ähnlich. Es wird nur nicht auf der Ebene des Hosts konfiguriert, sondern auf dem Datacenter. Zunächst erzeugen wir einen neuen dvSwitch mit Namen "vMotion" im Datacenter "my-Datacenter". Darin erstellen wir zwei verteilte virtuelle Portgruppen (dvPG) "vMotion1" und "vMotion2". Dem verteilten vSwitch fügen wir ESX-Hosts hinzu und definieren physische Uplink-Ports für diesen Host (vmnic1 und vmnic2). Die Uplink-Teaming-Policy bestimmt, dass Portgruppe "vMotion1" jeweils "Uplink1" als aktiven Port verwendet und "Uplink2" als Standby-Port. Die Portgruppe "vMotion2" verwendet diese umgekehrt (siehe Listings 1 und 2).
Ressourcen weiterreichen
Damit Virtualisierung funktioniert, müssen die Host-Ressourcen Arbeitsspeicher, CPU, Netzwerk und Disk an die virtuellen Maschinen weitergereicht werden. Solange es viele Ressourcen und wenige Konsumenten (VMs) gibt, erhält jede VM, was sie anfordert. Fordern aber zu viele VMs gleichzeitig eine begrenzte Ressource an, kommt es zu Engpässen und keine der VMs erhält ausreichend große Anteile der geforderten Ressource. Nun ist in einem Cluster aber nicht jede VM gleich wichtig. Der Webserver der Kantine ist vielleicht nicht unternehmenskritisch. Dienste wie Domänencontroller, Mailserver oder Datenbanken dagegen schon. Damit Sie in Spitzenzeiten einigen Kernanwendungen mehr Ressourcen zuteilen können als anderen, wurden Ressourcen-Pools entwickelt.
Deren Einrichtung ist leider zu einfach und die Standardvorgaben von VMware sind zu verlockend, sodass sie oft falsch verwendet werden. Im Standard gibt es drei mögliche Vorgaben: High, Normal und Low. Diese teilen die Ressourcen (RAM oder CPU) im Verhältnis 4:2:1. Dies bedeutet, dass wenn sich ein Pool High neben einem Pool Low befindet, erhält dieser bei Verknappung viermal so viele Ressourcen. Das klingt zunächst gut und der Administrator ist versucht, all seine kritischen Produktivsysteme in den Pool High zu werfen und die weniger kritischen Testsysteme in den Pool Low. Dabei gerät aber schnell in Vergessenheit, dass meist wesentlich mehr Produktivsysteme als Testmaschinen in Betrieb sind. Im Fall einer Verknappung macht der Administrator nun unfreiwillig Bekanntschaft mit dem "Ressourcen-Pool-Paradoxon": Er wird feststellen, dass seine Testmaschinen besser laufen als seine Produktivsysteme.
| Seite 1 von 2 | Nächste Seite >> |
dr/ln/Dr. Jens Söldner und Dr. Michael Schröder
