После прочтения статьи «Как мы встретили апокалипсис или как 3500 компаний остались без звонков?» появилось чувство недоумения, а потом возникло желание поделиться опытом.

Итак, если у вас, как было у yagodkinvs:

Резервирование было серверов для веб-морды, но с телефонией не все так просто…

То добро пожаловать под кат.



Участвуя в одном проекте, отвечал за первоначальную настройку и дальнейшее сопровождение телефонии. Проект со временем рос, менялись требования, одним из которых было — бесперебойная работа коллцентра, за исключением случаев пропадания электричества и/или магистральных аварий у провайдеров (Интернет и/или телефонии).

Как это решалось?

Хотелось бы отметить, что зарезервировать на 100% телефонный номер, если он у вас ОДИН — невозможно. При аварии у оператора связи — вы ничего сделать не сможете.

Поэтому действовали следующим образом. Основной сервер телефонии, был вынесен, грубо говоря из офиса в облако. Для его резервирования, был поднят второй в дешевом хостинге.

Настройки на резервном — копия основного, за исключением мелких нюансов.

Руководителю проекта были предложены следующие варианты автоматического переключения телефонии между серверами:

1. Использовать DNS, в частности — от Amazon. Там можно настроить очень быстрое переключение имени, например voip.company.pro между IP адресами наших двух серверов, по fail-over и другим параметрам.
2. Использовать балансировщик. Варианты настроек Kamailio и Asterisk, да и не только его есть на просторах сети.

Надо отметить, что в первом варианте, переключение SIP-клиентов на новый сервер будет после того, как сработает таймаут регистрации.

Во втором случае, авторизация вынесена за пределы Asterisk в сам балансировщик.

Но, заказчик, обыграв вариант с DNS отказался от этого. Обосновав тем, что обновление информации в DNS-серверах у конечных устройств может быть очень продолжительным.

Второй вариант был отложен, в виду того, что пока операторов не так много, да и не хотелось заказчику пока усложнять эту схему. Ну и слабым местом во втором варианте оказался бы балансировщик, пришлось бы резервировать и его.

Заказчик предложил подумать над другим вариантом — он настраивает у операторов в SIP-клиентах две учетные записи. Они по сути идентичны, отличии только в сервере подключения. А с моей стороны необходимо проработать переключение телефонии между серверами.

То есть часть схемы со стороны абонентов приняла такой вид:



Не идеально, но заказчик настоял на таком решении, да и все трудозатраты по настройке SIP-клиентов, были им взяты на себя. Возложены на имеющегося сисадмина :)

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

Номер размещен на сайте, вместе с основным.

В личных кабинетах у обоих поставщиков услуг телефонной связи были подключены оба сервера, как sip-клиенты.

Были настроены сценарии обработки входящих вызовов, по следующей схеме:

1. При поступлении входящего звонка, он отправлялся на основной сервер, время дозвона 20 сек.
2. При недоступности основного сервера, звонок отправлялся на резервный, время дозвона 20 сек.
3. При недоступности и резервного сервера, звонок отправлялся в голосовую почту.

Практически все VOIP провайдеры позволяют настроить эту схему или в личном кабинете или по заявке в службу поддержки. По крайней мере у выбранных нами, мы это настроили в личном кабинете.

Получилось следующая схема:



Так как сервера относительно SIP-клиентов являются внешними, то заказчик имеет возможность зарезервировать каналы доступа в Интернет для коллцентра без особых проблем. Хотя, надо сказать, он пошел еще дальше и зарезервировал коллцентр, открыв его часть в другом городе.

Выводы

Реализованная схема позволила избежать простоя коллцентра в таких случаях:

1. Выход из строя, по любым причинам, одного из серверов телефонии.
2. Пропадание электричества и/или всех каналов связи в Интернет у одного из коллцентров
3. Авария у одного из поставщиков услуг связи

Конечно, при любом из этих случаев, текущие звонки разрывались, а последующие уже поступали по резервной схеме.

Я помню, то чувство удовлетворения, когда вечером в мониторинге увидел случай переключения на резервную схему.
И при этом мне никто не позвонил с криками паники, так как этого практически не заметили.

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