Пинг маршрутизации vrrp, но не другой трафик

У меня есть две виртуальные машины под управлением BusyBox (под ESX). Эти машины работают только как балансировщики нагрузки.

Я использую ручку для балансировки нагрузки на каждой машине, которая работает нормально. Но когда я запускаю vrrpd ping работает, но больше ничего не делает.

Каждый балансировщик нагрузки имеет 3 интерфейса. IP-адреса управления находятся на eth0, eth1 для второй настройки балансировщика нагрузки.

LBCO102A
10.3.16.96 - (eth0) Management IP
10.3.16.84 - (eth2) IP that pen uses

LBCO102B
10.3.16.94 - (eth0) Management IP
10.3.16.85 - (eth2) IP that pen uses

vrrpd использует 10.3.16.58

На LBCO102A я использую следующее для запуска vrrpd:

vrrpd -i eth2 -v 58 -p 100 10.3.16.58

На LBCO102B я использую следующее для запуска vrrpd:

vrrpd -i eth2 -v 58 -p 50 10.3.16.58

Я могу подключиться к IP-адресам 10.3.16.84 и 10.3.16.85 без проблем на порту 80. Я могу подключиться к IP-адресам управления 10.3.16.94 и 10.3.16.96 без проблем. Когда я подключаюсь к 10.3.16.58, время ожидания истекает. В файле /var/run/messages ничего не отображается, за исключением того, что один является главным, а другой нет.

У кого-нибудь есть идеи относительно того, почему vrrpd не продвигает трафик, кроме ping? У меня есть три из этих установок. Один на pop3, один на smtp и один на http. Никто из них не работает ни для чего, кроме пинга.

Вот netstat -an от LBCO102A

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 10.3.16.107:110         0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:9999            0.0.0.0:*               LISTEN
tcp        0      0 10.3.16.84:80           0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:8888            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:8889            0.0.0.0:*               LISTEN
tcp        0      0 10.3.16.107:110         10.3.17.30:53960        TIME_WAIT
tcp        0      0 10.3.16.96:22           10.3.30.154:1224        ESTABLISHED
tcp        0      0 10.3.16.107:110         10.3.17.30:54000        TIME_WAIT
tcp        0      0 10.3.16.107:110         10.3.17.30:54102        TIME_WAIT
tcp        0      0 10.3.16.107:110         10.3.17.30:54038        TIME_WAIT
tcp        0      0 10.3.16.107:110         10.3.17.30:53959        TIME_WAIT
tcp        0      0 10.3.16.107:110         10.3.17.30:54001        TIME_WAIT
tcp        0      0 10.3.16.107:110         10.3.17.30:54101        TIME_WAIT
tcp        0      0 10.3.16.96:22           10.3.30.154:1097        ESTABLISHED
tcp        0      0 10.3.16.107:110         10.3.17.30:54037        TIME_WAIT
raw        0      0 0.0.0.0:112             0.0.0.0:*               0
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node Path
unix  7      [ ]         DGRAM                    983    /tmp/log
unix  2      [ ]         DGRAM                    1156708
unix  2      [ ]         DGRAM                    1156657
unix  2      [ ]         DGRAM                    1156524
unix  2      [ ]         DGRAM                    192729
unix  2      [ ]         DGRAM                    994

Вот netstat -an от LBCO102B

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:9999            0.0.0.0:*               LISTEN
tcp        0      0 10.3.16.85:80           0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:8888            0.0.0.0:*               LISTEN
tcp        0      0 10.3.16.94:22           10.3.30.154:1118        ESTABLISHED
raw        0      0 0.0.0.0:112             0.0.0.0:*               0
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node Path
unix  6      [ ]         DGRAM                    981    /tmp/log
unix  2      [ ]         DGRAM                    188253
unix  2      [ ]         DGRAM                    179316
unix  2      [ ]         DGRAM                    179306
unix  2      [ ]         DGRAM                    988

Вот что у меня есть в моих скриптах запуска. (в скриптах есть еще что проверить для запуска / остановки / перезапуска) LBCO103A

echo -n "Starting eth2: "
ifconfig eth2 10.3.16.84 netmask 255.255.255.0 up
echo "OK"

echo -n "Starting vrrp-ascossrs101: "
vrrpd -i eth2 -v 58 -p 100 10.3.16.58
echo "OK"

echo -n "Starting pen-ascossrs101: "
/bin/pen -C 8888 -X -l /var/log/ascossrs101.log -p /var/log/ascossrs101.pid 10.3.16.84:80 10.3.16.56:80 10.3.16.57:80
echo "OK"

LBCO102B

echo -n "Starting eth2: "
ifconfig eth2 10.3.16.85 netmask 255.255.255.0 up
echo "OK"

echo -n "Starting vrrp-ascossrs101: "
vrrpd -i eth2 -v 58 -p 100 10.3.16.58
echo "OK"

echo -n "Starting pen-ascossrs101: "
/bin/pen -C 8888 -X -l /var/log/ascossrs101.log -p /var/log/ascossrs101.pid 10.3.16.85:80 10.3.16.56:80 10.3.16.57:80
echo "OK"

3 ответа

Решение

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

Можете ли вы запустить netstat -an и предоставить вывод, пожалуйста? Я предполагаю, что ручка привязана к eth2 IP, а не ко всем адресам на коробке. Он должен быть настроен на 0.0.0.0, чтобы он мог подобрать любой адрес, которым владеет ящик, или вы должны запустить мастер-скрипт vrrpd, чтобы перо связывалось с вашим VIP. Что может случиться, так это то, что masterscript должен запустить саму ручку, уже настроенную на ожидание, что vip будет привязан к вашему интерфейсу eth2.

Редактируйте сейчас с выводом netstat: Хорошо, вот в чем проблема: LBCO102A tcp 0 0 10.3.16.84:80 0.0.0.0:* LISTEN

10.3.16.84:80 означает, что вы связаны только с 10.3.16.84 на порте 80, таким образом, даже если у сервера есть VIP, он не прослушивает 10.3.16.58 порт 80.

Опять же, я не очень знаком с ручкой, но при условии, что первый переданный IP-адрес является связыванием: /bin/pen -C 8888 -X -l /var/log/ascossrs101.log -p /var/log/ascossrs101.pid 10.3.16.84:80 10.3.16.56:80 10.3.16.57:80 может быть /bin/pen -C 8888 -X -l /var/log/ascossrs101.log -p /var/log/ascossrs101.pid 0.0.0.0:80 10.3.16.56:80 10.3.16.57:80

0.0.0.0:80 будет означать привязку ко всем адресам и всем интерфейсам на коробке.

Другой альтернативой может быть использование: /bin/pen -C 8888 -X -l /var/log/ascossrs101.log -p /var/log/ascossrs101.pid 10.3.16.58:80 10.3.16.56:80 10.3.16.57:80

Однако я сомневаюсь, что это будет работать как есть, потому что при запуске программы виртуальная машина не будет иметь этот IP-адрес, поэтому перо не сможет привязаться к нему явно. Я попытался просмотреть документацию для vrrpd, и я не уверен, что он сможет это сделать, но у freevrrp есть опция masterscript, которая в основном запускает скрипт, когда он принимает VIP. Таким образом, вы просто добавили бы команду запуска пера как часть мастер-скрипта, поэтому, когда блок вступит во владение VIP, он запустит перо и свяжет его с IP-адресом VIP.

Хорошо , я думаю, у меня все работает сейчас. Это была комбинация вещей, которые я получил от @Kevin, плюс некоторые вещи, которые я нашел в сети (о vrrpd очень мало).

Похоже, что vrrpd запускает сервер для прослушивания IP-адреса, поэтому вы не хотите запускать интерфейс с IP-адресом. Интерфейс должен иметь IP, а не тот IP, который будет использовать vrrp.

Моя следующая проблема заключалась в том, что у меня была ручка, работающая на IP, отличном от того, с которым работал vrrpd. Я закончил тем, что написал пера для всех подключений через порт 80 на всех IP. Если вы этого не сделаете, то, если ручка запускается, а машина не является основным балансировщиком нагрузки, то ручка умрет, потому что искомого IP-адреса нет.

Я настроил перо на другой IP-адрес и предположил, что vrrpd был еще одним балансировщиком нагрузки. Оказывается, vrrpd просто запускает IP и закрывает его.

Итак, напомню, что я закончил с этим.

LBCO102A
10.3.16.96 - eth0 (Management IP)
10.3.16.148 - eth1

LBCO102B
10.3.16.94 - eth0 (Management IP)
10.3.16.149 - eth1

Затем vrrpd на обеих машинах настроен с адресом 10.3.16.58, а ручка на обеих машинах настроена с 0.0.0.0.

Есть еще тестирование, но я запускаю pen в режиме отладки и слежу за файлом /var/run/messages, и если я перезапущу vrrpd на активном узле, он станет пассивным, и новый активный узел начнет показывать трафик, Время покажет, но выглядит многообещающе.

Просто предположение здесь. Вы можете спутать это с наличием двух интерфейсов в одной подсети. Вы можете попробовать создать отдельную подсеть для сети управления.

Другие вопросы по тегам