Отказоустойчивый кластер Asterisk / FreePBX: настройка Corosync, Pacemaker и DRBD
- Простой телефонии предприятия при аппаратном сбое основного сервера PBX.
- Состояние Split-Brain (обе ноды одновременно считают себя мастером и пытаются поднять один и тот же IP).
- Ресурс Asterisk в Pacemaker переходит в статус
FAILED / Unmanaged. - Рассинхронизация записей разговоров, очередей и конфигураций между Master и Slave серверами.
1. Архитектура решения Active-Passive
- Virtual IP (VIP): 192.168.1.100 (единый адрес для SIP-клиентов и транков).
- DRBD: блочная репликация каталогов
/etc/asterisk,/var/lib/asterisk,/var/spool/asterisk. - Corosync + Pacemaker: мониторинг здоровья нод, управление кворумом и переключение ресурсов.
2. Конфигурация Corosync (/etc/corosync/corosync.conf)
totem {
version: 2
cluster_name: asterisk-ha
transport: knet
crypto_cipher: aes256
crypto_hash: sha256
}
nodelist {
node {
ring0_addr: 192.168.1.10
nodeid: 1
}
node {
ring0_addr: 192.168.1.11
nodeid: 2
}
}
quorum {
provider: corosync_votequorum
no_quorum_policy: stop
}3. Создание кластерных ресурсов в Pacemaker (pcs)
# Авторизация и запуск кластера
pcs host auth pbx-node1 pbx-node2
pcs cluster setup asterisk-cluster pbx-node1 pbx-node2
pcs cluster start --all
pcs cluster enable --all
# Отключение STONITH для 2-нодового тестового стенда (в проде использовать IPMI STONITH!)
pcs property set stonith-enabled=false
# Создание плавающего IP
pcs resource create ClusterIP ocf:heartbeat:IPaddr2 ip=192.168.1.100 cidr_netmask=24 op monitor interval=5s
# Создание ресурса Asterisk
pcs resource create AsteriskService systemd:asterisk op monitor interval=10s timeout=20s
# Привязка ресурсов к одной ноде (Colocation & Order)
pcs constraint colocation add AsteriskService with ClusterIP INFINITY
pcs constraint order ClusterIP then AsteriskService4. Проверка статуса кластера
pcs status
crm_mon -1 Частые вопросы (FAQ)
Что происходит с активными разговорами в момент аварийного переключения кластера?
Текущие активные RTP-разговоры прерываются, так как состояние каналов ядра не реплицируется в реальном времени. Новые вызовы начинают обрабатываться в течение 5–10 секунд после поднятия Virtual IP на резервной ноде.
Зачем нужен STONITH (Shoot The Other Node In The Head)?
STONITH физически отключает питание зависшей ноды через IPMI/iLO/PDU, гарантируя, что старый сервер не начнет одновременно писать на общий реплицируемый диск DRBD и не вызовет повреждение базы данных (Split-Brain).
Как синхронизировать базу данных MySQL/MariaDB (CDR/FreePBX)?
Либо размещать /var/lib/mysql на реплицируемом томе DRBD, который монтируется только на активной ноде, либо использовать Master-Master репликацию Galera Cluster / MariaDB Replication.
Как предотвратить перерегистрацию телефонов при переключении нод?
SIP-телефоны должны быть настроены на Virtual IP (192.168.1.100). При переносе IP телефоны отправляют повторные запросы и восстанавливают связь без вмешательства пользователя (при условии низкого таймера registration expiry = 120 сек).