asterisk cluster with shared database
I want to build an asterisk cluster from 3 asterisk (13.x) nodes, one on US, one in Europe and one is Asia. Right now I have the 3 servers. Asterisk is using realtime infrastructure for sip/iax users, queues, cdr, cel, queue_logs. All users are using SIP and softphones.
Databases are replicated with a Master <==> Master solution so basically I have the "same" database on all locations and the datas are replicated realtime (1-2 minutes as the servers are far far away one from another).
Due to the fact that the queues table is replicated I have all queues on all locations, and this is the desired behavior as one server is backup for another.
What I want to accomplish is that no matter where a call is routed, to one of these 3 server the "system" should be able to find the available agents from that queue and ring to their device, no matter where the agent is logged in.
Для репликации состояний устройства я использовал Openfire XMPP, но здесь у меня есть некоторые несоответствия, поскольку часто у пользователя разные состояния в определенной очереди на разных серверах.
т.е. У меня есть агент Адриан IN_USE в реальном времени на одном сервере, где он звонит, и NOT_IN_USE в реальном времени на другом сервере. Проблема здесь в том, что если вызовы поступают в эту очередь на втором сервере, он попытается отправить вызов Адриану, не зная, что он уже находится в вызове. В связи с этим это вызовет стресс у Адриана, поскольку он будет звонить на 2-ю линию софтфона, и звонок не будет идти другому доступному агенту.
Я подозреваю, что проблемы вызваны тем фактом, что у меня есть все очереди на всех серверах, так что это каким-то образом меняет состояния.
Я видел, что есть установки, где есть выделенный сервер очереди. Это почему ? чтобы избежать подобных проблем или для распределения нагрузки?
Каков рекомендуемый подход для кластеризации звездочки со сценарием общей базы данных?
Есть мысли о том, как я могу этого добиться?
PS Я включил счетчики вызовов в sip.com
Обновления:
Indeed the term cluster is not proper used here. I guess that the ideal scenario would be to have a cluster of two asterisk server on each location (active-pasive with failover detection) and after that layer to have a higher one that balance the call between these locations.
The main problem that I have now is that I have these 3 locations and I share queues between them (as they all has the same database). Let's say that queue named TestQueue has 15 users, 5 on every location (the team is split in 3). What I want to accomplish is that no matter on what server a call enters the queue to be able to reach all available agents (and determine which are busy and which not).
I`m not sure if my approach is OK, or I should have one asterisk server used to host the queue and other 3 servers where the users will register (with xmpp sync status between queue server and register servers).
Из вашего описания вы путаете/смешиваете кластеризацию и балансировку нагрузки, что создаёт беспорядок... выбирайте тот или иной. Взгляните на этот неудачный серверный вопрос и ответ, который хорошо описывает состояние кластеризации для Asterisk.
Если это действительно кластер, то на резервных узлах не должно быть Asterisk, когда он не используется (нет активного SIP стека для агентов/транка, к которым можно подключиться). Попытка поддерживать активные и резервные узлы в рабочем состоянии, используя различные статусы и т.д., ближе к балансировке нагрузки - что на самом деле не желательно с точки зрения того, что вы пытаетесь достичь.
Синхронизация "мастер-мастер" также является ошибкой в кластеризации. Если один узел выходит из строя или начинает портить данные, он не должен портить другой - что делает синхронизация "мастер-мастер". Аналогично, использование общих файловых хранилищ, таких как NFS, iSCSI, DRBD, позволяет одному неработающему пиеру повреждать все пиры.
Вместо 'общей базы данных' ищите 'синхронизированные данные'. Таким образом, программное обеспечение кластеризации может контролировать то, что синхронизируется (и избегать синхронизации, если пиар не работает).
Вам также не хватает одного важного аспекта кластеризации - обнаружения здоровья. Как вы узнаете, если аппаратное обеспечение выходит из строя? Стволы не работают? Устройства, расположенные вверху по течению, не работают? Агенты не могут подключиться? и т.д. Как это спровоцирует обход отказа? К какому узлу?
Вы, кажется, рассматриваете кластеризацию на "аппаратном уровне", которая не очень хорошо работает на прикладном уровне, который должен разделять состояние (например: голосовая почта, очереди и т.д.) между коллегами. Ваш подход лучше всего работает с простыми службами на уровне ОС (общий доступ к файлам HA, база данных HA и т.д.) - а не со службами на прикладном уровне. Внимательно ознакомьтесь с вопросом ServerFault, упомянутым выше, и этой Voip-Info веб-страницей .
Если у вас возникли проблемы с выбором направления, рассмотрите следующее: балансировка нагрузки отлично подходит для достижения высокой пропускной способности на системах без состояния. 10 лет назад это было важно для Asterisk, учитывая то, как мало одновременных каналов один сервер может держать открытым. Теперь даже товарное оборудование может держать 500 каналов открытыми (без транскодирования), поэтому балансировка нагрузки оказалась не в пользу.
Кластеризация с управляемым состоянием сейчас является стандартом для критических call-центров. Это включает в себя сложный мониторинг здоровья, синхронизацию (не общие данные), интеллектуальную настройку/дифференциацию между коллегами, использующими общий план набора номера, и т.д. Кластеризация с 2-мя пирами также является стандартом (с пирами в разных центрах обработки данных) - когда вы достигаете 3+ пирами, вы начинаете сталкиваться с новыми проблемами синхронизирующего состояния в случае возникновения споров (2/3/4/etc активны). С БД Master-Master, как вы описали, вы никогда не восстановитесь после мультиактивного соперничества.
Похоже, что вы купили много аппаратного обеспечения и сейчас разрабатываете решение по его использованию. Возможно, вы захотите подойти к этой проблеме по-другому - и перепрофилировать ненужное аппаратное обеспечение, как только у вас будет практический дизайн. Я бы предложил 2-узловой кластер с синхронизацией данных и мониторингом здоровья.
.