ElasticSky

22. Mai 201223. Mai 2012

vSphere5: Multi NIC vMotion

Betrachtet man vSphere Cluster im produktiven Einsatz, so fällt auf daß immer noch sehr wenige davon mit 10 GB Uplinks ausgestattet sind. Und das meist aus gutem Grund, denn die Hardware ist sehr teuer und auch die Infrastruktur zwischen den ESX-Knoten (Switches, Router, etc.) muß 10 Gbit unterstützen. In der Regel kann man mit mehreren 1Gbit Uplinks sehr gut auskommen und es bedarf schon einiger Mühe einen 1 Gbit NIC zu sättigen. Einzig bei vMotion kann es gelegentlich zu Engpässen kommen, weswegen von mir in der Vergangenheit der Management Traffic vom VM-Network logisch getrennt wurde und die Adapter nur wechselseitig als Standby zur Verfügung standen.

Eine wirklich tolle Eigenschaft von vSphere5 ist mir aber bis vor kurzem entgangen: Multi-NIC vMotion. Hierbei wird der Datenverkehr über mehrere physische NICs geleitet. Es bedarf mindestens zweier NICs mit je einer VM-Kernel Portgruppe und ähnelt dem Verfahren zum Aufbau einer iSCSI-Portgruppe. Nur daß sich hier beide vmk Portgruppen im selben IP Subnetz befinden. Diese Funktion ist nicht nur bei mehreren gleichzeitigen vMotion Transaktionen nützlich, sonder auch schon bei einer einzelnen.

Manuelle Einrichtung

Wir brauchen dazu entweder zwei vSwitches mit je einem vmnic und je einer vmkernel Portgruppe, oder wir verwenden einen vSwitch mit zwei vmnics und zwei Portgruppen. Letztere Variante gefällt mir persönlich besser.

Einen vSwitch erstellen und diesem zwei NICs zuordnen (Bsp: vmnic1, vmnic2)
zwei vmkernel Portgruppen erstellen (Bsp: vMotion1, vMotion2), mit IP Adressen aus dem gleichen Subnetz.
Switch failover-order umgehen.
vMotion1 mit vmnic1 (active), vmnic2 (standby)
vMotion2 mit vmnic2 (active), vmnic1 (standby)

Achtung Bug!: Derzeit existiert noch ein Problem in vSphere5, wenn zwei Kernelports auf dem selben Virtual Standard Switch vorhanden sind. Das Problem wurde ausführlich im Blogartikel von VMtoday beschrieben und ist ab vSphere5 U1 behoben.

Skriptgesteuerte Einrichtung

Bei mehreren Hosts ist eine Automatisierung wichtig. Die manuelle Einrichtung ist nicht nur mühsam, sondern auch fehleranfällig. Im Diskussionsbereich des Artikels zum Thema Multiple-NIC-vMotion auf Yellow-Bricks werden Skripte in unterschiedlichen Skriptsprachen gelistet. Darunter auch vSphereCLI und PowerCLI.

Links

Frankdenneman.nl: Multi-NIC vMotion support in vSphere5
VMtoday: vSphere 5 Networking Bug #2 Affects Management Network Connectivity
Yellow-Bricks: Multiple-NIC vMotion in vSphere 5
VMware Pubs [PDF]: Networking-Guide

21. Mai 2012

Zero-Client: Fujitsu veröffentlicht Version 6

Nachdem es letze Woche aus internen Quellen angekündigt wurde, erschien heute die Version 6 des Zero-Client Managers mit allen zugehörigen Softwareprodukten wie Direct Service oder des Lizenzservers.

Ich vermisse allerdings noch das Updatepaket, mit welchem man z.B. eine ZC-Controller der Version 5 auf Version 6 aktualisieren kann.

Was ist neu:

Support für VMware WDDM Display Driver (endlich!) 🙂
Anmeldung per RSA Secur ID (alternativ)
Unterstützung vSphere 5 U1
Unterstützung VMware View 5.0.1
Unterstützung Windows 8 Gastsysteme
Unterstützung vCenter Appliance
Fehlermeldung “connection lost unexpectedly” erscheint nicht mehr wenn Sitzung am Zero-Client getrennt wird.
bessere Unterstützung für Hyper-V (auch für Multilanguage Windows)
viele weitere Bugfixes

Praxistest folgt in Kürze… 🙂

21. Mai 2012

CPU Ready und CPU Co-STOP

Bei der Kontrolle der Leistungsdaten eines ESXi Servers (vSphere-Client – Performance – Realtime) fiel mir ein unglaublich hoher Wert für CPU-Ready auf. Laut Graph war dort ein Wert von fast 23 Sekunden. Wie kann das sein?

Bevor man die Werte deutet, sollte man zunächst einige Bergriffe definieren.

CPU-Ready

Angabe in Prozent (%RDY) oder in Millisekunden (ms). CPU-Ready bezeichnet die Zeit, die eine VM warten muß bis ihrer vCPU eine physische CPU zugeteilt wird.

VM bereit – Host nicht.

Co-Scheduling

Hat eine VM mehr als eine vCPU, so müssen diese zeitgleich physischen CPU Kernen des Host Systems zugeordnet werden. Das bedeutet im Klartext, eine VM mit einer vCPU muß warten bis ein Kern frei ist. Eine VM mit 4 vCPU muß entsprechend warten bis 4 Kerne gleichzeitig frei sind. Letzteres ist wesentlich weniger wahrscheinlich. Und damit sind wir auch beim dritten Schlagwort: Co-Stop.

Co-STOP

Zeit, die eine VM bereit ist, jedoch aufgrund von Wartezeiten durch Co-Scheduling nicht einem physischen Kern zugeteilt werden kann. Im Prinzip das selbe wie CPU-Ready, jedoch für VMs mit Virtual Symetric Multiprocessing (vSMP). Während hohe CPU-Ready Werte auf ein Hostsystem unter Druck schließen lassen, kann man dies bei hohen Co-STOP Werten nicht unbedingt folgern. Es bedeutet nur, daß der Host nicht die geforderte Anzahl physischer Kerne gleichzeitig bereitstellen kann. „CPU Ready und CPU Co-STOP“ weiterlesen

11. Mai 201211. Mai 2012

Resourcepools und VMs auf einer Ebene

Zu meiner regelmäßigen vSphere Lektüre gehört der Blog von Frank Denneman. Oft findet man dort sehr gute Grundlagenartikel mit übersichtlichen Illustrationen.

In einem seiner aktuellen Beiträge schreibt er über VMs, die sich zusammen mit Resourcepools auf einer Hierarchie-Ebene befinden. Diese Vorgehensweise findet man immer wieder bei Kunden im produktiven Einsatz. Meist aus Unachtsamkeit, oder mangels tieferem Verständnis der Thematik. In seinem Artikel schildert er die Auswirkungen eines solchen Umfelds, wenn es zu akuter Ressourcenknappheit innerhalb des Clusters kommt.