Назад | Перейти на главную страницу

Как обеспечить или даже гарантировать правильную синхронизацию времени сервера между десятками серверов в нескольких центрах обработки данных в разных местах?

В настоящее время наши веб-приложения содержат логику для проверки того, истек ли срок действия данных, отправленных на веб-сервер, путем сравнения метки времени данных с датой / временем сервера.

Все идет, пока какой-нибудь чувак из центра обработки данных случайно не изменит дату / время одного из веб-сервера и не вызовет некоторые сбои в наших веб-сервисах. Мои менеджеры, конечно, недовольны этим, и сказали, что мы не должны использовать временную метку для проверки истечения срока действия ... в любом случае ....

Протокол сетевого времени реализован, поскольку центры обработки данных разбросаны по разным континентам, поэтому у нас есть один сервер NTP в каждом центре обработки данных. Серверы в центре обработки данных будут иметь задания cron для проверки времени с их сервером NTP из того же центра обработки данных. Если время не синхронизировано, он автоматически обновит дату / время сервера.

Но потом наши менеджеры недовольны этим и думают, что это может легко вызвать ту же проблему. например что, если кто-то случайно изменит дату / время NTP? что, если все серверы NTP не синхронизированы друг с другом? каким серверам NTP мы действительно можем доверять? и бла-бла ..

Итак, мои вопросы:

  1. Какова текущая практика синхронизации даты и времени между серверами в нескольких центрах обработки данных или местах?
  2. Как управлять отметкой времени между веб-приложениями? например Сервер A отправляет данные (содержащие метку времени сервера A) на сервер B (сравните метку времени между сервером B и метку времени из данных, чтобы увидеть, истек ли срок ее действия. Это необходимо для предотвращения воспроизведения HTTP)
  3. Разве мы действительно не должны использовать проверку отметок времени?

Спасибо и наилучшие пожелания

какой-то чувак из центра обработки данных случайно изменил дату / время одного из веб-серверов

Это твоя первая проблема. Скорее всего, это вызвано комбинацией:

  • "чувак [из] центра обработки данных" с недостаточной подготовкой и
  • Чрезмерно высокие привилегии

Для изменения системного времени требуются права администратора. Изменение времени вручную в системе, которая не только имеет правильное время, но и управляет временем с помощью NTP, является признаком недостаточного обучения. Сначала решите эту проблему, потому что, пока вы не решите ее, точное системное время, вероятно, будет наиболее заметной из ваших проблем. Что еще они делают в этой системе и почему?

Мои менеджеры ... сказали, что мы не должны использовать временную метку для проверки истечения срока действия

Если был предложен жизнеспособный альтернативный вариант, я бы хотя бы рассмотрел его. Почему-то я подозреваю, что это не так.

Протокол сетевого времени реализован, поскольку центры обработки данных разбросаны по разным континентам, поэтому у нас есть один сервер NTP в каждом центре обработки данных.

Я бы рекомендовал по два в каждом дата-центре. И я бы попросил, чтобы каждый из них ссылался на другой набор внешних серверов NTP, а также ссылался друг на друга. Это приведет к более стабильному времени и сделает вас более устойчивыми к единичным сбоям. Я также параноик и чрезмерно занимаюсь разработкой вещей, вот и все. Тем не менее, серверам NTP требуется примерно ноль ресурсов, поэтому запускайте их где угодно.

Серверы в центре обработки данных будут иметь задания cron для проверки времени с их сервером NTP из того же центра обработки данных. Если время не синхронизировано, дата и время сервера обновляются автоматически.

Это плохой план. Cron не имеет места для изменения времени в системе NTP. На серверах должны работать настоящие клиенты NTP. Каждый из этих клиентов должен ссылаться на (два) локальных сервера NTP.

Если вы хотите использовать cron, используйте cron на каждом сервере, чтобы убедиться, что сервер успешно синхронизирован с обоими локальными серверами NTP. Вы можете сделать это, изучив вывод команды ntpq. Вы должны узнать о выводе команды ntpq; это твой друг.

Чтобы ответить на вопросы, которые, по вашему мнению, возникли:

Но потом наши менеджеры недовольны этим и думают, что это может легко вызвать ту же проблему. например что, если кто-то случайно изменит дату / время NTP? что, если все серверы NTP не синхронизированы друг с другом? каким серверам NTP мы действительно можем доверять? и бла-бла ..

Первый вопрос не безумный. Немного параноик, если довести до крайности, но нормально. Ответы такие:

  • Использование более одного независимого опорного тактового сигнала. (одна ошибка будет проигнорирована, а не стабильное время из других источников)
  • Используйте надежные эталонные часы (например, GPS) (если ваши операторы могут случайно изменить время на спутнике GPS, у вас есть более серьезные проблемы, чем часы веб-сервера).
  • Используйте криптографические ключи, чтобы убедиться, что эталонные часы, с которыми вы общаетесь, являются теми, которым вы доверяете.

Второй решается путем настройки серверов NTP для ссылки друг на друга. Они будут стремиться сплотиться, при прочих равных. Также с помощью независимых надежных эталонных часов.

  • Если один из трех эталонных часов нижнего слоя не синхронизируется, он будет проигнорирован.
  • Если два сильно рассинхронизируются, они будут проигнорированы.
  • Если все три тактовых генератора сильно рассинхронизируются, NTP проигнорирует все три из них и сделает все, что в его силах (все равно неплохо, особенно если есть часы равного уровня, на которые он может ссылаться).
  • Здесь вам в основном нужно беспокоиться только о злонамеренной атаке.

Описать эти случаи может быть сложно, но NTP - это прежде всего стабильность и точность, если у нее есть точный источник.

Что касается доверия, у большинства людей, использующих общедоступный сервер NTP, нет причин мешать вашему времени. У многих из них есть причина указать точное время. Что касается уровня заинтересованности в предоставлении точного времени, я бы предложил:

  • Спутники GPS.
  • NTP-серверы NIST.
  • Любой известный провайдер уровня 1.
  • Любой известный провайдер уровня 2.
  • Ваш центр обработки данных (при условии, что вы приобрели хостинг), вероятно, должен иметь один или три собственных сервера NTP для их собственного использования, если нет другого.

Также, и это важно: NTP протокол предназначен для синхронизации времени с точностью до миллисекунд. Не секунды. Если вы используете cron + ntpdate, ваше время может отличаться на несколько секунд (спасибо переменной задержки!). NTP сделает ваши часы более стабильными и точными в подобных обстоятельствах.

Правильно настроенные NTP и GMT для всех серверов - лучшая практика. Есть главные серверы часов GPS, которые вы можете купить, если это крупная сделка, у вас есть деньги, и вы можете оправдать покупку по одному для каждого центра обработки данных. Это похоже на операционную проблему - они должны отслеживать время на серверах и предупреждать, если они значительно выходят из строя.