VMWare ESXi 3.5 Update 4 - Einstellungen des Ressourcenpools und NIC Einstellungen
Guten Morgen an alle hier!
Ich hab da mal eine kleine Frage zum Thema "Ressource Pool" und NICs im ESXi 3.5 und hoffe jemand von euch kann mir das beantworten!
Im ESXi kann man ja mehrere Ressource Pools einrichten.
Hier gibt es die Punkte jeweils für CPU und Memory: Shares, Reservation (mit expandable) und Limit (mit expandable)!
Frage, was bewirken diese Einstellungen im einzelnen? Limit denke ich ist klar, über eine angegebenen Menge in MHz oder MB gehts nicht drüber hinaus (außer expandable ist gesetzt)
Und zum zweiten gibt es ja sehr viele Einstellungen für Netzwerkkarten, etc. und darum wollte ich fragen, wie kann man mit 2 Physikalischen Netzwerkkarten ein NIC Teaming im ESXi machen bzw. auf welche Einstellungen muss ich aufpassen?
sonnige Grüße aus Bayern
Michael
Ich hab da mal eine kleine Frage zum Thema "Ressource Pool" und NICs im ESXi 3.5 und hoffe jemand von euch kann mir das beantworten!
Im ESXi kann man ja mehrere Ressource Pools einrichten.
Hier gibt es die Punkte jeweils für CPU und Memory: Shares, Reservation (mit expandable) und Limit (mit expandable)!
Frage, was bewirken diese Einstellungen im einzelnen? Limit denke ich ist klar, über eine angegebenen Menge in MHz oder MB gehts nicht drüber hinaus (außer expandable ist gesetzt)
Und zum zweiten gibt es ja sehr viele Einstellungen für Netzwerkkarten, etc. und darum wollte ich fragen, wie kann man mit 2 Physikalischen Netzwerkkarten ein NIC Teaming im ESXi machen bzw. auf welche Einstellungen muss ich aufpassen?
sonnige Grüße aus Bayern
Michael
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 118361
Url: https://administrator.de/forum/vmware-esxi-3-5-update-4-einstellungen-des-ressourcenpools-und-nic-einstellungen-118361.html
Ausgedruckt am: 23.12.2024 um 00:12 Uhr
4 Kommentare
Neuester Kommentar
Hi,
Zur ersten Frage: Limits: in Sachen Memory gibst du eigentlich schon dein Limit beim Kreieren der Maschine vor. Mehr RAM gibts nicht. Bei vCPUs kannst du VMs ein bisschen eingrenzen, damit sie nicht zuviel Ressourcen einnehmen. (z.B. für schlecht programmierte Anwendungen)
Reservations sollte klar sein, dieser Wert wird der Maschine bzw. einem Pool garantiert zur Verfügung gestellt. Kann aber auch zu Problemen führen, wenn man zuviele Reservations gesetzt hat. Dann kann es z.B. passieren, dass eine VM nicht mehr starten kann, weil ihre Reservierung nicht mehr erfüllt werden kann. Wenn andere Maschinen ihre gesetzten Reservierungen gar nicht in Anspruch nehmen ist das natürlich doof. Man muss also aufpassen. Ich überlasse das eigentlich gerne den ESXern bzw. dem VC sich darum zu kümmern.
Die Shares sind eigentlich auch klar. Je mehr Shares ein Pool hat, desto mehr/öfter wird er bedient und kann entsprechend höhere Performance zur Verfügung stellen. Man könnte sich also vorstellen verschiedene Pools für wichtige und unwichtige (vielleicht noch "normale") Maschinen zur Verfügung zu stellen. Bei den wichtigen kann man dann evtl. auch noch mit Reservations arbeiten.
zur zweiten Frage: Da genügt es eigentlich dem virtuellen Switch noch weitere physikalische Netzwerkkarten hinzuzufügen. Dann hast du ein ausgehendes Team. Damit das ganze auch eingehend funktionieren soll, muss auf der gegenseite, also dem Switch noch VLAN-Trunking konfiguriert werden.
So, das reicht erstmal :D
Achso zum Nachlesen gibt's hier noch lecker was:
Understanding and Managing Resource Pools: http://www.vmware.com/pdf/vi3_35/esx_3/r35u2/vi3_35_25_u2_resource_mgmt ... (zum Thema resource Pools/Shares etc.)
Server Configuration Guide: http://www.vmware.com/pdf/vi3_35/esx_3/r35u2/vi3_35_25_u2_3_server_conf ... (im Teil "Advanced Networking" wird auf NIC Teaming eingegangen.
Zur ersten Frage: Limits: in Sachen Memory gibst du eigentlich schon dein Limit beim Kreieren der Maschine vor. Mehr RAM gibts nicht. Bei vCPUs kannst du VMs ein bisschen eingrenzen, damit sie nicht zuviel Ressourcen einnehmen. (z.B. für schlecht programmierte Anwendungen)
Reservations sollte klar sein, dieser Wert wird der Maschine bzw. einem Pool garantiert zur Verfügung gestellt. Kann aber auch zu Problemen führen, wenn man zuviele Reservations gesetzt hat. Dann kann es z.B. passieren, dass eine VM nicht mehr starten kann, weil ihre Reservierung nicht mehr erfüllt werden kann. Wenn andere Maschinen ihre gesetzten Reservierungen gar nicht in Anspruch nehmen ist das natürlich doof. Man muss also aufpassen. Ich überlasse das eigentlich gerne den ESXern bzw. dem VC sich darum zu kümmern.
Die Shares sind eigentlich auch klar. Je mehr Shares ein Pool hat, desto mehr/öfter wird er bedient und kann entsprechend höhere Performance zur Verfügung stellen. Man könnte sich also vorstellen verschiedene Pools für wichtige und unwichtige (vielleicht noch "normale") Maschinen zur Verfügung zu stellen. Bei den wichtigen kann man dann evtl. auch noch mit Reservations arbeiten.
zur zweiten Frage: Da genügt es eigentlich dem virtuellen Switch noch weitere physikalische Netzwerkkarten hinzuzufügen. Dann hast du ein ausgehendes Team. Damit das ganze auch eingehend funktionieren soll, muss auf der gegenseite, also dem Switch noch VLAN-Trunking konfiguriert werden.
So, das reicht erstmal :D
Achso zum Nachlesen gibt's hier noch lecker was:
Understanding and Managing Resource Pools: http://www.vmware.com/pdf/vi3_35/esx_3/r35u2/vi3_35_25_u2_resource_mgmt ... (zum Thema resource Pools/Shares etc.)
Server Configuration Guide: http://www.vmware.com/pdf/vi3_35/esx_3/r35u2/vi3_35_25_u2_3_server_conf ... (im Teil "Advanced Networking" wird auf NIC Teaming eingegangen.
Frage, was bewirken diese Einstellungen im einzelnen? Limit denke ich
ist klar, über eine angegebenen Menge in MHz oder MB gehts nicht
drüber hinaus (außer expandable ist gesetzt)
ist klar, über eine angegebenen Menge in MHz oder MB gehts nicht
drüber hinaus (außer expandable ist gesetzt)
Mit Ressource Pools kannst du entsprechend Ressourcen verteilen.
Ressourcepool 1 hat 1000 Mhz und 1000 MB RAM, also dürfen alle VMs in diesem Pool ZUSAMMEN max 1000mhz + 1000mb ram verwenden.
Ist der Pool auf expandable gesetzt und benötigt mehr ressourcen wie ihm zugeteilt darf er nach oben (also seinen übergeordneten ressource pool oder server) fragen ob er mehr leistung bekommt.
Ein Limit kannst du z.b. auch auf einzelne VMs setzen. Bietet sich z.b. bei Servern an, wo java programme laufen. diese neigen dazu, sehr viel ram und cpu zu fressen ohne das sie was machen ;)
Eine Reservierung macht entsprechend das selbe nur andersrum ;)
Ressourcepools bieten sich z.b. an um testsysteme zu gruppieren und zu verhindern dass diese die echtsysteme auf einen esx ausbremsen.
Als Tipp: Ich vergebe jeder Virtuellen Maschine immer ~75Mhz reservierte CPU. Das ist der wert den Windows zum leben braucht (server ohne dienste mit vmware tools). Sollte ein server auf dem esx alle cpu zeit nehmen, bekommen die anderen noch ein minimum zugesichert zum überleben.
Und zum zweiten gibt es ja sehr viele Einstellungen für
Netzwerkkarten, etc. und darum wollte ich fragen, wie kann man mit 2
Physikalischen Netzwerkkarten ein NIC Teaming im ESXi machen bzw. auf
welche Einstellungen muss ich aufpassen?
Netzwerkkarten, etc. und darum wollte ich fragen, wie kann man mit 2
Physikalischen Netzwerkkarten ein NIC Teaming im ESXi machen bzw. auf
welche Einstellungen muss ich aufpassen?
Denke du möchtest mit NIC Teaming die Bandbreite erhöhen.
Wichtig ist, dass dieses deine Swiche unterstützen und einen entsprechenen Uplink zum Core switch haben.
Entscheident ist hier der Standard 802.3ad, bei Cisco auch Etherchannel genannt.
Schau dir mal http://www.vmware.com/pdf/esx2_NIC_Teaming.pdf an. ist zwar für 2.x, aber auch noch für 3.x und 4.x aktuell
Manchmal hilft google:
http://blog.scottlowe.org/2008/09/05/vmware-esx-nic-teaming-and-vlan-tr ...
Using Link Aggregation
There’s not a whole lot to this part. In the ProCurve configuration, users will mark the ports that should participate in link aggregation as part of a trunk (say, Trk1) and then set the trunk type. Here’s the only real gotcha: the trunk must be configured as type “Trunk” and not type “LACP”.
In this context, LACP refers to dynamic LACP, which allows the switch and the server to dynamically negotiate the number of links in the bundle. VMware ESX doesn’t support dynamic LACP, only static LACP. To do static LACP, users will need to set the trunk type to Trunk.
Then, as has been discussed elsewhere in great depth, configure the VMware ESX vSwitch’s load balancing policy to “Route based on ip hash”. Once that’s done, everything should work as expected. This blog entry gives the CLI command to set the vSwitch load balancing policy, which would be necessary if configuring vSwitch0. For all other vSwitches, the changes can be made via VirtualCenter.
That’s really all there is to making link aggregation work between an HP ProCurve switch and VMware ESX.
http://blog.scottlowe.org/2008/09/05/vmware-esx-nic-teaming-and-vlan-tr ...
Using Link Aggregation
There’s not a whole lot to this part. In the ProCurve configuration, users will mark the ports that should participate in link aggregation as part of a trunk (say, Trk1) and then set the trunk type. Here’s the only real gotcha: the trunk must be configured as type “Trunk” and not type “LACP”.
In this context, LACP refers to dynamic LACP, which allows the switch and the server to dynamically negotiate the number of links in the bundle. VMware ESX doesn’t support dynamic LACP, only static LACP. To do static LACP, users will need to set the trunk type to Trunk.
Then, as has been discussed elsewhere in great depth, configure the VMware ESX vSwitch’s load balancing policy to “Route based on ip hash”. Once that’s done, everything should work as expected. This blog entry gives the CLI command to set the vSwitch load balancing policy, which would be necessary if configuring vSwitch0. For all other vSwitches, the changes can be made via VirtualCenter.
That’s really all there is to making link aggregation work between an HP ProCurve switch and VMware ESX.