NTP/Chrony не поддерживает синхронизацию времени в CentOS 7.9 (VM, работающая на VMware ESXi)

У меня есть 3 сервера под управлением CentOS 7.9.2009 в центре обработки данных (VMware ESXi). Эти серверы сообщают, что время не синхронизировано. У меня есть аналогичная тестовая среда, работающая на собственном сервере VMware ESXi, где серверы синхронизируются. время Ок.Производственная среда изначально была настроена точно так же, но, очевидно, со временем обновлялась пакетными обновлениями. Так что они "должны" быть идентичными, но я больше не могу этого гарантировать. Оба сервера ESXi версии 6.

Первоначально серверы были настроены с использованием «ntpd», но при устранении этой проблемы за последние пару дней я обнаружил, что «Chrony» кажется лучшим выбором для CentOS 7. Поэтому я перенастроил серверы для использования Chrony, но все же есть проблема.

Изменить: шаги, используемые для перехода на Chrony

• ням установить хрони
• systemctl остановить ntpd
• systemctl отключить ntpd
• systemctl запустить хронид
• systemctl включить хронид

Поэтому, когда я использую timedatectl Я получаю этот вывод:

      Местное время: Пн 2021-08-02 09:14:43 CEST
  Всемирное время: пн 2021-08-02 07:14:43 UTC
        Время RTC: пн 2021-08-02 07:16:34
       Часовой пояс: Europe/Copenhagen (CEST, +0200)
     NTP включен: да
Синхронизация по NTP: нет
 RTC в местной ТЗ: нет
      Летнее время активно: да
 Последнее изменение летнего времени: летнее время началось в
                  Вс 2021-03-28 01:59:59 CET
                  Вс 2021-03-28 03:00:00 CEST
 Следующее изменение летнего времени: летнее время заканчивается (часы переходят на один час назад) в
                  Вс 2021-10-31 02:59:59 CEST
                  Вс 2021-10-31 02:00:00 CET

Если я перезапущу Chrony с помощью systemctl перезапустить хронид потом через пару секунд timedatectl отчеты:

      Местное время: Пн 2021-08-02 09:26:06 CEST
  Всемирное время: пн 2021-08-02 07:26:06 UTC
        Время RTC: пн 2021-08-02 07:26:08
       Часовой пояс: Europe/Copenhagen (CEST, +0200)
     NTP включен: да
Синхронизация NTP: да
 RTC в местной ТЗ: нет
      Летнее время активно: да
 Последнее изменение летнего времени: летнее время началось в
                  Вс 2021-03-28 01:59:59 CET
                  Вс 2021-03-28 03:00:00 CEST
 Следующее изменение летнего времени: летнее время заканчивается (часы переходят на один час назад) в
                  Вс 2021-10-31 02:59:59 CEST
                  Вс 2021-10-31 02:00:00 CET

Через некоторое время (минуты) он возвращается к Синхронизация по NTP: нет.

Когда я бегу нтпстат Я получил:

синхронизирован с сервером NTP (217.198.219.102) на уровне 2
   время правильное с точностью до 124123 мс
   сервер опроса каждые 64 с

или же

несинхронизированный
интервал опроса неизвестен

В последнем случае через некоторое время он снова покажет первый вывод. Но "в пределах ... мс" кажется довольно высоким???

Поскольку я могу синхронизировать его, перезапустив Chrony, я думаю, что брандмауэр / сеть в порядке. Я использую конфигурацию Chrony по умолчанию (как раньше делал с ntpd).

Служба VMwaretools установлена ​​и запущена (open-vm-tools, http://github.com/vmware/open-vm-tools).

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

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

/Джон

Я думаю, что я решил это сейчас.

По сути, Хрони подумал, что время слишком сильно разнится. Итак, следуя ссылке Питера Розенберга (и ресурсам, на которые она ссылалась), я попал на трассу....

Я разместил эту информацию здесь на случай, если кто-то еще ее ищет.

Первыми шагами в этом процессе был статус от сервиса chronyd:

статус systemctl хронид
▪ chronyd.service — клиент/сервер NTP
   Загружено: загружено (/usr/lib/systemd/system/chronyd.service; включено; предустановка поставщика: включена)
   Активно: активно (работает) с понедельника 02.08.2021 22:23:39 CEST; 10 часов назад
     Документы: мужчина:хронид(8)
           мужчина: chrony.conf(5)
  Процесс: 24758 ExecStartPost=/usr/libexec/chrony-helper update-daemon (code=exited, status=0/SUCCESS)
  Процесс: 24754 ExecStart=/usr/sbin/chronyd $OPTIONS (код=выход, статус=0/УСПЕХ)
 Основной PID: 24756 (хронид)
   CGroup: /system.slice/chronyd.service
           ââ24756 /usr/sbin/хронид

03 августа, 08:41:24 db1.aqua.dtu.dk chronyd[24756]: выбранный источник 162.159.200.1
03 августа, 08:41:24 db1.aqua.dtu.dk chronyd[24756]: системные часы ошиблись на 5,118732 секунды, настройка началась
03 августа, 08:41:26 db1.aqua.dtu.dk chronyd[24756]: Не удается синхронизировать: нет большинства
03 августа, 08:41:33 db1.aqua.dtu.dk chronyd[24756]: выбранный источник 162.159.200.123
03 августа, 08:41:33 db1.aqua.dtu.dk chronyd[24756]: системные часы ошиблись на 1,761045 секунды, настройка началась
03 августа, 08:42:29 db1.aqua.dtu.dk chronyd[24756]: Не удается синхронизировать: нет большинства
03 августа, 08:42:30 db1.aqua.dtu.dk chronyd[24756]: выбранный источник 192.36.143.130
03 августа, 08:42:30 db1.aqua.dtu.dk chronyd[24756]: системные часы ошиблись на 4,500188 секунды, настройка началась
03 августа, 08:43:34 db1.aqua.dtu.dk chronyd[24756]: системные часы ошиблись на 4,842190 секунд, настройка началась
03 августа, 08:44:39 db1.aqua.dtu.dk chronyd[24756]: не удается синхронизировать: нет выбираемых источников

Это ясно показало, что что-то не так. Итак, следующим шагом было:

хронические источники -v
210 Количество источников = 4

  .-- Режим источника '^' = сервер, '=' = партнер, '#' = локальные часы.
 / .- Исходное состояние '*' = текущая синхронизация, '+' = комбинированное, '-' = не комбинированное,
| / '?' = недоступен, 'x' = время может быть ошибочным, '~' = время слишком переменное.
|| .- xxxx [ гггг ] +/- zzzz
|| Регистр достижимости (восьмеричный) -. | xxxx = скорректированное смещение,
|| Log2 (интервал опроса) --. | | гггг = измеренное смещение,
|| \ | | zzzz = расчетная ошибка.
|| | | \
Имя MS/IP-адрес Stratum Poll Reach LastRx Последняя выборка               
================================================== ==============================
^~ time.cloudflare.com 3 6 377 1 -17,0 с[ -17,0 с] +/- 1318 мкс
^~ Time100.Stupi.SE 1 6 377 2 -16,9 с[ -16,9 с] +/- 4458 мкс
^~ time.cloudflare.com 3 6 377 53 -11,2 с[ -11,2 с] +/- 1306 мкс
^~ n1.taur.dk 1 6 377 60 -10,4 с[ -10,4 с] +/- 4964 мкс

Обратите внимание на время слишком изменчиво для всех серверов....

И хроническое отслеживание также показывает, что время вообще не выровнено:

Идентификатор ссылки: C0248F82 (Time100.Stupi.SE)
Слой: 2
Исходное время (UTC): вторник, 03 августа, 06:46:05 2021 г.
Системное время: 132,970306396 секунд медленнее времени NTP
Последнее смещение: -4,842189789 секунд
Среднеквадратичное смещение: 7,720179081 секунд
Частота: 63,104 ppm медленно
Остаточная частота: -81143,852 миллионных долей
Перекос: 90,130 частей на миллион
Корневая задержка: 0,008654756 секунд
Корневая дисперсия: 19,424978256 секунд
Интервал обновления: 58,2 секунды
Статус прыжка: нормальный

Еще немного почитав в ссылках на упомянутые статьи, я попытался настроить сделать шаг в /etc/chrony.conf файл для принудительного обновления. Я уже изменил серверы пула NTP, чтобы они были «ближе» к серверам приложений, поэтому файл конфигурации теперь выглядит так:

сервер 0.dk.pool.ntp.org iburst
сервер 1.dk.pool.ntp.org iburst
сервер 2.dk.pool.ntp.org iburst
сервер 3.dk.pool.ntp.org iburst
файл дрейфа /var/lib/chrony/drift
сделатьшаг 1 -1
rtcsync

Теперь он работает некоторое время и, кажется, синхронизирует время ;-)

РЕДАКТИРОВАТЬ:

Как указал Пол Гир, я не решил проблему... Время все еще шло.

С использованием /usr/bin/vmware-toolbox-cmd статус синхронизации времени Я обнаружил, что на рабочих серверах синхронизация времени с хостом ESXi была ВКЛЮЧЕНА (!!!). Я понятия не имею, как это произошло? Виртуальная машина, которую я изначально настроил и загрузил в центр обработки данных, не была включена.В любом случае, очевидно, он не должен синхронизироваться. время с хозяином.

Это довольно легко отключить, используя: /usr/bin/vmware-toolbox-cmd timesync отключить

И теперь у нас есть более реалистичные данные из хронические источники -v:

210 Количество источников = 4

  .-- Режим источника '^' = сервер, '=' = партнер, '#' = локальные часы.
 / .- Исходное состояние '*' = текущая синхронизация, '+' = комбинированное, '-' = не комбинированное,
| / '?' = недоступен, 'x' = время может быть ошибочным, '~' = время слишком переменное.
|| .- xxxx [ гггг ] +/- zzzz
|| Регистр достижимости (восьмеричный) -. | xxxx = скорректированное смещение,
|| Log2 (интервал опроса) --. | | гггг = измеренное смещение,
|| \ | | zzzz = расчетная ошибка.
|| | | \
Имя MS/IP-адрес Stratum Poll Reach LastRx Последняя выборка               
================================================== ==============================
^- sweetums.eng.tdc.net 2 7 377 36 +30us[ +30us] +/- 45мс
^* 77.68.139.83 1 7 377 92 -191 мкс[ -184 мкс] +/- 4742 мкс
^- 152.115.59.244 2 7 377 39 +99us[ +99us] +/- 31мс
^- pf.safe-con.dk 2 7 377 42 +359us[ +359us] +/- 29мс

а также хроническое отслеживание:

Идентификатор ссылки: 4D448B53 (77.68.139.83)
Слой: 2
Исходное время (UTC): вторник, 03 августа, 10:45:26 2021 г.
Системное время: на 0,000008465 секунд медленнее времени NTP
Последнее смещение: +0,000006720 секунд
Среднеквадратичное смещение: 7,358564854 секунды
Частота: 57,633 ppm медленно
Остаточная частота: +0,001 ppm
Перекос: 0,340 частей на миллион
Корневая задержка: 0,009058274 секунды
Корневая дисперсия: 0,000351956 секунд
Интервал обновления: 128,8 секунды
Статус прыжка: нормальный

Теперь он работает без сбоев в течение получаса, поэтому я уверен, что это решение. Спасибо за вклад!!!

Рассмотрите возможность использования минимальной настройки клиента, как предлагается здесь: https://www.golinuxcloud.com/configure-chrony-ntp-server-client-force-sync/ Когда достигается порог дрейфа, он отказывается от синхронизации, что, кажется, происходит с вами.