Zbliża się zmiana czasu UTC

Zbliża się zmiana czasu UTC

31 grudnia 2016 roku nastąpi zmiana światowego czasu UTC (Coordinated Universal Time). Czy spowoduje to awarie systemów IT, jak to było w przeszłości?

Zachęcamy do skorzystania z bezpłatnej prenumeraty
elektronicznej magazynu Computerworld!
Zabezpieczanie infrastruktury sieci i aplikacji

Zabezpieczanie infrastruktury sieci i aplikacji

Z kilku powodów największym zagrożeniem w nowoczesnej infrastrukturze sieci i aplikacji stały się aplikacje. Jednym z nich jest niezwykle szybki ich przyrost spowodowany coraz łatwiejszym ich opracowywaniem. W typowym środowisku biznesowym jest coraz więcej aplikacji, które dodatkowo...

Integracja bezpiecznego środowiska testowego z infrastrukturą zabezpieczeń

Integracja bezpiecznego środowiska testowego z infrastrukturą zabezpieczeń

W przypadku sprzętu komputerowego angielski termin „sandbox” od dawna oznaczał bezpieczne, odizolowane środowisko, w którym uruchamiano złośliwy kod w celu jego analizy. Zabezpieczenia sieciowe korzystają obecnie z tego rozwiązania — mogą bowiem wówczas emulować i analizować...

Zapora ISFW - ochrona przed propagacją zagrożeń i uszkodzeniami w sieci wewnętrznej

Zapora ISFW - ochrona przed propagacją zagrożeń i uszkodzeniami w sieci wewnętrznej

Liczba, zaawansowanie i oddziaływanie cyberataków stale się zwiększa. Z tego względu firmy i instytucje od dawna inwestują w mechanizmy ochrony granic sieci na różnych poziomach, aby uniemożliwiać przedostanie się zagrożeń zewnętrznych do infrastruktury wewnętrznej. Konieczne okazuje...

Jeśli ktoś o tym pamięta i jest przygotowany do zmiany czasu o jedną sekundę to nie będzie miał problemów podczas regulacji zaplanowanej na 31 grudnia 2016 roku.

Choć mogłoby się wydawać, że jedna sekunda to żaden problem, ale nie dla administratorów systemów IT, bo taka zmiana czasu może zagrażać stabilnej pracy systemów komputerowych i sieci. Wcześniejsze operacje dodawania nadmiarowej sekundy spowodowały awarie systemów m.in. firm LinkedIn, Reddit i Qantas (w 2012 roku), a ostatnia zmiana, 30 czerwca 2015 roku, według firmy analitycznej Dyn, wywołała awarię przynajmniej 2000 sieci na świecie.

Zobacz również:

Jak też przyznają przedstawiciele Google, zdarzały się sytuacje, gdy zmiany czasu UTC powodowały awarię niektórych systemów tej firmy, choć podkreślają, że bezpośrednio nie wpłynęło to na świadczone usługi.

Dokładna synchronizacja czasu ma krytyczne znaczenie dla prawidłowego działania wielu, zwłaszcza dużych systemów IT. Pozwala na zapewnienie, że repliki danych są aktualne, a kolejność operacji zależnych od czasu prawidłowa.

Niestety większość popularnych systemów operacyjnych nie ma mechanizmów umożliwiających automatyczną obsługę zmiany czasu UTC. W praktyce każdy administrator systemu musi ręcznie zaplanować w jaki sposób poradzić sobie z tym problemem.

Google udostępnia własne serwery NTP

Google udostępnił serwery NTP (Network Time Protocol) wszystkim użytkownikom co ma im ułatwić uniknięcie problemów związanych ze zmianą czasu UTC. Są one dostępne w ramach bezpłatnej usługi Google Public NTP Service. Użytkownicy mogą z niej skorzystać konfigurując ustawienia systemu sieciowego tak, by urządzenia, jako serwer NTP stosowały time.google.com. Google oferuje szczegółowe instrukcje, jak należy skonfigurować system

Użytkownicy korzystający z bibliotek Google API i maszyn wirtualnych wykorzystujących usługi Google Compute Engine powinni zapewnić synchronizację czasu z serwerami Google NTP. Dotyczy to również urządzeń klienckich współpracujących z serwerami.

Należy jednak pamiętać, że wszystkie urządzenia działające w systemie IT powinny korzystać z tego samego czasu i nie można dopuścić by jedne serwery były synchronizowane przy wykorzystaniu techniki rozmywania czasu, a inne zmiany skokowej.

Rozmywanie czasu

Od 2008 roku Google wykorzystuje technikę „rozmywania czasu” (smeared time) do łagodnej synchronizacji serwerów NTP ze zmianami czasu UTC. Ich zegary będą działać o 0,0014 procenta wolniej przez 10 godzin przed i 10 godzin po zmianie czasu UTC.

Z techniki tej korzysta nie tylko Google. Akamai będzie zwalniał bieg zegarów przez 24 godziny, a podobne rozwiązania stosują Amazon i Microsoft.

Wydaje się, że największe korporacje świadczące usługi chmurowe doprowadzą do tego, że 24-godzinne rozmywanie czasu stanie się standardem de facto. Google zapowiada, że najprawdopodobniej przy następnej zmianie czasu UTC, która jest przewidywana na rok 2018, również wydłuży czas synchronizacji.

Skąd ta sekunda?

Już od 1972 roku naukowcy od czasu do czasu dodają pojedyncze sekundy do najpopularniejszego systemu pomiaru czasu UTC (Coordinated Universal Time). Wynika to z tego, że szybkość obrotów naszej planety Ziemi systematycznie się zmniejsza (doba się wydłuża). Gdyby czasu nie regulowano, to w 2100 roku nastąpiłoby jego przesunięcie o jedną minutę, a za około 7000 lat zegary pokazywałyby południe o 12 w nocy.

Dopasowywaniem czasu atomowego do rzeczywistej prędkości obrotowej Ziemi zajmują się naukowcy z europejskiej organizacji International Earth Rotation Service, którzy na podstawie pomiarów określają kiedy należy dodać kolejną sekundę.

Ostatni dzień 2016 roku będzie miał 86 401 sekund, a nie standardowe 86 400. Oznacza to możliwość rozsynchronizowania i awarii niektórych systemów komputerowych.

Przesunięcia nie są regularne (sekundy są dodawane co 1-7 lat), bo zmiany tej prędkości nie są stabilne. Oznacza to, że trudno jest wprowadzić system regularnej korekty czasu podobny do „grubej” poprawki w przypadku której stworzono system lat przestępnych.

Od 1971 roku takich pojedynczych sekund dodano już 27 (pierwsza poprawka wynosiła 10 sekund). Wszystkie są zapisane w publikowanej tabeli, która niestety, według obecnych przewidywań, będzie się systematycznie, a jednocześnie nieregularnie powiększać.

Precyzyjna regulacja czasu ma znaczenie dla wielu systemów, których działanie wymaga dokładnego określenia czasu astronomicznego. Na przykład systemów satelitarnych lub takich, które wymagają precyzyjnego określenia kiedy słońce jest w zenicie czy też położenie gwiazd. Ale dla milionów serwerów i routerów działających na całym świecie ważne jest zdefiniowanie jednolitego, bieżącego czasu i jego synchronizacja, a nie dopasowanie do parametrów związanych z czasem astronomicznym.

Czas komputerowy

Czas w systemach komputerowych jest określany przez zliczanie sekund upływających od arbitralnie przyjętego momentu początkowego. W większości przypadków od północy (godziny 00:00) 1 stycznia 1970 roku, choć czasami wykorzystywane są inne daty, na przykład początek 1900 roku.

Czas przed taką bazową datą jest określany przez liczby ujemne.

Na podstawie liczby sekund, które upłynęły od czasu bazowego, system oblicza liczby minut, godzin, dni itd. i w efekcie określa bieżący czas i datę uwzględniając zmiany związane z latami przestępnymi (odpowiednie reguły są proste w implementacji).

Dla systemów komputerowych przesunięcia czasu są bardzo niewygodne, bo ich sprzętowe zegary i oprogramowanie zakładają, że każda minuta zawsze ma 60 sekund, godzina 60 minut, a doba 24 godziny.

Dodatkowo sekundy są dodawane o północy czasu UTC czyli w niektórych obszarach świata (np. W Azji lub zachodniej części USA) w środku biznesowego dnia.

Rekomendowaną metodą regulacji czasu jest zatrzymanie zegara na jedna sekundę. Niestety w przypadku komputerów nie jest to sposób praktyczny, bo powoduje że ta sama sekunda pojawia się dwukrotnie. Czasami powoduje to poważne problemy, na przykład w handlu na giełdach, gdzie w ciągu jednej sekundy można zyskać lub stracić fortunę.

Dlatego czasami stosowane jest odpowiednie wydłużanie czasu trwania każdej sekundy przez minuty, godziny lub dzień poprzedzający zmianę czasu. To także może wywołać problemy, bo operacja taka różnie wpływa na różne systemy komputerowe. A niestety nie ma jednego standardowego sposobu, który byłby stosowany przez wszystkie komputery i oprogramowanie. W efekcie niejednolitej implementacji pojawia się zagrożenie utraty synchronizacji między różnymi systemami i ich awarii.

Obecnie jest to szczególnie istotne w przypadku popularyzacji urządzeń IoT (Internet Rzeczy), które przesyłają do baz dane oznaczone odpowiednim stemplem czasowym. Nieregularne zmiany czasu UTC wymagają aktualizacji oprogramowania w takich urządzeniach co w praktyce jest trudne, a często niemożliwe do przeprowadzenia.

Propozycje rezygnacji z precyzyjnej regulacji czasu UTC

Pierwsze propozycje rezygnacji z tak skrupulatnej modyfikacji czasu pojawiły się w 2012 roku na konferencji WRC organizowanej co 3-4 lata przez ITU podczas której podejmowane są podstawowe decyzje dotyczące zasad regulacji dotyczących komunikacji radiowej, a w szczególności również definicji czasu UTC. Po przeprowadzeniu dyskusji, delegaci państw uczestniczących w konferencji zdecydowali, że decyzję w tej sprawie trzeba odłożyć do następnego spotkania w 2015 roku.

Gdyby wykorzystywany przez systemy informatyczne czas synchronizowany z UTC nie był modyfikowany, można by uniknąć wielu problemów związanych z synchronizacją systemów. Innym wyjściem byłoby przystosowanie oprogramowania, czyli wszystkich systemów operacyjnych, do obsługi modyfikacji czasu. Jest to jednak trudne zadanie, bo zmiany czasu nie są standardowo planowane, a wynikają z bieżących pomiarów i podejmowanych na ich podstawie decyzji. Oprócz tego wymagałoby to określenia standardu do którego dopasowali by się wszyscy dostawcy sprzętu i oprogramowania.

Niestety, podczas kolejnej konferencji w listopadzie 2015, okazało się, że niepewność pozostaje. Delegaci zdecydowali, że decyzja dotycząca rezygnacji ze skrupulatnej modyfikacji czasu UTC lub podjęcia innych środków zapobiegających problemom zostanie odłożona na osiem lat, a więc nie do kolejnej konferencji w 2019 roku, a do następnej planowanej dopiero na rok 2023. Uzasadnieniem było to, że trzeba zebrać więcej dowodów i analiz dotyczących znaczenia tego problemu.

W praktyce oznacza to, że przynajmniej przez kolejne 8 lat administratorzy systemów IT będą musieli sami radzić sobie z wpływem zmiany czasu na działanie zarządzanej przez nich infrastruktury.

Dla specjalistów, którzy się do tego nie przygotowali może to oznaczać problemy. Ale jeśli awarie się pojawią, dostarczy to delegatom na WRC-23 dodatkowych dowodów, że warto zrezygnować ze skrupulatnej regulacji czasu.

Dołącz do dyskusji
Bądź pierwszy i zostaw komentarz.