Cluster-Heartbeat, VM-Drift, Kerberos: Systemzeit synchronisieren in virtualisierten Umgebungen

    Kauf von Backup-Software vermeiden, Windows Server mit dem integrierten Backup und RDX-Datenträgern sichern: Kostenloses Whitepaper jetzt lesen »

    (Anzeige)

    Windows SystemzeitVirtua­lisierte Infra­strukturen stellen bei der Zeit­syn­chronisierung besondere Anforderungen, weil Hosts, Manage­ment-Umgebung und virtuelle Maschinen im Takt sein sollen. Mit dem einfachen Eintragen eines NTP-Servers ist es dabei nicht getan. Vielmehr bedarf es einer Strategie, um zu ver­meiden, dass verschiedene Zeitquellen sich in die Quere kommen.

    Dass eine synchrone Zeit beispiels­weise für Verzeichnis­dienste und speziell für das Verfallsdatum von Kerberos-Tickets wichtig ist, dürfte sich herum­gesprochen haben. Läuft die Systemzeit eines Windows-Domänen­mitglieds der des Domänen-Controllers bzw. des zeitgebenden PDC-Emulators um mehr als 5 Minuten hinterher oder voraus, dann steht kein sicherer Kanal mehr zur Verfügung und die Anmeldung misslingt. Kerberos-Tickets kommen auch in einer rein LDAP-basierten SSO-Domäne eines vCenter Platform Services Controllers (PSC) zum Einsatz.

    Einheitliche Zeit für Cluster, AD und Logs

    Ferner spielen überein­stimmende System­uhren in Cluster-Setups stets eine wichtige Rolle, zum Beispiel für die Synchronisation der Cluster-Nodes untereinander. ESXi-Hosts tauschen in einem HA-Setup regelmäßig Heartbeat-Signale aus. Eine nicht synchrone Zeit kann dazu führen, dass ein Master-Host einen Slave (oder umgekehrt) aufgrund der scheinbar zu hohen Latenz unnötiger­weise als tot einstuft.

    Eine synchrone Zeit ist zudem bei allen Applikationen in einem Cluster unabdingbar, deren Datenbestand häufigen Änderungen unterliegt, wie etwa Datenbanken oder Verzeichnisdienste. Hierbei sei beispielsweise eine Multimaster-Replikation im Active Directory oder ein OpenLDAP im Multimaster-Modus genannt.

    Verzeichnisdienste überprüfen bei einer Replikation anhand des Zeitstempels, welches Objekt das aktuellere ist. Ähnliches gilt auch für alle Datenbank-Anwendungen, die mit multiplen Instanzen und Replikas arbeiten. Außerdem dient die Uhrzeit eines ESXi-Hosts als Zeitstempel für die von ihm generierten Log-Dateien sowie für die Performance-Graphen.

    NTP-Server

    Eine synchrone Zeit im lokalen Netzwerk-Setup erreichen Sie dadurch, dass sämtliche beteiligten Komponenten die gleiche Referenzzeit als Quelle verwenden. Sogar wenn es sich dabei um einen lokalen NTP-Server handelt, der seine Zeit nicht mit einer Stratum-0-Ebene im Internet abgleicht, ist die durch ihn erzwungene synchrone Zeit meistens praktikabel. Allerdings sollte man dann keine zeitkritischen Daten mit anderen Netzwerken austauschen müssen.

    NTP-Server für ESXi über den Host-Client festlegen

    Besser ist es aber, einen Rechner in der eigenen Umgebung als NTP-Server (für das interne Netzwerk) und als NTP-Client zu einem öffentlich zugänglichen Time-Server im Internet zu konfigurieren, etwa die Atomzeit vom physikalisch technischen Bundesamt (ptbtime1.ptb.de). In vSphere könnte jede der beteiligten Komponenten ihre Zeit von einem Zeit-Server im lokalen Netz oder von einem Zeit-Server im Internet beziehen.

    Warum die Zeit in VMs abweichen kann

    Leider liegt es in der Natur von Virtualisierungs­technologien, dass die Systemzeit der virtuellen Maschinen und des Hosts auseinanderdriften. Benötigt eine VM beispielsweise unter ESXi keine Rechenzeit, dann wird sie, sofern keine CPU-Reservierungen gesetzt sind, (außer bei MS DOS oder Novell Netware) auch keine erhalten.

    Dies bringt aber den Zeitgeber im Gast aus dem Tritt und lässt die Uhr unregelmäßig laufen, weil ja auch er dann keine Rechenzeit bekommt. Probleme gibt es aber nicht nur bei hohen Idle-Zyklen, sondern auch, wenn der Host am oberen Limit agiert, weil er dann nicht mehr jeder VM ausreichende Rechenzeit zuteilen kann, um den Timer im Takt zu halten.

    Das  Abdriften der VM-Zeit hängt zudem von der verwendeten Virtualisierungs­technologie ab, also Vollvirtualisierung (mit und ohne Hardware-Unterstützung) oder Paravirtualisierung. VMware unterstützt nämlich bei 32-Bit-Systemen bzw. bei ESXi-Hosts, deren CPU über keine Virtualisierungs­erweiterung verfügt (Intel-VT, AMD-V), immer noch die von VMware 1998 entwickelte und in VMware Workstation heute noch eingesetzte software-gestützte Vollvirtualisierung (Binary Translation).

    Die VMware Workstation unterstützt noch das Verfahren der Binary Translation, das größere Abweichungen der VM-Zeit verursacht.

    Allerdings disqualifiziert sich eine solche Lösung ohnehin für den produktiven Einsatz, weil ja angefangen vom BIOS die komplette Hardware des virtuellen Gastes emuliert wird, was im Einzelfall zu einer extremen Zeitdrift führen kann. Möchten Sie weiter in die Problematik einsteigen, dann sollten Sie sich im Detail mit der Funktionsweise des Interrupt-Timers auseinandersetzen.

    Paravirtualisierende Hypervisor wie Xen und Hyper-V, die entsprechende Anforderungen der Gastsysteme an echte Hardware durchreichen, oder vollvirtualisierte Systeme mit Hardware-Unterstützung wie ESXi haben mit der Zeitdrift generell weniger Probleme.

    Zeitdrift korrigieren

    Um das Problem zu lösen, gibt es verschiedene Ansätze, etwa das Re-Synchroniseren der VM-Zeit mit dem Host über die VMware Tools. Allerdings können diese lediglich eine zu langsam laufende Uhr in der VM schneller laufen lassen und nicht langsamer.

    Kritisch ist ein solches Verstellen oder Re-Synchronisieren der VM-Zeit, wenn im Gastsystem zum Beispiel eine Datenbank oder eine andere zeitkritische Cluster-Applikation läuft, weil dann etwa Transaktionen verloren gehen können.

    Es kann auch zu einem Phänomen wie diesem kommen: Windows-VMs erhalten ihre Zeit in der Regel von einem PDC-Emulator. Handelt es sich hierbei um einen physischen (oder virtuellen) PDC, dessen Zeit sich beispielsweise um 6 Minuten vom ESX-Host, auf dem der Windows-Gast läuft, unterscheidet, dann stellen die Tools die Zeit 6 Minuten vor und der PDC macht es dann ggf. wieder rückgängig, was zu einer turnusmäßig "springenden" VM-Zeit führt.

    Wenn die VMware Tools die Zeit eines Gastsystems nach dem Host richten, dann können Konflikte mit anderen Zeitquellen entstehen.

    Bei Linux hängt es von der Kernel-Version ab, ob Sie eine Anpassung vornehmen müssen. So beschreibt VMware in seiner Knowledge-Base ein unschönes Phänomen einer "davonlaufenden" Zeit bei Linux-Gästen, die Sie etwa über einen cronjob wieder einfangen können, der regelmäßig ein ntpd-Update ausführt.

    VMware hat Probleme im Zusammenhang mit der Zeitsyn­chronisation durchaus erkannt und stellt dazu in seiner Knowledge Base einer Reihe lesenswerter KB-Beiträge zur Verfügung, wie zum Beispiel 1006427 und 1318.

    Strategien für die Zeitsynchronisierung

    Eine für alle Anwendungsfälle passende Generalstrategie gibt es also nicht, wohl aber ein paar Empfehlungen, die in den meistens gut passen:

    • Verwenden Sie auf keinen Fall mehrere Möglichkeiten der Zeit­synchronisation parallel
    • Gibt es im Unternehmen bereits einen Zeit-Server, dann sollte dieser als primäre Zeitquelle für die Hosts herangezogen werden. Handelt es sich hierbei um einen Domänen-Controller unter Windows bzw. den PDC-Emulator innerhalb der Windows-Domäne, sind allerdings ggf. Vorkehrungen zu treffen, dass ein ESXi-Host oder eine Linux-VM von diesem auch tatsächlich die Zeit erhält.
    • Generell sollten Sie das Synchronisieren der Zeit dem Gastbetriebs­system nach dem Start selbst  überlassen, also den Haken in den VMware Tools deaktivieren, damit es nicht zu einem kontinuierlichen Springen der Uhrzeit kommt. Das gilt uneingeschränkt dann, wenn alle VMs Mitglied einer Domäne sind.
    • Bei einzelnen Linux-VMs können Sie eventuell in der VM einen Zeit-Server befragen und ggf. den maxpoll-Wert für den NTP-Resync auf ein möglichst kurzes Intervall setzen.

    Und noch ein letzter Grundsatz: Besser alle Systeme haben die gleiche falsche Zeit, als alle eine unterschiedliche.

    2 Kommentare

    Bild von Martin Feuerstein
    Martin Feuerstein sagt:
    24. August 2017 - 16:14

    Kleine Korrektur: die Namen der Zeitserver der PTB sind ptbtime1.ptb.de, ptbtime2.ptb.de und ptbtime3.ptb.de - dieses können auch als Round-Robin im NTP-Client konfiguriert werden.

    Das PTB bittet um eine kurze Meldung per E-Mail, falls jemand diese in seinem System als Zeitserver einträgt. (sh. https://www.ptb.de/cms/ptb/fachabteilungen/abtq/fb-q4/ag-q42/zeitsynchro...)

    Bild von Wolfgang Sommergut
    24. August 2017 - 21:17

    Vielen Dank für den Hinweis, habe den Namen korrigiert!