Назад | Перейти на главную страницу

vrrp routing ping, но не другой трафик

У меня есть две виртуальные машины, на которых работает 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"

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

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

Теперь отредактируйте с выводом netstat: Хорошо, вот проблема: LBCO102A tcp 0 0 10.3.16.84:80 0.0.0.0:* СЛУШАТЬ

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

Опять же, я не совсем знаком с пером, но предполагая, что первый переданный 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 fires сообщает серверу слушать 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.

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

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