Система диагностики доступности узлов кластера

Материал из ISPWiki
Перейти к: навигация, поиск
Иерархия: VMmanager Cloud -> Облачные функции

В основе системы диагностики: система 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
[[en:Cluster node accessibility diagnostics]]
   } 
   quorum {
 	 expected_votes: 3
   }
   ihttpd {
 	 count: 1
 	 port0: 1500
   }
 

Секция 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
	 }
 }
 

Секция 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 файла конфигурации VMmanager;
    • Создается файл /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.