AF
Asterisk Forum
обсуждения телефонии, VoIP и IP-PBX
12разделов
5 423тем
34 385сообщений
← К списку тем

* и кластеры

Asterisk IP PBX 14 сообщений -
#1

Кто-нибудь пробовал создать кластер на * ?
#2

А смысл? Wink
#3

Смысл обалденный - сверхбезотказность (масло-масленное).
Для идеологии * как офисная АТС, для которой всё, что не внутренние телефоны - это транки усякие, для этого в общем-то не очень нужно кластеризоваться. Но вот есть два ** очень разнесённых друг от друга, и они стоят у провайдеров в датацентрах. Жалоб на канал там в общем то не было, но за последний месяц 3-4 раза рубился у одного заграничный канал. Самый большой простой - 1 час.
Вот тут мы и задвигались! Все наши VoIP устройства, зарегистрированые на №1* обсыхали. Это же не Channel_is_available!
В общем создаём симметричную конфигу на №2*, и это работает!
#4

2 Ded
А можно чуть поподробней ?
Для пользователей это прозрачно или какие действия предпринимают ?
#6

Не для всех пользователей Laughing
То есть сразу так охватить все софтфоны и терминалы тяжело, я просто стока особенностей настроек не знаю, что проверено и надёжно: АТА-186, там есть поле AltGk - вот туда и вписываем ИП адрес второго сервера *
Вот тогда - для пользователя прозрачно. Более того, если оба ** в эфире, АТА зарегистрирована на примарном, делает дозвон на него, и если по таймауту Dial(SIP/${EXTEN},20,Ttr) за 20 сек никто трубу не взял, она кидает звонок дальше на второй *.
Само собой, если на примарный * линк упал, сразу идёт на второй*.
#7

Интересней сделать outbound proxy типа ser и там уже направлять звонки на рабочие сервера *
Outbound proxy реализовать на кластере из хотябы 2-х машин для надежности и управлять маршрутизацией на них для балансировки нагрузки

Круто завернул правда Very Happy
#8

2 Ded
В Вашем случае резервирование исходит от клиента и как Вы правильно заметили "Не для всех пользователей"
2 Serega
А как быть с IAX ?

По-моему IMHO, если первоначальный коннект клиента идет к Asterisk, всеж таки IP PBX, будь то H323/SIP/IAX - не важно, надо его и кластеризовать, а далее научить * пробрасывать Dial(ы) на другие * в случае timeout.
#9

2 Serega: ну вот dyer же указал как раз на такое решение - VOCAL by VoVIDA
Я много тыркался с ним, продукт агроменный, и предполагает как раз масштабирование по кластерному принципу. Но, только SIP, про IAX он не знает.
#10

Вот зачем AGI придумали?
(не говоря ужо об экстеншнах а-ля t, n+101, n+1 )
...шоб было... но какой это, нах, кластер...
не круто... мы лучше желяски вумные возьмем... у нас в них опытов больше...

Нет, нас перлам в школах не учили!

А еще тут можно динамичный роутинг по туннелям устроить...
...о, и сбалансировать их, нах.
#11

2 bsg: есть известная осторожность заказчиков в реализациях толстых решений на OpenSource. А продумывать redundance до уровня кластера, это IP PBX с числом extensions > 1000.
Я думаю это и есть тормозящие предпосылки таких построений. Хороший Linux cluster можно строить на RedHat Enterpise, минимальное железо для этого - 2 симметричных нода + внешний разделяемый дисковый массив - storage, он конечно SCSI, ведь никто не даст под это дело Fibre Channel диски Smile
Теория: в архитектуре кластера каждый нод имеет свой ИП адрес и все они увязаны на один виртуальный ИП адрес, который для внеших аппликаций (клиентов) выглядит как простой сервер.
#12

Serega писал(а):

Круто завернул правда Very Happy


Если действительно такая система нужна, то она уже существует... у нас... Ноды там равноправны - в опическом кольце - перифирийным можно делать любой нод, несколько или все с соответствующей балансировкой... Для телефонии E1, FXO/FXS ну и ethernet (для ip phonов). Пропускная способность не ограничена (наращивается нодами и fiberом). Статистика, мониторинг и т.д. LAN и WAN организуются на них же...

Но это не дешево.
(мы ужо как-то с Вами переписывались, неудачно...)

А дешево - два нода с одинаковыми конфигурациями и простыми перловыми демонами, которые в случае потери нода/канала на себя все берут.


Последний раз редактировалось: Lev (Вс Мар 06, 2005 14:30)
#13

Ded писал(а):
известная осторожность заказчиков в реализациях толстых решений на OpenSource


Неправда...
#14

Lev писал(а):
мы ужо как-то с Вами переписывались, неудачно...

А что же у нас не вышло-то ?
Надо сделать удачно Wink
ася и мыло открыты, давай поробуем еще Exclamation
меня очень интересует как обеспечить безотказность сервиса, поскольку у нас в локалке * бывает падает
есть у нас умельцы настраивать сеть непойми как =)