История изменений [назад]

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

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

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

Система всегда бакапит каждый час все настройки, держит заданное количество копий (обычно 5) за час, и за день (10)
Для резервирования есть отдельный список настроек, он не включает в себя, например, сетевые. Архив с настройками для слейва складывается на HTTP.
Слейв подбирает архив с заданной периодичностью. Я не помню, но вроде бы перезагружаем ящик или там по-другому применяются изменения. Это происходит в фоне.
В каждом ящике имеется набор скриптов, которые обслуживают систему: удаляют временные файлы, следят за памятью, переполнением диска, процессами. Все это для того, чтобы не требовалось вмешательства и обслуживания, ибо памяти мало (изменения в RAM).
Записи разговоров не бакапятся, остаются там где их сделали, ибо это некритичная функция. Когда что-то валится, запись разговоров волнует в последнюю очередь.
Каждый ящик имеет ОС на флеш носителе, который всегда в режиме RO, и подключается в RW раз в час во время сохранения конфигурации, т.о. серьезно исключаем сбой ФС.
Один бакап системы весит 8..40 мб и позволяет полностью восстановить работу ящика в короткие сроки, которые примерно равны времени записи прошивки и бакапа на флешку (1.5 гб)
В довесок каждый ящик имеет сторожевой таймер, который ребутает ящик аппаратно если что-не так.

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

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

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

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