проблема с NTP после обновления UC до версии 15
-
Попробуйте использовать Chrony в качестве сервера времени вместо очень старого ntpd и убедитесь, что он указан в конфигурации. local stratum 2 Системы Cisco UC очень требовательны к уровню страты, с которым они взаимодействуют, и если сервер времени не предоставляет информацию об этом уровне, как, судя по логам, происходит в вашем случае, то система не будет работать. ![Response Signature]
-
В этой статье описывается, как настроить Chrony в качестве сервера времени в Raspberry-Pi.
https://conorrobinson.ie/raspberry-pi-ntp-server-part-2/ ![Response Signature] -
На прошлой неделе мы провели практически такое же обновление CER, с той разницей, что перешли на версию 15SU1a. Никаких проблем не возникло. На PCD мы обновили систему до версии FCS 15, а затем, когда вышла версия SU1, обновили ее до этой версии, но это было несколько месяцев назад. Никаких проблем не возникло. Какую версию ESXi вы используете и какую версию аппаратного обеспечения? ![Response Signature]
-
Я не совсем понимаю, что вы имеете в виду под вопросом «какую версию аппаратной совместимости вы используете?». Мы используем ESXi 7.0 U3 на устройстве BE7K M4. В первоначальном сообщении я действительно пропустил букву «a» в номере версии. Я выполнил обновление с версии v14su3 до версии v15su1a. На PCD работала версия FCS v14, и она была обновлена сразу до v15su1. Я должен был уточнить это в исходном сообщении. Когда я выполнял обновления из CLI и просматривал сообщения журнала, система зависала на довольно длительное время с выводом сообщения о NTP. В тот момент я не подумал об этом сделать запись. Завтра я должен получить ответ от TAC. Просто странно, что одно и то же произошло и на CER, и на PCD. Рад, что вы смогли выполнить тот же обновление без проблем, но я все еще ломаю голову над этим. Вы используете более новое оборудование и/или ESXi в своей среде?
-
Изначально мы использовали ту же версию ESXi, что и вы, но поскольку команда DC обновила хосты до v8u1, я думаю, не уверен в версии U. Наше оборудование, вероятно, немного новее вашего, и мы больше не используем оборудование Cisco, в прошлом году мы перешли на оборудование HPE для нашей инфраструктуры UC. В ESXi вы можете использовать разные версии совместимости на виртуальных машинах. Они отображаются в виде числа на виртуальных машинах, например, версия совместимости 19, которая соответствует ESXi 7u3, или 21, которая соответствует 8u1. Мы используем версию 19, даже если на хосте установлена более новая версия ESXi. Сейчас я в отпуске, поэтому не могу предоставить вам скриншот, на котором вы могли бы увидеть версию или обновить ее, но я уверен, что вы разберетесь. ![Response Signature]
-
В этом документе описывается процесс обновления версии совместимости на виртуальной машине.
Обновление совместимости виртуальной машины с помощью VMware Host Client ![Response Signature] -
TAC предложил удалить и повторно добавить сервер ntp. Для этого мне пришлось добавить другой сервер ntp, что удалось. Однако при повторном добавлении исходного сервера ntp произошла ошибка. Добавление дополнительного сервера ntp устранило проблему с несогласованными командами «utils ntp», и я смог остановить/запустить/перезапустить службу ntp. Это также устранило предупреждающее сообщение о недоступности ntp. NTP-сервер, работающий в этой тестовой среде, — это Raspberry Pi с ntpd. Он является источником времени для всего в тестовой среде и работает отлично. Я смог проанализировать некоторые журналы CER после того, как служба ntp фактически запустилась после добавления нового сервера ntp. При попытке добавить исходный сервер ntp проверка доступности вернула следующее сообщение: «Ответ для сервера NTP <x.x.x.x> не содержал информацию о стратуме. Ответ: 506 Невозможно связаться с демоном» в журналах. На сервере ntp ничего не изменилось, и «временный» сервер ntp, который я настроил, фактически использует исходный сервер ntp в качестве источника. Исходный сервер ntp также является источником для других 3 приложений UC (все работают под управлением 12.5), которые синхронизированы и функционируют с ним. Это странный результат, который, по-видимому, связан с тем, что v15 по какой-то причине не поддерживает службу raspberry pi ntpd.
@Roger Kallberg
, спасибо за ваши ответы, но, похоже, моя «проблема с обновлением ntp» является результатом моих собственных действий. Хотя, по-моему, это выходит за рамки данного форума. Я попробую продолжить устранение неполадки и посмотрю, смогу ли я восстановить связь между CER и pi, а также посмотрю, что TAC скажет о моих последних находках. -
Переход на chrony сработал! Обновленный сервер v15 позволил мне настроить исходный сервер ntp после перехода на использование chrony. Я также перестроил свой старый кластер v14 и восстановил резервные копии. При повторном обновлении до v15 никаких проблем (с базой данных или ntp) не возникло. TAC также подтвердил, что в версии 15 есть проблема с коммуникацией со службой ntpd в их лаборатории. Они получили те же результаты, что и я, при обновлении. Они передали эту информацию разработчикам и будут работать над обновлением документации, указывающей на несовместимость, пока проблема не будет решена.
@Roger Kallberg
, спасибо за помощь и особенно за ссылку по настройке chrony. Это был отличный ресурс. -
Привет, ребята, я не специалист по Linux, поэтому хотел бы узнать, есть ли у вас какие-нибудь полезные ссылки по настройке этого. Я установил Fedora и добавил к ней Chrony. Если Chrony настроен как NTP-сервер, нужно ли мне настраивать клиент, а затем использовать его в качестве NTP-сервера, или я использую сервер Chrony в качестве своего NTP-ресурса из CUCM?
-
Я тоже не специалист по Linux, но, насколько я знаю, в CUCM в качестве ресурса NTP используется сервер Chrony. ![Response Signature]
-
Привет, Роджер, спасибо за быстрый ответ.
-
Привет, Роджер, Тебе пришлось настраивать аутентификацию в cucm для NTP с Chrony? Все еще пытаюсь найти хороший пример конфигурационного файла для Chrony с изолированной сетью. Пытаюсь настроить его в своей лаборатории.
-
Нет. Насколько я знаю, CM не использует аутентификацию для NTP. ![Response Signature]
-
На данный момент сборка AlmaLinux/UCv15 от Cisco не может правильно взаимодействовать с NTP-сервером, на котором запущена служба ntpd для синхронизации времени. Поэтому убедитесь, что ваш NTP-источник — это либо коммутатор с запущенной службой NTP, либо компьютер под управлением Linux с запущенной службой ntp, которая не является ntpd. В противном случае новая ОС не сможет с ним взаимодействовать.
Здравствуйте! Похоже, вам интересна эта беседа, но у вас пока нет учетной записи.
Вы устали просматривать одни и те же посты каждый раз, когда заходите на сайт? После регистрации, вам не придётся искать обсуждения в которых вы принимали участие, настройте уведомления о новых сообщениях так как вам это удобно (по электронной почте или уведомлением). У вас появится возможность сохранять закладки и ставить лайки постам, чтобы выразить свою благодарность другим участникам сообщества.
С вашими комментариями этот пост может стать ещё лучше 💗
Зарегистрироваться Войти