🥇Tidssynkronisering i Linux: NTP, Chrony og systemd-timesyncd

De fleste mennesker følger med tiden. Vi står opp i tide for å gjennomføre våre morgenritualer og dra på jobb, ta en lunsjpause, overholde prosjektfrister, feire bursdager og høytider, gå ombord i et fly, og så videre.

Videre: noen av oss er besatt av tid. Klokkene mine drives av solenergi og får nøyaktig tid fra National Institute of Standards and Technology (NIST) i Fort Collins, Colorado, via en langbølge radiostasjon WWVB. Tidsignalene synkroniseres med atomklokker, som også ligger i Fort Collins. Min Fitbit synkroniserer med telefonen min, som synkroniseres med serveren NTP, som til slutt synkroniseres med atomklokkene.

Enheter følger også med tiden.

Det er mange grunner til at enheter og datamaskiner våre trenger nøyaktig tid. For eksempel, i banksektoren, på aksjemarkedene og i andre finansielle virksomheter må transaksjoner utføres i riktig rekkefølge, og nøyaktige tidsrekkefølger er kritisk viktig.

Telefonene våre, nettbrettene, bilene, GPS-systemene og datamaskinene krever riktig innstilling av tid og dato. Jeg vil at klokken på skrivebordet mitt skal vise riktig tid. Jeg vil at påminnelser i min lokale kalender skal dukke opp til rett tid. Riktig tid sikrer også at cron-jobber og systemd oppgaver kjøres til riktig tid.

Dato og tid er også viktige for logging, slik at det er litt enklere å finne forskjellige logger i henhold til dato og tid. For eksempel, en gang jobbet jeg i DevOps (den gangen ble det ikke kalt dette) og konfigurerte et e-postsystem i North Carolina. Vi håndterte tidligere mer enn 20 millioner e-poster om dagen. Å spore e-post gjennom en serie servere eller bestemme den nøyaktige rekkefølgen av hendelser ved hjelp av loggfiler på geografisk separerte verter kan være mye enklere hvis de aktuelle datamaskinene er synkronisert i tid.

Tiden er én — klokkene er mange.

Linux-verter må være klar over at det finnes systemtid og RTC-tid. RTC (Real Time Clock — realtidsklokke) er et litt merkelig og ikke særlig nøyaktig navn for maskinvareklokker.

Maskinurene jobber kontinuerlig, selv når datamaskinen er slått av, ved å bruke batteriet på hovedkortet. Hovedfunksjonen til RTC er å holde styr på tiden når forbindelsen til tidsserveren ikke er tilgjengelig. I tider da det ikke var mulig å koble til en tidsserver over internett, måtte hver datamaskin ha nøyaktige interne klokker. Operativsystemer måtte hente informasjon fra RTC under oppstart, og brukeren måtte manuelt sette systemtiden ved hjelp av BIOS-konfigurasjonsgrensesnittet for å sikre at den var korrekt.

Maskinurene forstår ikke konseptet med tidssoner; RTC lagrer bare tiden, ikke tidssonen eller forskyvningen fra UTC (Koordinert universaltid, som også er kjent som GMT eller Greenwich Mean Time). Du kan sette RTC med et verktøy som jeg vil forklare senere i denne artikkelen.

Systemtiden er tiden som operativsystemet viser på GUI-klokker på skrivebordet, i utdataene fra date-kommandoen, i loggposter. Dette refererer også til tidspunktet for opprettelse, endring og åpning av filer.

På siden man for rtc det er en fullstendig beskrivelse av RTC og systemklokker.

Hva med NTP?

Datamaskiner over hele verden bruker NTP (Network Time Protocol) for å synkronisere sin tid med standardreferanseklocker over internett ved hjelp av en hierarkisk struktur av NTP-servere. Primære tidsservere er på nivå 1, og de er direkte koblet til ulike nasjonale tids tjenester på nivå 0 via satellitt, radio, eller til og med modem over telefonlinjer. Tjenestene på nivå 0 kan være atomklokker, en radiomottaker som er innstilt på signaler sendt av atomklokker, eller en GPS-mottaker som bruker høypresisjons tids-signaler sendt av GPS-satellitter.

På de fleste referanseserverne er det åpnet flere tusen offentlige NTP-servere i stratum 2, som er tilgjengelige for alle. Mange organisasjoner og brukere (inkludert meg selv) med et stort antall verter som trenger en NTP-server, foretrekker å sette opp sine egne tidsservere, slik at bare én lokal vert kobler seg til stratum 2 eller 3. Deretter konfigurerer de de øvrige nodene i nettverket til å bruke den lokale tidsserveren. I tilfellet med mitt hjemmenettverk er dette en server i nivå 3.

Ulike implementasjoner av NTP

Den opprinnelige implementeringen av NTP er ntpd. Deretter kom to nyere, chronyd og systemd-timesyncd. Alle tre synkroniserer tiden på den lokale verten med en NTP-tidsserver. Tjenesten systemd-timesyncd er ikke så pålitelig som chronyd, men den er tilstrekkelig for de fleste formål. Hvis RTC ikke er synkronisert, kan den gradvis justere systemtiden for å synkronisere med NTP-serveren når den lokale systemtiden avviker noe. Tjenesten systemd-timesync kan ikke brukes som en tidsserver.

Chrony — det er en NTP-implementering som inneholder to programmer: daemon chronyd og et kommandolinjegrensesnitt kalt chronyc. Chrony har noen funksjoner som i mange tilfeller er helt uunnværlige:

Chrony kan synkronisere med en tidsserver mye raskere enn den gamle tjenesten ntpd. Dette er gunstig for bærbare PC-er eller stasjonære datamaskiner som ikke er på hele tiden.
Den kan kompensere for frekvensvibrasjoner, for eksempel når verten går i dvale eller når taktfrekvensen endres på grunn av plutselige endringer i frekvens, som bremser taktfrekvensene ved lave belastninger.
Den løser tidsproblemer knyttet til ustabile nettverksforbindelser eller nettverksbelastning.
Den justerer nettverksforsinkelser.
Etter den innledende tids-synkroniseringen stopper ikke Chrony klokkene. Dette sikrer stabile og konsistente tidsintervaller for mange systemtjenester og applikasjoner.
Chrony kan fungere selv uten nettverkstilkobling. I så fall kan den lokale verten eller serveren oppdateres manuelt.
Chrony kan fungere som en NTP-server.

Igjen: NTP er en protokoll som kan implementeres på en Linux-vert ved hjelp av Chrony eller systemd-timesyncd.

RPM-pakker for NTP, Chrony og systemd-timesyncd er tilgjengelige i standardarkivene til Fedora. RPM systemd-udev er en kjernedisponeringseventshåndterer som er forhåndsinstallert i Fedora, men som ikke er obligatorisk å bruke.

Du kan installere alle tre og bytte mellom dem, men det vil skape unødvendige problemer. Så det er bedre å unngå det. Moderne utgivelser av Fedora, CentOS og RHEL har gått over til Chrony som standardimplementering, og i tillegg har de systemd-timesyncd. Jeg synes Chrony fungerer bra, gir et bedre grensesnitt enn NTP-tjenesten, gir mye mer informasjon og øker kontrollen, noe som definitivt vil glede systemadministratorer.

Deaktivere NTP-tjenester

Det kan være at NTP-tjenesten allerede kjører på verten din. Hvis det er tilfelle, må du deaktivere den før du bytter til noe annet. Jeg hadde chronyd kjørende, så jeg brukte følgende kommandoer for å stoppe og deaktivere det. Kjør tilsvarende kommandoer for hvilken som helst NTP-demon du bruker på verten din:

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

Kontroller at tjenesten er stoppet og deaktivert:

[root@testvm1 ~]# systemctl status chronyd
● chronyd.service - NTP-klient/server
     Lest inn: lastet (/usr/lib/systemd/system/chronyd.service; deaktivert; leverandørforvalg: aktivert)
     Aktiv: inaktiv (død)
       Dokumenter: man:chronyd(8)
             man:chrony.conf(5)
[root@testvm1 ~]#

Sjekke status før oppstart

Status for systemklokkesynkronisering forteller deg om NTP-tjenesten kjører. Siden du ennå ikke har startet NTP, vil kommandoen timesync-status antyde dette:

[root@testvm1 ~]# timedatectl timesync-status
Kunne ikke spørre server: Kunne ikke aktivere ekstern likemann.

En direkte statusforespørsel gir viktig informasjon. For eksempel utfører kommandoen timedatectl uten argumenter eller parametere standard underkommandoen status:

[root@testvm1 ~]# timedatectl status
           Lokal tid: Fri 2020-05-15 08:43:10 EDT  
           Universell tid: Fri 2020-05-15 12:43:10 UTC  
                 RTC tid: Fri 2020-05-15 08:43:08      
                Tidsone: America/New_York (EDT, -0400)
Systemklokke synkronisert: nei                          
              NTP-tjeneste: inaktiv                    
          RTC i lokal TZ: ja                    

Advarsel: Systemet er konfigurert til å lese RTC-tid i lokal tidssone.
         Denne modusen kan ikke fullt ut støttes. Den vil skape ulike problemer
         med tidssoneendringer og justeringer for sommertid. RTC
         tiden blir aldri oppdatert, den er avhengig av eksterne tjenester for å opprettholde den.
         Hvis det er mulig, bruk RTC i UTC ved å kalle
         'timedatectl set-local-rtc 0'.
[root@testvm1 ~]#

Slik får du lokal tid for verten din, UTC-tid og RTC-tid. I dette tilfellet er systemtiden satt til tidssonen America/New_York (TZ), RTC er satt til tiden i lokal tidssone, og NTP-tjenesten er ikke aktiv. RTC-tiden begynner å avvike litt fra systemtiden. Dette er normalt for systemer der klokken ikke har vært synkronisert. Omfanget av avviket på verten avhenger av tiden som har gått siden den siste systemsynkroniseringen.

Vi fikk også en advarsel om bruk av lokal tid for RTC — dette gjelder endringer i tidssone og innstillinger for sommertid. Hvis datamaskinen er slått av når endringer må gjøres, vil RTC-tiden ikke endres. Men for servere eller andre verter som kjører døgnet rundt, er dette overhodet ikke et problem. I tillegg vil enhver tjeneste som gir NTP-tidsynkronisering justere vertens tid også tidlig i oppstartprosessen, så etter at oppstarten er fullført, vil tiden igjen være korrekt.

Innstilling av tidssone

Vanligvis angir du tidssonen under installasjonsprosedyren, og du har ikke behov for å endre den senere. Det kan imidlertid være tilfeller der det er nødvendig å endre tidssonen. Det finnes flere verktøy som kan hjelpe. For å bestemme den lokale tidssonen bruker Linux vertsfilene for tidssoner. Disse filene finnes i katalogen /usr/share/zoneinfo. Som standard angir systemet for min tidssone dette: /etc/ localtime -> ../usr/share/zoneinfo/America/New_York. Men du trenger ikke å kjenne til slike detaljer for å endre tidssonen.

Det viktigste er å vite det offisielle navnet på tidssonen for ditt sted og den tilsvarende kommandoen. La oss si at du ønsker å endre tidssonen til Los Angeles:


[root@testvm2 ~]# timedatectl list-timezones | column

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

Nå kan du sette tidssonen. Jeg brukte kommandoen date for å sjekke endringene, men du kan også bruke timedatectl:

[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 ~]#

Du kan nå endre tidssonen på verten din til lokal tid.

systemd-timesyncd

Systemd timesync demon gir en NTP-implementering som er enkel å administrere i systemd-konteksten. Den er forhåndsinstallert på Fedora og Ubuntu. Men den kjøres bare som standard på Ubuntu. Jeg er ikke sikker på andre distribusjoner. Du kan sjekke selv:

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

Konfigurering av systemd-timesyncd

Konfigurasjonsfilen for systemd-timesyncd er /etc/systemd/timesyncd.conf. Det er en enkel fil med færre alternativer enn det som finnes i de eldre NTP- og chronyd-tjenestene. Her er innholdet i denne filen (uten endringer) på min virtuelle maskin med Fedora:

#  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

Den eneste seksjonen den inneholder, bortsett fra kommentarer, er [Time]. Alle andre linjer er kommentert. Dette er standardverdier og trenger ikke å endres (med mindre du har spesifikke grunner). Hvis du ikke har en NTP-tidsserver definert i NTP=-linjen, brukes en bestemt Linux-tidsserver som standard i Fedora. Jeg pleier å legge til min tidsserver:

NTP=myntpserver

Start timesync

Du kan starte og aktivere systemd-timesyncd slik:

[root@testvm2 ~]# systemctl enable systemd-timesyncd.service
Opprettet symlink /etc/systemd/system/dbus-org.freedesktop.timesync1.service → /usr/lib/systemd/system/systemd-timesyncd.service.
Opprettet 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 ~]#

Innstilling av maskinens klokke

Slik ser situasjonen ut etter at timesyncd har blitt kjørt:

[root@testvm2 systemd]# timedatectl
               Lokal tid: Sat 2020-05-16 14:34:54 EDT  
           Universell tid: Sat 2020-05-16 18:34:54 UTC  
                 RTC-tid: Sat 2020-05-16 14:34:53      
                Tidssone: America/New_York (EDT, -0400)
Systemklokke synkronisert: ja                          
              NTP-tjeneste: aktiv                      
          RTC i lokal TZ: nei

Opprinnelig er forskjellen mellom RTC og lokal tid (EDT) ikke mer enn ett sekund, og avviket øker med et par sekunder de neste dagene. Siden RTC ikke har noe begrep om tidssoner, må timedatectl utføre en sammenligning for å bestemme hvilken tidssone som er nødvendig. Hvis RTC-tiden ikke nøyaktig samsvarer med lokal tid, betyr det at den heller ikke stemmer overens med lokal tidssone.

I jakten på mer informasjon sjekket jeg statusen til systemd-timesync og fant følgende:

[root@testvm2 systemd]# systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Nettverkstidsynkronisering
     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]#

Legg merke til loggmeldingen som indikerer at systemtiden ikke er satt eller har blitt tilbakeført. Timesync-tjenesten setter systemtiden basert på tidsstempler. Tidsstemplene opprettholdes av timesync-daemonen og opprettes ved hver vellykket synkronisering.

Timdatectl-kommandoen har ikke mulighet til å hente verdien av maskinvareklokken fra systemklokken. Den kan bare sette tid og dato fra verdien som er skrevet inn i kommandolinjen. Du kan sette RTC til den samme verdien som systemtiden ved å bruke hwclock-kommandoen:

[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

Alternativet --localtime betyr at maskinvareklokken viser lokal tid, og ikke UTC.

Hvorfor har du egentlig RTC?

Enhver implementasjon av NTP vil sette systemklokken ved oppstart. Så hvorfor er RTC nødvendig? Slik er det ikke helt: dette skjer bare hvis du har en nettverksforbindelse til en tidserver. Mange systemer har imidlertid ikke konstant tilgang til en nettverksforbindelse, så maskinvareklokker er nyttige for at Linux skal kunne sette systemtiden basert på dem. Det er bedre enn å sette tiden manuelt, selv om den kan avvike fra virkelig tid.

Konklusjon

I denne artikkelen ser vi på noen verktøy for å håndtere dato, tid og tidssoner. Verktøyet systemd-timesyncd gir en NTP-klient som kan synkronisere tiden på lokal vert med en NTP-server. Imidlertid gir ikke systemd-timesyncd en servertjeneste, så hvis du trenger en NTP-server i nettverket ditt, må du bruke noe annet - som Chrony, for å fungere som server.

Jeg foretrekker å ha en enkelt implementasjon for alle tjenester i nettverket mitt, så jeg bruker Chrony. Hvis du ikke trenger en lokal NTP-server, eller hvis du ikke har noe imot å bruke Chrony som server og systemd-timesyncd som SNTP-klient. Det er ikke nødvendig å bruke de ekstra funksjonene til Chrony som klient hvis du er fornøyd med funksjonaliteten til systemd-timesyncd.

Et annet poeng: du er ikke pålagt å bruke systemd-verktøy for å implementere NTP. Du kan bruke den gamle versjonen ntpd, Chrony eller en annen NTP-implementasjon. Systemd består av mange tjenester; mange av dem er valgfrie, så de kan deaktiveres og erstattes med noe annet. Det er ikke et stort monolittisk monster. Du trenger ikke å like systemd eller dens deler, men du må ta en informert beslutning.

Jeg liker NTP-implementeringen i systemd, men jeg foretrekker Chrony fordi det bedre møter mine behov. Det er Linux, kjære -)

Advertising

VDSina tilbyr servere for alle oppgaver, et stort utvalg av operativsystemer for automatisk installasjon, det er mulig å installere hvilket som helst OS fra egen ISO, praktisk kontrollpanel eget utvikling og daglig betaling. La oss minne om at vi har evige servere som definitivt er tidløse 😉

Kilde: habr.com