Autor: Michael Schroeder

Veröffentlicht am

vSphere5: Priorisierte I/O Pfade

Im Fall eines Pfadverlustes wählt normalerweise das Path-Selection-Plugin (VMW_PSP_MRU) zufällig einen der verbleibenden Pfade als Alternative. Im VMware vSphere Blog erschien kürzlich ein Artikel, der die Methode der Pfad-Priorisierung unter vSphere5 beschreibt und den VMware KB-Artikel etwas erweitert ausführt. Im Blogartikel wird noch die alte Syntax (4.x) der vSphereCLI verwendet, diese funktioniert nicht mehr bei einem ESXi5.0.0. Aus diesem Grund habe ich unten die aktuelle Syntax angegeben, die auch im KB Artikel genannt wird.

Im Kern geht es darum, daß es drei Kategorien für Pfade gibt:

  • ACTIVE
  • ACTIVE_UO  (active, unoptimized)
  • STANDBY

Die Auswahlreihenfolge ist Active > Active_UO > Standby. Gleichwertige Pfade der selben Kategorie werden weiterhin von VMW_PSP_MRU zufällig ausgewählt. Die Defaulteinstellung der Priorität ist bei allen Pfaden “0” und unterscheidet sich damit nicht vom Verhalten früherer vSphere Versionen.

Wie setzt man die Priorität?

Mittels vSphereCLI können die Einstellungen ausgelesen und neu gesetzt werden. Eine Konfiguration über die GUI ist derzeit nicht möglich.

Achtung! Keine ESXCLI 4.0 Kommandos an einen ESXi 5.0.0 Server absenden!

Die aktuelle Version gibt es bei VMware.

Im folgenden ist [connection] die Verbindungsdaten zum ESXi Server:

--server myserver.domain.com --user root --password mypassword

<vmhba pathname> könnte z.B. so aussehen: vmhba3:C0:T0:L0

# esxcli [connection] storage nmp psp generic pathconfig get -p <vmhba pathname>
# esxcli [connection] storage nmp psp generic pathconfig set -p <vmhba pathname> -c rank=<rank Number>

Alternativ kann der Pfad auch über die NAA-ID (Network Addressing Authority identifier) bestimmt werden.

# esxcli [connection] storage nmp psp generic deviceconfig get --device=<naa.xxx>

Die so eingestellte Priorität des Pfades bleibt auch nach einem Neustart des Hosts erhalten.

 

 

 

 

Veröffentlicht am

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

Veröffentlicht am

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… 🙂

Veröffentlicht am

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