Я пытаюсь реализовать схему прямого возврата сервера для нашего веб-кластера, и я думаю, что застрял с некоторыми проблемами ARP. Для тестирования я развернул 2 виртуальных сервера (внутри среды ESXi).
Хост A: eth0 10.0.0.1/24 (VIP) - наш директор с его виртуальным ip на eth0
Хост B: eth0 10.0.0.2/24, lo: 0 10.0.0.1/32 - это один из узлов webapp, на котором работает демон httpd.
Эти два сервера находятся в одном сегменте Ethernet. Как вы можете видеть, интерфейс обратной связи хоста B имеет псевдоним для хранения VIP (10.0.0.1). Чтобы сервер B не отвечал на VIP arp, фильтрация реализована через arptables:
arptables -A IN -d 10.0.0.1 -j DROP arptables -A OUT -s 10.0.0.1 -j mangle --mangle-ip-s 10.0.0.2
До сих пор все казалось хорошим, пока я не попытался проверить связь с хостом B от хоста A. "Destination host Unreachable" - вот что я получил. Запустив tcpdump на хосте B, я обнаружил, что он действительно получал запросы ARP от хоста A, но не отправлял ответы. Тем временем на запросы ARP от других узлов мы успешно ответили хостом B. Таким образом, похоже, что хост A не может связываться с другой машиной, имеющей свой VIP. Хотя я делал фильтрацию arp. На самом деле это странно для меня.
Какие-либо предложения? Кстати, я использую Centos 6.
Судя по тому, как это настроено, когда хост B получает пинг от хоста A, а затем пытается ответить, ему даже не нужно будет выполнять запрос arp (который вы хотите изменить), чтобы `` достичь 10.0.0.1 '', он уже напрямую подключен. Вы можете подтвердить это, распечатав таблицу arp на хосте B и увидев, что уже есть запись для 10.0.0.1. Я никогда не использовал DSR в настройке, где VIP находится в подсети, в которой есть реальные IP-адреса серверов. Обычно виртуальные IP-адреса привязаны к кольцевой проверке и находятся в разных подсетях с настройкой маршрутизации. Это предотвращает как эту проблему, так и необходимость искажать таблицы arp, что в дальнейшем может привести к действительно серьезным проблемам с отладкой.