Update vmware vSphere 5.1 auf vSphere 5.5 – Kurzer Erfahrungsbericht

Erfahrungen und Vorgehen beim Update einer vmware vSphere 5.1 Umgebung auf vSphere 5.5

Nach den eher „philosopischen“ Betrachtungen des letzten Artikels, nun wieder Praxis!

Heute möchte ich kurz meine Erfahrunge beim Update unserer vmware vSphere 5.1 Umgebung auf die aktuelle Version vSphere 5.5 weitergeben.

Dieses wurde höchste Zeit, aber wie das Leben so spielt braucht man doch ein wenig Zeit für diese Aktion.

Hierbei möchte ich auch kurz das prinzipielle Vorgehen bei einem vmware Plattformupdate vorstellen (vielen sicher geläufig).

Prinzipielles Vorgehen beim Update vSphere 5.1 auf vSphere 5.5

Das Update einer vmware vSphere Umgebung verläuft immer nach dem gleichen Schema. Dieses hier kurz zur Einführung:

1. Update des vCenter Servers (auch bei der Appliance!)
   1. Bei allen Komponenten auf einer VM einfach „Simpel Install“ auswählen
   2. Ansonsten:
      1. Update SSO (Achtung Änderungen von 5.1 auf 5.5)
      2. Installation bzw. Update WebClient
      3. Update Inventory Services
      4. Update vCenter Server
2. Update des vSphere Clients (vielleicht zum letzte Mal)
3. Update oder Installation 😉 des Update Managers
   1. Erstellen einer neuen HOST Baseline für das Update der ESXi Hosts
   2. Scan der Hosts mit dieser Baseline
   3. Test der Baseline auf einem der vorhandenen Hosts
   4. Remediate der übrigen Hosts wenn DRS vorhanden vollautomatisch

Soviel zum Prinzipiellen Ablauf. Handbuch der Wahl ist folgendes „vSphere Upgrade Guide„.

Die Umgebung

Kurz zur Umgebung die Upgedated wurde:

• vCenter Server 5.1 U2  als VM mit externer MS SQL DB
  • Alle Komponenten auf dieser VM (SSO, Inventory, WebClient Webserver, vCente Server + vSphere Client)
• 3 IBM Hosts auf ESXi 5.1 U1 mit IBM OEM ISO installiert

Hinweis: Bitte OEM Versionen NIE mit vmware Native ISO updaten! Das geht auf grund unterschiedlicher bzw. fehlender Treiber oft schief!

Mein Vorgehen und meine Erfahrungen

Mein Herangehen an die Migration bzw. das Update war einfach nach Lehrbuch (siehe oben). Dabei habe ich als erstes einen Snapshot des vCenter Servers Windows (2008 R2) erstellt.

Anschließend habe ich erst mal den neuen vSphere 5.5 Client auf meinem Arbeitsplatzrechner installiert bzw. Upgedated.

Nun mittels vSphere Client direkt mit dem Host verbunden auf welchem die vCenter Server VM läuft 😉 (zur Sicherheit)
ISO des neuen vCenter Servers mit der VM verbunden.

Anschließend per RDP eine „normale“ Remote Session auf den vCenter Server.

So nun ging es los.

Setup Wrapper vom ISO gestartet und Simple Install ausgewählt.

ISO Setup Wrapper

Jetzt werden nacheinander die Komponenten SSO, Web Client, Inventory Service und zum Abschluß vCenter Server upgedated!
Dieses verlief mehr als „gepflegt“ und ohne Probleme.

ACHTUNG: Der neue SSO Administrator heißt nun „administrator@vsphere.local“ und nicht mehr „admin@local-Domain„. Hier wird eine neues und vor allem komplexes Passwort erwartet!

Das SSO Update dauerte ca. 30 min da hier die alte SSO 5.1 DB ausgelesen werden muß und anschließend die neue Struktur erstellt wird. Unser AD als Authentifizierungsquelle wurde problemlos übernommen, doch gab es hier ein paar Problemchen im Nachgang (dazu später mehr). Diese waren aber unserer SSO „early Adapter Installation“ zuzuschreiben und sollten normalerweise nicht auftreten.

Anschließend dated der Wrapper den Web Server für den Web Client up. Dieses erfolgte relativ schnell und fehlerlos.

Nun kommt der Invertory Service an die Reihe und zum Schluß der vCenter Server.

Nach einem Windows obligatorischen Reboot sollte die Anmeldung via WebClient bzw. vSphere Client problemlos möglich sein. Zum Test erst mal den „administrator@vsphere.local“ verwenden und dann einen AD User testen. Dieser klappte erst gar nicht, lag aber, wie gesagt an einem etwas unglücklichen Alias aus der „Frühzeit des SSO 5.0“. Nachdem das behoben war (als administrator@vsphere.local) gab es keine weiteren Schwierigkeiten weiterzuarbeiten.

Jetzt wurde es Zeit den Update Manager ebenfalls auf die Version 5.5 zu bringen. Ging auch Problemlos von der Hand.

Nachdem der Update Manager 5.5 lief kann man im vSphere 5.5 Client das entsprechende PlugIn installieren und eine Baseline für die Migration auf ESXi 5.5 anlegen.

Baseline für ESXi Update erstellen

Ich möchte hier nicht den Update Manager erklären, sondern nur kurz angeben wie die Baseline schnell erstellt werden kann. Dazu einfach im Update Manager in der Administrator Ansicht auf „ESXi-Images“ gehen und ein neues ISO-Image importieren. Anschließend fragt der Wizzard automatisch nach einer neu zu erstellenden Baseline (Type Fixed)

Update Baseline

In unserem Fall ein IBM ISO Image.

Update der ESXi Hosts

Grundsätzlich sollte man für alle upzudatenden ESXi 5.1 Host noch einmal die „Critical Host Update“ Baseline laufen lassen und die Hosts auf den letzten Patchlevel der Version 5.1 bringen. Nach meiner Erfahrung erspart das eine Menge Ungemach bei Update auf die neue Version!

Nachdem die ESXi Hosts also alle auf dem „letzten Stand“ ESXi 5.1 waren wurde die neue Update Baseline an den vSphere Cluster attached und ein Scan durchgeführt.

Erwartungsgemäss sind alle Hosts „Rot“ und „Non Complient“ (so muß es sein, ein Ausrufezeichen und Nicht kompatibel ist schlecht – dann noch mal auf kritische Host-Patche überprüfen). Jetzt versuche ich immer erst mal nur einen einzelnen Host via Update Manager zu migrieren. Klappt das und der Host läuft zufriedenstellend können alle anderen in einem DRS Cluster vollautomatisch mit der Baseline migriert werden.

So habe ich das auch hier gemacht. Erst einen getestet. Dann die beiden anderen „Automatisiert“ migriert. Ging alles in allem in ca. 4,5 Stunden problemlos über die Bühne. Davon ca. 2,5 Stunden den ersten Host migrieren und test, dann in 2 weiteren Stunden automatisch mit Hilfe von DRS die beiden weiteren Hosts des Clusters migriert.

Fazit

Update erfolgreich! vmware vSphere 5.1  ohne besondere Vorkommnisse auf vSphere 5.5 migriert. Alles in allem hat mich die Aktion ca. 1 1/2 Tage gekostet, wobei ich natürlich auch meine anderen Arbeiten machen durfte 🙂

Wer „frisst“ in Zukunft die Ressourcen im Rechenzentrum – eine „philosophische“ Betrachtung

Wer stellt in Zukunft welche Ressource im Rechenzentrum breit? – Was ändert sich – Was verschiebt sich?

Zum Jahresanfang 2014 möchte ich einmal einen Artikel vorstellen der eher etwas „philosophisch“ daherkommt. Es geht um Überlegungen wie sich der Ressourcenverbrauch eines Rechenzentrums in den nächsten Monaten und Jahren verändert. Gerade im VMware Umfeld stehen ja einige neu Themen an, die im laufe des Jahres sicher an Fahrt aufnehmen. Virtuelles Storage [vSAN], virtuelle Netzwerk [NSX] und sicher noch viel mehr Lösungen verschieben die Gesamtlastverteilung in einem Rechenzentrum der Zukunft.

Dieses Thema möchte ich einfach kurz betrachten und zu Diskussion freigeben.

Es geht hier nicht um Positive oder Negative Bewertung! Eine Betrachtung der technischen Entwicklung und deren Auswirkung sehe ich als viel interessanter an. Ist dieses dann das „Software defined DataCenter“ [SDDC]?

Entschuldigt das ich meist die VMware Begriffe verwende, aber aus meiner Sicht ist VMware hier durchaus Vorreiter und ausserdem kenne ich diese Plattform nun mal am besten 😉 Andere Anbieter sollen keinesfalls ausgeschlossen werden.

Der X86 Host als Arbeitstier für ALLES?

Schaut man sich die Hauptakteure im DataCenter Bereich, vor allem im Virtualisierungsbereich an (nicht nur VMware), dann denke ich, kann man erkennen das immer mehr „Last“ und damit auch Ressourcenverbrauch direkt auf die X86 basierten HOSTS (für VMware ESXi) verlagert wird.

Begonnen hat das in Form von Virtuellen Maschinen die auf einmal nicht nur Applikationen der klassischen Art beheimateten, sondern auch als virtualisierte Router, Firewalls oder auch Anti Virus Lösungen auftraten. Zum Teil schnell erfolgreich, zum Teil noch auf dem Weg zum Erfolg.

Der Beginn der Verlagerung

Meiner Meinung nach hat das alles aber viel viel früher mit der Einführung des vSwitch (virtueller Switche) gestartet! Auf einmal gab es virtuelles Netzwerk und entsprechende Konfigurationen ausserhalb der etablierten „Netzwerk-Truppe“. Mit Einführung des „distributed virtuell Switches“ (VMware Bezeichnung) ist dann endgültig eine eigene Netzhierarchie in der Black-Box, Virtualisierungs-Plattform entstanden.

Der Beginn

Der nächste Schritt

Als nächster Schritt kamen dann VMs mit Infrastuktur Aufgaben, wie virtuelle Router (Vyatta was so ein Vorreiter) vShield Zones und vShield Edge als genannte Beispiele. Eine Schnittstelle im Hypervisor gekoppelt mit einer VM als zentrale Anti Virus Lösung wurde im VMware Umfeld als vShield Endpoint + Anti Virus Herstellerlösung als, quasi hybrid Lösung, etabliert.

Der nächste Schritt

Die weitere Entwicklung

Mit neuen Lösunge die nun auch das, für Virtualisierung zwingend notwendige SAN, in Software abbilden (DataCore usw. lässt grüßen ;-)) VSA und nun vSAN stehen die nächsten Bereiche zur reinen „Softwareisierung“ an. Wobei die VSA Lösung eher im vorigen Schritt angesiedelt ist, da diese Lösung auf einer VM basiert, während vSAN direkt in den Hypervisor implementiert wurde.Wenn dann auch noch das Netzwerk komplett als virtuelle Lösung dargestellt werden soll (mit NSX) dann haben wir plötzlich komplett andere Workloads in einem Rechenzentrum zu betrachten, zu beachten und zu kalkulieren!

Die Zukunft – Jetzt

Fazit – Offene Diskussion?

Wie man erkennen kann wird Workload verschiedener physikalischer Lösungen wie Router, Firewalls, Switche und Storage Systeme auf den X86 Host verlagert. Dieses bedeutet noch kein Ende der Physik! Schlussendlich müssen IP Pakete immer noch durch physikalisches Netzequipment reisen 😉

Der HOST der Zukunft!

Große Datenmengen werden auch weiterhin in entsprechenden Storage Systemen gelagert, aber welcher Anteil in den genannten Lösungen landet werden wir sehen – Ausserdem wollen die Storage und Netzwerkausrüster ja auch leben.

Eine spannende Diskussion währe schön!