[linux-l] Timingprobleme in virtuellen Maschinen [WAR: Desktop Virtualisierung]

[Lutz Willek]

Hallo,

und Danke Peter für die treffende Beschreibung und der Hintergründe des 
Problems timekeeping in virtuellen Umgebungen. Ich möchte anmerken, dass 
dieses Problem jede Art von Virtualisierung betrifft, egal ob KVM, XEN, 
VMware oder andere.

Was folgt ist ein Erfahrungsbericht und Lösungen für VMware. Mit der 
Bitte an Euch, Eure Informationen zu teilen, wenn Ihr Lösungsansätze für 
andere Virtualisierungsumgebungen kennt. Insbesondere interessieren mich 
persönlich Erfahrungen zu KVM und XEN, da ich noch keine größeren 
Umgebungen (mehr als 100 VMs) damit betrieben habe.

Wir betreuen viele virtuelle Maschinen, einen bunten Strauß aller großen 
Betriebssysteme. Dabei war nicht so sehr die Separation einzelner 
Systeme, sondern die einheitliche Hardwareumgebung und damit leichtere 
Wartbarkeit entscheidend für den Schritt hin zur Virtualisierung. Wegen 
der Möglichkeit der Implementierung von Hochverfügbarkeit auf 
Virtualisierungsebene, bei gleichzeitig möglichst hoher Auslastung des 
einzelnen Hosts, und ganz wichtig den Managementfunktionen, wurde und 
wird auf einem VMware ESX Cluster virtualisiert. Andere 
Virtualisierungslösungen boten zum Zeitpunkt der Entscheidung für VMware 
nicht alle nötigen Features. (Das ist heute teilweise anders)
Wir konnten im Vergleich zu vorher den Einsatz von Hardware um mehr als 
80% verringern und gleichzeitig eine bessere Gesamtperformance und 
Gesamtverfügbarkeit erreichen: Für uns wurde das Ziel erreicht.

Die von Peter angesprochenen Zeitprobleme traten schon im Testbetrieb 
auf und führten normalerweise nur zu subtilen Fehlern, teilweise aber 
auch zum totalen Versagen von Diensten. Besonders betroffen waren 
Dienste, die Zeitauflösungen von unter 100 ms benötigen, also 
Datenbanken, LDAP, AD oder HA-Lösungen, die über Netzwerk miteinander 
kommunizieren. Vorweg: Inzwischen laufen diese Dienste alle stabil in 
der virtuellen Umgebung, auch wenn hochgenaue Zeitauflösung von unter 1 
ms zwischen den einzelnen Diensten gefordert wird.

Der erste Lösungsansatz war, den Zeitgeber des physikalischen Hosts zu 
benutzen und diesen an die virtuellen Maschinen zu koppeln. Außer bei 
Livemigrationen zwischen Hosts war so zurückkaufen der Zeit innerhalb 
von virtuellen Maschinen verschwunden. Auch das langsame zurückdriften 
der VM-Zeit im Vergleich zur Realzeit war damit gelöst. Dafür hatten wir 
nun massiv Zeitsprünge innerhalb der VMs: die Zeit verlief nicht mehr 
linear. Normalerweise nur wenige ms, im Extrem haben wir einmal 27 
Sekunden "verlorene" Zeit festgestellt: Die Anwendungen kamen damit 
überhaupt nicht klar. Dieser Ansatz für sich allein war also schlecht 
und wurde schnell wieder verworfen. (BTW: Für Desktopvirtualisierung ist 
das heute noch brauchbar und auch gängige Lösung!)

Der nächste Ansatz war zusätzlich ein spezieller (vmi-)Kernel, der in 
der Lage war, innerhalb der VM die entstandenen Zeitsprünge zu "stauchen 
und zu dehnen": Damit verlief die Zeit innerhalb einer VM quasilinear. 
Nur auf eine Maschine beschränkte Anwendungen waren damit schon sehr 
glücklich. (Beispielsweise Webserver und dazugehörende Datenbank auf dem 
gleichen System) Der Nachteil: Die Zeit verlief nun zwischen den 
virtuellen Maschinen nicht mehr linear, sondern schwankte im Extrem 
relativ zu anderen VM's um bis zu einige Minuten vor/rückwärts. Das war 
natürlich Gift für beispielsweise Datenbankreplikationen oder 
Authentifizierungen (ldap/Kerberos: seeehr lustige Effekte!). Außerdem 
waren diese speziellen Kernel nicht für jedes Betriebssystem verfügbar. 
Außer für Spezialfälle wurde das schnell nicht mehr eingesetzt, heute 
gar nicht mehr.

Der nächste Ansatz waren spezielle Bootparameter, die den Kernel darauf 
vorbereiteten keine genaue Hardwareuhr zu haben, oder diese schlicht zu 
ignorieren. Gleichzeitig wurde die Bindung an den Zeitgeber des Hosts 
wieder gelöst. Die genauen Bootparameter sind abhängig von der 
eingesetzten Distribution und Kernelversion, wenn man danach sucht 
findet man auch 1000 verschiedene Angaben im Netz. Relevant für uns 
waren und sind die Empfehlungen im VMware KB 1006427 "Timekeeping best 
practices for Linux guests", danach sollte man sich dann auch richten. 
Dies brachte erstmals brauchbare Resultate. Sinngemäß: Je neuer der 
eingesetzte Kernel, um so weniger muss man beachten, umso genauere 
Resultate werden erzielt. Gerade bei p2v älterer Systeme lohnt also der 
Blick in diesen KB-Artikel.

Der entscheidende Durchbruch war dann ein speziell konfigurierter ntpd 
auf jeder virtuellen Maschine, der die Hardwareuhr ignoriert und 
schneller als normalerweise, entstehende Zeitungenauigkeiten ausgleicht. 
Damit erreichen wir eine lineare Zeit innerhalb der VM und eine 
quasilineare Zeit relativ zu anderen VMs, ausreichend für bisher alle 
Anwendungsfälle. Die prinzipielle Konfiguration des ntpd wird inzwischen 
auch im KB-Artikel 1006427 beschrieben, wir benutzen diese Konfiguration 
mit nur kleineren sitespezifischen Modifikationen seit etwa 2009. 
(Sinngemäß setzen wir das auch ein, wenn wir bspw. mit KVM virtualisieren)

Zusammengefasst lässt sich sagen, dass wir seit Anfang 2010 keine 
relevanten Zeitprobleme mehr innerhalb von virtuellen Maschinen haben. 
Soweit mal meine 2 ct. dazu, ich hoffe das hilft dem einen oder anderen 
etwas.

Nochmal die Bitte: Vergleichbare Erfahrungen mit XEN oder KVM 
interessieren mich sehr, bitte schreibt etwas dazu wenn Ihr solche 
Systeme betreibt und und ähnliche Probleme habt, und wie die 
Lösungsansätze dort aussehen.


Freundliche Grüße / Best Regards

         Lutz Willek

Am 29.11.2012 23:53, schrieb Peter Ross:
> [...]
> Es kann bei ordentlicher Last Timer-Probleme geben, die zu
> Performanceverlusten führen. Die sind ärgerlich und schwer zu finden...
>
> In Server-Umgebungen können die einen schon wahnsinnig machen, da sie
> sporadisch auftreten - und zu "verlorener Zeit" führen.
>
> Es gibt halt nur einen Hardware-Zeitgeber, der der Maschine "den Takt"
> gibt. Das ist ein hochpriorisierter Hardwareinterupt, der dann den
> laufenden Kernel unterbricht und den Kernel "antreibt".
>
> In einer Virtuellen Maschine wird der Taktgeber halt auch virtualisiert,
> kann aber natürlich nicht durch einen echten Hardware-Timer getrieben
> werden. Also ist es Software, und der Interruipt kann "verloren" gehen,
> wenn die Maschine gerade was besseres zu tun hat.
>
> Dann verliert die Virtuelle Maschine an Zeit und lastet die zugewiesenen
> Resourcen nicht ordentlich aus. Innerhalb der Maschine sieht man das gar
> nicht - da die Maschine gar nichts über die "verlorene Zeit" weiß, und
> so top z.B. eine "ordentliche Performance" vorgaukelt.
>
> Die verlorenen "Ticks" treten sporadisch auf, unter Last, sind von der
> Art der Last abhängig und in einer Testumgebung selten zu finden. Nur,
> wenn es "ernst" wird - z.B. tausende Leute gleichzeitig auf einen
> Webserver zugreifen, und jeder gerade was anderes macht.
>
> So kann sich das System ziemlich klebrig anfühlen. Ich habe knapp zwei
> Jahre einen VMWare-getriebene Umgebung, die immer wieder unter dem
> Problem litt, betrieben, und war wirklich froh, als ich da weg war...
>
> Es grüßt
> Peter