Przeczytałem wiele razy (choć nie mogę tego teraz znaleźć), że centra danych dokładają wszelkich starań, aby zapewnić, że wszystkie serwery mają dokładnie ten sam czas. Obejmuje to między innymi martwienie się o sekundy przestępne.

Dlaczego tak ważne jest, aby serwery miały ten sam czas? A jakie są rzeczywiste tolerancje?

Bezpieczeństwo

Zasadniczo znaczniki czasu są używane w różnych protokołach uwierzytelniania, aby zapobiegać atakom polegającym na odtwarzaniu , w których atakujący może ponownie użyć tokena uwierzytelniającego, który był w stanie ukraść (np. Poprzez wąchanie sieci).

Uwierzytelnianie Kerberos robi to dokładnie, na przykład. W wersji Kerberos używanej w systemie Windows domyślna tolerancja wynosi 5 minut.

Jest to również wykorzystywane w różnych protokołach jednorazowych haseł używanych do uwierzytelniania dwuskładnikowego, takich jak Google Authenticator, RSA SecurID itp. W takich przypadkach tolerancja wynosi zwykle około 30–60 sekund.

Bez synchronizacji między klientem a serwerem nie byłoby możliwe zakończenie uwierzytelnienia. (To ograniczenie zostało usunięte w najnowszych wersjach MIT Kerberos, ponieważ requester i KDC określają przesunięcie między swoimi zegarami podczas uwierzytelniania, ale zmiany te nastąpiły po Windows Server 2012 R2 i minie trochę czasu, zanim zobaczysz to w Windows wersja. Jednak niektóre implementacje 2FA prawdopodobnie zawsze będą wymagać zsynchronizowanych zegarów.)

Podawanie

Synchronizacja zegarów ułatwia pracę z różnymi systemami. Na przykład korelowanie wpisów dziennika z wielu serwerów jest znacznie łatwiejsze, jeśli wszystkie systemy mają ten sam czas. W takich przypadkach zazwyczaj możesz pracować z tolerancją 1 sekundy, co zapewni NTP, ale idealnie chcesz, aby czasy były jak najbardziej zsynchronizowane, jak możesz sobie pozwolić. Wdrożenie PTP, które zapewnia znacznie ściślejsze tolerancje, może być znacznie droższe.

Przede wszystkim pozwala to na korelowanie incydentów z dzienników na różnych urządzeniach. Załóżmy, że masz incydent związany z bezpieczeństwem, w wyniku którego ktoś uzyskuje dostęp do Twojej bazy danych za pośrednictwem serwera WWW - chcesz, aby znaczniki czasu w zaporze ogniowej, moduł równoważenia obciążenia, serwer WWW i serwer bazy danych były do ​​siebie dopasowane, abyś mógł znaleźć dzienniki na każdym urządzeniu które dotyczą zdarzenia. Idealnie byłoby, gdyby wszystko było w ciągu kilku milisekund. I musi być zsynchronizowany z faktycznym czasem zewnętrznym, aby można było również skorelować dzienniki z dziennikami innych firm, jeśli będzie to konieczne.

Jest to ważne nie tylko z punktu widzenia administracji, ale także synchronizacja zegarów może być ważna również z poziomu korelacji na poziomie aplikacji. Zależy to od sposobu zaprojektowania rozwiązania, od tego, w jaki sposób uruchomione aplikacje otrzymują swój znacznik czasu dla wszystkich transakcji, z którymi mogą współpracować. Widziałem, że sprawdzanie poprawności transakcji nie powiodło się z powodu aplikacji działającej na serwerze ze zbyt dużym przesunięciem (w przyszłości było to około 20 sekund) w porównaniu z innymi, z którymi współpracował.

Również jeśli wirtualizacja na przykład na serwerze VMWare ESXi, a czas maszyny wirtualnej nie jest zsynchronizowany z czasem hiperwizora, wówczas działanie takie jak vmotion może ponownie zsynchronizować zegar maszyny wirtualnej z hiperwizorami, co z kolei może prowadzić do nieprzewidywalnych wyników jeśli różnica czasu jest wystarczająco duża.

Nie wiem, jakie są rzeczywiste tolerancje, ponieważ myślę, że zależy to w dużej mierze od rodzaju systemów, ale myślę, że ogólnie rzecz biorąc możliwe jest utrzymanie serwerów w centrum danych z przesunięciem między sobą mniej niż jedną sekundę.

Ponieważ wspomniałeś o sekundach przestępnych, należy zauważyć, że wymagają one szczególnie trudnej obsługi.

Zazwyczaj są one dodawane przez wstrzyknięcie sekundy jako 23:59:60, jest to problematyczne, jeśli sprawdzasz znaczniki czasu jako 0-59 dla pól minut i sekund. Alternatywa powtórzenia 23:59:59, aby uzyskać 2 sekundy, nie jest dużo lepsza, ponieważ zepsuje wszystko, co jest wrażliwe na czas do poziomu na sekundę.

Google już dawno wymyśliło dobre rozwiązanie, które wydaje się, że nie zostało jeszcze powszechnie przyjęte. Ich rozwiązaniem było zastosowanie skokowego „rozmazu” i podzielenie zmiany na pewien okres, przy czym cały proces jest zarządzany przez serwer NTP. W 2011 roku opublikowali blog na ten temat, który jest interesujący do czytania i wydaje się odpowiedni do tego pytania.

Ilekroć w grę wchodzą znaczniki czasu, niezsynchronizowane urządzenia mogą tworzyć logiczne niespójności, takie jak: A wysyła zapytanie do B, a odpowiedź B zawiera znacznik czasu wcześniejszy niż zapytanie, co może spowodować, że A go zignoruje.

Zgadzam się ze wszystkimi powyższymi punktami. Chcę rzucić więcej przemyśleń
Niektóre bazy danych, takie jak Cassendra, w dużej mierze polegają na znaczniku czasu . W ten sposób radzi sobie z współbieżnością.

Inny znacznik czasu całkowicie zepsuje bazę danych.