Asterisk Load Balansing. Часть 1

Skip to end of metadata
Go to start of metadata

Пролог

Отличное приложение Asterisk, но свои косяки в нем тоже имеются, от утечек памяти появляющихся под большой нагрузкой, до багов которые еще никто не заметил. В итоге случается так, что до бесконечности Call центр на asterisk на одной машине масштабировать нельзя, рано или поздно утыкаемся в потолок производительности и система начинает периодически падать. Одна беда если просто звонок оборвался, но как правило Call центр у большой компании постепенно обрастает различным функционалом, по нему начинают вести статистику обращений по различным вопросам, по длительности вызовов на различные службы делают выводы о лояльности клиентов, по записанным разговорам решают конфликтные ситуации, по статистике очередей считают зарплаты операторам. В общем: если компания завязана на общение с многочисленными клиентами, то нестабильная работа Call центра нарушает слаженное взаимодействие разных отделов, приводит к уменьшению эффективности работы компании и как следствие уменьшению прибыли. Это все конечно банальные вещи, но просто захотелось излить душу, потому что с данной проблемой я столкнулся в полной мере. Для специалиста по телефонии в большой компании с количеством абонентов > 100000 нестабильность Call центра приводит к появлению стойкой головной боли  и появлению нервного тика , не говоря уже о том что даже банальный выезд за город происходит с задней мыслью, а что если Call центр опять свалится, а рядом меня не будет 

Как быть дальше?

Свелось все к тому, что так больше работать никто не мог. Решили принимать какие-то меры. Первая самая очевидная мера - это разделить Call центр на несколько машин. Да это работает, но не избавляет от всех прелестей по увеличению количества работы после каждой переконфигурации в системе, причем это количество работы растет с увеличением абонентов. Начали думать о каком-нибудь адски крутом проприетарном Call центре за много денег, надо сказать что я был категорически против, вспомнив только однажды увиденный прайс от Nec, с его кучей лицензий и непонятных "кабинетов" становилось плохо:). Слава ктулху мой голос был услышан и сомнительное решение за много денег покупать передумали, а решили попытаться построить решение на уже проверенном и знакомом Asterisk PBX.

Что же мы хотим?

Чего хотелось бы от Call центра, чего на данный момент у нас не было?

  1. Безотказную систему, желательно с полным резервирование и без единой точки отказа
  2. Легкую реализацию load balansing между машинами Call центра
  3. Масштабируемую систему. Чтобы для обработки увеличившейся нагрузки необходимо было бы только добавить еще одну машину, причем чтобы это не требовало перенастройки всей системы, необходимо чтобы это мог сделать обычный инженер по эксплуатации (да у нас и такие есть 
  4. Единую точку хранения учетных записей системы, у нас все сервисы для абонентов привязаны к логину и паролю, авторизацию для пользования сервисам осуществляет Radius, в общем - идеальный вариант, если Call центр будет работать с Radius
  5. Единая точка хранения статистики работы Call центра, ну тут и к бабке не ходи, asterisk-addons и mysql 
  6. Гибкое API для разработки собственных интерфейсов управления и просмотра статистики работы Call центра и тут Asterisk нам подходит: AMI, CDR, queue_log

В общем необходимо было реализовать Load Balansing, Radius, масштабируемость и безотказность. Всего ничего , не говоря уже о том что в процессе разработки наверняка всплывет еще куча всяких ньюансов.

Как же все это сделать?

Краем уха я слышал где-то про SIP софтсвитч на [OpenSer]?, когда начал искать как же он работает наткнулся на одном из любимых форумов по asterisk на книженцию Building Telephony Systems with [OpenSER]. Благодаря ей был освоен очень нелегкий в понимании[OpenSer]?. Изучив документацию стало ясно, что авторизация через Radius это не проблема, балансировка тоже. Решено было строить систему такого вида:

Т.к. мы предоставляем сервис телефонии то имеем стык с PSTN с несколькими операторами по E1. В [VoIP] загоняем его через 2 Cisco AS5350. Которые гонят трафик по SIP на sipbalanser, в качестве которого используется софтсвитч kamailio, бывший проект [OpenSer]?(все наверное в курсе что этот проект форкнулся на kamailio и opensips, вроде оба проекта развиваются но документацию мне больше по душе у kamailio). На sipbalanser-е регистрируюся сотрудники Call центра, их авторизует Radius, kamailio для связи с Radius использует radiusclient-ng. Логины и пароли хранятся в общей базе данных компании, в качестве сервера Radius используется Free Radius 2. Сведения о зарегистрированных клиентах хранятся в локальной базе данных на [MySql]?. Запросы на установление соединения маршрутизируются на sipbalanser, который затем с помощью модуля dispatcher распределяет их на ноды asterisk по алгоитму round robin. Asterisk обрабатывает звонок, если надо проигрывает музыку, помещает вызов в IVR или делает любое свойственное asterisk-у действие с звонком, затем если нужно соединить с реальным человеком, то звонок отправляется на нужного нам сотрудника обратно на sipbalanser, тот ищет у себя в локальной базе зарегистрированного User Agent-а и если находит отдает ему вызов. Вроде все просто 

В следующем части я детально опишу настройку данной схемы.

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.