Synchronizacja czasu na serwerze: logi bez NTP niewiele znaczą

Zegar serwera rozjeżdża się sam z siebie, powoli i bez żadnego komunikatu. Dopóki wszystko działa, nikt tego nie zauważa. Problem pojawia się w dniu, w którym musisz ułożyć zdarzenia z kilku maszyn w jedną oś czasu, a każda podaje inną godzinę.

Co psuje się, gdy czas się rozjedzie

Korelacja logów. Analiza incydentu polega na łączeniu zdarzeń z zapory, serwera aplikacji i bazy danych w jedną sekwencję. Jeśli zegary różnią się o kilka minut, kolejność przestaje być pewna, a wraz z nią wniosek o tym, co było przyczyną, a co skutkiem.

Kody jednorazowe. Uwierzytelnianie dwuskładnikowe oparte na kodach czasowych zakłada zgodność zegarów po obu stronach. Przy większym odchyleniu kody przestają działać i wygląda to na awarię aplikacji, a nie na problem z czasem.

Replikacja i rozproszone bazy. Mechanizmy rozstrzygania konfliktów i kolejność transakcji opierają się na znacznikach czasu. Rozjechany zegar potrafi wywołać błędy, których nie da się powtórzyć na żądanie.

Certyfikaty i sesje. Weryfikacja okresu ważności certyfikatu to porównanie z czasem lokalnym. Serwer z zegarem przestawionym w przód zacznie odrzucać połączenia jako wygasłe.

Znacznik czasu jako dowód

Wpis w logu jest wart tyle, ile jego znacznik czasu. Przy odtwarzaniu incydentu, rozliczeniu SLA albo pokazywaniu audytorowi, kiedy dokładnie nastąpiło zdarzenie, zapis z niezsynchronizowanej maszyny osłabia całą argumentację. Opisywaliśmy wcześniej, co się dzieje, gdy audytor prosi o logi sprzed pół roku. Retencja to jednak tylko połowa sprawy. Druga połowa to pewność, że zapisana godzina odpowiada rzeczywistości.

Do tego dochodzi kwestia strefy czasowej. Logi warto zapisywać w UTC, a przeliczać dopiero na etapie prezentacji. Inaczej dwa razy w roku, przy zmianie czasu, dostajesz w zapisach godzinę, która wystąpiła dwukrotnie, albo taką, której nie było wcale.

Jak ustawić to sensownie

Nowoczesne systemy mają wbudowaną usługę synchronizacji i zwykle wystarczy ją skonfigurować, a nie instalować cokolwiek dodatkowego. Kilka zasad, które robią różnicę:

• Wskaż co najmniej trzy niezależne źródła czasu, nie jedno. Pojedyncze źródło, które zacznie podawać błędną wartość, nie ma się z czym skonfrontować.
• W większej infrastrukturze postaw własny serwer czasu i skieruj do niego pozostałe maszyny. Wtedy nawet gdy całość odjedzie od czasu wzorcowego, pozostanie wewnętrznie spójna, a korelacja logów nadal będzie działać.
• Nie ustawiaj czasu skokowo na działającej produkcji. Nagłe cofnięcie zegara potrafi zdezorientować aplikacje i bazy. Usługi synchronizacji potrafią zamiast tego płynnie przyspieszać lub zwalniać zegar, aż odchylenie zniknie.
• Zadbaj o to, by ruch do serwerów czasu nie był blokowany przez zaporę. To częsta przyczyna sytuacji, w której usługa jest włączona, a synchronizacji nie ma.

Monitoruj odchylenie, nie tylko usługę

Sprawdzanie, czy usługa działa, nie wystarcza, bo może działać i nie synchronizować niczego. Monitorować trzeba samo odchylenie od źródła czasu i ustawić alarm na wartości, które zaczynają mieć znaczenie dla Twoich systemów.

Warto też sprawdzić serwery, o których nikt nie pamięta: maszyny wirtualne wznowione z migawki, sprzęt sieciowy, kontrolery zarządzania, urządzenia kontroli dostępu. To właśnie one najczęściej mają zegar z zupełnie innej epoki, a bywają źródłem zapisów potrzebnych w analizie.

Warstwa, za którą odpowiada centrum danych

Przy serwerze dedykowanym konfiguracja czasu w systemie operacyjnym jest po Twojej stronie, podobnie jak reszta warstwy systemowej. Dostawca odpowiada za to, by maszyna miała stabilne, ciągłe zasilanie i łączność, bez których żadna synchronizacja nie ma sensu. W kolokacji SDC zasilanie jest gwarantowane i dwutorowe, oparte o UPS i agregat prądotwórczy. Dostęp serwisowy działa w trybie 24/7/365 (źródło: sprintdatacenter.pl/kolokacja-serwerow-w-sdc).

Podsumowanie

Ustaw kilka niezależnych źródeł czasu, zapisuj logi w UTC i monitoruj odchylenie, a nie samą usługę. Koszt tej konfiguracji to kilkanaście minut. Koszt jej braku poznajesz dopiero przy pierwszej poważnej analizie incydentu.

Planujesz infrastrukturę, w której zdarzenia z wielu maszyn muszą się zgadzać co do sekundy? Napisz do nas albo zobacz ofertę serwerów dedykowanych.

FAQ – najczęściej zadawane pytania o synchronizację czasu

O ile realnie potrafi rozjechać się zegar serwera?

Zależy od sprzętu i obciążenia, ale dryf rzędu kilku sekund na dobę nie jest niczym niezwykłym. W skali miesiąca daje to różnicę, która wystarczy, by pomieszać kolejność zdarzeń między maszynami przy analizie incydentu.

Czy maszyny wirtualne wymagają osobnej uwagi?

Tak. Zegar maszyny wirtualnej bywa zależny od hosta, a wznowienie z migawki albo migracja potrafią cofnąć go o dowolną wartość. Warto sprawdzić, czy system gościa synchronizuje się niezależnie, czy ufa hostowi, i świadomie wybrać jedno z tych rozwiązań.

Czy trzeba stawiać własny serwer czasu?

Przy kilku maszynach zwykle nie. Przy kilkunastu i więcej własne źródło czasu upraszcza sprawę, bo cała infrastruktura pozostaje wewnętrznie spójna nawet przy problemach z łącznością na zewnątrz. To także mniejszy ruch wychodzący i jedno miejsce do kontroli.

Czy logi lepiej zapisywać w czasie lokalnym czy UTC?

W UTC. Czas lokalny zmienia się dwa razy w roku, przez co część znaczników staje się niejednoznaczna. Przeliczenie na czas lokalny należy robić przy wyświetlaniu, a nie przy zapisie.

Artykuł powstał z wykorzystaniem narzędzi sztucznej inteligencji (AI) pod nadzorem zespołu Sprint Data Center. Grafika ilustracyjna została wygenerowana przez AI.