Каковы плюсы и минусы этих двух способов синхронизации вашего сервера?
Мне кажется, что ваш сервер, вероятно, не будет дрейфовать более чем на 1 секунду каждый день, поэтому ntpdate на crontab подойдет. Но я слышал, что здесь можно использовать избыточные серверы NTP.
http://www.pool.ntp.org/en/use.html
для поддержания синхронизированного времени в случае сбоя.
Есть ли у вас какие-либо предложения?
Алгоритм NTP включает информацию, которая позволяет вам рассчитать и исправить отклонение часов вашего сервера. NTPD включает возможность использовать это для синхронизации ваших часов и будет работать более точно, чем часы на компьютере, на котором не запущен NTPD. NTPD также будет использовать несколько серверов для повышения точности.
ntpdate не сохраняет состояние для выполнения этой услуги для вас, поэтому не будет обеспечивать такую же точность. Это позволит вам предоставить ему список серверов, которые он будет использовать, чтобы попытаться предоставить вам лучший результат, но это не заменяет сложные алгоритмы, представленные в NTPD, которые отслеживают ваш уход от каждого из серверов с течением времени.
NTPDATE мгновенно корректирует системное время, что может вызвать проблемы с некоторым программным обеспечением (например, уничтожение сеанса, который теперь кажется старым). NTPD намеренно медленно корректирует системное время, избегая этой проблемы. Вы можете добавить переключатель -g при запуске NTPD, чтобы позволить NTPD сделать первое обновление большого, что более или менее эквивалентно запуску ntpdate один раз перед запуском NTPD, что в свое время было рекомендованной практикой.
Что касается проблем безопасности, серверы ntp не подключаются обратно к неинициализированным соединениям, что означает, что ваш брандмауэр должен иметь возможность сообщать, что вы инициировали запрос ntp, и разрешать обратный трафик. Не должно быть необходимости оставлять порты открытыми для произвольных подключений, чтобы NTPD работал.
На странице руководства ntpdate (8):
ntpdate можно запустить вручную, если необходимо, чтобы установить часы хоста, или его можно запустить из сценария запуска хоста, чтобы установить часы во время загрузки. В некоторых случаях это полезно для первоначальной установки часов перед запуском демона NTP ntpd. Также можно запустить ntpdate из скрипта cron. Однако важно отметить, что ntpdate с надуманными сценариями cron не заменяет демона NTP, который использует сложные алгоритмы для максимальной точности и надежности при минимальном использовании ресурсов. Наконец, поскольку ntpdate не контролирует тактовую частоту хоста, как ntpd, точность использования ntpdate ограничена.
ntpd предпочтительнее, чем ntpdate, потому что вы получаете плавную коррекцию времени, а не скачки в ваших часах. Какой смысл вы придаете своим журналам, когда в них есть скачок во времени назад? ntpdate также будет прозрачно переключаться между серверами по мере необходимости.
Что касается требования открытых портов (как упомянул Кайл), более новые версии ntpd (например, 4.2.4 на моем сервере Debian) могут быть настроены для широковещательной / многоадресной передачи в локальную сеть с криптографической аутентификацией.
Изменить: см. Также этот вопрос.
Обычно я рекомендую вам запустить NTPD и синхронизировать свои серверы с назначенным сервером времени в вашей организации. Этот внутренний сервер обычно синхронизируется с одним из общедоступных серверов NTP (как вы связали).
Я без проблем использовал метод ntpdate, но он кажется более хакерским, чем запуск настоящего демона ntpd.
Я слышал о проблемах с перекосом часов на виртуальных машинах, на которых работает ntpd. Я также слышал о людях, исправляющих эту проблему, выполняя регулярные задания cron, которые вызывают ntpdate для нескольких серверов пула. У меня не было этих проблем, но я слышал о них несколько раз.
Как упоминалось в другом месте, NTP обеспечивает плавную временную коррекцию. Если приложения на вашем сервере не возражают против того, чтобы целые секунды пропадали, или повторяли те же секунды снова, тогда ntpd не сильно выиграет от ntpdate.
С другой стороны, если у вас есть приложения, чувствительные ко времени, которые чувствительны к секундам, или, что еще хуже, чувствительны к частям секунды, тогда ntpd - безусловно лучший выбор. Novell eDirectory отмечает обновления для обработки конфликтов обновлений, что становится критичным, если обновления приходят очень быстро (например, во время утренней спешки при входе в систему). Сервер системного журнала должен иметь время с точностью до полсекунды, чтобы вести нормальные журналы.
Для своего дома MythTV я замечаю, что это даже несколько секунд от времени, которое считает мой кабельный провайдер, поэтому я использую NTP для этого. Для сервера мониторинга ИБП на работе я использую crontabbed ntpdate по тем же причинам, которые указал Кайл Ходжсон: поскольку это хост-бастион, я не хочу, чтобы этот порт открывался, даже если я заблокировал приложение; для этого приложения быть вторым от истины не страшно.
Что касается избыточности, мы поддерживаем как минимум два временных хоста в нашей сети и направляем все наши внутренние хосты на эти два. Затем эти два отслеживают разные хосты NTP в Интернете. Более того, они сконфигурированы как одноранговые, так что они могут согласованно проводить время между собой, если наше интернет-соединение прерывается. Надежный NTP определенно можно спроектировать.
На сервере, где доступ и усиление защиты имеют решающее значение, я использовал рассуждение, что xntpd, версия ntpd, на которую я полагался, требует открытого UDP-порта 123. Поскольку я предпочитал открывать только tcp 22 и 80, я использовал ntpdate вместо этого в crontab. Я никогда не слышал веской причины, почему ему это было нужно, или ни одной, насколько я помню.
Одним из недостатков использования вызова ntpdate crontab является то, что он не может элегантно обрабатывать коррекцию смещения. ntpdate, iirc, обновляет часы, как только обнаруживает, что вы устарели - демоны ntp обычно аккуратно исправляют дрейф. Это дает преимущество в том, что ваши журналы поддерживаются в здравом уме - вы можете представить, например, на загруженном веб-сервере, что если бы RTC сместился на несколько минут, чтение веб-журналов на следующий день могло бы сделать вывод о том, что люди смогли подключиться к безопасному URL-адреса до того, как они вошли в систему, так как веб-обращения не будут работать.
ntpdate предназначен для разовых обновлений, если вы хотите, чтобы время регулярно синхронизировалось, используйте для этой цели службу ntpd.
Насколько я могу судить, нет веских причин не использовать ntpd
Вам не нужно использовать crontab, для этого нужен ntpd.
Первоначально, когда ваше время истекает, один из способов - просто остановить ntpd, а затем запустить ntpdate ntp.server.com чтобы вернуть его в синхронизацию, затем снова запустите ntp.
Если у вас большая сеть, я бы, вероятно, установил пару локальных серверов ntp и заставил все хосты использовать их.
Видеть это обсуждение для понимания того, почему "ntpdate" по-прежнему желателен и используется.
Подводя итог: ntpd - это медленный по сравнению с масштабной корректировкой времени, даже с параметром -g.
Для домашнего использования ntpdate не особо важен ... Есть причина, по которой он "медленнее". Любой, кто использует cron с ntpdate в среде PRODUCTION ENTERPRISE, просто идиот.