В настоящее время мы запускаем FreePBX на одном узле. Я хотел бы иметь кластер экземпляров звездочки для разделения нагрузки, но в основном для аварийного переключения. Мне любопытно, как другие люди решили эту проблему. В идеале я бы хотел использовать «бесплатное» (как в пиве) софт.
Спасибо за любую помощь!
Требуется дополнительная информация ... если честно, мы попробуем что угодно, если это хорошее решение :)
Нам все равно, если вызовы будут прерваны во время аварийного переключения. Это было бы идеально, но я могу представить, чтобы это произошло, было бы очень сложно из-за количества состояний, которые необходимо реплицировать между узлами.
Я не думаю, что мы не используем повторное приглашение через SIP. Я никогда не встречал этого термина, несмотря на то, что использовал freepbx более года. Наш вариант использования просто позволяет людям совершать исходящие вызовы с помощью программного телефона и маршрутизировать несколько входящих вызовов в зависимости от DID.
Прямо сейчас мы запускаем FreePBX в контейнере LXC. Это работает, потому что наши восходящие операторы также являются SIP (не ISDN). У нас есть опыт работы с KVM, но в идеале мы хотели бы запускать вещи в контейнере LXC из соображений эффективности.
Начните с просмотра этой веб-страницы voip-info: дизайн с высокой доступностью. Он объяснит, что такое высокая доступность, а что нет - в контексте Asterisk. (Высокую доступность легко спутать с балансировкой нагрузки)
Затем посмотрите на эту веб-страницу voip-info: продукты высокой доступности. Он объяснит, что есть для открытых / коммерческих решений для высокой доступности Asterisk.
Никакие решения не утверждают, что они поддерживают вызовы во время аварийного переключения (при этом остается в рамках стандартного протокола SIP без создания новой единой точки отказа). Повторные приглашения SIP используются для разрешения потоков мультимедиа RTP непосредственно между конечными точками, но Asterisk обычно остается в потоке SIP. На самом деле это не проблема высокой доступности.
Есть еще кое-что, о чем следует подумать, это определение «неудачи». Проще говоря, процесс Asterisk умирает. Но часто процесс Asterisk активен, просто не соединяя вызовы (поэтому избегайте упрощенных сценариев мониторинга процессов). Что делать, если в локальном центре обработки данных обрывается сетевое соединение (или выходит из строя брандмауэр). Ваше решение высокой доступности должно учитывать факторы окружающей среды, такие как восходящие маршруты и т. Д., Чтобы определить, может ли партнер больше не предлагать услуги телефонии. Некоторые решения используют стандартное программное обеспечение для проверки пульса Linux, которое не имеет четкой видимости звездочки или видимости среды.
А как насчет синхронизации данных между одноранговыми узлами? От голосовой почты до данных конфигурации, микропрограмм телефонного аппарата и т. Д. Решения, подобные DRBD, упрощают эту задачу, но повреждение одним узлом сразу же повреждает другой. Например, если поврежденный процесс на одном узле повреждает критические файлы звездочки, запустится другой одноранговый узел (если они используют DRBD, то нет). Так что избегайте «решений» на основе DRBD.
Если вы введете балансировку нагрузки (то есть несколько активных одноранговых узлов), какой из них «выиграет» в том случае, если 2 одноранговых узла получат голосовую почту № 1 для пользователя 123 одновременно? Это потребует от вас наличия внешних серверов для мостовых вызовов, внутренних серверов для голосовой почты и т. Д. И у вас все еще есть единые точки отказа или общие компоненты.
Если вы восстанавливаетесь после сбоя и кластер необходимо повторно собрать, что произойдет, если каждый одноранговый узел записывает данные в свою копию общего «диска»? Вы вручную начинаете сверку? Что, если одновременно появятся 2 узла (двойная активность) - какой из них победит и возьмет верх? Если вы вводите решение с общим диском (DRBD, NFS, iSCSI), вы устраняете один из самых больших и самых важных элементов решения высокой доступности: автономность одноранговых узлов. Так что ищите «синхронизацию», а не «общий диск».
Самые дешевые решения «высокой доступности» для звездочки обычно используют общий виртуальный диск (например, DRBD / NFS / SMB) и / или банк общих каналов (например, Astribank). Как вы прочитаете выше, реальные решения высокой доступности (например, те, которые используются в центрах обработки вызовов 911 / PSAP) требуют полностью автономных одноранговых узлов и путей вызова. Был (коммерческий) Модуль FreePBX который использует общий диск (поэтому, если один одноранговый узел выходит из строя и повреждает диск, то другой одноранговый узел также поврежден) и базовое обнаружение - но он дешев и прост в установке для домашнего пользователя; однако FreePBX прекратил поддержку продукта несколько лет назад (работает только с очень старыми версиями FreePBX). Эластикс предложил аналогичный модуль FreePBX бесплатно. (Если вы разбираетесь в Linux, то вы можете создать тот же `` модуль '' бесплатно с пакетами Linux DRBD и Heartbeat, доступными бесплатно), но Elastix теперь называется Isabbel (новое название продукта), поэтому я думаю, что руководство с практическими рекомендациями больше не существует . На высоком конце HAAst (бесплатный / коммерческий) продукт, который не имеет общих компонентов и использует сложную систему обнаружения работоспособности и совместим со всеми дистрибутивами Asterisk, но требует дополнительных навыков для установки в Linux и может быть более дорогостоящим в зависимости от выпуска (больше для корпоративных телефонных систем). И в стороне (бесплатный сценарий) переверните его сценарий, который легко установить, но называть его «HA» с натяжкой. Существует также VMware, которая предлагает общий HA (но он не поддерживает PBX / trunk / SIP / и т.д.), и вы также найдете некоторых поставщиков, предлагающих RAID 1 как «HA» для PBX, но это натянуто. И в этом спектре есть и другие продукты. Ни один поставщик не «одобряет», не «одобряет» или не «сертифицирует» какой-либо другой продукт, поэтому вы должны попробовать перед покупкой.
Вы также найдете людей, предлагающих «контейнеры» в качестве решений высокой доступности, но это не совсем HA. Контейнеры - удобный способ развертывания программного обеспечения, и у вас может быть запасной контейнер PBX, готовый к развертыванию; но у вас нет ни синхронизации настроек / голосовой почты / т. д., ни обнаружения сбоев и т. д.
Просто не забывайте задавать правильные вопросы, когда оцениваете продукты! Ни один продукт не подходит для всех, но страница дизайна HA voip-info поможет вам выбрать один, исходя из правильных компромиссов. Если вам необходимо соответствовать стандартам службы 911 / PSAP или вы планируете создать крупный операторский центр, обратите внимание на высококачественный продукт HAAst. Если он предназначен для домашнего использования, сначала попробуйте flipit или бесплатную версию одного из коммерческих продуктов.