Linux Tijdsynchronisatie: NTP, Chrony en systemd-timesyncd

De meeste mensen houden de tijd bij. We staan ​​op tijd op om onze ochtendrituelen te voltooien en naar het werk te gaan, een lunchpauze te nemen, projectdeadlines te halen, verjaardagen en feestdagen te vieren, aan boord van een vliegtuig te stappen, enzovoort.

Bovendien: sommigen van ons zijn geobsedeerd door tijd. Mijn horloge werkt op zonne-energie en krijgt de juiste tijd van het National Institute of Standards and Technology (NIST) naar Fort Collins, Colorado via langegolfradio wwvb. De tijdsignalen worden gesynchroniseerd met de atoomklok, ook te vinden in Fort Collins. Mijn Fitbit synchroniseert met mijn telefoon die synchroniseert met de server NTP, die uiteindelijk synchroniseert met de atoomklok.

Apparaten houden ook de tijd bij

Er zijn veel redenen waarom onze apparaten en computers nauwkeurige tijd nodig hebben. In banken, aandelenmarkten en andere financiële bedrijven moeten transacties bijvoorbeeld in de juiste volgorde worden uitgevoerd, en nauwkeurige tijdreeksen zijn hiervoor van cruciaal belang.

Onze telefoons, tablets, auto's, gps-systemen en computers vereisen allemaal nauwkeurige tijd- en datuminstellingen. Ik wil dat de klok op het bureaublad van mijn computer de juiste tijd aangeeft. Ik wil dat herinneringen op het juiste moment in mijn lokale agenda verschijnen. De juiste tijd zorgt er ook voor dat de cron- en systemd-taken op de juiste tijd worden uitgevoerd.

Datum en tijd zijn ook belangrijk voor het loggen, dus het is wat makkelijker om bepaalde logs te vinden op basis van datum en tijd. Ik werkte bijvoorbeeld ooit in DevOps (zo heette het toen nog niet) en was bezig met het opzetten van een e-mailsysteem in de staat North Carolina. Vroeger verwerkten we meer dan 20 miljoen e-mails per dag. Het volgen van e-mail via een reeks servers, of het bepalen van de exacte volgorde van gebeurtenissen met behulp van logbestanden op geografisch verspreide hosts, kan veel eenvoudiger zijn als de respectieve computers in de tijd zijn gesynchroniseerd.

Een keer - vele uren

Linux-hosts moeten er rekening mee houden dat er een systeemtijd en een RTC-tijd is. RTC (Real Time Clock) is een enigszins vreemde en niet erg nauwkeurige naam voor een hardwareklok.

De hardwareklok loopt continu, zelfs als de computer is uitgeschakeld, met behulp van de batterij op het systeemmoederbord. De belangrijkste functie van de RTC is het opslaan van de tijd wanneer er geen verbinding met een tijdserver beschikbaar is. In de tijd dat het onmogelijk was om via internet verbinding te maken met een tijdserver, moest elke computer een nauwkeurige interne klok hebben. Besturingssystemen moesten tijdens het opstarten toegang hebben tot de RTC en de gebruiker moest de systeemtijd handmatig instellen met behulp van de BIOS-hardwareconfiguratie-interface om er zeker van te zijn dat deze correct was.

Hardwareklokken begrijpen het concept van tijdzones niet; RTC slaat alleen de tijd op, niet de tijdzone of offset ten opzichte van UTC (Coordinated Universal Time, ook wel GMT of Greenwich Mean Time genoemd). Je kunt RTC installeren met behulp van een tool die ik verderop in dit artikel zal bespreken.

De systeemtijd is de tijd die het besturingssysteem weergeeft op de GUI-klok op uw bureaublad, in de uitvoer van het datumcommando, in de tijdstempels van de logboeken. Dit geldt ook wanneer bestanden worden gemaakt, gewijzigd en geopend.

Op de pagina man voor rtc er is een volledige beschrijving van de RTC en de systeemklok.

Wat is er met NTP?

Computers over de hele wereld gebruiken NTP (Network Time Protocol) om hun tijd te synchroniseren met standaard referentieklokken via internet met behulp van een hiërarchie van NTP-servers. De belangrijkste tijdservers bevinden zich op laag 1 en ze zijn rechtstreeks verbonden met verschillende nationale tijddiensten op laag 0 via satelliet, radio of zelfs modems via telefoonlijnen. Laag 0-tijdservices kunnen een atoomklok zijn, een radio-ontvanger die is afgestemd op signalen die worden uitgezonden door atoomklokken, of een GPS-ontvanger die zeer nauwkeurige kloksignalen gebruikt die worden uitgezonden door GPS-satellieten.

De overgrote meerderheid van de referentieservers heeft enkele duizenden openbare NTP stratum 2-servers die open zijn voor het publiek. Veel organisaties en gebruikers (waaronder ikzelf) met veel hosts die een NTP-server nodig hebben, kiezen ervoor om hun eigen tijdservers op te zetten, zodat slechts één lokale host toegang heeft tot stratum 2 of 3. Vervolgens configureren ze de resterende knooppunten op het netwerk om de lokale tijd server. In het geval van mijn thuisnetwerk is dit een layer 3-server.

Diverse implementaties van NTP

De oorspronkelijke implementatie van NTP is ntpd. Het werd vervolgens vergezeld door twee nieuwere, chronyd en systemd-timesyncd. Alle drie synchroniseren ze de lokale hosttijd met een NTP-tijdserver. De systemd-timesyncd-service is niet zo betrouwbaar als chronyd, maar is goed genoeg voor de meeste doeleinden. Als de RTC niet synchroon loopt, kan hij de systeemtijd geleidelijk aanpassen om te synchroniseren met de NTP-server wanneer de lokale systeemtijd iets afwijkt. De service systemd-timesync kan niet als tijdserver worden gebruikt.

chronisch is een implementatie van NTP die twee programma's bevat: de chronyd-daemon en een opdrachtregelinterface genaamd chronyc. Chrony heeft een aantal eigenschappen die in veel gevallen onmisbaar zijn:

• Chrony kan veel sneller synchroniseren met een tijdserver dan de oude ntpd-service. Dit is goed voor laptops of desktops die niet altijd werken.
• Het kan klokfluctuaties compenseren, zoals wanneer de host in slaapstand gaat of in de slaapstand gaat, of wanneer de klok verandert als gevolg van frequentiehopping, wat klokken bij lage belasting vertraagt.
• Het lost tijdsproblemen op die verband houden met een onstabiele netwerkverbinding of netwerkcongestie.
• Het regelt netwerkvertragingen.
• Na de eerste tijdsynchronisatie stopt Chrony de klok nooit. Dit zorgt voor stabiele en consistente tijdslots voor veel systeemservices en applicaties.
• Chrony kan zelfs zonder netwerkverbinding werken. In dit geval kan de lokale host of server handmatig worden bijgewerkt.
• Chrony kan fungeren als een NTP-server.

Nogmaals, NTP is een protocol dat kan worden geïmplementeerd op een Linux-host met behulp van Chrony of systemd-timesyncd.

De NTP, Chrony en systemd-timesyncd RPM's zijn beschikbaar in de standaard Fedora repositories. De systemd-udev RPM is een kernelgebeurtenismanager die standaard op Fedora is geïnstalleerd, maar optioneel is.

Je kunt ze alle drie installeren en ertussen schakelen, maar dit zorgt voor extra hoofdpijn. Het is dus beter om het niet te doen. Moderne releases van Fedora, CentOS en RHEL zijn overgegaan naar Chrony als de standaardimplementatie, en ze hebben ook systemd-timesyncd. Ik vind dat Chrony goed werkt, een betere interface biedt dan de NTP-service, veel meer informatie en controle biedt, waar systeembeheerders zeker van zullen genieten.

NTP-services uitschakelen

De NTP-service is mogelijk al actief op uw host. Als dat het geval is, moet u het uitschakelen voordat u naar iets anders overschakelt. Ik had chronyd draaien, dus ik gebruikte de volgende commando's om het te stoppen en uit te schakelen. Voer de juiste opdrachten uit voor elke NTP-daemon die u op uw host uitvoert:

[root@testvm1 ~]# systemctl disable chronyd ; systemctl stop chronyd
Removed /etc/systemd/system/multi-user.target.wants/chronyd.service.
[root@testvm1 ~]#

Controleer of de service is gestopt en uitgeschakeld:

[root@testvm1 ~]# systemctl status chronyd
● chronyd.service - NTP client/server
     Loaded: loaded (/usr/lib/systemd/system/chronyd.service; disabled; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:chronyd(8)
             man:chrony.conf(5)
[root@testvm1 ~]#

Statuscontrole voor lancering

Met de synchronisatiestatus van de systeemklok kunt u bepalen of de NTP-service actief is. Aangezien je NTP nog niet hebt gestart, geeft het commando timesync-status hier een hint naar:

[root@testvm1 ~]# timedatectl timesync-status
Failed to query server: Could not activate remote peer.

Een direct statusverzoek levert belangrijke informatie op. De opdracht timedatectl zonder argument of opties voert bijvoorbeeld standaard de subopdracht status uit:

[root@testvm1 ~]# timedatectl status
           Local time: Fri 2020-05-15 08:43:10 EDT  
           Universal time: Fri 2020-05-15 12:43:10 UTC  
                 RTC time: Fri 2020-05-15 08:43:08      
                Time zone: America/New_York (EDT, -0400)
System clock synchronized: no                          
              NTP service: inactive                    
          RTC in local TZ: yes                    

Warning: The system is configured to read the RTC time in the local time zone.
         This mode cannot be fully supported. It will create various problems
         with time zone changes and daylight saving time adjustments. The RTC
         time is never updated, it relies on external facilities to maintain it.
         If at all possible, use RTC in UTC by calling
         'timedatectl set-local-rtc 0'.
[root@testvm1 ~]#

Dit geeft je de lokale tijd voor je host, UTC-tijd en RTC-tijd. In dit geval wordt de systeemtijd ingesteld op de tijdzone America/New_York (TZ), wordt de RTC ingesteld op de tijd in de lokale tijdzone en is de NTP-service niet actief. De RTC-tijd begint iets af te wijken van de systeemtijd. Dit is normaal voor systemen waarvan de klokken niet zijn gesynchroniseerd. De hoeveelheid offset op de host is afhankelijk van de tijd die is verstreken sinds het systeem voor het laatst is gesynchroniseerd.

We hebben ook een waarschuwing ontvangen over het gebruik van lokale tijd voor RTC - dit is van toepassing op tijdzonewijzigingen en DST-instellingen. Als de computer wordt uitgeschakeld wanneer er wijzigingen moeten worden aangebracht, verandert de RTC niet. Maar voor servers of andere hosts die de klok rond draaien, is dit helemaal geen probleem. Bovendien past elke service die NTP-tijdsynchronisatie biedt de tijd van de host aan tijdens de initiële opstartfase, zodat de tijd weer correct is nadat het opstarten is voltooid.

De tijdzone instellen

Meestal geeft u tijdens de installatieprocedure de tijdzone op en hoeft u deze later niet te wijzigen. Er zijn echter momenten waarop u de tijdzone moet wijzigen. Er zijn verschillende tools die kunnen helpen. Linux gebruikt tijdzonebestanden om de lokale tijdzone van een host te bepalen. Deze bestanden staan ​​in de directory /usr/share/zoneinfo. Standaard schrijft het systeem voor mijn tijdzone dit voor: /etc/localtime -> ../usr/share/zoneinfo/America/New_York. Maar u hoeft dergelijke subtiliteiten niet te kennen om de tijdzone te wijzigen.

Het belangrijkste is om de officiële tijdzonenaam voor uw locatie en de bijbehorende opdracht te kennen. Stel dat u de tijdzone wilt wijzigen in Los Angeles:

[root@testvm2 ~]# timedatectl list-timezones | column
<SNIP>
America/La_Paz                  Europe/Budapest
America/Lima                    Europe/Chisinau
America/Los_Angeles             Europe/Copenhagen
America/Maceio                  Europe/Dublin
America/Managua                 Europe/Gibraltar
America/Manaus                  Europe/Helsinki
<SNIP>

Nu kunt u de tijdzone instellen. Ik heb de opdracht date gebruikt om te controleren op wijzigingen, maar je kunt ook timedatectl gebruiken:

[root@testvm2 ~]# date
Tue 19 May 2020 04:47:49 PM EDT
[root@testvm2 ~]# timedatectl set-timezone America/Los_Angeles
[root@testvm2 ~]# date
Tue 19 May 2020 01:48:23 PM PDT
[root@testvm2 ~]#

Nu kunt u de tijdzone van uw gastheer weer wijzigen in lokale tijd.

systemd-timesyncd

De systemd timesync-daemon biedt een NTP-implementatie die eenvoudig te beheren is in de systemd-context. Het is standaard geïnstalleerd op Fedora en Ubuntu. Het start echter alleen standaard op Ubuntu. Ik ben niet zeker van andere distributies. U kunt zelf controleren:

[root@testvm1 ~]# systemctl status systemd-timesyncd

Systemd-timesyncd configureren

Het configuratiebestand voor systemd-timesyncd is /etc/systemd/timesyncd.conf. Dit is een eenvoudig bestand met minder ingeschakelde opties dan de oude NTP- en chronyd-services. Hier is de inhoud van dit bestand (zonder verdere aanpassingen) op mijn Fedora VM:

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See timesyncd.conf(5) for details.

[Time]
#NTP=
#FallbackNTP=0.fedora.pool.ntp.org 1.fedora.pool.ntp.org 2.fedora.pool.ntp.org 3.fedora.pool.ntp.org
#RootDistanceMaxSec=5
#PollIntervalMinSec=32
#PollIntervalMaxSec=2048

De enige sectie die het bevat, naast opmerkingen, is [Tijd]. Alle andere regels zijn becommentarieerd. Dit zijn de standaardwaarden en mogen niet worden gewijzigd (tenzij je daar een reden voor hebt). Als je geen NTP tijdserver gedefinieerd hebt in de NTP= regel, zal Fedora standaard een fallback Fedora tijdserver gebruiken. Ik voeg meestal mijn tijdserver toe:

NTP=myntpserver

Lopende tijdsynchronisatie

U kunt systemd-timesyncd als volgt starten en actief maken:

[root@testvm2 ~]# systemctl enable systemd-timesyncd.service
Created symlink /etc/systemd/system/dbus-org.freedesktop.timesync1.service → /usr/lib/systemd/system/systemd-timesyncd.service.
Created symlink /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service → /usr/lib/systemd/system/systemd-timesyncd.service.
[root@testvm2 ~]# systemctl start systemd-timesyncd.service
[root@testvm2 ~]#

De hardwareklok instellen

Zo ziet de situatie eruit na het uitvoeren van timesyncd:

[root@testvm2 systemd]# timedatectl
               Local time: Sat 2020-05-16 14:34:54 EDT  
           Universal time: Sat 2020-05-16 18:34:54 UTC  
                 RTC time: Sat 2020-05-16 14:34:53      
                Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes                          
              NTP service: active                      
          RTC in local TZ: no    

Aanvankelijk is het verschil tussen RTC en lokale tijd (EDT) minder dan een seconde, en de discrepantie neemt de komende dagen met nog een paar seconden toe. Aangezien er geen concept van tijdzones is in RTC, moet de opdracht timedatectl een vergelijking uitvoeren om de juiste tijdzone te bepalen. Komt de RTC-tijd niet exact overeen met de lokale tijd, dan komt deze ook niet overeen met de lokale tijdzone.

Op zoek naar meer informatie, controleerde ik de status van systemd-timesync en vond dit:

[root@testvm2 systemd]# systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
     Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: disabled)
     Active: active (running) since Sat 2020-05-16 13:56:53 EDT; 18h ago
       Docs: man:systemd-timesyncd.service(8)
   Main PID: 822 (systemd-timesyn)
     Status: "Initial synchronization to time server 163.237.218.19:123 (2.fedora.pool.ntp.org)."
      Tasks: 2 (limit: 10365)
     Memory: 2.8M
        CPU: 476ms
     CGroup: /system.slice/systemd-timesyncd.service
             └─822 /usr/lib/systemd/systemd-timesyncd

May 16 09:57:24 testvm2.both.org systemd[1]: Starting Network Time Synchronization...
May 16 09:57:24 testvm2.both.org systemd-timesyncd[822]: System clock time unset or jumped backwards, restoring from recorded timestamp: Sat 2020-05-16 13:56:53 EDT
May 16 13:56:53 testvm2.both.org systemd[1]: Started Network Time Synchronization.
May 16 13:57:56 testvm2.both.org systemd-timesyncd[822]: Initial synchronization to time server 163.237.218.19:123 (2.fedora.pool.ntp.org).
[root@testvm2 systemd]#

Let op het logbericht dat zegt dat de systeemtijd niet is ingesteld of is gereset. De Timesync-service stelt de systeemtijd in op basis van het tijdstempel. Tijdstempels worden bijgehouden door de timesync-daemon en worden gemaakt bij elke geslaagde synchronisatie.

De opdracht timedatectl kan op geen enkele manier de waarde van de hardwareklok van de systeemklok halen. Het kan alleen de tijd en datum instellen vanaf de waarde die op de opdrachtregel is ingevoerd. U kunt de RTC op dezelfde waarde instellen als de systeemtijd met behulp van de opdracht hwclock:

[root@testvm2 ~]# /sbin/hwclock --systohc --localtime
[root@testvm2 ~]# timedatectl
               Local time: Mon 2020-05-18 13:56:46 EDT  
           Universal time: Mon 2020-05-18 17:56:46 UTC  
                 RTC time: Mon 2020-05-18 13:56:46      
                Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes                          
              NTP service: active                      
          RTC in local TZ: yes

De optie --localtime vertelt de hardwareklok om lokale tijd weer te geven, niet UTC.

Waarom heb je überhaupt RTC nodig?

Elke implementatie van NTP stelt de systeemklok in bij het opstarten. En waarom dan RTC? Dit is niet helemaal waar: dit gebeurt alleen als je een netwerkverbinding hebt met de tijdserver. Veel systemen hebben echter niet altijd toegang tot een netwerkverbinding, dus een hardwareklok is handig voor Linux om de systeemtijd in te stellen. Dit is beter dan handmatig de tijd instellen, ook al kan deze afwijken van real time.

Conclusie

In dit artikel zijn enkele tools besproken voor het manipuleren van datum, tijd en tijdzones. De tool systemd-timesyncd biedt een NTP-client die de tijd op de lokale host kan synchroniseren met een NTP-server. Systemd-timesyncd biedt echter geen serverservice, dus als u een NTP-server op uw netwerk nodig heeft, moet u iets anders gebruiken, zoals Chrony, om als server te fungeren.

Ik heb liever een enkele implementatie voor elke service op mijn netwerk, dus ik gebruik Chrony. Als je geen lokale NTP-server nodig hebt, of als je het niet erg vindt om Chrony als server en systemd-timesyncd als SNTP-client te gebruiken. Het is immers niet nodig om als client de extra features van Chrony te gebruiken als je tevreden bent met de functionaliteit van systemd-timesyncd.

Nog een opmerking: u bent niet verplicht om de systemd-tools te gebruiken om NTP te implementeren. U kunt een oudere versie van ntpd, Chrony of een andere NTP-implementatie gebruiken. systemd bestaat immers uit een groot aantal diensten; veel ervan zijn optioneel, dus u kunt ze uitschakelen en in plaats daarvan iets anders gebruiken. Dit is geen enorm monolithisch monster. Misschien vind je systemd of delen ervan niet leuk, maar je moet een weloverwogen beslissing nemen.

Ik hou van de implementatie van NTP door systemd, maar ik geef de voorkeur aan Chrony omdat het beter bij mijn behoeften past. Het is Linux, schat -)

Als advertentie

VDSina aanbiedingen servers voor elke taak, een enorme keuze aan besturingssystemen voor automatische installatie, is het mogelijk om elk eigen besturingssysteem te installeren ISO, comfortabel controlepaneel eigen ontwikkeling en dagelijkse betaling. Bedenk dat we eeuwige servers hebben die absoluut tijdloos zijn 😉

Bron: www.habr.com