Последняя версия для Debian

[Alexander Freydkin]

Месяц назад установили систему на новый сервер (собственный, ОС - Debian). Лицензия Enterprise NFR. Стоит задача протестировать failover.
На днях на другом сервере развернули Debian. Стали устанавливать систему использую бэкап с первого сервера. Получаем сообщение: The backup version 18.0.7.441 is newer than the PBX version 18.0.7.312. You can restore this backup only with PBX version 18.0.7.441 or newer.
Новый сервер устанавливали из свежего образа с портала.
В чем может быть проблема? Где взять 18.0.7.441?

 

[paurus]

Последняя стабильная версия 18.0.7.312. У вас похоже стоит тестовая альфа.
Тестовую посмотрите здесь https://downloads-global.3cx.com/downloads/debian10iso/debian-10.11.0_9d3725f-amd64-netinst-3cx.iso

 

[igorsnezhko]

Лучше на обеих системах переустановить текущий релиз https://downloads-global.3cx.com/downloads/debian10iso/debian-amd64-netinst-3cx.iso А затем накатить все обновления. После этого настраивать Failover.

 

[Alexander Freydkin]

Лучше на обеих системах переустановить текущий релиз https://downloads-global.3cx.com/downloads/debian10iso/debian-amd64-netinst-3cx.iso А затем накатить все обновления. После этого настраивать Failover.

Как сделать downgrade на работающей системе?

 

[igorsnezhko]

Невозможно. Сделать бэкап и накатить на новый образ в нерабочее время.

 

[Alexander Freydkin]

Так а не возникнет той же коллизии: The backup version 18.0.7.441 is newer than the PBX version 18.0.7.312. You can restore this backup only with PBX version 18.0.7.441 or newer?

 

[igorsnezhko]

Возникнет, вы правы. Тогда лучше поставить второй сервер из ТОГО ЖЕ образа, который вы использовали для первого. Он у вас сохранился?

 

[Alexander Freydkin]

Не можем найти. Там же из названия файла не понять какой build. стоит 441

 

[igorsnezhko]

Поищите в истории загрузок браузера, попробуйте повторно скачать то, что скачали для установки.

 

[Alexander Freydkin]

Продолжаем наши изыскания. В итоге сейчас имеем:
Сервер1 - установлена версия 18.0.7.312. Система работает. Планируем использовать в качестве Active
Сервер2 - установлена версия 18.0.7.441 Система установлена с тем же FQDN и лицензией. После ее установки были проблемы с сервером1 (с самой виртуалкой) и система на Сервер2 успешно работала. Ее хотели использовать в дальнейшем в качестве Active. После восстановления работоспособности Сервера1 3СХ автоматически "вернулась" работать на Сервер1.
Сервер3 - установлена версия 18.0.7.312. Ждет конфигурирования (пока бэкап не загружали). Планируем использовать в качестве Passive.

Вопрос: как правильно остановить (деинсталлировать) 3СХ на Сервере2?

 

[igorsnezhko]

Я бы настроил сервер 3, а потом просто указал в нем данные активного узла кластера https://www.3cx.com/docs/failover/

 

[Alexander Freydkin]

Я бы настроил сервер 3, а потом просто указал в нем данные активного узла кластера https://www.3cx.com/docs/failover/

Выключили второй сервер до Вашего сообщения.
Запустили Сервер3 из бэкапа сервера1. Инсталляция прошла удачно, но:
1. браузеры ругаются на сертификат.


2. FQDN по-прежнему ссылается на сервер1 (хотя в описаниях настроек Failover говорится о том, что после запуска второго сервера запись DNS должна измениться)

 

[Alexander Freydkin]

Обновили информацию о лицензии на первом сервере
Перезапустили службу 3CX PhoneSystem 01 System Server на первом сервере
FQDN снова ссылается на первый сервер. ОК

Настроены функции Failover на серверах согласно документации 3cx
Восстановление из бэкапа по расписанию на втором сервере выполнено
На резервном сервере все сервисы в состоянии «остановлен»

10:59 Остановка доступа в интернет на основном сервере на 600 секунд

Event log резервного сервера:
· The following service(s) were interrupted: 3CXAudioProvider01 3CXPhoneSystem01 3CXSystemService01 3CXIVR01 3CXCallFlow01 3CXGatewayService 3CXQueueManager01 3CXPhoneSystemMC01
3CX Event Notification Manager ID: 30035 04/06/2023 11:06:39

· Service started
SIP Server ID: 4097 04/06/2023 11:05:32

· Trunk L:90000(WebMeeting bridge) has changed status to registered.
SIP Server ID: 4100 04/06/2023 11:05:32

В Dashboard Services запущены. Зеленый индикатор

Телефоны продолжают безуспешно пытаться зарегистрироваться

11:09 Восстановление доступа в интернет на основном сервере
Телефоны сразу зарегистрировались на основном сервере
Вызов между внутренними абонентами проходит на основном сервере
Исходящие вызовы через основной сервер - ОК

11:20 на втором сервере сервисы продолжают работать
При входящих звонках снаружи вызов на т\а приходит, но при снятии трубки сброс входящего. При этом у звонящего продолжается КПВ. Эти вызовы продолжают приходить на второй сервер

11:30 Обновление информации о лицензии на основном сервере
11:35 Рестарт 3CXSystemService01 на основном сервере
11:38 внешние вызовы продолжают приходить на второй сервер
11:40 внешние вызовы стали приходить на основной сервер


Основной вопрос - почему не сработал Failover
Второй вопрос - как "возвращаться" в штатный режим (основной/резервный) после восстановления основного сервера. Фраза в документации "When the active server (#1) fails, the passive detects this and takes over. With the backup already restored, the failover action triggers the 3CX DNS Servers to update the FQDN to the IP address of the new active server (#2)." не очень-то объясняет, что надо делать.

 

[igorsnezhko]

Failover нормально и быстро работает, если у вас используется FQDN от 3CX, разделенная DNS (т.е. внутри сети серверы 3CX резолвятся по тому же имени, что и снаружи, а также на хостах (телефонах) используется Google DNS 8.8.8.8. Либо этот DNS стоит как dns windows server forwarder (в терминологии Microsoft). В других случаях нужно вручную или скриптом обновлять настройки вашего DNS (менять А запись вашего сервера 3CX).

 

[Alexander Freydkin]

Failover нормально и быстро работает, если у вас используется FQDN от 3CX, разделенная DNS (т.е. внутри сети серверы 3CX резолвятся по тому же имени, что и снаружи, а также на хостах (телефонах) используется Google DNS 8.8.8.8. Либо этот DNS стоит как dns windows server forwarder (в терминологии Microsoft). В других случаях нужно вручную или скриптом обновлять настройки вашего DNS (менять А запись вашего сервера 3CX).

Мы используем FQDN от 3CX. Сервера установлены на виртуальных машинах в разных дата-центрах. У каждого свой статический ip-адрес. Все телефоны "живут" в глобальной сети.
Разве в такой моделе Failover не должен работать автоматически?
да, лицензия Enterprise

 

[igorsnezhko]

Должен, если все телефоны смотрят на общий DNS 8.8.8.8 Иначе обновление DNS (и, соответственно, переключение) по стандарту может занять до 24 часов. Иногда больше https://ns1.com/resources/dns-propa...ation is the time,typically takes a few hours.

 

[Alexander Freydkin]

Второй вопрос - как "возвращаться" в штатный режим (основной/резервный) после восстановления основного сервера. Фраза в документации "When the active server (#1) fails, the passive detects this and takes over. With the backup already restored, the failover action triggers the 3CX DNS Servers to update the FQDN to the IP address of the new active server (#2)." не очень-то объясняет, что надо делать.

Спасибо. С первым понятно. А что можете сказать по второму вопросу?

 

[igorsnezhko]

Когда вы восстановите первый сервер, накатите на него свежий бэкап с резервного сервера, а потом остановите сервисы на резервном сервере. Базово "автоматического" восстановления нет, т.е. подразумевается, что возвращение на основной сервер происходит в ручном режиме. https://www.3cx.com/community/threads/automatic-change-of-the-failover-mode.115489/