Вопрос или проблема
У меня есть кластер серверов, состоящий из следующей конфигурации:
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) не доступен извне, хотя он виден внутри вашего частного сегмента сети.
Причины проблемы
-
Маршрут по умолчанию:
Вы добавили маршрут по умолчанию через командуip r add default via 77.1.2.1 dev eth1
, однако убедитесь, что он полностью настроен правильно и что пакет может проходить через маршрутизатор. -
ARP-запросы:
Виртуальный IP-адрес должен корректно обрабатываться маршрутизаторами в сети. Проверьте, правильно ли у вас настроены ARP-таблицы. Когда сеть видит ARP-запрос для 77.1.2.4, она должна знать, к какому из двух серверов (HA-01 или HA-02) направить запрос. -
IPTables:
Если на ваших серверах включены IPTables, то это может быть причиной блокировки входящего трафика к виртуальному IP-адресу. Проверьте правила фильтрации пакетов и убедитесь, что порты, используемые вашим приложением, открыты. -
Настройки брандмауэра:
Вы установили правило для службы «high availability» черезfirewall-cmd
, но убедитесь, что дополнительные правила не препятствуют доступу к виртуальному IP.
Рекомендации по решению
-
Проверка ARP:
Запустите командуarp -a
на каждом из серверов, чтобы проверить, какой MAC-адрес ассоциирован с виртуальным IP-адресом. Это поможет определить, правильно ли работает механика ARP. -
Настройка 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.
-
Перенаправление 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, на соответствующий сервер.
-
Тестирование маршрутизации:
Используйте инструменты для тестирования маршрутизации и сетевой доступности, такие какtraceroute
илиping
, для проверки того, где происходит обрыв соединения. -
Настройка VIP учитывая отказоустойчивость:
Не забывайте о конфигурации Pacemaker. Убедитесь, что ваши ресурсы настроены корректно и возможности «поднимите» на обоих серверах. Хорошей практикой является использованиеclusterip
для управления IP-адресами с высокой доступностью.
Заключение
Рекомендуется провести диагностику на каждом уровне: от настройки маршрутов к ARP-таблицам и IPTables. Также полезно проверить, не блокирует ли трафик ваше сетевое оборудование. Повторите вышеуказанные шаги, и это поможет решить вашу проблему с доступом к виртуальному IP-адресу. Если потребуется более детальной помощи, не стесняйтесь задавать вопросы.