Аварийное переключение IP-адресов с 2 узлами в другой подсети: не удается пропинговать виртуальный IP со второго узла?

Я собираюсь настроить резервное переключение при сбое Redmine:

  • другой экземпляр был установлен на втором сервере без проблем
  • MySQL (работающий на той же машине с Redmine) был настроен как репликация мастер-мастер

Поскольку они находятся в разных подсетях (192.168.3.x и 192.168.6.x), кажется, что VIPArip - единственный выбор.

/etc/ha.d/ha.cf на узле 1

logfacility none
debug 1
debugfile /var/log/ha-debug
logfile /var/log/ha-log
autojoin none
warntime 3
deadtime 6
initdead 60
udpport 694
ucast eth1 node2.ip
keepalive 1
node node1
node node2
crm respawn

/etc/ha.d/ha.cf на узле 2:

logfacility none
debug 1
debugfile /var/log/ha-debug
logfile /var/log/ha-log
autojoin none
warntime 3
deadtime 6
initdead 60
udpport 694
ucast eth0 node1.ip
keepalive 1
node node1
node node2
crm respawn

crm configure show:

node $id="6c27077e-d718-4c82-b307-7dccaa027a72" node1
node $id="740d0726-e91d-40ed-9dc0-2368214a1f56" node2
primitive VIPArip ocf:heartbeat:VIPArip \
        params ip="192.168.6.8" nic="lo:0" \
        op start interval="0" timeout="20s" \
        op monitor interval="5s" timeout="20s" depth="0" \
        op stop interval="0" timeout="20s" \
        meta is-managed="true"
property $id="cib-bootstrap-options" \
        stonith-enabled="false" \
        dc-version="1.0.12-unknown" \
        cluster-infrastructure="Heartbeat" \
        last-lrm-refresh="1338870303"

crm_mon -1:

============
Last updated: Tue Jun  5 18:36:42 2012
Stack: Heartbeat
Current DC: node2 (740d0726-e91d-40ed-9dc0-2368214a1f56) - partition with quorum
Version: 1.0.12-unknown
2 Nodes configured, unknown expected votes
1 Resources configured.
============

Online: [ node1 node2 ]

 VIPArip    (ocf::heartbeat:VIPArip):   Started node1

ip addr show lo:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet 192.168.6.8/32 scope global lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever

Я могу пропинговать 192.168.6.8 с узла 1 (192.168.3.x):

# ping -c 4 192.168.6.8
PING 192.168.6.8 (192.168.6.8) 56(84) bytes of data.
64 bytes from 192.168.6.8: icmp_seq=1 ttl=64 time=0.062 ms
64 bytes from 192.168.6.8: icmp_seq=2 ttl=64 time=0.046 ms
64 bytes from 192.168.6.8: icmp_seq=3 ttl=64 time=0.059 ms
64 bytes from 192.168.6.8: icmp_seq=4 ttl=64 time=0.071 ms

--- 192.168.6.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.046/0.059/0.071/0.011 ms

но не может пропинговать виртуальный IP-адрес от узла 2 (192.168.6.x) и снаружи. Я что-то пропустил?

PS: вы, вероятно, хотите установить IP2UTIL=/sbin/ip в /usr/lib/ocf/resource.d/heartbeat/VIPArip скрипт агента ресурса, если вы получите что-то вроде этого:

5 июня 11:08:10 node1 lrmd: [19832]: информация: выход RA: (VIPArip:stop:stderr) 2012/06/05_11:08:10 ОШИБКА: недопустимый OCF_RESK EY_ip [192.168.6.8]

http://www.clusterlabs.org/wiki/Debugging_Resource_Failures

Ответить @DukeLion:

Какой маршрутизатор получает обновления RIP?

Когда я начинаю VIPArip ресурс, ripd был запущен с файлом конфигурации ниже (на узле 1):

/var/run/resource-agents/VIPArip-ripd.conf :

hostname ripd
password zebra
debug rip events
debug rip packet
debug rip zebra
log file /var/log/quagga/quagga.log
router rip
!nic_tag
 no passive-interface lo:0
 network lo:0
 distribute-list private out lo:0
 distribute-list private in lo:0
!metric_tag
 redistribute connected metric 3
!ip_tag
access-list private permit 192.168.6.8/32
access-list private deny any

show ip route:

Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, A - Babel,
       > - selected route, * - FIB route

K>* 0.0.0.0/0 via 192.168.3.1, eth1
C>* 127.0.0.0/8 is directly connected, lo
K>* 169.254.0.0/16 is directly connected, eth1
C>* 192.168.3.0/24 is directly connected, eth1
C>* 192.168.6.8/32 is directly connected, lo

sh ip rip status:

Routing Protocol is "rip"
  Sending updates every 30 seconds with +/-50%, next due in 7 seconds
  Timeout after 180 seconds, garbage collect after 120 seconds
  Outgoing update filter list for all interface is not set
    lo:0 filtered by private
  Incoming update filter list for all interface is not set
    lo:0 filtered by private
  Default redistribution metric is 1
  Redistributing: connected
  Default version control: send version 2, receive any version 
    Interface        Send  Recv   Key-chain
  Routing for Networks:
    lo:0
  Routing Information Sources:
    Gateway          BadPackets BadRoutes  Distance Last Update
  Distance: (default is 120)
Источник

1 ответ

Я думаю, что проблема не в конфигурации кластера, а в вашей архитектуре маршрутизации.

Агент ресурса VIPArip управляет локальной кваггой для отправки обновлений маршрутизации. Но вам также нужно использовать эти обновления маршрутизации, чтобы изменить маршруты, чтобы они указывали на активный сервер. Я постараюсь объяснить, как это работает.

RIP HA

Посмотрите на картинку. HA1 и HA2 - члены кластера linux-ha с запущенным quagga. Синий роутер слушает RIP с обоих сетевых каналов.

Когда vip поднимается на HA1, quagga отправляет обновление RIP на синий маршрутизатор. Он добавляет префикс vip к своей таблице маршрутизации с помощью 192.168.1.2 nexthop.

Когда происходит аварийное переключение, vip отключается на HA1 и quagga полностью останавливается, поэтому обновления не будут отправляться. Синий маршрутизатор удалит запись таблицы маршрутизации после истечения времени ожидания, даже если VIP не повысится на HA2. И когда VIP поднимается на HA2, он запускает quagga и отправляет обновления RIP. Синий роутер добавит запись в таблицу маршрутизации с 192.168.2.2 nexthop.

Можно использовать viparip в более сложной топологии сети, просто убедитесь, что ваши пограничные маршрутизаторы получают обновления маршрутизации по всей сети.

Источник
Другие вопросы по тегам