После прочтения статьи «Как мы встретили апокалипсис или как 3500 компаний остались без звонков?» появилось чувство недоумения, а потом возникло желание поделиться опытом.
Итак, если у вас, как было у yagodkinvs:
Резервирование было серверов для веб-морды, но с телефонии не все так просто…
То добро пожаловать под кат.
Участвуя в одном проекте, отвечал за первоначальную настройку и дальнейшее сопровождение телефонии. Проект со временем рос, менялись требования, одним из которых было — бесперебойная работа коллцентра, за исключением случаев пропадания электричества и/или магистральных аварий у провайдеров (Интернет и/или телефонии).
Как это решалось?
Хотелось бы отметить, что зарезервировать на 100% телефонный номер, если он у вас ОДИН — невозможно. При аварии у оператора связи — вы ничего сделать не сможете.
Поэтому действовали следующим образом. Основной сервер телефонии, был вынесен, грубо говоря из офиса в облако. Для его резервирования, был поднят второй в дешевом хостинге.
Настройки на резервном — копия основного, за исключением мелких нюансов.
Руководителю проекта были предложены следующие варианты автоматического переключения телефонии между серверами:
- Использовать DNS, в частности — от Amazon. Там можно настроить очень быстрое переключение имени, например voip.company.pro между IP адресами наших двух серверов, по fail-over и другим параметрам.
- Использовать балансировщик. Варианты настроек Kamailio и Asterisk, да и не только его есть на просторах сети.
Надо отметить, что в первом варианте, переключение SIP-клиентов на новый сервер будет после того, как сработает таймаут регистрации.
Во втором случае, авторизация вынесена за пределы Asterisk в сам балансировщик.
Но, заказчик, обыграв вариант с DNS отказался от этого. Обосновав тем, что обновление информации в DNS-серверах у конечных устройств может быть очень продолжительным.
Второй вариант был отложен, в виду того, что пока операторов не так много, да и не хотелось заказчику пока усложнять эту схему. Ну и слабым местом во втором варианте оказался бы балансировщик, пришлось бы резервировать и его.
Заказчик предложил подумать над другим вариантом — он настраивает у операторов в SIP-клиентах две учетные записи. Они по сути идентичны, отличи только в сервере подключения. А с моей стороны необходимо проработать переключение телефонии между серверами.
То есть часть схемы со стороны абонентов приняла такой вид:
Не идеально, но заказчик настоял на таком решении, да и все трудозатраты по настройке SIP-клиентов, были им взяты на себя. Возложены на имеющегося сисадмина 🙂
Далее. Для того чтобы звонки поступали в любом случае, был арендован дополнительный городской номер, но у другого поставщика услуг.
Номер размещен на сайте, вместе с основным.
В личных кабинетах у обоих поставщиков услуг телефонной связи были подключены оба сервера, как sip-клиенты.
Были настроены сценарии обработки входящих вызовов, по следующей схеме:
- При поступлении входящего звонка, он отправлялся на основной сервер, время дозвона 20 сек.
- При недоступности основного сервера, звонок отправлялся на резервный, время дозвона 20 сек.
- При недоступности и резервного сервера, звонок отправлялся в голосовую почту.
Практически все VOIP провайдеры позволяют настроить эту схему или в личном кабинете или по заявке в службу поддержки. По крайней мере у выбранных нами, мы это настроили в личном кабинете.
Получилось следующая схема:
Так как сервера относительно SIP-клиентов являются внешними, то заказчик имеет возможность зарезервировать каналы доступа в Интернет для коллцентра без особых проблем. Хотя, надо сказать, он пошел еще дальше и зарезервировал коллцентр, открыв его часть в другом городе.
Выводы
Реализованная схема позволила избежать простоя коллцентра в таких случаях:
- Выход из строя, по любым причинам, одного из серверов телефонии.
- Пропадание электричества и/или всех каналов связи в Интернет у одного из коллцентров
- Авария у одного из поставщиков услуг связи
Конечно, при любом из этих случаев, текущие звонки разрывались, а последующие уже поступали по резервной схеме.
Я помню, то чувство удовлетворения, когда вечером в мониторинге увидел случай переключения на резервную схему.
И при этом мне никто не позвонил с криками паники, так как этого практически не заметили.
Спасибо, за ваше внимание! Надеюсь, что кому-нибудь это будет полезным.
ссылка на оригинал статьи http://megamozg.ru/post/15504/
Добавить комментарий