У меня есть две виртуальные машины, на которых работает 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 на активном узле, он станет пассивным, а новый активный узел начнет показывать трафик . Время покажет, но выглядит многообещающе.
Только предположение здесь. Вы можете спутать это с наличием двух интерфейсов в одной подсети. Вы можете попробовать создать отдельную подсеть для сети управления.