Пожалуйста, войдите здесь. Часто задаваемые вопросы О нас
Задайте Ваш вопрос

Asterisk Real Time HA

0

Здравствуйте

Поскольку поиск дает, в основном, старые темы, спрошу здесь: как сейчас обстоят дела с резервированием Asterisk с высоким уровнем надежности. Может, появились какие устоявшиеся решения, готовые к установке без длительного багфиксения. Open Sorce совершенно не обязательно.

Начальные условия такие:

  1. Подключения как внешние, так и внутренние - только по IP. AS есть, BGP с провайдерами тоже. Возможно будут факультативные FXO/FXS шлюзы, их резервирование не требуется.
  2. Количество внутренних абонентов - до 120, терминалы предполагаются Yealink/TipTel.
  3. Переключение серверов, вплоть до выключения одного из них - без перерыва сервиса, т.е. HAAST в чистом виде - не очень устраивает.
  4. Решение создается "с нуля", будет использоваться только существующая сетевая инфраструктура.

Большое спасибо всем за ответы и комментарии. Ясно, что многое можно сделать и многое хочется, но, исходя из существующих промышленных, серийных решений, остановлюсь на простой кластеризации с мониторингом, типа Heartbeat/asha.

удалить закрыть спам изменить тег редактировать

спросил 2012-09-17 12:54:29 +0400

DVK Gravatar DVK
1 1 3

обновил 2012-09-19 17:16:52 +0400

Comments

Если надо, можем запилить вам систему отказоустойчивую. У нас есть прототип системы управления для кластеризованного астериска. Могу дать посмотреть тестовый доступ.

switch ( 2012-09-19 17:18:26 +0400 )редактировать

5 Ответов

2

120 абонентов - не повод для HA. Поднимите два идентичных сервера и реплицируйте с мастера на слейв изменения, при отказе мастера вручную переходите на слейв. Если бы было 1200 абонентов, тогда да, резервирование имело бы смысл.

UPDATE: Оказалось, что еще один ответ нельзя запостить. Потому просто дополню:

У нас же сделано так:

  1. Система всегда бакапит каждый час все настройки, держит заданное количество копий (обычно 5) за час, и за день (10)

  2. Для резервирования есть отдельный список настроек, он не включает в себя, например, сетевые. Архив с настройками для слейва складывается на HTTP.

  3. Слейв подбирает архив с заданной периодичностью. Я не помню, но вроде бы перезагружаем ящик или там по-другому применяются изменения. Это происходит в фоне.

  4. В каждом ящике имеется набор скриптов, которые обслуживают систему: удаляют временные файлы, следят за памятью, переполнением диска, процессами. Все это для того, чтобы не требовалось вмешательства и обслуживания, ибо памяти мало (изменения в RAM).

  5. Записи разговоров не бакапятся, остаются там где их сделали, ибо это некритичная функция. Когда что-то валится, запись разговоров волнует в последнюю очередь.

  6. Каждый ящик имеет ОС на флеш носителе, который всегда в режиме RO, и подключается в RW раз в час во время сохранения конфигурации, т.о. серьезно исключаем сбой ФС.

  7. Один бакап системы весит 8..40 мб и позволяет полностью восстановить работу ящика в короткие сроки, которые примерно равны времени записи прошивки и бакапа на флешку (1.5 гб)

  8. В довесок каждый ящик имеет сторожевой таймер, который ребутает ящик аппаратно если что-не так.

Таким образом если что-то валится, то максимум что потеряем так это настройки и CDR за последний час работы.

Для автоматического определения отказа на каждой ноде имеется отдельная служба, которая мониторит состояние системы по нескольким критериям. Основной из них - контрольный список SIP экстеншенов, которые и являются арбитром. Есть такие шлюзы и телефоны, которые умеют бакапить регистрацию на резервном сервере. Как только один становится недоступным, они переходят на второй и мониторят первый.

Если нода вдруг обнаруживает, что этот 75% из них не зарегистрированы, она освобождает разделяемый адрес, отключает eth интерфейс через который приходит Е1 (TDMoE девайс). В то же время если нода обнаруживает, что контрольный список экстеншенов зарегистрировался, она считает что она стала основной, поднимает разделяемый адрес, подключает E1.

Все переключение занимает несколько минут (обычно две), но при этом мы имеем некоторое множество гарантированно независимых арбитров, которые коллегиально решают кто жив, а кто мертв. В этой схеме разделяемый адрес нужен для устройств, которые не умеют резервировать регистрацию.

ссылка удалить спам редактировать

ответил 2012-09-17 13:55:36 +0400

switch Gravatar switch
8334 11 7 92
http://lynks.ru/

обновил 2012-09-18 06:38:42 +0400

Comments

зачм велик с квадратными колесами делать если есть готовый мопЭд с круглыми ? HA настраивать проще чем "делать 2 идентичных сервера и вручную переключать их"

komrad123 ( 2012-09-17 14:04:34 +0400 )редактировать

Для меня ваш способ - изобретение велика с квадратными колесами, ибо эта схема давно себя оправдала, все для нее понаписано. Но делали так всего пару раз, ибо и без этого все работает нормально. А делать HA на хербите это для мастеров извращений. По крайней мере так было в 2007 году, может сейчас допилили.

switch ( 2012-09-17 14:16:44 +0400 )редактировать

Мастера извращений это те кто не мог разобраться в HA с 2007 года и поэтому написал кучу вело-скриптов которые делают тоже самое (?) что hearbeat+drbd но через Ж...

komrad123 ( 2012-09-17 14:36:09 +0400 )редактировать

Кто-то готов поставить один сервер и заключить недешевое SLA на работоспособность "6 девяток" (простой сервиса - 10 мин/год)? Вот и ищу решение, которое давно реализовано в традиционной телефонии, хоть и у каждого по-своему. Еще раз, давайте не путать HA и load balansing. HA может быть актуально и для 5 абонентов, смотря какие абоненты.

DVK ( 2012-09-17 14:44:44 +0400 )редактировать

2 komrad123: давным-давно я попробовал hearbeat+drbd и понял что это не то. Почему? на этом форуме я много раз отвечал на этот вопрос. Я просто взял и написал что мне нужно: систему, которая однозначно анализирует отказы, реплицирует изменения, убивает мертвую ноду.

2 DVK: 6 девяток в современном мире - нереально. У вас отказ других сервисов будет происходить чаще. Я не знаю какова ваша задача, но SLA должно расти пропорционально количеству абонентов и я ни разу не видел контору, которая готова платить за шесть девяток. В любом случае пока вы поднимете и отладите это решение у себя вы получите много отказов, что на первый год эксплуатации однозначно перечеркнет мечты о шести девятках.

Возможно вам стоит глянуть в сторону freeswitch, там есть механизм дублирования состояния между нодами, можно добиться горячего резервирования.

В настоящее время мы разрабатываем прототип системы которая подходит под ваши требования, но до готовности еще далеко. Только вот на этой неделе принялись за маршрутизацию ;)

switch ( 2012-09-17 14:54:38 +0400 )редактировать

"вы получите много отказов" - ну, на это есть тестовая эксплуатация. Будет много отказов - не будет внедрения и все. Freeswitch - скорее, операторское решение, а здесь хочется небольшую удобную и надежную офисную PBX с хорошей и работающей функциональностью.

DVK ( 2012-09-17 17:30:33 +0400 )редактировать

никогда не используйте drbd если не уверены что без него никак. востановления пофейленного дрбд требует уровня гуру во внутреностях файловых систем. я таких людей знаю немного. а вы?

meral ( 2012-09-17 19:19:31 +0400 )редактировать

2 meral: Вот и я о том же. В drbd+ha никогда не знаешь, где остались корректные данные. Телефония - не та задача, которая требует drbd+ha, настройки меняются раз в месяц.

2 DVK: Если интересно, можете посмотреть наши девайсы. Шесть девяток гарантировать не можем, но необслуживаемость, быстрое восстановление, автоматическое резервирование и прочее - у нас есть, многое сделано в сторону улучшения надежности. Если интересно, пишите на сайте в мессенджер или на емайл sales@lynks.ru

switch ( 2012-09-17 19:24:22 +0400 )редактировать

lol. на * врядли получится сделать выше трех девяток. больше трех - это хардварные системы с резирвированием.

meral ( 2012-09-17 19:31:44 +0400 )редактировать

switch, то есть cdr вы пишите раз в месяц, запись звонков тоже раз в месяц, логин пользователь в гуй строго первого числа в 9-00 а штатное падения конечноже после отработки кроновских скриптов для бекапа ? :)

komrad123 ( 2012-09-17 20:11:25 +0400 )редактировать

cdr пишется в базу(master-master) а запись звонков во временную папочку а потом там в конце скриптик отрабатывает в котором ВООБЩЕ не проблема написать скопировать на оба хоста.

meral ( 2012-09-17 20:48:52 +0400 )редактировать

тоесть эксперт по восстановлению базы master-master из состояния она "встала раком" находится быстрее чем тот же експерт по drbd ? вот это вот 'скриптик тут, скриптик там костылик тут' выливается при уходе "спеца" нагородившего это в 'бл* кто это делал'

komrad123 ( 2012-09-17 21:16:41 +0400 )редактировать

да. намного быстрее. ибо если увас сделан мониторинг, то "стала раком" это одна копия не синхронизирована(заметьте, у меня ОДНА работает). и синхронизация это стандартная операция выполняемая за несколько минут. и даже если не так, то всегда можно потрочно вотановить. это вам не востановление ФС. у вас будуте ДВЕ рабочие базы. да если архитектура плохая, то в них будет разные данные. но они БУДУТ. а с дрбд нефига не будет. и первое дествия во всех руководствах по востановлению будет "выключить сервис".( базой всего лишь "выключить вторую базу")

meral ( 2012-09-17 22:15:07 +0400 )редактировать

а нефиг костылики к репликации прикручивать. они и так работает вполне стабильно.и ОЧЕНЬ стабильно если писать в одну.

meral ( 2012-09-17 22:16:42 +0400 )редактировать

какой тогда нафиг это ХА, если есть время одну остановить, вторую построчно восстановить ? детский сад какой то. Все что приходилось видеть с drbd это падали обя линка между нодами и они "теряли" друг друга, после чего обе счтали себя мастероми продолжали жить дальше, но также приводились в чуства автоматом либо руками. чтоб там покрашилась FS надо было СИЛЬНО постараться.

komrad123 ( 2012-09-17 22:39:17 +0400 )редактировать
1

я в таких случаях(абонентов меньше 1000) делаю так 2 сервера. 4+1 адрес. 2 kamailio. 4 астериска (по два на каждом).

1 failover ip на pacemaker. на нем основной kamailio. kamailio делает редиректы, медиа трафик идет напрямую на *.

1 nagios.это обязательно. без мониторинга - лучше и не начинать эту канитель.

все файлы бекапяться и синкаются любым удобным методом(rsync/glusterfs/scp) ТОЛЬКО с мейн ноды. инкрементальный бекап раз в 12 часов.

все управление в mysql

mysql master-master.

конфиг переживает сбой любого астериска и холодный сбой одной ноды. да с обрывом разговоров. но вероятность сбоя ноды достаточно низкая и падение на минуту раз в год вполне допустимо. падение по другим причинам более вероятно честно говоря.

drbd - бред. шанс сбойнуть как показывает практика - больше чем без него. ибо сверху него надо потом кластерную файловую систему что редко кто делает и вообще внимательно за ним следить.

хотите без потери одной минуты? варианты 1) можно чисто на камилиа сделать.он поддежривает. сложно. очень. очень. да.сильно сложно. 2) есть патченые платные форки *. дорого.

3) можно сделать xen в режиме HA c виртуальным астериском и вторым в режиме тени. при падении первого второй нод взлетает за 100мс. без потерь звонков. RAM синкается по сети. производительность плохая. надежность высокая. сложноть настройки высокая. гдето видел, но чето не найду ссылки. ипользуетя какойто демон который держит готовую к live migration копию ос и постоянно ее синхронизирует. ага. вот http://wiki.xen.org/xenwiki/Remus. но только 100500 раз подумайте есть ли у вас xen guru с необходимым скилом и необходимым уровнем доступности чтоб ЭТО запустить и что главное потом ВОСТАНОВИТЬ если что. если б мне ставили такие условия, я бы назвал цену сетапа 5000 и цену поддержки 600 в месяц.

ссылка удалить спам редактировать

ответил 2012-09-17 19:28:40 +0400

meral Gravatar meral flag of Ukraine
23347 24 20 177
http://pro-sip.net/

обновил 2012-09-17 19:47:57 +0400

Comments

2 сервера * через kamailio - это, как я понял, для load balansing. В данном случае (100-120 пользователей) это не надо, kamailio тоже уходит и остается уже проверенный вырожденный случай - два * с HA. На нем, наверное, и надо остановиться, умерив аппетиты (6 девяток, непрерывность).

ЗЫ: Nagios - это ,конечно, это наше все, но уже мигрируюсь на cacti.

Про xen - это сильно. Если обязательно нужен гуру, чтобы ЭТО ВОССТАНОВИТЬ, то лучше ну его, это не решение, а экспериментальная площадка. А экспериментировать с людьми, которые платят зарплату как-то не с руки :)

DVK ( 2012-09-19 14:22:40 +0400 )редактировать

неа. 2 севера * на каждом это потому,что астериск иногда зараза падает без обьяснения причин. причем явно наблюдаетя зависимость от нагрузки. тоесть так вы уменьшаете шанс выхода из строя раза в четыре. конфиг камалио для балансировки вообще простой. и стоит годами.

meral ( 2012-09-19 18:06:25 +0400 )редактировать
0

Kamailio + два asterisk в режиме realtime.

ссылка удалить спам редактировать

ответил 2012-09-17 13:17:33 +0400

awsswa Gravatar awsswa flag of Russian Federation
685 5 2 9

Comments

Т.е. вместо одной точки отказа получаем другую? Load balansing не нужен. Если только в качестве SIP-proxy использовать какую-нибудь высоконадежную железку.

DVK ( 2012-09-17 14:35:57 +0400 )редактировать

А есть примеры кластеризации того же Kamailio или Yate? А если эти 4 сервера в виртуалки на два физических хоста запихнуть? Или бред?

DVK ( 2012-09-17 17:35:34 +0400 )редактировать

заставить сбоить камалио - уметь надо. а астериск - раз плюнуть. такчто количество точек отказа падает.ну понятно надо мониторинг нормальный ставить

meral ( 2012-09-17 19:18:16 +0400 )редактировать

камалио нормально себя чувствует в виртуальной машине

komrad123 ( 2012-09-17 20:13:43 +0400 )редактировать

это вы к чему? ну да ногрмально.а без нее лучше. и что?

meral ( 2012-09-17 20:47:44 +0400 )редактировать

это я к предложению топик стартера про два физ сервера и 4 виртуальных

komrad123 ( 2012-09-17 21:12:42 +0400 )редактировать

так такое есть. Ramus называется.

meral ( 2012-09-17 22:19:18 +0400 )редактировать
0

У VmWare очень хорошо с HA в конфигурации 2 ноды + 2 внешних NAS'а. В варианте с FC NAS оно конечно будет стоить как самолет но мне кажется что варианта iSCSI через гигабитную сеть тоже должно хватить если не писать 100500 одновременно идущих разговоров.

При выходе из строя любой из 4-х единиц оборудования текущие разговоры не прервутся.

Ну и остается вопрос в том, как себя будет вести сильно нагруженный астериск в виртуалке. Опыт показывает что 5-10 разговоров проблем не составляют а вот больше...

ссылка удалить спам редактировать

ответил 2012-09-18 12:35:00 +0400

SolarW Gravatar SolarW
356 2 10

обновил 2012-09-18 12:35:36 +0400

Comments

VmWare c 2-мя нодами и внешними SAN/NAS...Почему бы нет? По идее должно работать. А может и не будет. 5-10 разговоров - это несерьезно, если только на старых айфонах ноды собирать :) Будет устойчивое решение когда-нибудь у кого-нибудь - будет о чем говорить.

DVK ( 2012-09-19 13:59:17 +0400 )редактировать

угу. вмваре имеет пробелмы с одной нодой. а будет ли работать две - ну смотрите мои коментарии по xen+ramus. то же самое.

meral ( 2012-09-19 18:19:57 +0400 )редактировать
0

с 3 пунктом засада - если медиа через астериск шла, то второй ее не подхватит.

  • для каких целей этот HAкластер будет использоваться ?
ссылка удалить спам редактировать

ответил 2012-09-17 13:51:15 +0400

komrad123 Gravatar komrad123
3810 5 3 44

Comments

Офисная телефония, делаем себе, т.е. end user.

DVK ( 2012-09-17 14:37:31 +0400 )редактировать

Ваш ответ

Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
[скрыть предварительный просмотр]

Закладки и информация

Добавить закладку
2 закладки

подписаться на rss ленту новостей

Статистика

Задан: 2012-09-17 12:54:29 +0400

Просмотрен: 1,255 раз

Обновлен: Sep 19 '12

Похожие вопросы:

Проект компании "АТС Дизайн"
Asterisk® и Digium® являются зарегистрированными торговыми марками компании Digium, Inc., США.
IP АТС Asterisk распространяется под лицензией GNU GPL.