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

Зачем мне нужен твик, чтобы заставить VMware ESXi 5 синхронизировать время с NTP-сервером Windows

Меня мучает, казалось бы, простая, но на самом деле неприятная проблема, поэтому я прошу помощи здесь.

Симптом

Я установил экземпляр VMware ESXi 5.1 внутри VMware Workstation, чтобы узнать о различных функциях ESXi. Позвольте мне называть это машиной vESXi. Моя проблема с запуском vESXi заключается в том, что каждый раз, когда я приостанавливаю vESXi на ночь и возобновляю его на следующий день, время vESXi отстает. То есть, если я приостановлю vESXi в 22:00 вчера вечером и возобновлю его сегодня утром, я увижу отчеты vESXi, что вчера вечером все еще было 22:00. Я знаю, что это нормально, потому что система ПК отслеживает время, считая прерывания аппаратного таймера. Итак, я решил, что vESXi будет использовать NTP для синхронизации с NTP-сервером. Мой NTP-сервер - это контроллер домена Windows Server 2003, работающий в том же сегменте локальной сети.

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

Вы можете предложить мне выключить vESXi, а не приостановить его, но мне очень нравится функция приостановки, предоставляемая VMware Workstation, которая работает очень быстро и плавно.

Вопросы

я прочел http://kb.vmware.com/kb/1035833 который предоставляет обходной путь (некоторые настройки, чтобы заставить его работать с сервером Windows NTP), но эта статья в KB создает больше затруднений при первом чтении. Более того, очень громоздко настраивать каждый vESXi, если у меня их довольно много.

Q1 (первичный): Что, черт возьми, означают эти утверждения?

По умолчанию несинхронизированный сервер Windows выбирает 10-секундную дисперсию и добавляет к дисперсии на каждом интервале опроса, который остается синхронизированным. Хост ESXi / ESX по умолчанию не принимает никаких ответов NTP с корневая дисперсия более 1,5 секунды.

Q2: KB говорит мне добавить

tos maxdist 30

к /etc/ntp.conf . Что означает эта линия? Справочная страница ntpd.conf http://linux.die.net/man/5/ntp.conf кажется, ничего не говорит о tos или maxdist.

В3: Поскольку клиент (демон) NTP ESXi не синхронизируется с назначенным сервером NTP, генерирует ли ESXi какое-либо сообщение журнала, объясняющее детали?

Q4: Есть ли способ заставить клиента ntp ESXi немедленно синхронизироваться с определенным сервером NTP? Приветствуется даже ручное управление. Не знаю, есть ли в комплекте ntpd команда может это сделать.

Q5: без руководства /etc/ntp.conf настройте ESXi, какой тип NTP-сервера я могу настроить для предоставления источника времени для моего устройства vESXi? Linux ntpd что ли? требуется какая-либо специальная конфигурация на стороне сервера?

Заранее спасибо.

ОБНОВЛЕНИЕ ЭКСПЕРИМЕНТОВ

После прочтения NTP FAQ Проведя несколько экспериментов, я подтвердил следующие факты:

  1. Благодаря настройке KB1035833 vESXi действительно может синхронизироваться с моим NTP-сервером Windows, даже если время vESXi отстает от сервера на 7 дней (всего лишь 5-10 минут ожидания).
  2. Используя Viclient для назначения Linux-машины (openSUSE 11.4, ntp package 4.2.6 в моем случае) в моей локальной сети в качестве NTP-сервера, vESXi без настройки KB1035833 также может синхронизироваться с NTP-сервером только с задержкой от 5 до 10 минут. , даже с 7-дневным отставанием. Но я считаю, что я должен помнить о том, что мне нужно поставить галочку Перезапустите службу NTP, чтобы применить изменения. in viclient, чтобы ускорить синхронизацию времени (от 5 до 10 минут). Другими словами, если я не перезапущу службу NTP ESXi, будет довольно сложно предсказать, сколько времени потребуется, чтобы получить синхронизацию времени после возобновления vESXi с ночной задержкой (иногда это стоит один час или больше) - - вероятно, потому, что возобновленный клиентский код NTP считает джиттер времени сервера NTP неприемлемым в течение этого периода.

Итак: Моя практическая проблема с хронометражем для vESXi решена (я предпочитаю синхронизировать время с Linux NTP-сервером).

Теперь в центре внимания находится первый квартал. Что не так с NTP-сервером Windows? Я надеюсь, что кто-нибудь сможет объяснить эти два утверждения в первом квартале с точки зрения протокола NTP.

Выражаю благодарность quadruplebucky и Reality Extractor за их полезную информацию, хотя их ответы на мою конкретную проблему не совсем точны.

Если разница во времени слишком велика, NTP не будет синхронизироваться. Это ожидаемое поведение.

Обычно это не проблема, поскольку инструменты VMware, установленные в гостевой ОС, синхронизируют время с хостом независимо от того, насколько далеко ушло время. Поскольку вы используете экспериментальный и неподдерживаемый вариант для запуска ESXi в качестве виртуальной машины, вы не получаете функциональных возможностей VMware Tools и, следовательно, не синхронизируются.

Для tos maxdist вы можете просмотреть Параметры автоматической конфигурации NTP но это не решит вашу проблему, потому что время еще слишком далеко.

Это довольно извращенная установка, ESXi внутри VMWare Workstation. Снимаю перед вами шляпу.

NTPD не будет делать таких огромных корректировок времени, если он «думает», что работает (скажем, усыпляя). ESXi, к сожалению, похоже, не имеет двоичного файла ntpdate (который вы могли бы просто запускать через cron каждые полчаса или около того и полностью отключить ntpd).

Я заметил, что ntp имеет тенденцию исправляться, если вы останавливаете и запускаете службу (возможно, несколько раз).

Уродливый обходной путь, но, возможно, задание cron для остановки / запуска ntpd?

Вот ссылка на добавление заданий cron в ESXi

Команды для остановки и запуска:

/etc/init.d/ntpd stop
/etc/init.d/ntpd start

Я наконец понял это. Ключом к пониманию утверждений VMware KB в первом квартале является значение разброс. На самом деле это относится к Корневая дисперсия поле в пакете ответа NTP. Windows объявляет поле корневой дисперсии около 10 секунд, а Linux ntpd - около 0,01 секунды.

Я думаю, что Microsoft делает это намеренно и объявляет об этом в http://support.microsoft.com/kb/939322/en-us .

На изображении ниже показано 10-секундное поле дисперсии (снятое с помощью Microsoft Network Monitor 3.4).