Концепции высокой доступности и кластеризации

В предыдущих модулях мы научились собирать метрики производительности и визуализировать их в Grafana. Однако даже идеальный мониторинг лишь констатирует факт: «Сервер недоступен, связь прервана». Для корпоративных систем в 2026 году простой в несколько минут — это потерянные клиенты и репутация. Настало время перейти от наблюдения к созданию систем, способных выживать самостоятельно.

Фундамент надежности: Отказоустойчивость и HA

Когда мы говорим о надежности АТС, важно различать три понятия, которые часто путают.

• Отказоустойчивость (Fault Tolerance) — способность системы работать при поломке отдельных компонентов (например, блока питания или сетевой карты).
• Высокая доступность (High Availability, HA) — комплекс мер для минимизации простоя. Доступность измеряют в «девятках». Стандарт индустрии — «пять девяток» (99.999%), что означает не более 5 минут простоя в год.
• Кластеризация — объединение нескольких серверов (узлов) в единую логическую единицу. Узлы следят за состоянием друг друга. Если «Мастер» (основной сервер) падает, «Стендбай» (резервный) подхватывает его функции.

Модели резервирования

Выбор архитектуры зависит от того, допустим ли обрыв текущих разговоров при аварии. Как показано на Схеме 1, существует три подхода.

1. Холодный резерв. Второй сервер выключен. При аварии вы включаете его вручную, восстанавливаете бэкап и переключаете кабели. Простой: от 30 минут.
2. Теплый резерв. Резервный сервер включен, конфигурации синхронизированы. При аварии запускается скрипт перехвата управления. Простой: 1–3 минуты. Звонки обрываются, телефонам нужна перерегистрация.
3. Горячий резерв. Оба сервера работают параллельно, данные реплицируются в реальном времени. Переключение мгновенное (Seamless Failover). Простой: доли секунды.

Для связки Asterisk и FreePBX в 2026 году самым стабильным остается Active-Passive (Теплый резерв). Модель Active-Active (оба сервера принимают звонки одновременно) часто приводит к конфликтам в базе данных и логике FreePBX.

Ключевые компоненты HA-кластера

Чтобы кластер работал бесшовно, нужно настроить три процесса:

1. Виртуальный IP (VIP)

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

2. Репликация данных

Резервный сервер должен быть точной копией основного. Что синхронизируем:

• Конфиги: файлы в /etc/asterisk/.
• Базу данных: настройки FreePBX в MySQL/MariaDB (используем стандартную репликацию).
• Медиа: записи разговоров и приветствия IVR (через сетевое хранилище или rsync).

3. Репликация состояния (State Replication)

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

Опасность Split-brain

Самый опасный сценарий — Split-brain («раздвоение мозга»). Это ситуация, когда связь между серверами пропала, но оба они исправны.

Резервный сервер решает, что основной упал, и забирает себе VIP. Основной сервер продолжает держать VIP у себя. В сети появляются два устройства с одинаковыми IP, что вызывает хаос в маршрутизации и повреждение баз данных. 🕸️

Для защиты используют:

• Quorum (голосование): узлы должны подтвердить статус друг друга через «третейского судью».
• Fencing (изоляция): принудительное отключение отказавшего узла (метод STONITH — Shoot The Other Node In The Head).

---

Мы разобрали теорию и теперь понимаем: высокая доступность — это не просто «второй сервер рядом», а настроенная синхронизация и контроль состояний.

В следующей теме перейдем к практике: настроим Keepalived, чтобы реализовать механизм плавающего IP-адреса для автоматического переключения вашей АТС.