Wskazówka Unix: Polecenia NTP

ITworld.com – Wyślij swoje pytania dotyczące systemu Unix już dziś!

Zobacz dodatkowe porady i wskazówki dotyczące systemu Unix

W zeszłotygodniowej kolumnie przedstawiliśmy NTP, Network Time Protocol i koncepcję bardzo dokładnego pomiaru czasu. Chociaż istnieją liczne polecenia pomagające administratorom systemów w utrzymaniu w miarę dokładnego czasu w systemach, którymi zarządzają, te najbardziej oczywiste są bardzo ograniczone. W rezultacie, większość sieci cierpi z powodu dużych rozbieżności w czasie systemowym. Różnice czasowe takie jak te pokazane poniżej (wzięte z rzeczywistej sieci) nie są rzadkością:

host01: Thu Oct 14 10:50:23 EDT 2004

host02: Thu Oct 14 10:43:53 EDT 2004

host03: Thu Oct 14 10:41:52 EDT 2004

host04: Thu Oct 14 10:50:13 EDT 2004

host05: Thu Oct 14 10:33:59 EDT 2004

host06: Thu Oct 14 14:48:17 GMT 2004

host07: Thu Oct 14 10:52:04 EDT 2004 *

host08: Thu Oct 14 10:52:33 EDT 2004

host09: Thu Oct 14 10:49:55 EDT 2004

host10: Thu Oct 14 10:33:20 EDT 2004 *

host11: Thu Oct 14 10:51:22 EDT 2004

Tylko w obrębie tych jedenastu sekwencyjnie ankietowanych systemów, możemy zauważyć znaczną zmienność w raportowanym czasie. Podczas gdy sondaże odbywały się na przestrzeni kilku sekund, różnice czasowe są znacznie większe niż kilka sekund. W rzeczywistości różnica między najwcześniejszym a najpóźniejszym zgłoszonym czasem wynosi 18 minut i 44 sekundy. Gdybyśmy przepytali całą sieć, różnica między najwcześniejszym a najpóźniejszym zgłoszonym czasem byłaby jeszcze większa.

Aby zmusić systemy takie jak te do zbliżenia się do siebie w czasie, administrator systemu może użyć jednego z wielu poleceń, z różnym skutkiem.

Komenda date

Komenda date, która pozwala administratorowi systemu ustawić datę i czas, jest najbardziej oczywistym poleceniem korygującym czas w systemie, ale zależy od tego, czy administrator ma dość dokładne odniesienie do czasu. To polecenie jest również uruchamiane dla jednego systemu na raz. Używając polecenia date do zsynchronizowania dwóch systemów, administrator nie ma szans na uzyskanie czasów systemowych bliższych niż kilka sekund od siebie. Polecenie date zdecydowanie nie jest poleceniem z wyboru, gdy synchronizacja jest ważna. A w sieci z kilkuset systemami takie podejście może być zarówno żmudne, jak i niedokładne.

Gdyby administrator systemów wydał polecenie date w pętli takiej jak pokazana poniżej, czasy systemowe byłyby bliższe niż pokazane powyżej, ale nadal różniłyby się o tyle sekund, ile trwała pętla. I, oczywiście, to zróżnicowanie czasu będzie coraz bardziej znaczące, jeśli hasło musi być wpisane dla każdego polecenia ssh.

for host in `cat host_list`do ssh $host "date 10141045"done

Komenda date jest wyraźnie tylko minimalnie użyteczna w synchronizacji systemów. Zegary systemowe, które mają tendencję do zyskiwania lub tracenia czasu, nawet jeśli tylko na poziomie kilku sekund każdego dnia, szybko ponownie powiększą luki czasowe. Ponadto, systemy skonfigurowane dla innych stref czasowych — takie jak jeden system podający czas jako GMT na liście pokazanej powyżej, miałyby swoje zegary przesunięte o godziny, gdybyśmy użyli polecenia date, jak pokazano na rysunku.

Komenda rdate

Komenda rdate, znacznie lepszy wybór do synchronizacji zegarów w sieci, wymaga od administratora wybrania jednego systemu dostępnego dla jego sieci, przypuszczalnie takiego, który utrzymuje dość dokładny czas, aby użyć go jako odniesienia czasowego dla reszty.

Poniższa pętla przyniosłaby znacznie lepsze rezultaty niż ta pokazana powyżej. Po tym wszystkim, czas wymagany do zakończenia tej pętli nie będzie miał szkodliwego wpływu, ponieważ każde polecenie rdate będzie synchronizować się z czasem na serwerze referencyjnym, gdy to polecenie jest uruchamiane.

for host in `cat host_list`do ssh $host "rdate timekeeper"done

Dodatkowo, polecenie rdate nie zastępuje strefy czasowej w systemie docelowym. Zamiast ustawiania czasu dosłownie na wartość, która jest podawana w wierszu poleceń, rdate żąda danych czasowych, które są niezależne od strefy czasowej. Innymi słowy, jeśli uruchomisz „rdate ” w systemie używającym GMT, czas w systemie GMT będzie ustawiony poprawnie.

Komenda rdate jest generalnie uruchamiana przy starcie systemu lub przez cron raz dziennie lub raz na godzinę, aby wyrównać zegary w systemach w sieci LAN. W porównaniu do niezdyscyplinowanych zegarów systemowych pokazanych wcześniej, jest to duża poprawa. Jednakże, z punktu widzenia każdego systemu, którego zegar jest resetowany za pomocą rdate, może się zdarzyć kilka bardzo niezwykłych rzeczy. Zegary mogą przeskakiwać do przodu lub do tyłu w czasie za każdym razem, gdy uruchamiana jest komenda rdate. Takie zachowanie może prowadzić do bardzo dziwnych interpretacji zdarzeń wrażliwych na czas.

Komendy NTP

NTP ma wyraźne zalety w stosunku do komend date i rdate. Po pierwsze, NTP zapewnia sposób na synchronizację zegarów systemowych z niezwykłą precyzją i płynne wprowadzanie wymaganych poprawek, unikając skoków w czasie, które często powodują polecenia takie jak rdate. Przyjrzyjmy się bliżej.

NTP dostarcza dwóch poleceń do regulacji czasu: polecenie ntpdate — które ustawia czas systemowy podobnie jak polecenie rdate (tzn, przez odwołanie się do zdalnego systemu w celu uzyskania aktualnego czasu) oraz demon NTP – ntpd lub xntpd – który zapewnia znacznie bardziej rozbudowany mechanizm dochodzenia do właściwego czasu i synchronizacji z nim.

Komenda ntpdate

Komenda ntpdate – zazwyczaj używana, podobnie jak komenda rdate, przy starcie systemu, na żądanie lub okresowo przez cron – synchronizuje czas na zasadzie „ad hoc” w podobny sposób jak rdate. Jednakże polecenie ntpdate ma dwie bardzo ważne zalety w stosunku do rdate.

Po pierwsze, ntpdate odwołuje się do serwera NTP, a nie tylko do niezawodnego czasomierza dostępnego w sieci. Ponieważ serwery NTP są zazwyczaj powiązane z hierarchią NTP (i ostatecznie z bardzo dokładnym zegarem atomowym), są one prawie gwarantowane jako bardziej precyzyjne niż jakikolwiek serwer, który po prostu ma dobry układ zegara.

Po drugie, ntpdate może zebrać pewną liczbę próbek czasu z wielu źródeł czasu (tj. wielu serwerów NTP), a następnie wybrać czas, który wydaje się najbardziej dokładny. Tak więc, nie tylko polecenie ntpdate odwołuje się do źródła czasu, które jest bardziej prawdopodobne, że jest dokładne niż te wybrane do użycia z rdate, ale odwołuje się do wielu takich systemów i stosuje wyrafinowany proces wyboru.

Komenda ntpdate może wyglądać tak:

# ntpdate 129.6.15.28

14 Oct 10:52:41 ntpdate: adjust time server 129.6.15.28 offset -0.003350 sec

W rzeczywistości, jeśli polecenie ntpdate jest zainstalowane w Twoim systemie (/usr/sbin/ntpdate w większości systemów Solaris), możesz spróbować właśnie teraz tego polecenia ntpdate. Serwer referencyjny w tym przykładzie to serwer NTP w NIST w Gaithersburgu w stanie Maryland.

Alternatywnie można spróbować wykonać polecenie ntpdate w następujący sposób:

# ntpdate 129.6.15.28 216.200.93.8 208.184.49.9

14 Oct 14:57:41 ntpdate: adjust time server 216.200.93.8 offset 0.015733 sec

W tym przypadku odpytywanych jest wiele serwerów NTP.

Demon NTP

Pomimo że polecenie ntpdate zapewnia poziom kontroli czasu, który jest o rząd wielkości lepszy niż rdate, demon NTP idzie o krok dalej niż ntpdate ze swoimi wyrafinowanymi algorytmami maksymalizującymi dokładność i niezawodność. Używany prawidłowo, demon NTP wykorzystuje również minimalną ilość zasobów sieciowych — zajmiemy się tą kwestią w następnym tygodniu.

Demon NTP dostarcza wyrafinowanych algorytmów, które płynnie synchronizują zegary systemowe poprzez proces kolejnych przybliżeń. Im dłużej demon działa, tym bardziej zbliża czas systemowy do czasu źródłowego. Dokonuje dużych korekt szybko, a następnie mniejszych korekt w czasie, aby uniknąć przekroczenia właściwego czasu.

Może to zająć NTP minut lub godzin, aby zbliżyć się do poziomu dokładności, ale gdy już to zrobi, wiarygodność czasu w systemie może być zdumiewająco dokładna. Jednak dokładność czasu NTP jest ostatecznie związana z dokładnością źródeł czasu, do których się odwołuje. Każdy serwer NTP próbuje zsynchronizować się z UTC (tj. uniwersalnym czasem koordynowanym) przy użyciu najlepszego dostępnego źródła czasu i ścieżki transmisji. Jeśli zestaw serwerów, do których się odwołuje, przesyła czasy, które nie są w bliskiej odległości od siebie, NTP uzna jeden lub więcej z tych serwerów czasu za uszkodzone i odrzuci je. Tak więc, aby uzyskać dokładny czas przy użyciu NTP, wybór serwerów czasu musi być dokładny.

Nowicjusze w dziedzinie NTP powinni zauważyć, że uruchomienie procesu demona NTP NIE musi koniecznie uczynić systemu serwerem NTP. O tym, czy system z obsługą NTP pełni rolę klienta czy serwera, decydują pliki konfiguracyjne demona w tym systemie – co przeanalizujemy w przyszłotygodniowej kolumnie.

Ten artykuł, „Unix Tip: Polecenia NTP” został pierwotnie opublikowany przez ITworld .