Synchronizacja czasu w systemie Linux: NTP, Chrony i systemd-timesyncd

Większość ludzi śledzi czas. Wstajemy punktualnie, aby dokończyć poranne rytuały i iść do pracy, zrobić sobie przerwę na lunch, dotrzymać terminów projektów, świętować urodziny i święta, wejść na pokład samolotu i tak dalej.

Co więcej: niektórzy z nas mają obsesję na punkcie czasu. Mój zegarek jest zasilany energią słoneczną i pobiera dokładny czas z Narodowego Instytutu Standardów i Technologii (NIST) do Fort Collins w Kolorado przez radio długofalowe WWVB. Sygnały czasu są zsynchronizowane z zegarem atomowym, również znajdującym się w Fort Collins. Mój Fitbit synchronizuje się z moim telefonem, który synchronizuje się z serwerem NTP, który ostatecznie synchronizuje się z zegarem atomowym.

Urządzenia śledzą też czas

Istnieje wiele powodów, dla których nasze urządzenia i komputery potrzebują dokładnego czasu. Na przykład w bankowości, giełdach i innych branżach finansowych transakcje muszą być przeprowadzane we właściwej kolejności, a do tego kluczowe znaczenie mają dokładne sekwencje czasowe.

Nasze telefony, tablety, samochody, systemy GPS i komputery wymagają dokładnego ustawienia czasu i daty. Chcę, aby zegar na pulpicie mojego komputera pokazywał prawidłową godzinę. Chcę, aby przypomnienia pojawiały się w moim lokalnym kalendarzu we właściwym czasie. Właściwy czas zapewnia również, że zadania cron i systemd będą działać we właściwym czasie.

Data i godzina są również ważne dla rejestrowania, więc trochę łatwiej jest znaleźć określone dzienniki na podstawie daty i godziny. Na przykład kiedyś pracowałem w DevOps (wtedy to się jeszcze nie nazywało) i konfigurowałem system poczty elektronicznej w stanie Karolina Północna. Kiedyś przetwarzaliśmy ponad 20 milionów e-maili dziennie. Śledzenie wiadomości e-mail przez szereg serwerów lub określanie dokładnej sekwencji zdarzeń za pomocą plików dziennika na rozproszonych geograficznie hostach może być znacznie łatwiejsze, jeśli odpowiednie komputery są zsynchronizowane w czasie.

Jeden raz - wiele godzin

Hosty z systemem Linux muszą wziąć pod uwagę, że istnieje czas systemowy i czas RTC. RTC (Real Time Clock) to nieco dziwna i niezbyt dokładna nazwa zegara sprzętowego.

Zegar sprzętowy działa nieprzerwanie nawet wtedy, gdy komputer jest wyłączony, wykorzystując baterię na płycie głównej systemu. Główną funkcją RTC jest przechowywanie czasu, gdy połączenie z serwerem czasu jest niedostępne. W czasach, gdy nie można było połączyć się z serwerem czasu przez Internet, każdy komputer musiał mieć dokładny zegar wewnętrzny. Systemy operacyjne musiały uzyskiwać dostęp do RTC podczas uruchamiania, a użytkownik musiał ręcznie ustawić czas systemowy za pomocą interfejsu konfiguracji sprzętu BIOS, aby upewnić się, że jest prawidłowy.

Zegary sprzętowe nie rozumieją pojęcia stref czasowych; RTC przechowuje tylko czas, a nie strefę czasową ani przesunięcie względem UTC (Uniwersalny czas koordynowany, znany również jako GMT lub Greenwich Mean Time). Możesz zainstalować RTC za pomocą narzędzia, które omówię w dalszej części tego artykułu.

Czas systemowy to czas, który system operacyjny wyświetla na zegarze GUI na pulpicie, w danych wyjściowych polecenia date, w sygnaturach czasowych dzienników. Dotyczy to również tworzenia, modyfikowania i otwierania plików.

Strona człowiek dla rtc znajduje się pełny opis RTC i zegara systemowego.

O co chodzi z NTP?

Komputery na całym świecie używają protokołu NTP (Network Time Protocol) do synchronizacji swojego czasu ze standardowymi zegarami referencyjnymi przez Internet przy użyciu hierarchii serwerów NTP. Główne serwery czasu znajdują się w warstwie 1 i są bezpośrednio połączone z różnymi krajowymi usługami czasowymi w warstwie 0 za pośrednictwem satelity, radia, a nawet modemów przez linie telefoniczne. Usługami czasu warstwy 0 mogą być zegar atomowy, odbiornik radiowy dostrojony do sygnałów nadawanych przez zegary atomowe lub odbiornik GPS wykorzystujący bardzo dokładne sygnały zegarowe nadawane przez satelity GPS.

Zdecydowana większość serwerów referencyjnych ma kilka tysięcy publicznych serwerów NTP warstwy 2, które są otwarte dla publiczności. Wiele organizacji i użytkowników (w tym ja) z wieloma hostami, które potrzebują serwera NTP, decyduje się na skonfigurowanie własnych serwerów czasu, aby tylko jeden lokalny host miał dostęp do warstwy 2 lub 3. Następnie konfigurują pozostałe węzły w sieci, aby korzystały z lokalnego serwer czasu. W przypadku mojej sieci domowej jest to serwer warstwy 3.

Różne implementacje NTP

Oryginalną implementacją NTP jest ntpd. Następnie dołączyły do ​​niego dwa nowsze, chronyd i systemd-timesyncd. Wszystkie trzy synchronizują czas lokalnego hosta z serwerem czasu NTP. Usługa systemd-timesyncd nie jest tak niezawodna jak chronyd, ale jest wystarczająca do większości zastosowań. Jeśli RTC nie jest zsynchronizowany, może stopniowo dostosowywać czas systemowy, aby zsynchronizować się z serwerem NTP, gdy lokalny czas systemowy nieznacznie się zmieni. Usługa systemd-timesync nie może być używana jako serwer czasu.

kronika jest implementacją NTP zawierającą dwa programy: demona chronyd i interfejs wiersza poleceń o nazwie chronyc. Chrony ma kilka funkcji, które są niezbędne w wielu przypadkach:

• Chrony może synchronizować się z serwerem czasu znacznie szybciej niż stara usługa ntpd. Jest to dobre dla laptopów lub komputerów stacjonarnych, które nie działają przez cały czas.
• Może kompensować fluktuacje zegara, na przykład gdy host przechodzi w stan uśpienia lub przechodzi w tryb uśpienia, lub gdy zegar zmienia się z powodu przeskakiwania częstotliwości, co spowalnia zegary przy niskim obciążeniu.
• Rozwiązuje problemy czasowe związane z niestabilnym połączeniem sieciowym lub przeciążeniem sieci.
• Reguluje opóźnienia w sieci.
• Po początkowej synchronizacji czasu Chrony nigdy nie zatrzymuje zegara. Zapewnia to stabilne i spójne przedziały czasowe dla wielu usług i aplikacji systemowych.
• Chrony może działać nawet bez połączenia sieciowego. W takim przypadku lokalny host lub serwer można zaktualizować ręcznie.
• Chrony może działać jako serwer NTP.

Po raz kolejny NTP jest protokołem, który można zaimplementować na hoście z systemem Linux przy użyciu Chrony lub systemd-timesyncd.

NTP, Chrony i systemd-timesyncd RPM są dostępne w standardowych repozytoriach Fedory. Systemd-udev RPM to menedżer zdarzeń jądra, który jest instalowany domyślnie w Fedorze, ale jest opcjonalny.

Możesz zainstalować wszystkie trzy i przełączać się między nimi, ale spowoduje to dodatkowy ból głowy. Więc lepiej tego nie robić. Nowoczesne wersje Fedory, CentOS i RHEL zostały przeniesione do Chrony jako domyślna implementacja, a także mają systemd-timesyncd. Uważam, że Chrony działa dobrze, zapewnia lepszy interfejs niż usługa NTP, zapewnia znacznie więcej informacji i kontroli, co z pewnością spodoba się administratorom systemu.

Wyłączanie usług NTP

Usługa NTP może już działać na twoim hoście. Jeśli tak, musisz go wyłączyć przed przełączeniem na coś innego. Miałem uruchomiony chronyd, więc użyłem następujących poleceń, aby go zatrzymać i wyłączyć. Uruchom odpowiednie polecenia dla dowolnego demona NTP uruchomionego na hoście:

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

Sprawdź, czy usługa jest zatrzymana i wyłączona:

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

Sprawdzenie stanu przed uruchomieniem

Stan synchronizacji zegara systemowego pozwala określić, czy usługa NTP jest uruchomiona. Ponieważ jeszcze nie uruchomiłeś NTP, polecenie timesync-status podpowie:

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

Bezpośrednie żądanie statusu dostarcza ważnych informacji. Na przykład polecenie timedatectl bez argumentu lub opcji domyślnie wykonuje podpolecenie statusu:

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

To da ci czas lokalny dla twojego hosta, czas UTC i czas RTC. W takim przypadku czas systemowy jest ustawiony na strefę czasową America / New_York (TZ), RTC jest ustawiony na czas w lokalnej strefie czasowej, a usługa NTP nie jest aktywna. Czas RTC zaczął nieznacznie odbiegać od czasu systemowego. Jest to normalne w systemach, których zegary nie zostały zsynchronizowane. Wielkość przesunięcia na hoście zależy od czasu, jaki upłynął od ostatniej synchronizacji systemu.

Otrzymaliśmy również ostrzeżenie o korzystaniu z czasu lokalnego dla RTC – dotyczy to zmian stref czasowych i ustawień czasu letniego. Jeśli komputer zostanie wyłączony, gdy trzeba wprowadzić zmiany, zegar czasu rzeczywistego nie ulegnie zmianie. Ale w przypadku serwerów lub innych hostów, które działają przez całą dobę, nie stanowi to żadnego problemu. Ponadto każda usługa zapewniająca synchronizację czasu NTP dostosuje czas hosta podczas początkowej fazy uruchamiania, więc czas będzie ponownie poprawny po zakończeniu uruchamiania.

Ustawianie strefy czasowej

Zwykle określasz strefę czasową podczas procedury instalacji i nie musisz jej później zmieniać. Są jednak chwile, kiedy trzeba zmienić strefę czasową. Istnieje kilka narzędzi, które mogą pomóc. Linux używa plików strefy czasowej do określenia lokalnej strefy czasowej hosta. Te pliki znajdują się w katalogu /usr/share/informacje o strefie. Domyślnie dla mojej strefy czasowej system zaleca to: /etc/localtime -> ../usr/share/zoneinfo/America/New_York. Ale nie musisz znać takich subtelności, aby zmienić strefę czasową.

Najważniejsze jest, aby znać oficjalną nazwę strefy czasowej dla swojej lokalizacji i odpowiednie polecenie. Załóżmy, że chcesz zmienić strefę czasową na 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>

Teraz możesz ustawić strefę czasową. Użyłem polecenia date, aby sprawdzić zmiany, ale możesz także użyć 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 ~]#

Teraz możesz zmienić strefę czasową swojego gospodarza z powrotem na czas lokalny.

systemd-timesyncd

Demon systemd timesync zapewnia implementację NTP, którą można łatwo zarządzać w kontekście systemd. Jest instalowany domyślnie w Fedorze i Ubuntu. Jednak domyślnie uruchamia się tylko w systemie Ubuntu. Nie wiem jak z innymi dystrybucjami. Możesz sam sprawdzić:

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

Konfigurowanie systemd-timesyncd

Plik konfiguracyjny dla systemd-timesyncd to /etc/systemd/timesyncd.conf. Jest to prosty plik z mniejszą liczbą włączonych opcji niż stare usługi NTP i chronyd. Oto zawartość tego pliku (bez dalszych modyfikacji) na mojej 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

Jedyna sekcja, która zawiera, oprócz komentarzy, to [Czas]. Wszystkie pozostałe wiersze są komentowane. Są to wartości domyślne i nie należy ich zmieniać (chyba, że ​​masz ku temu powód). Jeśli nie masz zdefiniowanego serwera czasu NTP w wierszu NTP=, Fedora domyślnie korzysta z rezerwowego serwera czasu Fedory. Zwykle dodaję mój serwer czasu:

NTP=myntpserver

Uruchamianie synchronizacji czasu

Możesz uruchomić i uaktywnić systemd-timesyncd w następujący sposób:

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

Ustawianie zegara sprzętowego

Oto jak wygląda sytuacja po uruchomieniu 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    

Początkowo różnica między RTC a czasem lokalnym (EDT) jest mniejsza niż sekunda, a rozbieżność wzrasta o kolejne kilka sekund w ciągu następnych kilku dni. Ponieważ w RTC nie ma koncepcji stref czasowych, polecenie timedatectl musi wykonać porównanie, aby określić poprawną strefę czasową. Jeśli czas RTC nie odpowiada dokładnie czasowi lokalnemu, oznacza to również, że nie jest zgodny z lokalną strefą czasową.

Szukając więcej informacji, sprawdziłem status systemd-timesync i znalazłem to:

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

Zwróć uwagę na komunikat w dzienniku, który mówi, że czas systemowy nie został ustawiony lub został zresetowany. Usługa Timesync ustawia czas systemowy na podstawie znacznika czasu. Sygnatury czasowe są utrzymywane przez demona synchronizacji czasu i są tworzone przy każdej udanej synchronizacji.

Komenda timedatectl nie ma możliwości pobrania wartości zegara sprzętowego z zegara systemowego. Może ustawić tylko czas i datę na podstawie wartości wprowadzonej w wierszu poleceń. Możesz ustawić RTC na taką samą wartość jak czas systemowy za pomocą polecenia 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

Opcja --localtime mówi zegarowi sprzętowemu, aby pokazywał czas lokalny, a nie UTC.

Dlaczego w ogóle potrzebujesz RTC?

Każda implementacja NTP ustawi zegar systemowy w czasie uruchamiania. A dlaczego w takim razie RTC? To nie do końca prawda: stanie się tak tylko wtedy, gdy masz połączenie sieciowe z serwerem czasu. Jednak wiele systemów nie zawsze ma dostęp do połączenia sieciowego, więc zegar sprzętowy jest przydatny w systemie Linux do ustawiania czasu systemowego. Jest to lepsze niż ręczne ustawianie czasu, nawet jeśli może odbiegać od czasu rzeczywistego.

wniosek

W tym artykule dokonano przeglądu niektórych narzędzi do manipulowania datą, godziną i strefami czasowymi. Narzędzie systemd-timesyncd udostępnia klienta NTP, który może synchronizować czas na hoście lokalnym z serwerem NTP. Jednak systemd-timesyncd nie zapewnia usługi serwera, więc jeśli potrzebujesz serwera NTP w swojej sieci, musisz użyć czegoś innego, takiego jak Chrony, aby działać jako serwer.

Wolę mieć jedną implementację dla dowolnej usługi w mojej sieci, więc używam Chrony. Jeśli nie potrzebujesz lokalnego serwera NTP lub nie masz nic przeciwko używaniu Chrony jako serwera i systemd-timesyncd jako klienta SNTP. W końcu nie ma potrzeby korzystania z dodatkowych funkcji Chrony jako klient, jeśli jesteś zadowolony z funkcjonalności systemd-timesyncd.

Kolejna uwaga: nie musisz używać narzędzi systemowych do implementacji NTP. Możesz użyć starszej wersji ntpd, Chrony lub innej implementacji NTP. W końcu systemd składa się z dużej liczby usług; wiele z nich jest opcjonalnych, więc możesz je wyłączyć i zamiast tego użyć czegoś innego. To nie jest ogromny monolityczny potwór. Możesz nie lubić systemd lub jego części, ale powinieneś podjąć świadomą decyzję.

Podoba mi się implementacja NTP przez systemd, ale wolę Chrony, ponieważ lepiej odpowiada moim potrzebom. To Linux, kochanie -)

O prawach reklamy

oferty VDSina serwery do każdego zadania, ogromny wybór systemów operacyjnych do automatycznej instalacji, możliwe jest zainstalowanie dowolnego systemu operacyjnego z własnego ISO, wygodny панель управления własny rozwój i codzienna płatność. Przypomnijmy, że mamy wieczne serwery, które są zdecydowanie ponadczasowe 😉

Źródło: www.habr.com