У меня следующий сценарий в Corosync + Pacemaker
Узел 1:
eth0: 10.143.0.21/24
eth1: 10.10.10.1/30 (связь Corosync)
eth2: 192.168.5.2/24
Узел 2:
eth0: 10.143.0.22/24
eth1: 10.10.10.2/30 (связь Corosync)
eth2: 192.168.5.3/24
Плавающие IP-адреса
eth0: 10.143.0.23/24
eth2: 192.168.5.1/24
Интерфейс eth1 используется только для связи corosync.
Например, я отключил сетевой кабель от интерфейса eth0, но ничего не произошло, в другом примере я отключил сетевой кабель от интерфейса eth2, и у меня тот же результат, но я отключил сетевой кабель от интерфейса eth1 (связь corosync) и проход плавающего IP-адреса на другой узел.
Как я могу сделать так, чтобы при отключении любого интерфейса ресурсы переходили на другой узел?
С уважением
ОБНОВИТЬ
Я тестировал со следующими настройками
crm configure primitive PING-WAN ocf:pacemaker:ping params host_list="10.143.0.1" multiplier="1000" dampen="1s" op monitor interval="1s"
crm configure primitive Failover-WAN ocf:heartbeat:IPaddr2 params ip=10.143.0.23 nic=eth0 op monitor interval=10s meta is-managed=true
crm configure primitive Failover-LAN ocf:heartbeat:IPaddr2 params ip=192.168.5.1 nic=eth2 op monitor interval=10s meta is-managed=true
crm configure group Cluster Failover-WAN Failover-LAN
crm configure location Best_Connectivity Cluster rule pingd: defined pingd
У меня это работает, при отключении сетевого кабеля от eth0 и потере пинга до пункта назначения ресурсы 10.143.0.1 (шлюз) были перемещены на другой узел, но мой сценарий - это 3 интерфейса, поэтому я решил добавить тест ping еще
crm configure primitive PING-LAN ocf:pacemaker:ping params host_list="192.168.5.4" multiplier="1000" dampen="1s" op monitor interval="1s"
Но теперь необходимо потерять соединение с двумя хостами (10.143.0.1 и 192.168.5.4), чтобы ресурсы были перемещены на другой узел.
Я ищу информацию, но не могу заставить работать следующий сценарий:
Если узел теряет связь с любым хостом, который добавляет к тесту ping, другие ресурсы переходят к другому узлу без необходимости терять возможность подключения всех тестов ping одновременно.
Вам нужно сказать Pacemaker, что вы беспокоитесь о сбоях интерфейсов. Посмотрите на ocf:pacemaker:ping ресурс. Вы можете использовать этот агент-ресурс для проверки связи с другими списками хостов в сетях с разными интерфейсами, и Pacemaker отреагирует, если эти проверки связи не пройдут.
Если вы сгруппируете ocf:pacemaker:ping ресурсов или используйте ограничения, чтобы связать их с тем, чем вы управляете в Pacemaker, все они будут перемещаться вместе.
Кроме того, я готов поспорить, что когда вы отключите eth1 в ваших предыдущих тестах было видно, что IP-адрес не «перемещался», а скорее запускался на ОБЕИХ узлах кластера одновременно; к узлам кластера, они оба думали, что их одноранговый узел пропал. По сути, вы тестировали, что произойдет, если кластер разделится.
В этой заметке вам обязательно следует настроить второе избыточное кольцо в своей конфигурации Corosync, как предлагается в другом ответе, но это не даст желаемого эффекта.
ОБНОВЛЕНИЕ 0: Вы должны добавить оба IP-адреса к одному ping примитив host_list вместо добавления дополнительных ping примитив и установите failure_score на этом примитиве все, что приемлемо.
Из ocf:pacemaker:ping агент ресурсов (# crm ra info ocf:pacemaker:ping):
...
failure_score (integer):
Resource is failed if the score is less than failure_score.
Default never fails.
host_list* (string): Host list
A space separated list of ping nodes to count.
...
Что-то вроде: # crm configure primitive PING-O-DOOM ocf:pacemaker:ping params host_list="10.143.0.1 192.168.5.4" failure_score="2" op monitor interval="10s"
Вам необходимо настроить оба интерфейса в кольце corosync.
Пример:
pcs cluster auth node1 node2
pcs cluster setup --start --name zfs-cluster zfs-node1,zfs-node1-ext zfs-node2,zfs-node2-ext
Куда:
# Management addresses of both nodes
172.16.40.15 zfs-node1.ewwhite.net zfs-node1
172.16.40.16 zfs-node2.ewwhite.net zfs-node2
# Cluster ring address for heartbeat
192.168.91.1 zfs-node1-ext
192.168.91.2 zfs-node2-ext