Я хочу построить кластер звездочки из 3 узлов звездочки (13.x), один в США, один в Европе и один в Азии. Прямо сейчас у меня 3 сервера. Asterisk использует инфраструктуру реального времени для пользователей sip / iax, queues, cdr, cel, queue_logs. Все пользователи используют SIP и софтфоны.
Базы данных реплицируются с помощью решения Master <==> Master, поэтому в основном у меня одна и та же база данных во всех местах, и данные реплицируются в реальном времени (1-2 минуты, поскольку серверы находятся далеко друг от друга).
Из-за того, что таблица очередей реплицируется, у меня есть все очереди во всех местах, и это желаемое поведение, поскольку один сервер является резервным для другого.
Я хочу добиться того, чтобы независимо от того, куда направляется вызов, на один из этих трех серверов «система» должна быть в состоянии найти доступных агентов из этой очереди и позвонить на их устройство, независимо от того, где агент вошел в систему. .
Для репликации состояний устройства я использовал Openfire XMPP, но здесь у меня есть некоторые несоответствия, поскольку часто у пользователя разные состояния в определенной очереди на разных серверах.
т.е. У меня есть агент Адриан IN_USE в реальном времени на одном сервере, где он звонит, и NOT_IN_USE в реальном времени на другом сервере. Проблема здесь в том, что если вызовы поступают в эту очередь на втором сервере, он попытается отправить вызов Адриану, не зная, что он уже находится в вызове. В связи с этим это вызовет стресс у Адриана, поскольку он будет звонить на 2-ю линию софтфона, и звонок не будет идти другому доступному агенту.
Я подозреваю, что проблемы вызваны тем фактом, что у меня есть все очереди на всех серверах, так что состояния каким-то образом меняются.
Я видел, что есть установки, где есть выделенный сервер очереди. Это почему ? чтобы избежать такого рода проблем или для распределения нагрузки?
Каков рекомендуемый подход для кластеризации звездочек со сценарием общей базы данных?
Есть мысли о том, как я могу этого добиться?
P.S. Я включил счетчики вызовов в sip.com
Обновления:
Действительно, термин «кластер» здесь не используется. Я предполагаю, что идеальным сценарием было бы иметь кластер из двух серверов звездочки в каждом месте (активный-пассивный с обнаружением аварийного переключения) и после этого уровня иметь более высокий уровень, который балансирует вызов между этими местоположениями.
Основная проблема, которая у меня есть сейчас, заключается в том, что у меня есть эти 3 места, и я разделяю очереди между ними (поскольку все они имеют одну и ту же базу данных). Скажем, в очереди с именем TestQueue 15 пользователей, по 5 в каждом месте (команда разделена на 3). Я хочу добиться того, чтобы независимо от того, на каком сервере вызов попадает в очередь, можно было достичь всех доступных агентов (и определить, какие из них заняты, а какие нет).
Я не уверен, что мой подход в порядке, или у меня должен быть один сервер звездочки, используемый для размещения очереди, и другие 3 сервера, на которых будут регистрироваться пользователи (со статусом синхронизации xmpp между сервером очереди и серверами регистрации).
Из вашего описания вы путаете / смешиваете кластеризацию и балансировку нагрузки, что создаст беспорядок ... выберите один или другой. Посмотри на этот вопрос и ответ serverfault который хорошо описывает состояние кластеризации для Asterisk.
Если это действительно кластер, то на резервных узлах не должно быть запущено Asterisk, когда он не используется (нет активного стека SIP для подключения агентов / магистралей). Попытка поддерживать активные и резервные узлы в рабочем состоянии с использованием разных статусов и т. Д. Ближе к балансировке нагрузки, что на самом деле нежелательно с точки зрения того, чего вы пытаетесь достичь.
Синхронизация мастер-мастер также является ошибкой при кластеризации. Если один узел выходит из строя или начинает повреждать данные, он не должен повреждать другой одноранговый узел (а) - что и происходит при синхронизации мастер-мастер. Точно так же использование общих файловых хранилищ, таких как NFS, iSCSI, DRBD, позволяет одному отказавшему одноранговому узлу повредить все одноранговые узлы.
Вместо «общей базы данных» ищите «синхронизированные данные». Таким образом, программное обеспечение кластеризации может контролировать то, что синхронизируется (и избегать синхронизации в случае сбоя однорангового узла).
Вам также не хватает одного важного аспекта кластеризации - определения работоспособности. Как узнать, что оборудование выходит из строя? стволы опущены? вышестоящие устройства не работают? Агенты не могут подключиться? и т.д. Как это вызовет аварийное переключение? К какому узлу?
Похоже, вы используете перспективу кластеризации «аппаратного уровня», которая не работает на уровне приложений, который должен совместно использовать состояние (например, голосовая почта, очереди и т. Д.) Между одноранговыми узлами. Ваш подход лучше всего работает с простыми службами уровня ОС (совместное использование файлов высокой доступности, база данных высокой доступности и т. Д.), А не с службами уровня приложений. Внимательно ознакомьтесь с упомянутым выше вопросом ServerFault и эта веб-страница Voip-Info.
Если у вас возникли проблемы с выбором направления, примите во внимание следующее: балансировка нагрузки отлично подходит для достижения высокой емкости в системах без состояния. 10 лет назад это было важно для Asterisk, учитывая, как мало одновременных каналов мог поддерживать один сервер. Теперь даже обычное оборудование может поддерживать открытыми 500 каналов (без перекодирования), поэтому балансировка нагрузки вышла из моды.
Кластеризация с управляемым состоянием теперь является стандартом для критически важных центров обработки вызовов. Это включает в себя сложный мониторинг работоспособности, синхронизацию (не общие данные), интеллектуальную настройку / дифференциацию между одноранговыми узлами с использованием общей схемы набора и т. Д. Кластеризация с 2 одноранговыми узлами также является стандартом (с одноранговыми узлами в разных центрах обработки данных) - когда вы получаете 3+ одноранговые узлы, у которых вы начинаете сталкиваться с новыми проблемами синхронизации состояния в случае конфликта (активны 2/3/4 и т. д.). С Master-Master DB, как вы описываете, вы никогда не оправитесь от многоактивной конкуренции.
Похоже, вы купили много оборудования и теперь разрабатываете решение для его использования. Возможно, вы захотите подойти к этой проблеме с другой стороны - и перепрофилировать ненужное оборудование, как только у вас будет практичный дизайн. Я бы предложил двухузловой кластер с синхронизацией данных и мониторингом работоспособности.