the Sky is the Limit
Alan Renouf, der vielen bekannt ist durch vCheck oder andere sehr nützliche Skriptsammlungen, hat jetzt einen sogenannten Fling veröffentlicht, mit dem man eine Virtuelle Infrastruktur vor dem Upgrade auf vSphere 5.1 testen kann.
Das Skript kommt mit einer schönen GUI und zeigt im Vorfeld der Migration mögliche Probleme auf.
vmware Labs – vCenter 5.1 Pre-Install Check Script
Die vSphere PowerCLI wurde aktualisiert auf Version 5.1 R2 und bringt eine Menge neuer Fuktionen mit.
Alan Renouf, der wir auch als Virtu-Al kennen, gibt uns eine Zusammenfassung der neuen Funktionen im vmware PowerCLI Blog.
Einen Datastore leeren kann eine sehr mühsame Arbeit sein. Man kann zwar mehrere VMs gleichzeitig auswählen, aber diese müssen im selben Ressourcepool sein damit man sie gemeinsam verschieben kann. Das ganze wird zum Klickdrama. Viel schöner wäre es, wenn man diesen Vorgang mittels PowerCLI automatisieren könnte. Zu meiner Freude fand ich genau so ein Skript. Es basiert auf einer Programmierung von ict-freak.nl und wurde von Richard Yaw erweitert. Die Programmierung basiert auf der PowerCLI und wurde mit einer einfachen GUI ausgestattet.
Easy Migration Tool v2.1 by Richard Yaw
Bei der Datastore to Datastore Migration kommt als erfreulicher Nebeneffekt hinzu, daß die VMs nacheinander migriert werden und somit das Plattensubsystem nicht unnötig belasten.
Man startet das Skript über die PowerCLI. Es öffnet sich die GUI und man muß nur den vCenter Hostnamen eingeben, den Cluster auswählen und den vMotion Modus festlegen (vgl. oben).
Die Version ist schon etwas älter, funktioniert aber auch unter vSphere 5.1 noch zuverlässig.
So kann man auch größere Datastores über Nacht oder über das Wochenende leeren lassen. 🙂
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.
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.
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.
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.
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