chrony vs. systemd-timesyncd - Jakie są różnice i przypadki użycia jako klienci NTP?

Jakoś, ale nie całkiem, bazując na starszym pytaniu „ntpd vs. systemd-timesyncd - Jak osiągnąć niezawodną synchronizację NTP?” , Chciałbym zapytać o różnice między chrony a systemd-timesyncd pod względem klienta NTP .

Wiem, że systemd-timesyncd jest mniej lub bardziej minimalną implementacją klienta NTP, podczas gdy Chrony to pełnoprawne rozwiązanie demona NTP, które zawiera klienta NTP.

Informacje o wersji ubuntu Bionic Beaver zawierają następujące informacje:

Dla prostej synchronizacji czasu system podstawowy jest już wyposażony w systemd-timesyncd. Chrony jest potrzebny tylko jako serwer czasu lub jeśli chcesz, aby reklamowana bardziej dokładna i wydajna synchronizacja.

Podoba mi się pomysł użycia minimalnie preinstalowanego narzędzia do wykonania zadania i jestem pewien, że systemd-timesyncd wykona zadanie dla moich przypadków użycia, nadal jestem ciekawy:

Jakie są prawdziwe różnice między nimi pod względem dokładności?
Jakie są różnice w wydajności?
Czego potrzebuje „nie prosta” synchronizacja czasu, czyli przypadki użycia dla chronicznego klienta NTP?

systemd ntp chrony

— wedi
źródło

Odpowiedzi:

Zapowiedź Systemd-timesyncd w Systemd pliku NEWS robi dobrą robotę wyjaśniając różnice pomiędzy tym programem w porównaniu z chrony i narzędzia podobnego. (moje podkreślenie):

Dodano nowego demona „systemd-timesyncd” do synchronizacji zegara systemowego w sieci. Implementuje klienta SNTP . W przeciwieństwie do implementacji NTP, takich jak chrony lub serwer referencyjny NTP, implementuje to tylko stronę klienta i nie przeszkadza w pełnej złożoności NTP, koncentrując się tylko na zapytaniach o czas z jednego zdalnego serwera i synchronizowanie z nim lokalnego zegara . O ile nie zamierzasz obsługiwać NTP klientom sieciowym lub chcesz łączyć się z lokalnymi zegarami sprzętowymi, ten prosty klient NTP powinien być bardziej niż odpowiedni dla większości instalacji. [...]

Ta konfiguracja jest częstym przypadkiem użycia większości hostów we flocie serwerów. Zwykle będą synchronizowane z lokalnymi serwerami NTP, które same są synchronizowane z wielu źródeł, w tym ewentualnie ze sprzętu. systemd-timesyncd próbuje zapewnić łatwe w użyciu rozwiązanie dla tego typowego przypadku użycia.

Próbujesz odpowiedzieć na twoje konkretne pytania:

Jakie są prawdziwe różnice między nimi pod względem dokładności?

Wierzę, że można uzyskać większą dokładność, uzyskując dane synchronizacji z wielu źródeł, co nie jest szczególnie obsługiwanym przypadkiem użycia dla systemd-timesyncd. Ale gdy używasz go do pobierania danych synchronizacji z centralnych serwerów NTP podłączonych do niezawodnej sieci wewnętrznej, używanie wielu źródeł nie jest tak istotne i uzyskujesz dobrą dokładność z jednego źródła.

Jeśli synchronizujesz swój serwer z zaufanym serwerem w sieci lokalnej i w tym samym centrum danych , różnica dokładności między NTP i SNTP będzie praktycznie nie istniała. NTP może brać pod uwagę RTT i dokonywać pomiaru czasu, ale nie jest to tak korzystne, gdy twój RTT jest naprawdę mały, jak w przypadku szybkiej sieci lokalnej i pobliskiej maszyny. Nie potrzebujesz również wielu źródeł, jeśli możesz zaufać temu, którego używasz.

Jakie są różnice w wydajności?

Uzyskiwanie synchronizacji z jednego źródła jest znacznie prostsze niż uzyskiwanie z wielu źródeł, ponieważ nie musisz podejmować decyzji, które źródła są lepsze od innych, i ewentualnie łączyć informacje z wielu źródeł. Algorytmy są znacznie prostsze i będą wymagały mniejszego obciążenia procesora w prostym przypadku.

Czego potrzebuje „nie prosta” synchronizacja czasu, czyli przypadki użycia dla chronicznego klienta NTP?

Zostało to rozwiązane w powyższym cytacie, ale w każdym razie są to przypadki użycia Chrony, które nie są objęte przez systemd-timesyncd:

działający serwer NTP (aby inne hosty mogły używać tego hosta jako źródła synchronizacji);
uzyskiwanie informacji o synchronizacji NTP z wielu źródeł (co jest ważne dla hostów otrzymujących te informacje z publicznych serwerów w Internecie); i
uzyskiwanie informacji o synchronizacji z lokalnego zegara, który zwykle wymaga specjalistycznego sprzętu, takiego jak urządzenia GPS, które mogą uzyskać dokładne informacje o czasie z satelitów.

Te przypadki użycia wymagają Chrony, NTTP lub podobnego.

— filbranden
źródło

Bardzo dziękuję za twoją wyszukaną odpowiedź i kciuki za konkretne odpowiedzi na moje pytania. Aby to rozwinąć: - - 1. Jaki jest rząd wielkości delty dokładności. Świadomość tego na pewno dodawałaby pewnej treści do podejmowania decyzji. Czy mówimy o 10 ^ -9 lub 10 ^ -1 sekundach? - - 2. Twoja odpowiedź na temat wydajności uczyniła mnie jeszcze bardziej pasjonującym: Czy - bluźnierczo - niektóre uśrednianie kilku liczb tak bardzo zwiększa obciążenie procesora, że musisz o tym wspomnieć w informacjach o wydaniu Ubuntu?

— śr.

@wedi: Dokładność timesyncd będzie zależeć głównie od serwera i sieci. Z jednym serwerem nie ma sposobu, aby stwierdzić, czy serwer zwraca fałszywe dane, więc musisz w pełni mu zaufać. (Maksymalny błąd z tego jest nieograniczony). Maksymalna dokładność, jaką możesz osiągnąć, zależy od fluktuacji sieci między tobą a serwerem (może to być kilka milisekund lub więcej).

— TooTea,

Dzięki, @TooTea! Dobrze. Widzę. Tak więc zwiększona dokładność wynika z używania więcej niż jednego źródła, a każda specjalna magiczna kronika działania z jednym źródłem może zostać zignorowana. Rozumiem: - - 1. Używanie pojedynczego serwera metadata.google.internal na instancji GCE => brak mierzalnej różnicy w dokładności (wykluczmy timemearing i in.) - - 2. Używanie trzech serwerów czasu o doskonałej reputacji na vm w jakiejś osiedlającej się firmie hostingowej => widzisz różnicę, ale nie „dużo” (cokolwiek to może być) - - 3. Korzystając z pool.ntp.org na raspi połączonej przez jakiegoś ISP => jesteś tak szczęśliwy, jak tylko może być Larry.

— śr.

Powiedziałbym poprawnie na wszystkich trzech @wedi. W szczególności (1), jeśli używasz serwera czasu w tej samej „sieci lokalnej”, co twój komputer i zasadniczo w tym samym centrum danych (bardzo niski rtt i bardzo niski jitter), korzyści z NTP i pomiaru czasu w porównaniu z SNTP, w odniesieniu do dokładności, będzie bardzo niski. Więc nie ma powodu, aby uruchamiać NTP (a nie SNTP) w tych przypadkach użycia!

— filbranden

@wedi Zaktualizowano odpowiedź, aby wyraźnie wspomnieć o korzystaniu z zaufanego serwera w sieci lokalnej.

— filbranden

Jak druga odpowiedź poprawnie stwierdza, chronyimplementuje NTP i systemd-timesyncdSNTP.

Z punktu widzenia klienta usług czasowych:

SNTP jest znacznie prostszym protokołem do wdrożenia;
NTP pozwala na stopniowe zwiększanie / poprawianie na czas. Jedną z głównych zalet NTP jest to, że bierze również pod uwagę RTT odpowiedzi, aby uzyskać dokładniejszy czas.

Od https://www.meinbergglobal.com/english/faq/faq_37.htm

Podczas gdy w pełni funkcjonalny serwer lub klient NTP osiąga bardzo wysoki poziom dokładności i unika tak gwałtownych kroków czasowych, jak to możliwe, stosując różne metody matematyczne i statystyczne oraz płynną regulację prędkości zegara, SNTP może być zalecane tylko dla prostych aplikacji, w których wymagania dotyczące dokładność i niezawodność nie są zbyt wymagające. Pomijając wartości dryfu i stosując uproszczone metody regulacji zegara systemowego (często proste stopniowanie czasu), SNTP osiąga jedynie niską jakość synchronizacji czasu w porównaniu z pełną implementacją NTP.

SNTP przyjmuje znacznie prostsze podejście. Wiele zawiłości algorytmu NTP zostało usuniętych. Zamiast skośnego czasu, wielu klientów SNTP robi krok w krok. Jest to przydatne w wielu aplikacjach, w których wymagany jest prosty znacznik czasu. Ponadto SNTP nie ma możliwości monitorowania i filtrowania wielu serwerów NTP. Często stosuje się proste podejście typu „round-robin”, w którym w przypadku awarii jednego serwera używany jest następny na liście

Od https://www.masterclock.com/company/masterclock-inc-blog/ntp-vs-sntp

NTP jest znacznie bardziej dokładny i precyzyjny niż SNTP, co czyni go de facto zwycięzcą w większości aplikacji dla przedsiębiorstw. Z drugiej strony, prostota SNTP sprawia, że jest bardziej odpowiedni dla takich rzeczy jak kamery IP, rejestratory DVR i niektóre przełączniki sieciowe. Tego rodzaju sprzętowi brakuje zasobów przetwarzania do obsługi bardziej złożonych protokołów, ale wraz ze wzrostem mocy podłączonych urządzeń może się to zmienić.

Jednym z głównych słabych punktów SNTP jest to, że nie można poprawić jego dokładności, pobierając czas z wielu źródeł, tak jak w przypadku Network Time Protocol.

Inną ważną kwestią, jaką widzę, są implementacje SNTP dające więcej problemów niż NTP w wirtualizacji, gdy zarówno hiperwizor, jak i demon NTP próbują zmienić czas VM. Zwłaszcza, że nie zgadzają się na czas z pewną błędną konfiguracją powoduje, że oba są aktywne, może to powodować duże problemy. (Chociaż kompetentni administratorzy systemu utrzymają aktywną tylko jedną metodę synchronizacji z czasem, może się zdarzyć, że obaj są aktywni przez błąd konfiguracji).

PS systemd-timesyncdnie powinien być zalecaną alternatywą, gdy nie jest używany systemd.

— Rui F. Ribeiro
źródło

To nie jest całkowicie oczywiste. Teoretycznie systemd-timesyncdprogram można uruchomić pod innym menedżerem usług. Dostarczam pakiet usług do uruchamiania go pod zestawem narzędzi nosh service-managerod 2018 roku. Brakowało Ci tego, że ludzie systemowi (na błąd Debiana # 812522) zachęcają usługi gości VirtualBox i inne osoby do jawnego konfliktu z systemd-timesyncdusługą, aby uniemożliwić jej użycie w maszynach wirtualnych.

— JdeBP,

@JdeBP Interesująca uwaga. Używam Debiana bez systemd.... Niemniej jednak vmtools timesync może i będzie wyłączone, i powinno być wyłączone na serwerach wykonujących usługi NTP (na przykład maszyny wirtualne serwerów NTP), a niektóre sysadminy synchronizują się z vmtools, inni podążają za dokumentami VmWare dotyczącymi wyłączania vmtools timesync (z których należy korzystać tylko wtedy, gdy wiesz, co robisz). Ten błąd nie jest liniowy do rozwiązania, a będzie to dodatkowy punkt konfiguracji, który będzie łatwo przeoczony przez osoby przestrzegające zaleceń VmWare dotyczących niestosowania vmtools timesync.

— Rui F Ribeiro

(edytuj moją odpowiedź na podstawie twojej uwagi, popełniłem jeden błąd w tym tekście na temat zarządzania vmtools vs (S) NTP i wyraźniej)

— Rui F Ribeiro

@wedi W przypadku VmWare synchronizację czasu z hypervisorem można wyłączyć zarówno w Vcenter, konfiguracji obrazu VM lub po stronie Linux. zobacz powiązane unix.stackexchange.com/questions/492487/ ... Zawsze robię to vmware-toolbox-cmd timesync disablena moich serwerach NTP, niezależnie od tego, czy faceci VmWare wyłączyli synchronizację czasu dla tych maszyn wirtualnych. (Ja też zazwyczaj wolę używać chrony jako klienta NTP)

— Rui F Ribeiro

Cieszę się, że wskazałeś możliwy wyścig synchronizacji czasu! Dobrze o tym pamiętać!

— śr.

chronynie jest formą widelca, ntpdale jest implementowany od zera. Implementuje tryby klienta i serwera pełnego protokołu NTPv4 ( RFC5905 ). Użytkownicy klasy korporacyjnej widzą trend z tradycyjnego ntpdna chronypodobny do Red Hat (RHEL 7 i nowsze) i SuSE (od SLES 15).

systemd-timesyncdimplementuj tylko tryb klienta protokołu SNTP ( RFC4330 ) . Dlatego złożone przypadki użycia nie są objęte . Na przykład SNTP nie może zwiększyć dokładności, pobierając czas z wielu źródeł, jak domyślnie NTP. W rezultacie nie może zapewnić tak wysokiej precyzji czasu jak .systemd-timesyncdsystemd-timesyncdchrony

— PT Huynh
źródło

Mmm Nie zauważyłem, że ktoś twierdzący, że chrony jest rozwidleniem, i wspomniałem w moim pytaniu, że chrony implementuje serwer i klienta, podczas gdy systemd-timesyncd jest tylko klientem. Dzięki za wzmiankę o odpowiednich RFC.

— śr.