von Roman Seibold
Mein heutiger Beitrag ist ein wenig anders. Ich möchte von einem interessanten Phänomen in Bezug auf VMWare berichten, das mir einiges an Kopfzerbrechen bereitet hat.

Die Ausgangslage.

Für einige Tests wollte ich ein WebSphere Application Server V7 Cluster erstellen und zu diesem Behufe habe ich folgendes Setup gewählt:

(1) Ein Host Windows XP auf AMD Athlon X2 4200+ mit 2GB RAM.
(2) Ein Host Windows XP auf Intel Core2 T5600 mit 3GB RAM.

(3) Ein Guest Linux in einer VMWare mit 2 GB RAM, 1 CPU auf (1)
(4) Ein Guest Linux in einer VMWare mit 2 GB RAM, 1 CPU auf (2)

Die beiden Linux-Images sind Clones, d.h. die Images weichen bis auf Hostname und IP-Adresse nicht voneinander ab. Dass der Hauptspeicher von (1) etwas limitiert ist, tut nichts zur Sache, die VMWare nutzt ihren Speicher nicht voll aus.

Das WebSphere-Cluster-Setup sah aus wie folgt. Auf

(1,3): HTTPServer und ApplicationServer "server1"
(2,4): Deployment-Manager und ApplicationServer "server2"

server1 und server2 sind zu einem TestCluster zusammengeschlossen.

Das Problem.

Vielleicht ist es Ihnen auch schon einmal so gegangen, vorausgesetzt Sie haben Erfahrung mit WebSphere im Betrieb, aber wenn innerhalb einer Zelle die Systemuhren auseinanderdriften, dann mag der FileSynchronisation-Service irgendwann nicht mehr.
Also wird es zur "Best-Practice", dass man vor der Installation von WebSphere und vor der Profil-Erzeugung die Systemzeiten auf den genutzten Systemen einander angleicht. Natürlich habe ich dies getan.
Als aber der Cluster schon munter am Laufen war und ich jenen zu Testzwecken durchstarten wollte (engl. "Ripplestart", in der deutschen Admin-Konsole irrtümlich mit "Schnellstart" übersetzt), bemerkte ich Erstaunliches in den Logs:
die Systemzeit beider gleichartiger VMWare-Images driftete auseinander. Das System, oben mit (3) bezeichnet, war deutlich träger und wirkte so "irgendwie schlapp". Problem erkannt, denkt man, und setzt die Systemzeit neu.

Das hielt aber nicht lange an. Schon beim Starten des Clusters war der schlappe Server gleich wieder hinterher. Also wieder die Systemzeit, diesmal im laufenden Betrieb, gesetzt, was WebSphere mit einem "CPU Starvation detected" launig im Log kommentiert, aber anstandslos weiterarbeitet.

Keine Lösungen.

Zunächst einmal kann ich ja verraten, was keine Lösungen waren. Es brachte nichts, an den Speicherkapazitäten Veränderungen vorzunehmen. Nicht besser geworden, aber auch nicht schlechter.

Ein anderer Ansatz war, die Zeitsynchronisierung der VMWare-Tools zu verwenden.
Innerhalb der VMWare-Tools (auf Linux ist deren GUI mit dem Befehl "vmware-toolbox" erhältlich) gibt es die Möglichkeit, periodisch mit dem Wirtssystem die Zeit zu vergleichen und anzupassen.
Das funktioniert im normalen Desktop-Betrieb sicher gut, nur WebSphere bemerkte jetzt ständig Zeitsprünge. Immer wenn die Systemuhr zu langsam lief und durch die VMWare-Tools auf einen aktuellen Wert gesetzt wurde, fehlten meinem Server ein paar Sekunden und es gab wieder ein "CPU Starvation detected".
Der ausführlichere Zusatz zur Meldung lautet:
"Did not receive adequate CPU time slice. Last known CPU usage time at [...]. Inactivity duration was [...]"

Die Lösung.

Es beschäftigte mich, dass dieses Problem nur auf der Maschine mit dem AMD-Prozessor auftrat. Die baugleiche VMWare auf der Intel-CPU, die sogar noch in einem Notebook steckte, lief reibungslos. Nach einiger Recherche, wieder gepaart mit dem berühmten "inspirierten Raten", stand der Übeltäter fest: es war das Cool'n'quiet-Feature der AMD-CPU
(http://www.amd.com/us/products/technologies/cool-n-quiet/Pages/cool-n-quiet.aspx).

Kurz gesagt ist Cool'n'quiet eine Technologie von AMD, um bei wenig Last auf der CPU die Taktzahl zu reduzieren und somit Geld in Form von Stromkosten zu sparen. Das ist lieb von AMD, aber die VMWare (momentan Workstation 6.5.2 bzw. Player 2.5.2) scheint nicht richtig mitzuspielen. Während das Host-OS, hier Windows XP, damit klar kam und die Systemzeit immer richtig mitführt, bekommt das VMWare-Image einfach weniger Leistung ab und die Zeit innerhalb des Images schien somit langsamer zu vergehen. Also war es kein Problem der Tagesform, dass der Server "schlapp" war, sondern ich hatte eine Möglichkeit gefunden, die Raum-Zeit-Relativität, die Einstein uns netterweise "entdeckt" hat, auf meinem lokalen Computersystem nachzustellen. Das gelingt einem nicht jeden Tag.

Nachdem ich im BIOS die Einstellung für Cool'n'quiet deaktiviert hatte, lief auch der ehemals träge Server ganz tadellos. Aber natürlich typisch: zunächst schiebt man es mal auf WebSphere oder Linux, dabei war die Relativitätstheorie schuld :-)

Wenn Sie ähnliche Erfahrungen gemacht oder einfach eine Anmerkung dazu haben, sind Sie jederzeit eingeladen, Kommentare zu diesem Blog abzugeben. Wir freuen uns über jede Meinung.

Bis dahin verbleibe ich, Ihr

Roman Seibold