Я несколько раз читал (хотя сейчас не могу найти), что центры обработки данных прилагают большие усилия, чтобы убедиться, что все серверы имеют одинаковое время. Включая, но не ограничиваясь этим, беспокойство о дополнительных секундах.
Почему так важно, чтобы у серверов было одинаковое время? А каковы реальные допуски?
Как правило, временные метки используются в различных протоколах аутентификации, чтобы предотвратить повторные атаки, где злоумышленник может повторно использовать токен аутентификации, который он смог украсть (например, путем прослушивания сети).
Например, проверка подлинности Kerberos делает именно это. В версии Kerberos, используемой в Windows, допуск по умолчанию составляет 5 минут.
Это также используется различными протоколами одноразового пароля, используемыми для двухфакторной аутентификации, такими как Google Authenticator, RSA SecurID и т. Д. В этих случаях допуск обычно составляет около 30-60 секунд.
Без синхронизации времени между клиентом и сервером невозможно завершить аутентификацию. (Это ограничение снимается в новейших версиях MIT Kerberos, когда запрашивающая сторона и KDC определяют смещение между своими часами во время аутентификации, но эти изменения произошли после Windows Server 2012 R2, и пройдет некоторое время, прежде чем вы увидите это в Windows версия. Но некоторые реализации 2FA, вероятно, всегда будут нуждаться в синхронизированных часах.)
Синхронизация часов упрощает работу с разнородными системами. Например, сопоставление записей журнала с нескольких серверов намного проще, если все системы имеют одинаковое время. В этих случаях вы обычно можете работать с допуском в 1 секунду, который предоставит NTP, но в идеале вы хотите, чтобы время было максимально синхронизировано, насколько вы можете себе позволить. PTP, который обеспечивает гораздо более жесткие допуски, может быть намного дороже в реализации.
В основном это для того, чтобы вы могли соотносить инциденты из журналов на разных устройствах. Предположим, у вас есть инцидент безопасности, когда кто-то обращается к вашей базе данных через ваш веб-сервер - вы хотите, чтобы метки времени на вашем брандмауэре, балансировщике нагрузки, вашем веб-сервере и сервере базы данных совпадали, чтобы вы могли найти журналы на каждом устройстве. которые имеют отношение к инциденту. В идеале вы хотите, чтобы все произошло в течение нескольких миллисекунд. И оно должно быть синхронизировано с фактическим внешним временем, чтобы вы также могли соотносить свои журналы со сторонними журналами, если в этом возникнет необходимость.
Это важно не только с точки зрения администрирования, но и синхронизация часов также важна с точки зрения корреляции на уровне приложений. Это зависит от того, как спроектировано решение, как запущенные приложения получают метку времени для любых транзакций, с которыми они могут работать. Я видел сбой проверки транзакции из-за того, что приложение, работающее на сервере со слишком большим смещением (в будущем составляло около 20 секунд), по сравнению с другими, с которыми оно взаимодействовало.
Также, если виртуализация, например, на сервере VMWare ESXi, и время виртуальной машины не синхронизировано с временем гипервизора, то действие, такое как vmotion, может повторно синхронизировать часы виртуальной машины с гипервизорами, что, в свою очередь, может привести к непредсказуемым результатам. если разница во времени достаточно велика.
Я не знаю, каковы какие-либо фактические допуски, потому что я думаю, что это во многом зависит от того, какой тип системы существует, но я думаю, что, вообще говоря, возможно, чтобы серверы в центре обработки данных имели смещение друг от друга менее одной секунды.
Поскольку вы упомянули дополнительные секунды, следует отметить, что они требуют особенно сложного обращения.
Обычно они добавляются путем ввода секунды как 23:59:60, это проблематично, если вы проверяете отметки времени как 0-59 для полей минут и секунд. Альтернатива повторению 23:59:59, чтобы сделать его продолжительностью 2 секунды, не намного лучше, поскольку это испортит все, что зависит от времени до уровня в секунду.
Некоторое время назад Google действительно предложил хорошее решение, которое, похоже, еще не получило широкого распространения. Их решение состояло в том, чтобы применить скачкообразное «размытие» и разделить изменение по периоду времени, при этом весь процесс управлялся сервером NTP. Oни опубликовал блог об этом еще в 2011 году, интересно прочитать и, кажется, имеет отношение к этому вопросу.
Всякий раз, когда задействованы временные метки, десинхронизированные устройства могут создавать логические несогласованности, например: A отправляет запрос B, а ответ B приходит с меткой времени, более ранней, чем у запроса, что, возможно, заставляет A игнорировать его.
Я согласен со всем изложенным выше. Я хочу подкинуть еще мысли
Некоторая база данных, такая как Кассендра во многом полагается на метку времени. Так обстоит дело с параллелизмом.
Другая временная метка полностью испортит базу данных.