Систем диагностики — одна из компонент, обеспечивающих отказоустойчивость кластера. Система диагностики проверяет доступность узлов кластера и при отказе восстанавливает виртуальные машины на доступных узлах кластера.
В основе системы диагностики: система corosync и сервис собственной разработки corolistener.
corosync
Corosync при запуске автоматически определяет участников кластера с помощью multicast/unicast пакетов, адресованных на определенный IP-адрес и порт. Подробно о настройке транспорта, IP-адреса и порта для corosync см. в статье Настройка облачных функций.
Файл конфигурации corosync — /etc/corosync/corosync.conf. Настраивается corosync панелью управления на основе данных о подключенных узлах кластера. Файл конфигурации corosync содержит следующую информацию:
Основная секция (пример с использованием multicast):
totem {
interface {
bindnetaddr: 172.31.223.47
mcastaddr: 239.255.1.1
mcastport: 5405
ttl: 1
}
config_version: 1
cluster_name: VMmanager
}
quorum {
expected_votes: 3
}
ihttpd {
count: 1
port0: 1500
}Секция списка узлов кластера:
nodelist {
node {
ring0_addr: 172.31.223.46
nodeid: 2
prio: 99
replication: on
}
node {
ring0_addr: 172.31.223.47
nodeid: 4
prio: 100
replication: on
}
node {
ring0_addr: 172.31.223.48
nodeid: 8
prio: 98
replication: on
}
}corolistener
Сервис corolistener является собственной разработкой компании ISPsystem. Corolistener анализирует сообщения corosync и принимает решения о необходимости восстановления сервисов, либо переноса виртуальных машин на другой узел. Также как и corosync, corolistener запускается при включении облачных функций. При добавлении сервера в кластер со включенными облачными функциями, сервис corolistener начинает работать сразу после присоединения узла к кластеру. Corolistener расположен в директории /usr/local/mgr5/sbin/corolistener.
На каждом узле кластера сервис corolistener самостоятельно обрабатывает события corosync и в случае изменения состава узлов кластера производит анализ кворума. В результате анализа могут быть запущены следующие процессы:
- узел оказался в меньшинстве, то есть количество "живых" узлов меньше кворума: работа приостанавливается, виртуальные машины выключаются;
- узел оказался в большинстве и приоритет узла самый высокий из "живых": узел становится мастером, при этом выполняются следующие действия:
- на сетевой интерфейс узла кластера добавляется IP-адрес кластера (лицензии). Добавляется он на интерфейс, который определен параметром CloudIpDev конфигурационного файла VMmanager (по умолчанию — vmbr0) и с маской, которая определена параметром CloudMask. Конфигурационный файл по умолчанию расположен в /usr/local/mgr5/etc/vmmgr.conf;
- создается файл /tmp/.lock.vmmgr.service и запускается VMmanager. Файл /tmp/.lock.vmmgr.service является признаком того, что узел кластера, на котором файл расположен, является мастером;
- если отсутствует файл /tmp/.lock.vmmgr.relocated, то VMmanager считает, что только что перенесен на узел кластера. В этом случае VMmanager скачивает реплику базы данных и перераспределяет виртуальные машины, которые были на вышедших из строя узлах кластера, создает файл /tmp/.lock.vmmgr.relocated. Файл /tmp/.lock.vmmgr.relocated удаляется после того, как узел кластера перестаёт быть мастером;
- corolistener меняет приоритет узла с предыдущим мастером, обновляет файл конфигурации corosync и рассылает сообщение оставшимся узлам кластера о том, что они должны запросить у мастера новый файл конфигурации corosync.
- узел оказался в большинстве и приоритет узла не самый большой — узел продолжает работать в режиме slave.
Для просмотра текущего состояния кластера, можно использовать средства corosync:
corosync-quorumtool -l
Membership information
----------------------
Nodeid Votes Name
7 1 172.31.224.72 (local)
9 1 172.31.224.74
13 1 172.31.224.80Либо средства corolistener:
/usr/local/mgr5/sbin/corolistener -l
VMmanager-cloud node list
=============================================================
Id Ip Status Master/Slave Priority
7 172.31.224.72 joined M 100
9 172.31.224.74 joined S 40
13 172.31.224.80 joined S 10Вывод corolistener более информативный, так как показывает основной узел и приоритет узлов.
Сервис corolistener имеет отдельный лог-файл — /usr/local/mgr5/var/corolistener.log.