Я прочитал несколько раз (хотя я не могу найти это прямо сейчас), что центры обработки данных прилагают большие усилия, чтобы обеспечить одинаковое время на всех серверах. Включая, но не ограничиваясь, беспокойство о високосных секундах.
Почему так важно, чтобы на серверах было одинаковое время? И каковы фактические допуски?
Ответы:
В общем, временные метки используются в различных протоколах аутентификации, чтобы помочь предотвратить атаки повторного воспроизведения , когда злоумышленник может повторно использовать токен аутентификации, который он смог украсть (например, путем прослушивания сети).
Аутентификация 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, а время виртуальной машины не синхронизировано с временем гипервизора, то такое действие, как vmotion, может повторно синхронизировать часы виртуальной машины с гипервизорами, что, в свою очередь, может привести к непредсказуемым результатам. если разница во времени достаточно велика.
Я не знаю, каковы фактические допуски, потому что я думаю, что это во многом зависит от того, какие системы существуют, но я думаю, что, вообще говоря, можно сохранить серверы в центре обработки данных с смещением менее одной секунды друг от друга.
Поскольку вы упомянули високосные секунды, следует отметить, что они требуют особенно сложного обращения.
Они обычно добавляются путем введения секунды как 23:59:60, это проблематично, если вы проверяете временные метки как 0-59 для полей минут и секунд. Альтернатива повторения 23:59:59, чтобы сделать его продолжительностью 2 секунды, не намного лучше, так как это может испортить все, что чувствительно ко времени до уровня в секунду.
Google на самом деле недавно нашел хорошее решение, которое, похоже, еще не получило широкого распространения. Их решение состояло в том, чтобы применить скачкообразное «размазывание» и разделить изменения по промежутку времени, причем весь процесс управляется NTP-сервером. Они опубликовали блог об этом еще в 2011 году, интересны для чтения и, похоже, имеют отношение к этому вопросу.
Всякий раз, когда используются временные метки, десинхронизированные устройства могут создавать логические несоответствия, такие как: A отправляет запрос B, а ответ B приходит с временной меткой, более ранней, чем у запроса, что может привести к тому, что A проигнорирует ее.
Я согласен со всем пунктом выше. Я хочу добавить больше мыслей.
Некоторые базы данных, такие как Cassendra, сильно зависят от метки времени . Вот как он справляется с параллелизмом.
Разные временные метки неизбежно испортят базу данных.