Verwenden von NTP zum Synchronisieren einer Gruppe von Linux-Servern mit einer gemeinsamen Zeitquelle


7

Ich habe ungefähr 20 Linux-Server und möchte alle ihre Uhren mit einem einzelnen NTP-Server synchronisieren, der sich im selben Rack und Switch befindet wie meine Server. Nichts ist virtualisiert.

Unsere Administratoren haben Probleme, die Uhren der verschiedenen Maschinen näher als etwa 500 ms zu synchronisieren. Ich hätte es erraten, und dieser Beitrag impliziert, dass wir in der Lage sein sollten, die Linux-Boxen innerhalb von 2 ms von der Quelle und voneinander zu synchronisieren.

Sind meine Erwartungen an NTP nicht zumutbar? Irgendwelche Hinweise, was die Administratoren tun / überprüfen sollten?


1
In einem Netzwerk mit konsistenter Latenz und ordnungsgemäß konfigurierten Abfragen sollte es sehr genau sein können. Die Standardabrufwerte sind möglicherweise zu groß für Sie. Ich weiß, dass die Standardeinstellungen unter Debian / Ubuntu zu 2-6 ms Offsets in meinen VMs und 1-3 ms Offsets auf meinen physischen Boxen führen.
Zoredache

1
Lesen Sie auch die entsprechende Frage zur Überwachung des Zeitversatzes. Wenn Ihre Zeit auf> 2 ms genau sein soll, möchten Sie möglicherweise regelmäßig alle Ihre Hosts überwachen, damit Sie sicher sein können. serverfault.com/questions/183298/…
Zoredache

Antworten:


12

Ich besitze eine Hosting-Firma und wir machen genau das. So erreichen wir das.

Zunächst benötigen Sie eine NTP-Masterquelle. So wird einer Ihrer Linux-Server zum Master. Ich würde einen DNS A-Eintrag namens time.example.com erstellen (vorausgesetzt, example.com ist die Domain). Auf diese Weise müssen Sie die anderen 19 Server nicht aktualisieren, wenn Ihr Master umzieht.

Auf dem Master-Server benötigen Sie eine entsprechend konfigurierte ntp.conf-Datei.

So sieht eine unserer Master-Dateien /etc/ntp.conf aus. Beachten Sie, dass dies ein Rechenzentrum mit einem privaten Adressraum (RFC1918) ist, der 172.17.xx verwendet, sodass Sie entsprechende Anpassungen vornehmen müssen. Wenn Sie mehr als einen Master möchten, erstellen Sie mehr als einen DNS A-Eintrag mit jeweils unterschiedlicher IP, um auf Wunsch eine gewisse Fehlertoleranz zu erzielen.

server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

server 0.north-america.pool.ntp.org
server 1.north-america.pool.ntp.org
server 2.north-america.pool.ntp.org
server 3.north-america.pool.ntp.org


# Logging & Stats
statistics loopstats
statsdir /var/log/ntp/
filegen peerstats file peers type day link enable
filegen loopstats file loops type day link enable

# Drift file.  Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
#
driftfile /etc/ntp/drift
broadcastdelay  0.008

restrict default noquery nomodify

restrict 0.north-america.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
restrict 1.north-america.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
restrict 2.north-america.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
restrict 3.north-america.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery

# Allow LAN to query us
restrict 172.17.0.0 mask 255.255.0.0 nomodify notrap

# Trust ourselves.  :-)
restrict 127.0.0.1

Jetzt haben wir auf jedem Client eine /etc/ntp.conf-Datei, die folgendermaßen aussieht:

server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10
server time.example.com

# Drift file.  Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.

driftfile /etc/ntp/drift
multicastclient                 # listen on default 224.0.1.1
broadcastdelay  0.008

# Don't serve time or stats to anyone else by default (more secure)

restrict default noquery nomodify

restrict time.example.com mask 255.255.255.255 nomodify notrap noquery

# Allow LAN to query us
restrict 172.17.0.0 mask 255.255.0.0 nomodify notrap

# Trust ourselves.  :-)
restrict 127.0.0.1

Verwenden Sie den Befehl ntpq, um die Server anzuzeigen, mit denen Sie synchronisiert sind. Sie erhielten eine Liste der konfigurierten Zeitserver sowie die Verzögerung, den Versatz und den Jitter, die Ihr Server mit ihnen hat. Für eine korrekte Synchronisation sollten die Verzögerungs- und Versatzwerte ungleich Null sein und der Jitterwert sollte unter 100 liegen.

Auch auf unseren Client-Knoten haben wir ein RC-Skript (/etc/rc.d/rc.local), das die Uhr synchronisiert, bevor der NTPD-Daemon gestartet wird. Hier sind die wichtigen Teile ... Sie sind auftragsabhängig.

Synchronisieren Sie die Uhr des Clients mit der Hauptzeitquelle / usr / sbin / ntpdate -b time.example.com

Starten Sie den NTPD-Daemon, um während des Startvorgangs umfangreiche Zeitanpassungen vorzunehmen. / usr / sbin / ntpd -g -x

Abhängig von Ihrer Einrichtung müssen Sie eine Firewall-Regel festlegen, damit Ihr time.example.com-Master über den UDP-Port auf das öffentliche Internet zugreifen kann. Hier ist eine typische und entsprechend platzierte IPTables-Regel

iptables -t nat -A POSTROUTING -o $ PUB_IF -p udp --dport 123 -j MASQUERADE

Wobei PUB_IF die öffentliche Schnittstelle ist (eth0, eth1, was auch immer)


Tun Sie etwas, um Ihre Systeme mit einem Tool zu überwachen, das nicht auf dem System ausgeführt wird? Was ist Ihr durchschnittlicher Zeitversatz?
Zoredache

Ja, wir überwachen mit einer Reihe von benutzerdefinierten Skripten. Einige Skripte werden auf den Clients ausgeführt, die unter anderem nur sicherstellen, dass der NTPD-Dämon ausgeführt wird. Wenn festgestellt wird, dass er nicht ausgeführt wird, wird versucht, ihn neu zu starten. Wenn dies fehlschlägt, werden die Protokolle protokolliert und E-Mails gesendet. Die Zeit des Rechenzentrums wird von externen Systemen verfolgt - größtenteils eine Kombination aus Nagios und Munin.
Kilo

Was ist es in dieser Antwort, das die Administratoren des OP darauf hinweist, was zu untersuchen ist? Ist es das multicastclientund broadcastdelaydas ist der Schlüssel, dann sag es.
MattBianco

@MattBianco: Nein. Wir verwenden dafür ein benutzerdefiniertes Skript. Es handelt sich um ein umgebungsspezifisches Implementierungsdetail. Um dies zu beleuchten, wird das Skript auf unseren Mastern ausgeführt und fordert die Zeit von jedem Client-Knoten an. Es kennt die Clients, da alle unsere Hosts zentrales LDAP verwenden. Dieses Skript ist Teil vieler, die wir als täglichen "Morgenbericht" ausführen, den wir es nennen. Mithilfe von Variablen im Skript können wir Schwellenwerte festlegen, die wir über ein Nagios-Dashboard melden.
Kilo

Zu Ihrer Information: Neuere Versionen von ntp können restrict source blah blahanstelle der vier Zeilen für jeden Poolserver verwendet werden.
dfc

3

Richtig konfiguriertes NTP erreicht die Synchronisation innerhalb weniger ms. Ich stelle immer sicher, dass jeder NTP-Client mit mindestens drei NTP-Servern kommuniziert.

Verwenden Sie ntpq -pdiese Option , um den Status zu überwachen. Dies sollte einen Hinweis darauf geben, warum Sie keine bessere Synchronisierung erhalten.


Ich bin damit einverstanden, dass Sie mehr als eine Zeitquelle benötigen. Es ist einfach genug, ein paar weitere dieser Hosts zum Hören einzurichten.
Aaron Copley

Wenn alle Server mit demselben Master synchronisiert werden sollen, habe ich nur eine einzige Quelle. Gibt es ein Problem damit?
Ted Graham

Siehe Erics Antwort. Ich habe immer mehrere Quellen verwendet.
RedGrittyBrick

0

Ich bin nicht sicher, ob Sie so viel weniger Zeit für die Synchronisierung erreichen können, aber durch die korrekte Konfiguration des NTP-Servers werden die Server fast 10 bis 20 ms synchronisiert, die ich auf meinen Servern durchgeführt habe. Minimieren Sie die Driftzeit. Es ist nicht unmöglich, das zu bekommen, aber nachdem Sie den NTP-Server eingerichtet und alle Server auf diesen NTP-Server verwiesen und die Zeit zum ersten Mal manuell synchronisiert haben, wird der Zeitunterschied zwischen den Servern verringert.


Wir haben über 700 Server und VMs in unseren 3 Rechenzentren und keiner ist länger als 1 oder 2 Sekunden ausgeschaltet. Alles, was länger als 1-2 Sekunden dauert, ist fast immer auf einen kürzlich erfolgten Neustart usw. zurückzuführen. Der normale tägliche Betrieb ist für uns alles in Sekundenschnelle synchronisiert.
Kilo

"NTP bietet mit schnellen LANs und Computern im Allgemeinen Genauigkeiten im Bereich von 0,1 ms und im interkontinentalen Internet bis zu einigen zehn Millisekunden." cis.udel.edu/~mills/ntp.html
RedGrittyBrick
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.