У нас есть два сервера Asterisk. Один из них - «теплый» отказ (т. Е. Мы должны заставить его работать вручную, если первый выйдет из строя, но он получает регулярные обновления конфигурации, поэтому он всегда готов к работе), а другой - это рабочий сервер. В них обоих есть Digium Wildcard TE405P, а аппаратное и программное обеспечение в остальном идентично, но в последний раз, когда нам понадобилось использовать сервер аварийного переключения, все пошло плохо, когда он был подключен к линии PRI. Теперь мы обновляем модуль аварийного переключения до Asterisk 1.6 и запускаем его в эксплуатацию.
Мне действительно нужен способ тщательного тестирования (включая тестирование под нагрузкой) оборудования и конфигурации TE405. перед нам это нужно. Я не могу просто настроить и отключить линию PRI для тестирования в течение часа или дня, а стоимость линии не позволяет нам иметь полную резервную копию. Точно так же простое переключение кабеля с одного сервера на другой также сильно мешает.
В прошлом для подобных тестовых ситуаций я просто делал Перекрестный кабель T1. TE405P - это четырехпортовая карта, поэтому в системе аварийного переключения просто подключите два порта последовательно с кроссовером T1, а затем напишите быстрый сценарий, чтобы звездочка отправляла несколько вызовов на один порт, отвечая на них. на другой порт.
Тестирование аварийного восстановления должно быть частью ваших планов регулярного обслуживания системы или, по крайней мере, вы должны регулярно проводить тестирование аварийного восстановления раз в год, раз в полгода и т. Д. действительно знаю, работает ли он, если вы не протестируете его с реальной линией PRI, совершая реальные звонки. Я бы порекомендовал лоббировать регулярно проводимые тесты аварийного восстановления, запланированные на время, наименее разрушительное для бизнеса.
Компоненты аварийного восстановления похожи на все остальное (например, резервные копии), они бесполезны, если они действительно не работают, и чтобы убедиться, что они работают, вы должны их протестировать.