Виртуальный IP-адрес Pacemaker не может маршрутизироваться за пределами своей сети.

Вопрос или проблема

У меня есть кластер серверов, состоящий из следующей конфигурации:

2 виртуальных сервера с 2 сетевыми интерфейсами. eth0 (частная сеть 10.0.0.0/16) и eth1 (публичная сеть 77.1.2.0/24 с шлюзом 77.1.2.1)

Для VPS HA-01 у меня установлен приватный IP на eth0 — 10.0.0.1.
Для VPS HA-02 у меня установлен приватный IP на eth0 — 10.0.0.2.

Кластер Pacemaker/Corosync был создан между частными IP-адресами и виртуальным IP (77.1.2.4), который определен как ресурс клон (IPAddr2), чтобы он мог перемещаться между двумя узлами.

pcs resource create VirtualIP1 ocf:heartbeat:IPaddr2 ip="77.1.2.4" cidr_netmask="24" nic="eth1" clusterip_hash="sourceip-sourceport" op start interval="0s" timeout="60s" op monitor interval="1s" timeout="20s" op stop interval="0s" timeout="60s" clone interleave=true ordered=true

Проблема в том, что я не могу обратиться к этому IP-адресу из внешнего мира. Я заметил, что отсутствует маршрут, поэтому добавил статический маршрут.

ip r add default via 77.1.2.1 dev eth1

Но я все еще не могу пинговать google.com с этих серверов, и мир не видит их по этому IP.
Я также пробовал добавить IP-адреса из той же подсети на eth1 следующим образом:

HA-01 eth1: 77.1.2.2
HA-02 eth1: 77.1.2.3

Серверы видны по этим IP во внешнем мире, но если я добавляю ресурс VirtualIP, я не могу достучаться до них по виртуальному IP-адресу.
Я также пробовал добавить исходный IP в таблицу маршрутизации.

ip r add default via 77.1.2.1 src 77.1.2.4

Но безрезультатно. Я не знаю, что мне делать, чтобы этот VirtualIP заработал.
Я могу достучаться до 77.1.2.4 (виртуальный IP-адрес) с других серверов в этой сети, но не снаружи этой сети.

Брандмауэр установлен, и порты высокой доступности открыты с помощью команды:

firewall-cmd --add-service="high availability"; firewall-cmd --add-service="high availability" --permanent

Есть ли что-то, что я упускаю?
Если я добавлю этот адрес (77.1.2.4 – виртуальный IP) отдельно на интерфейсе только одного из этих серверов, это сработает… Так что, возможно, есть проблема с таблицей ARP или роутер блокирует какой-то трафик?

Посмотрите на этот вопрос: https://serverfault.com/questions/778997/pacemaker-virtual-ip-loadbalancing-with-clone-and-clusterip

Я думаю, что это проблема маршрута. Попробуйте последний комментарий, оставленный в вопросе пользователем strzelecki.maciek. Он применил некоторые правила iptables для предварительной маршрутизации, которые помогли. Возможно, это и ваш случай.

Ответ или решение

Проблема, с которой вы столкнулись, возникает из-за конфигурации маршрутизации и неправильной обработки ARP на вашей сетевой инфраструктуре. Давайте подробно разберёмся в причинах и возможных решениях.

Описание проблемы

У вас есть кластер серверов, состоящий из двух виртуальных серверов (HA-01 и HA-02), каждый из которых имеет два сетевых интерфейса (eth0 и eth1). Основная проблема заключается в том, что виртуальный IP-адрес (77.1.2.4) не доступен извне, хотя он виден внутри вашего частного сегмента сети.

Причины проблемы

  1. Маршрут по умолчанию:
    Вы добавили маршрут по умолчанию через команду ip r add default via 77.1.2.1 dev eth1, однако убедитесь, что он полностью настроен правильно и что пакет может проходить через маршрутизатор.

  2. ARP-запросы:
    Виртуальный IP-адрес должен корректно обрабатываться маршрутизаторами в сети. Проверьте, правильно ли у вас настроены ARP-таблицы. Когда сеть видит ARP-запрос для 77.1.2.4, она должна знать, к какому из двух серверов (HA-01 или HA-02) направить запрос.

  3. IPTables:
    Если на ваших серверах включены IPTables, то это может быть причиной блокировки входящего трафика к виртуальному IP-адресу. Проверьте правила фильтрации пакетов и убедитесь, что порты, используемые вашим приложением, открыты.

  4. Настройки брандмауэра:
    Вы установили правило для службы «high availability» через firewall-cmd, но убедитесь, что дополнительные правила не препятствуют доступу к виртуальному IP.

Рекомендации по решению

  1. Проверка ARP:
    Запустите команду arp -a на каждом из серверов, чтобы проверить, какой MAC-адрес ассоциирован с виртуальным IP-адресом. Это поможет определить, правильно ли работает механика ARP.

  2. Настройка IPTables:
    Попробуйте добавить правило в IPTables, чтобы перенаправить трафик к виртуальному IP. Проверьте, что конфигурация IPTables разрешает всю необходимую сетевую активность. Например:

    iptables -A INPUT -d 77.1.2.4 -j ACCEPT
    iptables -A FORWARD -d 77.1.2.4 -j ACCEPT

    Не забудьте сохранить изменения и перезапустить IPTables.

  3. Перенаправление NAT:
    Попробуйте настроить перенаправление NAT на вашем маршрутизаторе или сервере:

    iptables -t nat -A PREROUTING -d 77.1.2.4 -j DNAT --to-destination 77.1.2.2
    iptables -t nat -A POSTROUTING -j MASQUERADE

    Это позволит перенаправить трафик, поступающий на виртуальный IP, на соответствующий сервер.

  4. Тестирование маршрутизации:
    Используйте инструменты для тестирования маршрутизации и сетевой доступности, такие как traceroute или ping, для проверки того, где происходит обрыв соединения.

  5. Настройка VIP учитывая отказоустойчивость:
    Не забывайте о конфигурации Pacemaker. Убедитесь, что ваши ресурсы настроены корректно и возможности «поднимите» на обоих серверах. Хорошей практикой является использование clusterip для управления IP-адресами с высокой доступностью.

Заключение

Рекомендуется провести диагностику на каждом уровне: от настройки маршрутов к ARP-таблицам и IPTables. Также полезно проверить, не блокирует ли трафик ваше сетевое оборудование. Повторите вышеуказанные шаги, и это поможет решить вашу проблему с доступом к виртуальному IP-адресу. Если потребуется более детальной помощи, не стесняйтесь задавать вопросы.

Оцените материал
Добавить комментарий

Капча загружается...