"Weiß jemand wirklich, wie spät es ist? Interessiert es wirklich jemanden?"
– Chicago, 1969
Vielleicht war es dieser Rockgruppe egal, wie spät es war, aber unsere Computer müssen die genaue Zeit kennen. Die Zeiterfassung ist für Computernetzwerke sehr wichtig. In Banken, Börsen und anderen Finanzgeschäften müssen Transaktionen in der richtigen Reihenfolge gehalten werden, und genaue zeitliche Abfolgen sind dafür entscheidend. Für Systemadministratoren und DevOps-Profis ist es einfacher, die Spur von E-Mails über eine Reihe von Servern zu verfolgen oder die genaue Abfolge von Ereignissen anhand von Protokolldateien auf geografisch verteilten Hosts zu bestimmen, wenn auf den betreffenden Computern genaue Zeiten gespeichert werden.
Früher habe ich in einer Organisation gearbeitet, die über 20 Millionen E-Mails pro Tag erhielt und über vier Server verfügte, nur um die eingehende E-Mail-Flut zu akzeptieren und einen einfachen Filter dafür einzusetzen. Von dort wurden die E-Mails an einen von vier anderen Servern gesendet, um komplexere Anti-Spam-Bewertungen durchzuführen, und dann an einen von mehreren zusätzlichen Servern zugestellt, wo die E-Mails in den richtigen Posteingängen abgelegt wurden. Auf jeder Ebene würden die E-Mails an einen der Server der nächsten Ebene gesendet, der nur durch die Zufälligkeit von Round-Robin-DNS ausgewählt wird. Manchmal mussten wir eine neue Nachricht durch das System verfolgen, bis wir feststellen konnten, wo sie „verloren gegangen“ ist, so die spitzhaarigen Chefs. Wir mussten dies mit erschreckender Regelmäßigkeit tun.
Die meisten dieser E-Mails stellten sich als Spam heraus. Einige Leute haben sich tatsächlich darüber beschwert, dass ihr [Witz, Katzenbild, Rezept, inspirierender Spruch oder eine andere seltsame E-Mail] des Tages fehlt, und uns gebeten, es zu finden. Wir haben diese Gelegenheiten abgelehnt.
Unsere E-Mail- und andere Transaktionssuchen wurden durch Protokolleinträge mit Zeitstempeln unterstützt, die – heute – sogar auf den langsamsten modernen Linux-Computern bis auf die Nanosekunde aufgelöst werden können. In Umgebungen mit sehr hohen Transaktionsvolumen kann selbst ein Unterschied von wenigen Mikrosekunden in den Systemuhren bedeuten, dass Tausende von Transaktionen sortiert werden müssen, um die richtige(n) zu finden.
Die NTP-Serverhierarchie
Computer auf der ganzen Welt verwenden das Network Time Protocol (NTP), um ihre Zeiten über eine Hierarchie von NTP-Servern mit Internet-Standard-Referenzuhren zu synchronisieren. Die primären Server befinden sich in Schicht 1 und sind über Satellit, Funk oder sogar Modems über Telefonleitungen direkt mit verschiedenen nationalen Zeitdiensten in Schicht 0 verbunden. Der Zeitdienst in Stratum 0 kann eine Atomuhr, ein Funkempfänger, der auf die von einer Atomuhr gesendeten Signale abgestimmt ist, oder ein GPS-Empfänger sein, der die hochgenauen Zeitsignale verwendet, die von GPS-Satelliten gesendet werden.
Um zu verhindern, dass Zeitanfragen von Zeitservern niedriger in der Hierarchie (d. h. mit einer höheren Stratum-Nummer) die primären Referenzserver überfordern, gibt es mehrere tausend öffentliche NTP-Stratum-2-Server, die offen und für jedermann nutzbar sind. Viele Organisationen mit einer großen Anzahl von Hosts, die einen NTP-Server benötigen, richten ihre eigenen Zeitserver ein, sodass nur ein lokaler Host auf die Zeitserver von Stratum 2 zugreift, und konfigurieren dann die verbleibenden Netzwerkhosts so, dass sie den lokalen Zeitserver verwenden, was in meinem Fall der Fall ist , ist ein Stratum-3-Server.
NTP-Auswahlmöglichkeiten
Der ursprüngliche NTP-Daemon, ntpd , wurde von einem neueren, chronyd, ergänzt . Beide halten die Zeit des lokalen Hosts mit dem Zeitserver synchronisiert. Beide Dienste sind verfügbar, und ich habe nichts gesehen, was darauf hindeutet, dass sich dies in absehbarer Zeit ändern wird.
Chrony verfügt über Funktionen, die es aus folgenden Gründen zur besseren Wahl für die meisten Umgebungen machen:
-
Chrony kann viel schneller als NTP mit dem Zeitserver synchronisieren. Dies ist gut für Laptops oder Desktops, die nicht ständig laufen.
-
Es kann schwankende Taktfrequenzen kompensieren, z. B. wenn ein Host in den Ruhezustand wechselt oder in den Energiesparmodus wechselt, oder wenn die Taktgeschwindigkeit aufgrund von Frequenzschritten variiert, die die Taktgeschwindigkeiten verlangsamen, wenn die Last gering ist.
-
Es verarbeitet intermittierende Netzwerkverbindungen und Bandbreitensättigung.
-
Es gleicht Netzwerkverzögerungen und Latenzzeiten aus.
-
Nach der anfänglichen Zeitsynchronisierung stellt Chrony die Uhr nie weiter. Dies gewährleistet stabile und konsistente Zeitintervalle für Systemdienste und Anwendungen.
-
Chrony kann auch ohne Netzwerkverbindung funktionieren. In diesem Fall kann der lokale Host oder Server manuell aktualisiert werden.
Die NTP- und Chrony-RPM-Pakete sind in Standard-Fedora-Repositories verfügbar. Sie können beide installieren und zwischen ihnen wechseln, aber moderne Versionen von Fedora, CentOS und RHEL wurden von NTP auf Chrony als Standardimplementierung für die Zeitmessung verschoben. Ich habe festgestellt, dass Chrony gut funktioniert, eine bessere Schnittstelle für den Systemadministrator bietet, viel mehr Informationen präsentiert und die Kontrolle erhöht.
Nur um es klarzustellen, NTP ist ein Protokoll, das entweder mit NTP oder Chrony implementiert wird. Wenn Sie mehr wissen möchten, lesen Sie diesen Vergleich zwischen NTP und Chrony als Implementierungen des NTP-Protokolls.
Dieser Artikel erklärt, wie Chrony-Clients und -Server auf einem Fedora-Host konfiguriert werden, aber die Konfiguration für aktuelle Versionen von CentOS und RHEL funktioniert genauso.
Chrony-Struktur
Der Chrony-Daemon, chronyd , läuft im Hintergrund und überwacht die Uhrzeit und den Status des in der chrony.conf angegebenen Zeitservers Datei. Wenn die Ortszeit angepasst werden muss, chronyd macht es reibungslos ohne das programmatische Trauma, das auftreten würde, wenn die Uhr sofort auf eine neue Zeit zurückgesetzt würde.
Chronys chronyc Mit dem Tool kann jemand den aktuellen Status von Chrony überwachen und bei Bedarf Änderungen vornehmen. Die Chronik Das Dienstprogramm kann als Befehl verwendet werden, der Unterbefehle akzeptiert, oder es kann als interaktives Programm im Textmodus verwendet werden. Dieser Artikel erklärt beide Verwendungen.
Client-Konfiguration
Die NTP-Client-Konfiguration ist einfach und erfordert wenig oder gar keinen Eingriff. Der NTP-Server kann während der Linux-Installation definiert oder vom DHCP-Server beim Booten bereitgestellt werden. Die standardmäßige /etc/chrony.conf Datei (unten vollständig gezeigt) erfordert keinen Eingriff, um als Client ordnungsgemäß zu funktionieren. Für Fedora verwendet Chrony den Fedora-NTP-Pool, und CentOS und RHEL haben ihre eigenen NTP-Serverpools. Wie viele Red Hat-basierte Distributionen ist die Konfigurationsdatei gut kommentiert.
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
pool 2.fedora.pool.ntp.org iburst
# Record the rate at which the system clock gains/losses time.
driftfile /var/lib/chrony/drift
# Allow the system clock to be stepped in the first three updates
# if its offset is larger than 1 second.
makestep 1.0 3
# Enable kernel synchronization of the real-time clock (RTC).
# Enable hardware timestamping on all interfaces that support it.
#hwtimestamp *
# Increase the minimum number of selectable sources required to adjust
# the system clock.
#minsources 2
# Allow NTP client access from local network.
#allow 192.168.0.0/16
# Serve time even if not synchronized to a time source.
#local stratum 10
# Specify file containing keys for NTP authentication.
keyfile /etc/chrony.keys
# Get TAI-UTC offset and leap seconds from the system tz database.
leapsectz right/UTC
# Specify directory for log files.
logdir /var/log/chrony
# Select which information is logged.
#log measurements statistics tracking
Sehen wir uns den aktuellen Status von NTP auf einer virtuellen Maschine an, die ich zum Testen verwende. Die Chronik Befehl bei Verwendung mit Tracking Unterbefehl, stellt Statistiken bereit, die angeben, wie weit das lokale System vom Referenzserver entfernt ist.
[root@studentvm1 ~]# chronyc tracking
Reference ID : 23ABED4D (ec2-35-171-237-77.compute-1.amazonaws.com)
Stratum : 3
Ref time (UTC) : Fri Nov 16 16:21:30 2018
System time : 0.000645622 seconds slow of NTP time
Last offset : -0.000308577 seconds
RMS offset : 0.000786140 seconds
Frequency : 0.147 ppm slow
Residual freq : -0.073 ppm
Skew : 0.062 ppm
Root delay : 0.041452706 seconds
Root dispersion : 0.022665167 seconds
Update interval : 1044.2 seconds
Leap status : Normal
[root@studentvm1 ~]#
Die Referenz-ID in der ersten Zeile des Ergebnisses ist der Server, mit dem der Host synchronisiert wird – in diesem Fall ein Stratum 3-Referenzserver, der zuletzt um 16:21:30 2018 vom Host kontaktiert wurde. Die anderen Zeilen werden in beschrieben chronyc(1) Manpage.
Die Quellen Der Unterbefehl ist ebenfalls nützlich, da er Informationen über die in chrony.conf konfigurierte Zeitquelle liefert .
[root@studentvm1 ~]# chronyc sources
210 Number of sources = 5
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^+ 192.168.0.51 3 6 377 0 -2613us[-2613us] +/- 63ms
^+ dev.smatwebdesign.com 3 10 377 28m -2961us[-3534us] +/- 113ms
^+ propjet.latt.net 2 10 377 465 -1097us[-1085us] +/- 77ms
^* ec2-35-171-237-77.comput> 2 10 377 83 +2388us[+2395us] +/- 95ms
^+ PBX.cytranet.net 3 10 377 507 -1602us[-1589us] +/- 96ms
[root@studentvm1 ~]#
Die erste Quelle in der Liste ist der Zeitserver, den ich für mein persönliches Netzwerk eingerichtet habe. Die anderen wurden vom Pool bereitgestellt. Auch wenn mein NTP-Server nicht in der Chrony-Konfigurationsdatei oben erscheint, stellt mein DHCP-Server seine IP-Adresse für den NTP-Server bereit. Die Spalte „S“ – Quellstatus – zeigt mit einem Sternchen (* ) der Server, mit dem unser Host synchronisiert wird. Dies stimmt mit den Daten aus dem Tracking überein Unterbefehl.
Das -v Option bietet eine nette Beschreibung der Felder in dieser Ausgabe.
[root@studentvm1 ~]# chronyc sources -v
210 Number of sources = 5
.-- Source mode '^' = server, '=' = peer, '#' = local clock.
/ .- Source state '*' = current synced, '+' = combined , '-' = not combined,
| / '?' = unreachable, 'x' = time may be in error, '~' = time too variable.
|| .- xxxx [ yyyy ] +/- zzzz
|| Reachability register (octal) -. | xxxx = adjusted offset,
|| Log2(Polling interval) --. | | yyyy = measured offset,
|| \ | | zzzz = estimated error.
|| | | \
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^+ 192.168.0.51 3 7 377 28 -2156us[-2156us] +/- 63ms
^+ triton.ellipse.net 2 10 377 24 +5716us[+5716us] +/- 62ms
^+ lithium.constant.com 2 10 377 351 -820us[ -820us] +/- 64ms
^* t2.time.bf1.yahoo.com 2 10 377 453 -992us[ -965us] +/- 46ms
^- ntp.idealab.com 2 10 377 799 +3653us[+3674us] +/- 87ms
[root@studentvm1 ~]#
Wenn ich wollte, dass mein Server die bevorzugte Referenzzeitquelle für diesen Host ist, würde ich die folgende Zeile zur /etc/chrony.conf hinzufügen Datei.
server 192.168.0.51 iburst preferNormalerweise platziere ich diese Zeile direkt über der ersten Pool-Server-Anweisung am Anfang der Datei. Dafür gibt es keinen besonderen Grund, außer dass ich die Server-Anweisungen gerne zusammen halte. Am Ende der Datei würde es genauso gut funktionieren, und ich habe das auf mehreren Hosts gemacht. Diese Konfigurationsdatei ist nicht sequenzsensitiv.
Die bevorzugen Option markiert dies als bevorzugte Referenzquelle. Daher wird dieser Host immer mit dieser Referenzquelle synchronisiert (solange sie verfügbar ist). Wir können auch den vollständig qualifizierten Hostnamen für einen Remote-Referenzserver oder nur den Hostnamen (ohne den Domänennamen) für eine lokale Referenzzeitquelle verwenden, solange die Suchanweisung in /etc/resolv.conf Datei. Ich bevorzuge die IP-Adresse, um sicherzustellen, dass die Zeitquelle zugänglich ist, auch wenn DNS nicht funktioniert. In den meisten Umgebungen ist der Servername wahrscheinlich die bessere Option, da NTP auch dann weiter funktioniert, wenn sich die IP-Adresse des Servers ändert.
Wenn Sie keine bestimmte Referenzquelle haben, mit der Sie synchronisieren möchten, können Sie die Standardeinstellungen verwenden.
Konfigurieren eines NTP-Servers mit Chrony
Das Schöne an der Chrony-Konfigurationsdatei ist, dass diese einzelne Datei den Host sowohl als Client als auch als Server konfiguriert. Um unserem Host eine Serverfunktion hinzuzufügen – es wird immer ein Client sein, der seine Zeit von einem Referenzserver bezieht – müssen wir nur ein paar Änderungen an der Chrony-Konfiguration vornehmen und dann die Firewall des Hosts so konfigurieren, dass sie NTP-Anfragen akzeptiert.
Öffnen Sie /etc/chrony .conf Datei in Ihrem bevorzugten Texteditor und kommentieren Sie die lokale Schicht 10 aus Linie. Dadurch kann sich der Chrony NTP-Server weiterhin so verhalten, als wäre er mit einem entfernten Referenzserver verbunden, wenn die Internetverbindung ausfällt; Dadurch kann der Host weiterhin ein NTP-Server für andere Hosts im lokalen Netzwerk sein.
Lassen Sie uns chronyd neu starten und verfolgen Sie einige Minuten lang, wie der Dienst funktioniert. Bevor wir unseren Host als NTP-Server aktivieren, wollen wir ein wenig testen.
[root@studentvm1 ~]# systemctl restart chronyd ; watch chronyc trackingDie Ergebnisse sollten so aussehen. Die Uhr Befehl führt das chronyc Tracking aus Befehl alle zwei Sekunden, damit wir Änderungen im Laufe der Zeit beobachten können.
Every 2.0s: chronyc tracking studentvm1: Fri Nov 16 20:59:31 2018
Reference ID : C0A80033 (192.168.0.51)
Stratum : 4
Ref time (UTC) : Sat Nov 17 01:58:51 2018
System time : 0.001598277 seconds fast of NTP time
Last offset : +0.001791533 seconds
RMS offset : 0.001791533 seconds
Frequency : 0.546 ppm slow
Residual freq : -0.175 ppm
Skew : 0.168 ppm
Root delay : 0.094823152 seconds
Root dispersion : 0.021242738 seconds
Update interval : 65.0 seconds
Leap status : Normal
Beachten Sie, dass mein NTP-Server, die studentvm1 host, synchronisiert mit dem Host unter 192.168.0.51, meinem internen Netzwerk-NTP-Server, auf Schicht 4. Eine direkte Synchronisierung mit den Fedora-Pool-Maschinen würde zu einer Synchronisierung auf Schicht 3 führen. Beachten Sie auch, dass die Fehlermenge mit der Zeit abnimmt. Schließlich sollte es sich mit einer winzigen Variation um einen ziemlich kleinen Fehlerbereich herum stabilisieren. Die Größe des Fehlers hängt von der Schicht und anderen Netzwerkfaktoren ab. Verwenden Sie nach einigen Minuten Strg+C, um die Überwachungsschleife zu verlassen.
Um unseren Host in einen NTP-Server umzuwandeln, müssen wir ihm erlauben, das lokale Netzwerk zu überwachen. Kommentieren Sie die folgende Zeile aus, um Hosts im lokalen Netzwerk den Zugriff auf unseren NTP-Server zu ermöglichen.
# Allow NTP client access from local network.
allow 192.168.0.0/16
Beachten Sie, dass der Server in jedem lokalen Netzwerk, mit dem er verbunden ist, auf Anfragen lauschen kann. Die IP-Adresse in der „allow“-Zeile dient nur der Veranschaulichung. Achten Sie darauf, das IP-Netzwerk und die Subnetzmaske in dieser Zeile so zu ändern, dass sie mit denen Ihres lokalen Netzwerks übereinstimmen.
Starten Sie chronyd neu .
[root@studentvm1 ~]# systemctl restart chronydUm anderen Hosts in Ihrem Netzwerk den Zugriff auf diesen Server zu ermöglichen, konfigurieren Sie die Firewall so, dass sie eingehende UDP-Pakete auf Port 123 zulässt. Sehen Sie in der Dokumentation Ihrer Firewall nach, wie das geht.
Testen
Ihr Host ist jetzt ein NTP-Server. Sie können es mit einem anderen Host oder einer VM testen, die Zugriff auf das Netzwerk hat, auf dem der NTP-Server lauscht. Konfigurieren Sie den Client so, dass er den neuen NTP-Server als bevorzugten Server in /etc/chrony.conf verwendet Datei, und überwachen Sie dann diesen Client mit chronyc Tools, die wir oben verwendet haben.
Chronyc als interaktives Tool
Wie ich bereits erwähnt habe, chronyc kann als interaktives Befehlswerkzeug verwendet werden. Führen Sie den Befehl einfach ohne Unterbefehl aus und Sie erhalten einen chronyc Eingabeaufforderung.
[root@studentvm1 ~]# chronyc
chrony version 3.4
Copyright (C) 1997-2003, 2007, 2009-2018 Richard P. Curnow and others
chrony comes with ABSOLUTELY NO WARRANTY. This is free software, and
you are welcome to redistribute it under certain conditions. See the
GNU General Public License version 2 for details.
chronyc>
Sie können an dieser Eingabeaufforderung nur die Unterbefehle eingeben. Versuchen Sie, das Tracking zu verwenden , ntpdata , und Quellen Befehle. Die Chronik Befehlszeile ermöglicht das Abrufen und Bearbeiten von Befehlen für chronyc Unterbefehle. Sie können die Hilfe verwenden Unterbefehl, um eine Liste möglicher Befehle und ihrer Syntax zu erhalten.
Schlussfolgerung
Chrony ist ein leistungsstarkes Tool zum Synchronisieren der Zeiten von Client-Hosts, unabhängig davon, ob sie sich alle im lokalen Netzwerk befinden oder auf der ganzen Welt verstreut sind. Es ist einfach zu konfigurieren, da trotz der großen Anzahl verfügbarer Optionen für die meisten Umstände nur wenige Konfigurationen erforderlich sind.
Nachdem sich meine Client-Computer mit dem NTP-Server synchronisiert haben, stelle ich gerne die Systemhardwareuhr anhand der Systemzeit (Betriebssystemzeit) ein, indem ich den folgenden Befehl verwende:
/sbin/hwclock --systohcDieser Befehl kann als Cron-Job oder Skript in cron.daily hinzugefügt werden um die Hardware-Uhr mit der Systemzeit synchronisiert zu halten.
Chrony und NTP (der Dienst) verwenden beide dieselbe Konfiguration, und die Inhalte der Dateien sind austauschbar. Die Manpages für chronyd, chronyc und chrony.conf enthalten eine erstaunliche Menge an Informationen, die Ihnen beim Einstieg helfen oder etwas über esoterische Konfigurationsoptionen erfahren können.
Betreiben Sie einen eigenen NTP-Server? Lassen Sie es uns in den Kommentaren wissen und teilen Sie uns unbedingt mit, welche Implementierung Sie verwenden, NTP oder Chrony.