Welche Einschränkungen gibt es beim Ausführen von NTP-Servern in virtuellen Maschinen? (2010)

Welche Einschränkungen gibt es beim Ausführen von NTP-Servern in virtuellen Maschinen? (2010)

Ich möchte in meinem lokalen Netzwerk mehrere Stratum 2-Zeitserver einrichten. Virtuelle Maschinen wären hierfür sicherlich günstiger als der Kauf von drei 1U-Servern. Welche Einschränkungen wären damit verbunden? Das heißt, in welchem ​​Ausmaß wird die Genauigkeit beeinträchtigt?

Außerdem gehe ich davon aus, dass diese lokalen Zeitserver auf unterschiedlichen physischen Rechnern laufen sollten, um Hardware-Unregelmäßigkeiten zu vermeiden. Ist diese Intuition richtig?

Bearbeiten Ich sollte sagen, dass ich mit "virtuellen Maschinen" nichtspeziellbedeutenVMware. Ich meinte vielmehr das allgemeine Konzept virtualisierter Instanzen.

Antwort1

Es ist jetzt das Jahr 2023, undalle früheren Antworten auf diese Frage sind nun falsch(und das seit mindestens Ende 2016), zumindest was Linux-VMs betrifft. [Die folgenden Hinweise gelten möglicherweise nicht für Windows-VMs.]

Wenn Sie dies im Jahr 2023 oder später lesen, glauben Sie bitte nicht den Behauptungen in Antworten aus dem Jahr 2013 oder früher über eine maximale Genauigkeit von 20-100 ms. Die Zeitsynchronisierung in modernen VMs kann in einem LAN eine Genauigkeit von unter 1 Millisekunde und über eine Internetverbindung für Verbraucher eine Genauigkeit von nahezu 1 Millisekunde erreichen.

Die folgenden ServerFault-Fragen enthalten aktuellere Diskussionen:

Hier sind einige anschauliche Offset-Diagramme (in chronologischer Reihenfolge), die meine Behauptungen untermauern. In einigen Fällen habe ich noch die Rohprotokolldateien, die ich gerne jedem zur Verfügung stelle, der selbst nachforschen möchte. Beachten Sie den Maßstab des Diagramms in jedem Fall:

  1. Eine VM, die ntpdEnde 2016 in einer privaten OpenStack-Cloud unter dem KVM-Hypervisor (auf einer Art Intel Xeon) ausgeführt wird: Offset-KVM
  2. Eine VM, die ntpdMitte 2020 auf einem eigenständigen KVM-Host (auf einem Intel Celeron 1037U) läuft: Offset-KVM-Celeron
  3. Eine Reihe von AWS t3a.micro(AMD)-Instanzen, die chronydEnde 2021 laufen: Offset-AWS-T3A
  4. Eine Reihe von AWS t4g.micro(ARM)-Instanzen, die chronydEnde 2021 laufen: Offset-AWS-T4G
  5. Eine Reihe von Azure Standard_B1s(Intel)-Instanzen, die chronydAnfang 2022 ausgeführt werden: Offset-Azurblau-B1s
  6. Eine Anzahl von Containern, die chronydEnde 2022 in AWS ECS/Fargate (Intel) laufen: Offset-Fargate

Antwort2

Tatsache ist, dass die Uhrgenauigkeit innerhalb einer VM im Jahr 2010 immer noch sehr schlecht ist. Das kommt von einigen Stellen, aber das Schlimmste ist, dass die Zeitabweichung nicht konstant ist; der Abweichungsfaktor ändert sich von Moment zu Moment. NTP ist ein Protokoll, das eine eingebaute Uhrkompensation hat, aber es wurde mit einem eingebauten statischen Abweichungsfaktor entwickelt. Wenn beispielsweise eine physische Maschine alle 30 Tage 12 Sekunden verliert, kann NTP dies kompensieren und tut dies sehr gut. Aber wenn diese Maschine alle 30 Tage zwischen 4 und 70 Sekunden verlieren kann, ist NTP nicht so gut darin, dieses Maß an Änderung zu verfolgen.

Was es für NTP wirklich schwierig macht, in einer VM-Umgebung mitzuhalten, ist, dass die lokale Uhr, die es sieht, ihren Driftfaktor im Laufe einer Minute ändern kann. Je nachdem, wie häufig es seine übergeordneten Zeitquellen überprüft, kann dies zu großen Driftfaktoränderungen führen und dazu, dass es viel häufiger nicht mehr synchron ist. Nicht mehr synchrone Zeit wirkt sich auf Ihr gesamtes Unternehmen aus.

NTP für ein lokales Netzwerk ist ein relativ ressourcenschonendes Protokoll mit sehr geringem Speicherbedarf und kann problemlos auf anderen Servern Ihrer Netzwerkinfrastruktur wie Ihren DNS- und DHCP-Servern verwendet werden. Einige Router bieten auch NTP-Funktionalität, daher sollten Sie sich das einmal ansehen.

Idealerweise möchten Sie zwei separate Server an separaten Standorten, die jeweils mit einem anderen Satz von Servern höherer Schicht synchronisiert werden. Es wäre auch eine sehr gute Idee, beide Zeitserver so zu konfigurieren, dass sie den anderen Server als „Peer“ verwenden, was die Auswirkungen auf den Zeitdienst minimiert, falls eine der Upstream-Zeitquellen ausfällt; es wird zwar eine Schichtänderung geben, aber zumindest wird keine Synchronisation gemeldet. Und schließlich sollten Sie nett zu Ihren Upstream-Zeitanbietern sein und Ihre Server so konfigurieren, dass zwischen den Abfragen sehr lange Zeit vergeht, sobald die Zeit gut etabliert ist. Dies ist der Parameter „maxpoll“ in der Zeile „Server“ und ist eine Zweierpotenz in Sekunden zwischen den Synchronisierungsversuchen.

Wenn Sie dafür unbedingt VMs verwenden müssten, würde ich mindestens drei solcher NTP-Server einrichten. Jeder davon muss sich auf einem anderen Host und wenn möglich in einem anderen Rechenzentrum befinden. Wie ich gerade vorgeschlagen habe, benötigen sie unterschiedliche Zeitquellen und sollten miteinander peeren. Konfigurieren Sie dann alle Ihre NTP-Clients so, dass sie alle drei als übergeordnete Quellen verwenden. Stellen Sie sicher, dass Ihre Maxpoll-Werte niedrig genug sind, damit zwischen Synchronisierungspaketen außerhalb des Netzwerks nie mehr als anderthalb Stunden und 30 Minuten im Netzwerk vergehen. Die Chancen stehen gut, dass mindestens einer der drei zu einem bestimmten Zeitpunkt synchron ist. Clients, die nur mit einem Zeithost kommunizieren können, müssen sich mit gelegentlichen Synchronisationsereignissen abfinden. Insgesamt wäre die Zeitqualität in diesem Szenario nicht so genau wie bei physischen Servern.

Wenn ich eine Schätzung abgeben müsste, würde ich sagen, dass Ihre Konsenszeit in einer reinen VM-Umgebung wahrscheinlich im Bereich von, sagen wir mal, 30 bis 100 ms vom tatsächlichen Wert liegt. In einer rein physischen Umgebung würde Ihre Konsenszeit wahrscheinlich im Bereich von 10 ms liegen, wenn die Zeitserver lange genug aktiv waren, damit sich die Zeit stabilisieren konnte.

Antwort3

Siehe die VMware-Zeitmessungdokumentieren. Das Ausführen eines NTP-Daemons in einer VM ist wahrscheinlich keine gute Idee, insbesondere wenn Sie eine zuverlässige Zeit benötigen.

Antwort4

Wenn Sie NTP in einer virtualisierten Umgebung ausführen, können Sie froh sein, wenn Sie eine Genauigkeit von 20 ms erreichen (das haben wir mit VMware erreicht). Die virtualisierte Taktabweichung ist schlecht, insbesondere in einer virtualisierten Umgebung mit Ressourcenkonflikten.

Es hängt davon ab, wie genau Sie sein müssen. Wenn Sie nur auf die Sekunde genau sein wollen (z. B. bei Webservern), ist das wahrscheinlich kein Problem, solange Sie keine Ressourcenkonflikte haben. Wenn Sie eine Genauigkeit im Millisekundenbereich wünschen (z. B. bei einer ausgelasteten Datenbank, einem Protokollserver oder einem Forschungsprojekt), vergessen Sie virtualisierte Zeitserver.

NTP-Server sollten sich immer auf physischen Hosts befinden. Sie sollten mindestens 3 davon in einem Pool haben (damit ein Rogue-Server vom Pool abgelehnt wird); und wenn möglich, sollten sie ihre Zeit von GPS oder einer anderen lokalen Tier-0-Quelle beziehen und nicht über das Internet.

verwandte Informationen