Większość ludzi zwraca uwagę na czas. Wstajemy o odpowiedniej porze, aby wykonać poranne rytuały i udać się do pracy, zrobić przerwę na lunch, dotrzymać terminów projektów, celebrować urodziny i święta, wsiąść do samolotu i tak dalej.
Co więcej, niektórzy z nas są wręcz obsesyjnie skupieni na czasie. Moje zegarki działają na energię słoneczną i otrzymują dokładny czas z Narodowego Instytutu Standaryzacji i Technologii () w Fort Collins (stan Kolorado) za pośrednictwem stacji radiowej o długiej fali . Sygnaly czasu są synchronizowane z zegarami atomowymi, które również znajdują się w Fort Collins. Mój Fitbit synchronizuje się z moim telefonem, który synchronizuje się z serwerem , który ostatecznie synchronizuje się z zegarami atomowymi.
Urządzenia również śledzą czas.
Istnieje wiele powodów, dla których nasze urządzenia i komputery potrzebują dokładnego czasu. Na przykład w sektorze bankowym, na rynkach finansowych i w innych instytucjach finansowych transakcje muszą być realizowane w odpowiedniej kolejności, a dla tego dokładne sekwencje czasowe są kluczowe.
Nasze telefony, tablety, samochody, systemy GPS i komputery wymagają precyzyjnego ustawienia daty i czasu. Chcę, żeby zegar na pulpicie mojego komputera pokazywał właściwy czas. Chcę, aby przypomnienia w moim lokalnym kalendarzu pojawiały się o właściwej porze. Dokładny czas zapewnia także, że zadania cron i systemd uruchamiają się o właściwym czasie.
Data i czas są również ważne do prowadzenia logów, co znacznie ułatwia odnajdywanie określonych logów według daty i czasu. Na przykład, pewnego razu pracowałem w DevOps (wtedy tak tego nie nazywano) i zajmowałem się konfiguracją systemu poczty elektronicznej w stanie Karolina Północna. Kiedyś obsługiwaliśmy ponad 20 milionów wiadomości dziennie. Śledzenie e-maili przez szereg serwerów lub określenie dokładnej sekwencji zdarzeń za pomocą plików dziennika na geograficznie rozproszonych hostach może być znacznie łatwiejsze, jeśli odpowiednie komputery są ze sobą zsynchronizowane pod względem czasu.
Czas to jeden — zegarów wiele
Serwery Linux muszą uwzględnić, że istnieje czas systemowy oraz czas RTC. RTC (Real Time Clock — zegar czasu rzeczywistego) jest nieco dziwną i nie szczególnie dokładną nazwą dla zegarów sprzętowych.
Zegary sprzętowe działają nieprzerwanie, nawet gdy komputer jest wyłączony, korzystając z akumulatora 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ładne wewnętrzne zegary. Systemy operacyjne musiały odwoływać się do RTC podczas uruchamiania, a użytkownik musiał ręcznie ustawić czas systemowy za pomocą sprzętowego interfejsu konfiguracji BIOS, aby upewnić się, że jest on poprawny.
Zegary sprzętowe nie rozumieją pojęcia stref czasowych; w RTC przechowywany jest tylko czas, a nie strefa czasowa ani przesunięcie od UTC (Czasu Uniwersalnego Koordynowanego, który jest także znany jako GMT lub średni czas Greenwich). Możesz ustawić RTC za pomocą narzędzia, o którym opowiem później w tym artykule.
Czas systemowy to czas, który system operacyjny wyświetla na zegarze interfejsu GUI na twoim pulpicie, w danych wyjściowych polecenia date, w znacznikach czasowych dzienników. Odnosi się to również do czasu utworzenia, zmiany i otwierania plików.
Na stronie jest pełny opis RTC i zegarów systemowych.
Co słychać w NTP?
Komputery na całym świecie korzystają z NTP (Network Time Protocol) do synchronizacji swojego czasu z standardowymi czasami odniesienia przez Internet za pomocą hierarchii serwerów NTP. Główne serwery czasu znajdują się na poziomie 1 i są bezpośrednio połączone z różnymi krajowymi służbami czasu na poziomie 0 przez satelitę, radio lub nawet modemy na liniach telefonicznych. Służby czasu na poziomie 0 mogą być zegarami atomowymi, odbiornikami radiowymi dostrojonymi do sygnałów przesyłanych przez zegary atomowe lub odbiornikami GPS korzystającymi z wysoce dokładnych sygnałów czasu przesyłanych przez satelity GPS.
Na zdecydowanej większości standardowych serwerów otwartych jest kilka tysięcy publicznych serwerów NTP stratum 2, które są dostępne dla wszystkich. Wiele organizacji i użytkowników (w tym ja) z dużą liczbą hostów wymagających serwera NTP preferuje instalację własnych serwerów czasu, aby tylko jeden lokalny host łączył się z stratum 2 lub 3. Następnie konfigurują pozostałe węzły w sieci do korzystania z lokalnego serwera czasu. W przypadku mojej domowej sieci jest to serwer poziomu 3.
Różne realizacje NTP
Pierwotną realizacją NTP jest ntpd. Następnie dołączyły do niej dwie nowsze, chronyd i systemd-timesyncd. Wszystkie trzy synchronizują czas lokalnego hosta z serwerem czasu NTP. Serwis systemd-timesyncd nie jest tak niezawodny jak chronyd, ale wystarcza do większości celów. Jeśli RTC nie jest zsynchronizowany, może stopniowo korygować systemowy czas, aby synchronizować się z serwerem NTP, kiedy lokalny czas systemu jest trochę przesunięty. Usługa systemd-timesync nie może być używana jako serwer czasu.
to realizacja NTP, która zawiera dwa programy: demon chronyd i interfejs wiersza poleceń zwany chronyc. Chrony ma kilka funkcji, które w wielu przypadkach są po prostu niezbędne:
- Chrony może synchronizować się z serwerem czasu znacznie szybciej niż stary serwis ntpd. Jest to korzystne dla laptopów lub komputerów stacjonarnych, które nie działają cały czas.
- Może kompensować wahania częstotliwości zegara, na przykład, gdy host przechodzi w tryb uśpienia lub wchodzi w stan uśpienia, lub gdy częstotliwość zegara zmienia się z powodu skokowego zmniejszenia obciążenia, co spowalnia czas zegara przy niskich obciążeniach.
- Rozwiązuje problemy z czasem 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 zegarów. Zapewnia to stabilne i spójne interwały czasowe dla wielu usług systemowych i aplikacji.
- Chrony może działać nawet bez podłączenia do sieci. W takim przypadku lokalny host lub serwer można zaktualizować ręcznie.
- Chrony może działać jako serwer NTP.
Jeszcze raz: NTP to protokół, który może być zaimplementowany na hoście Linux z użyciem Chrony lub systemd-timesyncd.
Pakiety RPM NTP, Chrony i systemd-timesyncd są dostępne w standardowych repozytoriach Fedory. RPM systemd-udev to menedżer zdarzeń jądra, który w Fedorze jest domyślnie zainstalowany, ale nie jest obowiązkowy do użycia.
Możesz zainstalować wszystkie trzy i przełączać się między nimi, ale to stworzy dodatkowe problemy. Lepiej tego nie robić. Nowoczesne wydania Fedory, CentOS i RHEL przeszły na Chrony jako standardową implementację, a ponadto mają systemd-timesyncd. Uważam, że Chrony działa dobrze, zapewnia lepszy interfejs niż usługa NTP, dostarcza znacznie więcej informacji i zwiększa kontrolę, co bez wątpienia spodoba się administratorom systemów.
Wyłączanie usług NTP
Możliwe, że na Twoim hoście już działa usługa NTP. Jeśli tak, musisz ją wyłączyć przed przełączeniem się 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, którego używasz na swoim hoście:
[root@testvm1 ~]# systemctl disable chronyd ; systemctl stop chronyd
Usunięto /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 - Klient/serwer NTP
Załadowany: załadowano (/usr/lib/systemd/system/chronyd.service; wyłączony; domyślne ustawienia dostawcy: włączone)
Aktywny: nieaktywny (martwy)
Dokumenty: man:chronyd(8)
man:chrony.conf(5)
[root@testvm1 ~]#Sprawdzenie statusu przed uruchomieniem
Status synchronizacji czasu systemu pozwala określić, czy usługa NTP jest uruchomiona. Ponieważ jeszcze nie uruchomiłeś NTP, polecenie timesync-status zasugeruje to:
[root@testvm1 ~]# timedatectl timesync-status
Nie udało się zapytać serwera: Nie można aktywować zdalnego rówieśnika.Bezpośrednie zapytanie o status dostarcza ważne informacje. Na przykład polecenie timedatectl bez argumentów lub parametrów wykonuje domyślną podkomendę status:
[root@testvm1 ~]# timedatectl status
Czas lokalny: pt 2020-05-15 08:43:10 EDT
Czas uniwersalny: pt 2020-05-15 12:43:10 UTC
Czas RTC: pt 2020-05-15 08:43:08
Strefa czasowa: America/New_York (EDT, -0400)
Zegar systemowy zsynchronizowany: nie
Usługa NTP: nieaktywna
RTC w lokalnej strefie czasowej: tak
Ostrzeżenie: System jest skonfigurowany do odczytu czasu RTC w lokalnej strefie czasowej.
Ten tryb nie może być w pełni wspierany. Spowoduje to różne problemy
z zmianami stref czasu i regulacjami czasu letniego. Czas RTC
nigdy nie jest aktualizowany, polega na zewnętrznych urządzeniach do jego utrzymania.
Jeśli to możliwe, użyj RTC w UTC, wykonując
'timedatectl set-local-rtc 0'.
[root@testvm1 ~]#W ten sposób uzyskasz czas lokalny dla swojego hosta, czas UTC i czas RTC. W tym przypadku czas systemowy ustawiony jest na strefę czasową America/New_York (TZ), RTC jest ustawione na czas w lokalnej strefie czasowej, a usługa NTP nie jest aktywna. Czas RTC zaczyna się nieco odbiegać od czasu systemowego. To normalne dla systemów, których zegary nie były zsynchronizowane. Wartość odchylenia na hoście zależy od czasu, który minął od ostatniej synchronizacji systemu.
Otrzymaliśmy również ostrzeżenie o użyciu czasu lokalnego dla RTC — to odnosi się do zmian stref czasowych i ustawień czasu letniego. Jeśli komputer jest wyłączony w momencie, gdy konieczne jest wprowadzenie zmian, czas RTC nie zmieni się. Jednak dla serwerów lub innych hostów, które działają 24/7, to w ogóle nie jest problem. Co więcej, każda usługa zapewniająca synchronizację czasu NTP skoryguje czas hosta jeszcze na etapie uruchamiania, więc po zakończeniu uruchamiania czas znów stanie się prawidłowy.
Ustawienie strefy czasowej
Zazwyczaj podajesz strefę czasową podczas procedury instalacji i nie masz potrzeby jej później zmieniać. Jednak zdarzają się sytuacje, kiedy trzeba zmienić strefę czasową. Istnieje kilka narzędzi, które mogą pomóc. Aby określić lokalną strefę czasową, system Linux używa plików stref czasowych. Pliki te znajdują się w katalogu /usr/share/zoneinfo. Domyślnie dla mojej strefy czasowej system zapisuje to: /etc/ localtime -> ../usr/share/zoneinfo/America/New_York. Ale nie musisz znać takich szczegółów, aby zmienić strefę czasową.
Najważniejsze jest, aby znać oficjalną nazwę strefy czasowej dla twojej lokalizacji i odpowiednie polecenie. Powiedzmy, że chcesz zmienić strefę czasową na 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/HelsinkiTeraz możesz ustawić strefę czasową. Użyłem polecenia date, aby sprawdzić zmiany, ale możesz także użyć timedatectl:
[root@testvm2 ~]# date
Wto 19 Maj 2020 04:47:49 PM EDT
[root@testvm2 ~]# timedatectl set-timezone America/Los_Angeles
[root@testvm2 ~]# date
Wto 19 Maj 2020 01:48:23 PM PDT
[root@testvm2 ~]#Teraz możesz ponownie zmienić strefę czasową swojego hosta na czas lokalny.
systemd-timesyncd
Demon systemd timesync zapewnia implementację NTP, którą można łatwo zarządzać w kontekście systemd. Jest domyślnie instalowany w systemach Fedora i Ubuntu. Jednakże uruchamiany jest domyślnie tylko w Ubuntu. Nie jestem pewien co do innych dystrybucji. Możesz to sprawdzić sam:
[root@testvm1 ~]# systemctl status systemd-timesyncdKonfiguracja systemd-timesyncd
Plik konfiguracyjny dla systemd-timesyncd to /etc/systemd/timesyncd.conf. Jest to prosty plik z mniejszą liczbą włączonych opcji niż w starszych usługach NTP i chronyd. Oto zawartość tego pliku (bez dodatkowych zmian) na mojej maszynie wirtualnej z systemem 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=2048Jedyna sekcja, którą zawiera, poza komentarzami, to [Time]. Wszystkie pozostałe wiersze są zakomentowane. To są wartości domyślne, których nie trzeba zmieniać (jeśli nie ma ku temu powodów). Jeśli nie masz zdefiniowanego serwera czasu NTP w wierszu NTP =, domyślnie w systemie Fedora używany jest zapasowy serwer czasu Fedora. Zwykle dodaję swój serwer czasu:
NTP=myntpserverUruchamianie timesync
Uruchomić i aktywować systemd-timesyncd można w następujący sposób:
[root@testvm2 ~]# systemctl enable systemd-timesyncd.service
Utworzono dowiązanie symboliczne /etc/systemd/system/dbus-org.freedesktop.timesync1.service → /usr/lib/systemd/system/systemd-timesyncd.service.
Utworzono dowiązanie symboliczne /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
Tak wygląda sytuacja po uruchomieniu timesyncd:
[root@testvm2 systemd]# timedatectl
Czas lokalny: Sob 2020-05-16 14:34:54 EDT
Czas uniwersalny: Sob 2020-05-16 18:34:54 UTC
Czas RTC: Sob 2020-05-16 14:34:53
Strefa czasowa: America/New_York (EDT, -0400)
Zegar systemowy zsynchronizowany: tak
Usługa NTP: aktywna
RTC w lokalnej strefie czasowej: nie Początkowo różnica między RTC a czasem lokalnym (EDT) nie przekracza sekundy, a rozbieżność zwiększa się jeszcze o kilka sekund w ciągu następnych kilku dni. Ponieważ RTC nie ma pojęcia stref czasowych, polecenie timedatectl musi wykonać porównanie, aby określić potrzebną strefę czasową. Jeśli czas RTC nie jest dokładnie zgodny z czasem lokalnym, oznacza to, że nie jest zgodny również z lokalną strefą czasową.
W poszukiwaniu dodatkowych informacji sprawdziłem stan systemd-timesync i odkryłem to:
[root@testvm2 systemd]# systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Synchronizacja czasu sieciowego
Załadowany: załadowano (/usr/lib/systemd/system/systemd-timesyncd.service; włączony; domyślne ustawienia dostawcy: wyłączone)
Aktywny: aktywny (działający) od sob. 2020-05-16 13:56:53 EDT; 18h temu
Dokumenty: man:systemd-timesyncd.service(8)
Główny PID: 822 (systemd-timesyn)
Status: "Wstępna synchronizacja z serwerem czasu 163.237.218.19:123 (2.fedora.pool.ntp.org)."
Zadania: 2 (limit: 10365)
Pamięć: 2.8M
CPU: 476ms
CGroup: /system.slice/systemd-timesyncd.service
└─822 /usr/lib/systemd/systemd-timesyncd
Maj 16 09:57:24 testvm2.both.org systemd[1]: Rozpoczęcie synchronizacji czasu sieciowego...
Maj 16 09:57:24 testvm2.both.org systemd-timesyncd[822]: Czas zegara systemowego nie jest ustawiony lub cofnął się, przywracanie z zapisanej znacznej: sob. 2020-05-16 13:56:53 EDT
Maj 16 13:56:53 testvm2.both.org systemd[1]: Rozpoczęto synchronizację czasu sieciowego.
Maj 16 13:57:56 testvm2.both.org systemd-timesyncd[822]: Wstępna synchronizacja z serwerem czasu 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 jest ustawiony lub cofnął się. Usługa Timesync ustawia czas systemowy na podstawie znacznika czasu. Znaczniki czasu są obsługiwane przez demona timesync i są tworzone przy każdej udanej synchronizacji.
Polecenie timedatectl nie ma możliwości pobrania wartości zegarów sprzętowych z zegarów systemowych. Może ustawić czas i datę tylko na podstawie wartości wprowadzonej w wierszu polecenia. Możesz ustawić RTC na tę samą wartość, co czas systemowy, używając polecenia hwclock:
[root@testvm2 ~]# /sbin/hwclock --systohc --localtime
[root@testvm2 ~]# timedatectl
Czas lokalny: pon. 2020-05-18 13:56:46 EDT
Czas uniwersalny: pon. 2020-05-18 17:56:46 UTC
Czas RTC: pon. 2020-05-18 13:56:46
Strefa czasowa: America/New_York (EDT, -0400)
Synchronizacja zegara systemowego: tak
Usługa NTP: aktywna
RTC w lokalnej strefie czasowej: takOpcja —localtime oznacza, że zegary sprzętowe wskazują czas lokalny, a nie UTC.
Dlaczego w ogóle potrzebujesz RTC?
Każda implementacja NTP ustawi zegary systemowe w momencie uruchomienia. A po co wtedy RTC? To nie do końca tak: stanie się to tylko wtedy, gdy będziesz mieć połączenie sieciowe z serwerem czasu. Jednak wiele systemów nie ma stałego dostępu do połączenia sieciowego, dlatego zegary sprzętowe są przydatne, aby Linux mógł ustawić czas systemowy na ich podstawie. To lepsze niż ręczne ustawianie czasu, nawet jeśli może on odbiegać od rzeczywistego czasu.
Podsumowanie
W tym artykule omówiono niektóre narzędzia do zarządzania datą, czasem i strefami czasowymi. Narzędzie systemd-timesyncd zapewnia klienta NTP, który może synchronizować czas na lokalnym hoście 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 - na przykład Chrony, aby działał jako serwer.
Preferuję mieć jedną implementację dla jakichkolwiek usług w mojej sieci, dlatego używam Chrony. Jeśli nie potrzebujesz lokalnego serwera NTP lub jeśli nie masz nic przeciwko używaniu Chrony jako serwera i systemd-timesyncd jako klienta SNTP. Nie ma potrzeby korzystania z dodatkowych możliwości Chrony jako klienta, jeśli odpowiada ci funkcjonalność systemd-timesyncd.
Jeszcze jedna uwaga: nie musisz korzystać z narzędzi systemd do implementacji NTP. Możesz użyć starszej wersji ntpd, Chrony lub innej implementacji NTP. Systemd składa się z wielu usług; wiele z nich jest opcjonalnych, więc można je wyłączyć i użyć czegoś innego. To nie jest olbrzymi monolit. Można nie lubić systemd lub jego części, ale musisz podjąć uzasadnioną decyzję.
Podoba mi się implementacja NTP w systemd, ale wolę Chrony, ponieważ lepiej odpowiada moim potrzebom. To Linux, dziecinko -)
Reklama
VDSina oferuje , ogromny wybór systemów operacyjnych do automatycznej instalacji, możliwość zainstalowania dowolnego OS z własnego , wygodne własnej produkcji i płatność dzienna. Przypominamy, że mamy wieczne serwery, które naprawdę nie podlegają czasowi 😉
Źródło: habr.com
