Как стать автором
Обновить

Комментарии 12

А что делать если весь сервис упадет? На мой взгляд гораздо надежнее и без прыжков с патчами исходников взять kamailio и добавить надежность через keepalived или аналог. А за него уже убрать несколько asterisk с dialplan. Таким образом будет дублировано все. Если хочется еще - добавить несколько входов через kamailio и DNS-rr.

А использовать Asterisk realtime это путь получать много интересных и разных ошибок по любому поводу и креши.

Если сервис упадет, Asterisk продолжит работу в состоянии, предшествующему аварийной ситуации.

я имел ввиду сам Asterisk, у него нет восстановления после падений. Все регистрации потеряются например.

Даже для среднего бизнеса это слишком "масштабное" решение относительно трудозатрат на запуск телефонии. Но вот для всего крупного бизнеса, однозначно полезное и нужное решение. Тут даже обсуждать нечего.

А крупному не очень-то и надо - они покупают решения от вендоров и обычно по результатам тендеров

Крупному агресивная маркетинговая политика Freeswitch довела, что они должны все делать на FS.
Эту войну диджиум уже походу проиграли.
В реальной жизни разница в скорости больше зависит от архитектуры системы, но рекламная компания работает, крупные бизнесы даже с успешными кейсами 50+ тыс каналов на астериск затребывают разработку новых сервисов на FS.
Угу. Теперь у вас астериск зависит не только от базы данных, которую проще было задуалить.
Но также от 1) кеширующей части 2) веб сервиса 3) ну и от базы тоже.
Также это очевидно не исправляет ситуации «база работает, но данные удалены».

БД и так реплицирована в 3-х датацентрах (..."клиентская балансировка между источниками данных в разных ЦОД‑ах является зоной ответственности отдельной команды"...). Пока жив хотя бы один, будет штатный режим работы.
Нас интересовал случай, когда ничего внешнее недоступно. В этом случае телефония должна работать как минимум в аварийном режиме (т.е. вся локальная связь плюс городские операторы, если они заведены не через ЦОД).

Для этого традиционно пишут в файлы.
При правильной организации это работает сильно лучше и для «локальных» систем вполне доступно.
В любом случае не вижу смысла городить такую сложную систему для ЛОКАЛЬНЫХ атс.

А кто сказал, что у нас система локальная? Она как раз вполне себе распределенная, только в случае аварий поддерживает минимальный функционал в локальном режиме.
Раскатывать файлами на 60+ серверов во-первых долго, во-вторых сбои тоже возможны, в-третьих dialplan/pjsip reload здоровья Asterisk не добавляют. Клиента надо включить здесь и сейчас, при этом конфигурация абонента должна быть на всех серверах, ибо роуминг (автоматический, конечно. Без костылей на AMI/ARI/AGI).

Можно подумать realtime добавляет здоровья. Особенно вот так, как у вас описано.
Не надо «раскатывать файлами» на 60 серверов. Обновляйте только те части, которые поменялися. Если все равно часто — разбейте ваших пользователей на псевдо-группы.
Перегружать без изменений тоже не стоит
Хотя да, если не думать — видел я системы где только диалплан перегружается 4 минуты. Ну просто там по 100 строчек на каждый DID из 5 тысяч.

В любом случае статический диалплан гараздо более оттестирован. И делать в реалтайм части, которая меняется — еще неподдерживаемые патчи — ну таксебе идея. Особенно если оно по сути ничего и не даст.

Патч точно не "пролезет", если его нет в gerrit. Стоит его залить и получить feedback от разработчиков из sangoma.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий