Які плюси і мінуси між цими двома способами синхронізації вашого сервера?
Мені здається, що ваш сервер, ймовірно, не дрейфував би більше 1 секунди щодня, тому ntpdate на crontab було б добре. Але я чув, що ви можете тут використовувати зайві NTP-сервери
http://www.pool.ntp.org/uk/use.html
щоб підтримувати синхронізований час у разі відмови.
Чи є у вас якісь пропозиції?
Відповіді:
Алгоритм NTP включає інформацію, яка дозволяє обчислити та виправити дрейф у тактовій частоті вашого сервера. NTPD включає можливість використовувати це для синхронізації вашого годинника та працюватиме точніше, ніж годинник на комп'ютері, де не працює NTPD. NTPD також використовуватиме декілька серверів для підвищення точності.
ntpdate не дозволяє державі виконувати цю послугу для вас, тому не забезпечить точну точність. Це дозволить вам надати йому список серверів, які він використовуватиме, щоб спробувати забезпечити вам кращий результат, але це не замінить складні алгоритми, надані в NTPD, які відслідковують ваш дрейф з кожного з серверів протягом часу.
NTPDATE миттєво виправляє системний час, що може спричинити проблеми з деяким програмним забезпеченням (наприклад, знищити сеанс, який тепер видається старим). NTPD навмисно виправляє системний час повільно, уникаючи цієї проблеми. Ви можете додати комутатор -g під час запуску NTPD, щоб дозволити NTPD вперше оновити велике, що більш-менш еквівалентно запуску ntpdate один раз перед запуском NTPD, що свого часу було рекомендовано практикою.
Що стосується проблем безпеки, сервери ntp не підключаються назад по непосвяченим з'єднанням, а значить, ваш брандмауер повинен бути в змозі повідомити, що ви ініціювали запит ntp і дозволяти повертати трафік. Не потрібно залишати порти відкритими для довільних з'єднань для того, щоб NTPD працювала.
На сторінці чоловічої сторінки ntpdate (8):
ntpdate можна запустити вручну в міру необхідності для встановлення хост-годинника, або можна запустити з сценарію запуску хоста, щоб встановити годинник під час завантаження. Це корисно в деяких випадках, щоб спочатку встановити годинник перед запуском NTP-демон NTP. Можливо також запустити ntpdate із скрипту cron. Однак важливо відзначити, що ntpdate з надуманими сценаріями cron не є заміною демону NTP, який використовує складні алгоритми для максимальної точності та надійності при мінімізації використання ресурсів. Нарешті, оскільки ntpdate не дисциплінує тактову частоту хоста, як ntpd, точність використання ntpdate обмежена.
ntpd віддається перевагу перед ntpdate, тому що ви отримуєте плавне виправлення часу, а не стрибки у вашому годиннику. Який сенс ви маєте для своїх журналів, коли в них відбувається зворотний стрибок часу? При необхідності ntpdate також прозоро переключатиметься між серверами.
Що стосується того, щоб вимагати відкритих портів (як згадував Kyle), новіші версії ntpd (наприклад, 4.2.4 на моєму сервері Debian) можуть бути налаштовані для трансляції / багатоадресної передачі в локальну мережу з криптографічною автентифікацією.
Редагувати: див. Також це питання .
Я, як правило, рекомендую запускати NTPD та синхронізувати свої сервери із призначеним сервером часу у вашій організації. Цей внутрішній сервер, як правило, синхронізується з одним із загальнодоступних серверів NTP (як ви пов’язані).
Я використовував метод ntpdate без жодних проблем, але він просто здається більш хакерським, ніж запуск справжнього демона ntpd.
Я чув про проблеми з перекосом годинника на віртуальних машинах під керуванням ntpd. Я також чув, як люди виправляють цю проблему, виконуючи регулярні завдання cron, які викликають ntpdate на кількох серверах пулу. У мене не було цих проблем, але я чув про них кілька разів.
Як було зазначено в іншому місці, NTP забезпечує плавну корекцію часу. Якщо програми на вашому сервері не заперечують пропадати цілі секунди або робити ті ж секунди заново, то ntpd не надто прискорить вас за ntpdate.
Якщо, з іншого боку, у вас є чутливі до часу програми, чутливі до секунд, або ще гірше, вони чутливі до часткових секунд, то ntpd - це набагато кращий вибір. Оновлення часових міток Novell eDirectory для обробки та зіткнення оновлень, що стає критичним, якщо оновлення надходять дуже швидко (наприклад, під час ранкового входу в систему). Сервер syslog повинен мати час з точністю принаймні до половини секунди, щоб зберігати здорові журнали.
Удома MythTV я помічаю, що це навіть кілька секунд, ніж мій провайдер кабелів вважає час, тому я використовую NTP для цього. Для сервера монітора UPS на роботі я використовую ntpdate із затримкою клітини з тих же причин, на який вказував Кайл Ходжсон, оскільки це хост бастіону, я не хочу, щоб цей порт відкривався, навіть якщо я заблокував додаток; тому що ця програма є секундою від істинного, не страшно.
Що стосується надмірності, то ми підтримуємо принаймні два хости часу у нашій мережі та вказуємо всі наші внутрішні хости на ці два. Потім вони відслідковують різних хостів Інтернет-протоколів NTP. Більше того, вони налаштовані за допомогою програми Peer, щоб вони могли тримати час між собою консенсусом, якщо наше інтернет-посилання знизиться. Надійний NTP, безумовно, можливий для інженерів.
На сервері, де доступ і загартовування є критичними, я використовував міркування, що для xntpd, версії ntpd, на яку я покладався, потрібен відкритий порт UDP 123. Оскільки я вважав за краще відкрити лише tcp 22 і 80, я використовував ntpdate на кронтаб замість цього. Я ніколи не чув хорошої причини, чому це було потрібно, чи не той, який я пригадую.
Одним із мінусів використання виклику cntab'ed ntpdate є те, що він не може елегантно впоратися з корекцією дрейфу. ntpdate, iirc, оновлює годинник, як тільки виявить, що ви застаріли - ntp демони зазвичай обережно виправляють дрейф. Це має перевагу в тому, що ваші журнали зберігаються здоровими - ви можете уявити, наприклад, на зайнятому веб-сервері, що якщо RTC проїхав кілька хвилин, то читання веб-журналів наступного дня може зробити висновок, що люди зможуть захистити URL-адреси, перш ніж вони входили в систему, оскільки веб-звернення вийшли з ладу.
Вам не потрібно використовувати crontab, саме для цього ntpd.
Спочатку, коли ваш час закінчується, один із способів - просто зупинити ntpd, потім запустити, ntpdate ntp.server.comщоб повернути його синхронізовано, а потім запустити ntp знову.
Якщо у вас є велика мережа, я, мабуть, створив би пару локальних серверів ntp і змусив усіх хостів їх використовувати.
Дивіться цю дискусію, щоб зрозуміти, чому "ntpdate" все ще бажаний і використовується.
Підсумовуючи це: ntpd повільний у порівнянні під час масового регулювання часу, навіть із опцією -g.
Для домашнього використання ntpdate - це не велика особа. Є причина, що це "повільніше". Той, хто використовує cron з ntpdate у середовищі ВИРОБНИЧЕ ПІДПРИЄМСТВО, - просто ідіот.