In einer virtualisierten IT-Infrastruktur sollte der Austausch von Hardware ja keine große Hürde mehr darstellen, so die Theorie. Aber die Praxis zeigt wieder mal ein anderes Bild und es zeigt sich, es hängt manchmal einfach an Kleinigkeiten! Aber ich fange erstmal langsam an, in der letzten Woche sollten neue Server-Hardware, ein Festplatte-Array und zwei neue Netzwerk-Switch in Betrieb genommen werden.
Netzwerk-Switche
Der Austausch der beiden Netzwerk-Switche für das VMWare-ESX-Netzwerk, welches die Verbindung der Server mit dem Festplatten-Array herstellt, lief erwartungsgemäß reibungslos. Da die beiden alten Netzwerk-Switche bereits redundant angebunden waren, konnte einer nach dem anderen durch jeweils einen neueren Switch ausgetauscht werden. Den Switchen wurde vorher eine IP-Adresse für die Verwaltung zugewiesen. Danach wurden die Switche in den Serverschrank eingebaut und laufen seit dem ohne Probleme.
Festplatten-Array
Das neue Festplatten-Array musste auch nur eingebaut werden und sollte erstmal parallel zum alten in Betrieb gehen. Dafür war es nur notwendig es mit dem Switchen zu verbinden und über die Verwaltungsports, entsprechend zu konfigurieren. Fazit auch hier, einbauen und läuft.
ESX-Server
Auch bei den neuen Servern war der Plan die neue Hardware erstmal parallel zu installieren und in die VMWare-Infrastruktur einzubinden und die virtuellen Maschinen dann eine nach der anderen zu migrieren. Also wurden auch die beiden neuen Server in den Server-Schrank eingebaut, entsprechend verkabelt und in die Infrastruktur eingebunden. Bis dahin lief auch noch alles ohne Probleme.
Da die neue Hardware natürlich auch eine neuere Prozessor-Generation enthält, konnten die virtuellen Maschinen nicht im laufenden Betrieb auf die neuen Server migriert werden, so dass mit der sog. "Cold-Migration" erst heruntergefahren werden mussten und um dann auf der neuen Hardware wieder hochgefahren zu werden. Nach dem alle Maschinen migirert waren und das Netzwerk scheinbar ohne Probleme lief, konnte der Feierabend kommen.
Der nächste Morgen
Am nächsten Morgen machten die Server und das Netzwerk auch noch einen lauffähigen Eindruck, einziges Problem war, es fühlte sich alles etwas langsam an. Nach einer kurzen Analyse der Leistungsgraphen der ESX-Server, wurde der MS SQL-Server als Problemursache erstmal identifiziert. Die CPU-Leerlaufleistung war in etwa doppelt so hoch, wie beim alten ESX-Server, trotz in der in etwas doppelten Leistungsfähigkeit auf dem neuen Server...kurios. Nach dem die Dienste auf dem SQL-Server überprüft worden sind und dabei keine Auffälligkeiten festgestellt werden konnten, wurde diese eine virtuelle Maschine erstmal für den reibungslosen Betrieb wieder auf den alten ESX-Server migriert. Damit war der Betrieb des Netzwerkes erstmal wieder gesichert und eine längere Ursachenforschung konnte beginnen.
Ursachenforschung
Beim genaueren Betrachten der Leitungsdaten aller virtuellen Server konnte man feststellen, dass alle virtuellen Maschinen dieses Problem mit der erhöhten CPU-Leerlauf-Leistung hatten. Jedoch waren die Auswirkungen nicht so gravierend, wie auf dem SQL-Server. Damit muss das Problem, beim neuen ESX-Server liegen. Da das Problem aber auf beiden neuen Server bestand, konnte es eigentlich nur ein Konfigurationsproblem sein. Als erstes wurde versucht die CPU-Mask-ID in den virtuellen Maschinen zurückzusetzen, da dies laut Internet-Recherche bei der Migration auf neue Hardware ein Problem sein kann. Leider war das aber auch nicht die Ursache.
Energieverwaltung
Da ein Hardwareschaden auszuschließen war und die Konfiguration der ESX-Server über vSphere identisch war, konnte es eigentlich nur eine BIOS- oder Power-Management-Einstellung sein. Auf den ersten Blick sahen die BIOS- und Energie-Einstellungen alle gut aus. Im letzten Schritt, dieser sollte das nächste Mal der erste sein, wurde der Dell-Service kontaktiert. Dieser bestätigte, dass es nur ein Problem mit der Energieverwaltung der CPU ist. Wenn im BIOS auf "maximale Leistung" umgestellt wird, dann arbeiten die CPUs auch mit allen 12 Kernen und nicht nur mit einem wie es in der "Default"-Einstellung ist. Letztendlich liefen alle virtuelle Maschinen nur auf jeweils einem Kern der beiden CPUs, was natürlich zu einem merklichen Verlust der Leistung führt. Nach dem diese Einstellung auf beiden Servern gemacht war und der SQL-Server wieder auf einen von den neuen ESX-Server migriert wurde, lief das Netzwerk auch wieder in gewohnter Geschwindigkeit.
Fazit, schade das Dell die Energieeinstellung nicht schon ab Werk richtig setzt. Weiterhin zeigt sich, ein sofortiger Anruf beim Dell-Support hätte Zeit gespart, aber man sucht ja das Problem erstmal bei sich bzw. den gemachten Einstellungen.
Und am Ende zeigt sich wieder, kleine Ursache, große Wirkung.