Я не раз читав (хоча зараз не можу знайти), що центри обробки даних докладають великих зусиль, щоб переконатися, що всі сервери мають точний час. Включаючи, але не обмежуючись, турбуватися про високосні секунди.
Чому так важливо, щоб сервери мали однаковий час? А які фактичні допуски?
Відповіді:
Як правило, часові позначки використовуються в різних протоколах аутентифікації для запобігання повторним атакам , коли зловмисник може повторно використовувати маркер аутентифікації, який він зміг викрасти (наприклад, обнюхуючи мережу).
Наприклад, автентифікація Kerberos робить саме це. У версії Kerberos, що використовується в Windows, допуск за замовчуванням становить 5 хвилин.
Це також використовується різними одноразовими протоколами паролів, які використовуються для двофакторної аутентифікації, таких як Google Authenticator, RSA SecurID тощо. У цих випадках допуск зазвичай становить близько 30-60 секунд.
Без синхронізації між клієнтом і сервером, неможливо було б завершити аутентифікацію. (Це обмеження видалено в новітніх версіях MIT Kerberos, за допомогою того, що запитувач і KDC визначають зсув між своїми годинами під час аутентифікації, але ці зміни відбулися після Windows Server 2012 R2, і ви побачите його в Windows протягом певного часу версія. Але для деяких реалізацій 2FA, ймовірно, завжди потрібні синхронізовані годинники.)
Синхронізація годин полегшує роботу з різними системами. Наприклад, співвіднесення записів журналу з декількох серверів набагато простіше, якщо всі системи мають однаковий час. У цих випадках зазвичай ви можете працювати з допуском 1 секунду, який надасть NTP, але в ідеалі ви хочете, щоб часи були настільки ж тісно синхронізовані, як ви можете собі дозволити. PTP, який забезпечує набагато більш жорсткі допуски, може бути набагато дорожчим для реалізації.
makeтакож плутається перекос годинника між клієнтом / сервером NFS.
Головним чином, це так, що ви можете співвідносити випадки з журналів на різних пристроях. Припустимо, у вас трапляється інцидент безпеки, коли хтось отримує доступ до вашої бази даних через ваш веб-сервер - ви хочете, щоб позначки часу на вашому брандмауері, вашому балансирі завантаження, веб-сервері та сервері баз даних збігалися, щоб ви могли знайти журнали на кожному пристрої які стосуються інциденту. В ідеалі ви хочете, щоб все було за кілька мілісекунд. І це повинно бути синхронізовано з фактичним зовнішнім часом, щоб ви могли також співвіднести свої журнали із сторонніми журналами, якщо це стане необхідним.
Це важливо не лише з точки зору адміністрації, але і синхронізація годин, важлива і для кореляції рівня додатків. Це залежить від того, як розроблено рішення, як запущені програми отримують часову позначку для будь-яких транзакцій, з якими вони можуть працювати. Я бачив помилку перевірки транзакцій через те, що програма, запущена на сервері із занадто великим зміщенням (становила приблизно 20 секунд у майбутньому) порівняно з іншими, з якими вона взаємоділа.
Крім того, якщо віртуалізація, наприклад, на сервері VMWare ESXi, і час VM не синхронізується з частотою гіпервізора, то така дія, як vmotion, може повторно синхронізувати годинник VM з гіпервізорами, а це, в свою чергу, може призвести до непередбачуваних результатів якщо різниця у часі досить велика.
Я не знаю, що таке фактичні допуски, тому що я думаю, що багато що залежить від того, який тип систем існує, але я вважаю, що загалом кажучи, доцільно тримати сервери в центрі обробки даних, які мають менше одного секунди зміщення між собою.
Оскільки ви згадали стрибкові секунди, слід зазначити, що вони вимагають особливо складних поводження.
Зазвичай вони додаються шляхом введення секунди як 23:59:60, це проблематично, якщо ви перевіряєте часові позначки як 0-59 для полів хвилин і секунд. Альтернатива повторення 23:59:59 зробити це на 2 секунди довше не набагато краще, оскільки це зіпсується з будь-чим, що чутливе до часу, до рівня секунди.
Google насправді придумав хороше рішення, яке, здається, ще не було широко прийняте. Їх рішенням було застосувати стрибковий "мазок" і розділити зміни за певний проміжок часу, усім процесом керував NTP-сервер. Вони опублікували блог про це ще в 2011 році, що цікаво читає і здається актуальним для цього питання.
Щоразу, коли задіяні часові позначки, десинхронізовані пристрої можуть створювати логічні невідповідності, наприклад: A надсилає запит до B, а відповідь B надходить із часовою позначкою раніше, ніж запит, можливо, викликаючи A, ігноруючи її.
Я згоден з усім пунктом вище. Я хочу кинути більше думок.
Деякі бази даних, такі як Кассендра, значною мірою покладаються на часовий штамп . Саме так вона має справу з одночасністю.
Різні часові позначки будуть суттєво зіпсувати базу даних.