Полагаю, все кто на этом форуме присутствуют, задавались вопросом, как сделать систему еще надежнее. Самый простой способ - поднять linux ha. Кому интересно, тому сюда:

http://www.opennet.ru/docs/RUS/ha_cluster/
http://www.opennet.ru/base/sys/ha_cluster_setup.txt.html
http://xgu.ru/wiki/DRBD
http://www.trixbox.org/forums/trixbox-forums/open-discussion/looking-ha-asterisk-solution

Когда linux ha поднимается, имеем обычно 2 сервера, один из них - первичный, другой - вторичный. Оба имеют дисковый drbd раздел, который непрерывно реплицируется на вторичный узел. Когда первичный валится, вторичный становится первичным и имеет полную копию данных. На нем монтируется для записи drbd раздел, поднимаются сервисы и общий IP, drbdlinks делает символические ссылки, сопоставляя нужным элементам ФС элементы на разделяемом разделе.

Все это работает нормально, но есть недостатки. Неочевидно, но нужно 3 сервера. Иначе возможна ситуация, когда связь между серверами порвалась и оба сервера, решив что они неисправны, сами себя отключают. В итоге - ничего не работает. Нужна третья сторона, которая осуществляет арбитраж. Помимо проблемы с арбитражом имеется и другая. На моей практике из-за корявого прова сам сервер виснет (я писал на форуме), но продолжает пинговаться. Linux HA на сколько я понимаю, смотрит, есть ли пинги, а нужно определять доступны ли сервисы.

Идея:
Берем любой телефон (или шлюз, и лучше - несколько), который имеет 2 регистрации: на основном и резервном сервере. Если SIP сервис недоступен, то телефон автоматом регистрируется на резервном сервере. Скрипт на резервном (и на основном) сервере периодически смотрит, есть ли регистрация этого телефона, и если есть, узел становится первичным.
Трудности:
1) нужно отключать первичный сервер. Можно использовать шлюз или телефон, у которого загорается лампочка, если пропадает регистрация (dlink новой серии, thomson), этой лампочкой управлять реле и тд по вкусу. Мне, например, технически не сложно собрать копеешный usb девайс на AVR309 и несложную прогу на дельфи (кому интересно, можете погуглить, действительно все просто), которая будет простейшим sip клиентом, работать под виндой (я не умею под линь програмить), мониторить наличие sip коннекта и при случае, мочить отказавший сервак.
2) если мониторить появление sip регистрации на резервном сервере, то asterisk должен быть запущен, что идет в разрез с идеологией linux ha, где астериск - резервиремый сервис. К тому же drbd не позволяет получить доступ к данным с вторичного узла, только если он стал первичным. Как вариант - * всегда запущен на обоих машинах, но скрипы linux HA не запускают его при останове узла, а перезапускают тогда, когда drbdlinks подставил вместо дефолтных конфигов - общие. Но что в этом случае делать с отказавшим сервером?

Резервирование ZAP не рассматриваю, так как это отдельная тема. Интересует только SIP.

вопрос в зал:
1) Кто и как решает подобные задачи, если не секрет? Ведь 1 физический сервер на 500-1000 пользователей это несерьезно с точки зрения отказоустойчивости.
2) Что делать после восстаноления сбоя? Как назначить/прибить первичный linux ha узел из командной строки?

Уважаемый switch, не хотите расширить свои ТЕОРЕТИЧЕСКИЕ знания по high-availability? Уже давно выработаны концепции, устойчивые термины, на базе которых готовые реализации. Предлагаю придерживаться этих терминов, иначе - инструкция "Как в домашних условия собрать ракету для полёта на Марс".

Тема решается концептуально: кластер и его ноды. Самый простой кластер описан у вас выше, в режиме Актив/Пассив, только уточняю: оба нода имеют обший доступ к дисковому внешнему массиву с данными, при такой конфигурации не нужно непрерывно реплицировать данные. Варианты подключений к такому массиву: iSCSI, Fibre Channel, в широко разнесённом варианте и NFS. Надёжность самого массива обеспечивается избыточностью RAID 5 и более, двумя контроллерами, двумя блоками питания, и пр. Очевидно, что такая схема экономически невыгодна - один нод почти всегда "спит" в режиме Пассив.

Поэтому прогрессивные схемы Актив/Актив более интересны, но трудны в настройке.
В таком варианте у каждого нода сой функционал, но он знает о функционале второго нода, и в случае failure берёт на себя двойной функционал. Связь между локальными и удалёнными осуществляется через функцию heartbeat, название говорит само за себя. Локально - это специальный сигнальный провод, удалённо - это всякие подобия пингеров.

Теперь о ИП адресации. Ваша идея вполне функциональна и работает, лучше на Н.323, хуже - на SIP, но к сожалению с низким процентом отказоустойчивости всех пользователей в целом, так как перерегистрация на другой сервер происходит мгновенно только у шлюзов, абоненты перетекают кто-как, зависит от таймеров registration expired.

В варианте кластера - он имеет один (!) ИП адрес, неважно, сколько нодов подключено. Через load balancer он превращается в ИП адрес конкретного нода, активного в текущий момент внутри системы.

Понятно, что назначать, прибивать из командной строки ничего не нужно. Такая система может обслуживать и более 10 000 человек.

ded, спасибо за ответ, я все это понимаю. Как понимаю и что такое кластер и чем настоящий кластер отличается от кластера просто отказоустойчивого.

Теперь ситуация, может так будет понятней всем:
Имеется 2 сервера и 300 телефонов грандстрим BT 200. эти телефоны при всех своих достоинствах имеют недостаток: у них нет возможности регистрации на резервном сервере. И нет никаких внешних NFS и прочих scsi массивов. Это слишком дорого и объемы данных не те. Нужно сделать отказоустойчивое решение.

Если рассматривать другие телефоны, умеющие регистрироваться на втором сервере, то тут время перерегистраци не имеет значения. можно поставить 1 минуту, этого вполне хватит. Но и в этом случае возникает засада: как второй сервер узнает, что первый сервак сдох, а не порвалась связь между ними?

классический кластера конечно хорош. Но реализация его сложна. Да и имеем тонкое место - load balancer (SER?). И опять же, возникает вопрос о внешнем дисковом массиве... Но высокая производительность не нужна. Нужна избыточность. а heartbeat не умеет мониторить SIP пртокол. СOM порт - да, пинги - да. а нужный сервис - нет.

В общем вопрос остается открытым. Кто-нибудь из старожилов делал избыточное резервирование? Или упомянутые кластеры балансировки нагрузки?

пока как работающее решение вижу:
- периодическое копирование/реплицирование настроек на резервный сервер. хотябы тупо бакапами freepbx.
- скрипт мониторит каждую минуту 10 эталонных телефонов/шлюзов.
- если эти телефоны регистрируются, то присваивать себе общий IP
- если эти телефоны пропадают (не пингуются), то освободить IP.
- на обоих серваках сделать переход switch => (толком не понял как работает)

при этом: никакого гимора со SCSI и drbd, и гарантировано наблюдение за сервисом SIP

Но опять: как гарантировано прибить неработающую ноду?

Изучай именно варианты с load balancer. Это чисто ИП решение. Именно load balancer слушает ноды и роутит запросы к живому.

а кто будет смотреть за смотрящим?
т.е. кто будет следить чтоб не сдох load balancer?
хороший вариант - DNS балансир. Но на мелкомягком DNS такое не сделаешь наверно.

в общем, как я понял, никто из форумчан такую задачу не решал