Систем диагностики — одна из компонент, обеспечивающих отказоустойчивость кластера. Система диагностики проверяет доступность узлов кластера и при отказе восстанавливает виртуальные машины на доступных узлах кластера.

В основе системы диагностики: система 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
}
BASH

Секция totem:

  • bindnetaddr — адрес, на который сервис будет "биндиться" при запуске;
  • mcastaddr и mcastport — соответственно адрес и порт multicast;
  • config_version определяет версию файла конфигурации. По мере изменения состава кластера (добавления/удаления из кластера серверов) файл конфигурации будет меняться. При изменении файла меняется и номер версии, что позволяет поддерживать файл конфигурации corosync актуальным на всех серверах кластера.

Секция quorum:

  • expected_votes — общее количество серверов в кластере. Значение необходимо для расчета кворума;

Секция ihttpd:

  • count и port0 — определяет количество портов и порт, на котором будет запущен сервис ihttpd на новом мастер сервере.


Секция списка узлов кластера:

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
     }
}
BASH

Секция nodelist содержит информацию о всех узлах кластера:

  • ring0_addr — IP-адрес узла кластера;
  • prio — приоритет узла кластера;
  • replication — значение "on" сигнализирует о том, что для узла кластера включена репликация базы данных VMmanager. Значение "off" — репликация выключена.

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
BASH

Либо средства 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
BASH


Вывод corolistener более информативный, так как показывает основной узел и приоритет узлов.

Сервис corolistener имеет отдельный лог-файл — /usr/local/mgr5/var/corolistener.log.