Keepalived попадает в плохое состояние, когда один пакет повторно загружается

Question

Keepalived попадает в плохое состояние, когда один пакет повторно загружается

У меня есть два сервера, на которых выполняется Keepalived с отказоустойчивостью и балансировкой нагрузки с использованием прямой маршрутизации. Настройка будет работать нормально в течение некоторого времени. В конце концов, он перестанет отвечать. Когда я смотрю на tcpdump, я вижу поток сообщений вроде этого:

15:14:55.943992 IP (tos 0x0, ttl 59, id 32319, offset 0, flags [DF], proto TCP (6), length 60)
    10.31.109.208.50132 > 10.18.28.224.https: Flags [S], cksum 0x7cb9 (correct), seq 1334967248, win 29200, options [mss 1460,sackOK,TS val 2453083948 ecr 0,nop,wscale 7], length 0
15:14:55.944173 IP (tos 0x0, ttl 59, id 32319, offset 0, flags [DF], proto TCP (6), length 60)
    10.31.109.208.50132 > 10.18.28.224.https: Flags [S], cksum 0x7cb9 (correct), seq 1334967248, win 29200, options [mss 1460,sackOK,TS val 2453083948 ecr 0,nop,wscale 7], length 0
15:14:55.944183 IP (tos 0x0, ttl 59, id 32319, offset 0, flags [DF], proto TCP (6), length 60)
    10.31.109.208.50132 > 10.18.28.224.https: Flags [S], cksum 0x7cb9 (correct), seq 1334967248, win 29200, options [mss 1460,sackOK,TS val 2453083948 ecr 0,nop,wscale 7], length 0
15:14:55.944370 IP (tos 0x0, ttl 59, id 32319, offset 0, flags [DF], proto TCP (6), length 60)
    10.31.109.208.50132 > 10.18.28.224.https: Flags [S], cksum 0x7cb9 (correct), seq 1334967248, win 29200, options [mss 1460,sackOK,TS val 2453083948 ecr 0,nop,wscale 7], length 0
15:14:55.944379 IP (tos 0x0, ttl 59, id 32319, offset 0, flags [DF], proto TCP (6), length 60)
    10.31.109.208.50132 > 10.18.28.224.https: Flags [S], cksum 0x7cb9 (correct), seq 1334967248, win 29200, options [mss 1460,sackOK,TS val 2453083948 ecr 0,nop,wscale 7], length 0
15:14:55.944571 IP (tos 0x0, ttl 59, id 32319, offset 0, flags [DF], proto TCP (6), length 60)
    10.31.109.208.50132 > 10.18.28.224.https: Flags [S], cksum 0x7cb9 (correct), seq 1334967248, win 29200, options [mss 1460,sackOK,TS val 2453083948 ecr 0,nop,wscale 7], length 0
15:14:55.944581 IP (tos 0x0, ttl 59, id 32319, offset 0, flags [DF], proto TCP (6), length 60)
    10.31.109.208.50132 > 10.18.28.224.https: Flags [S], cksum 0x7cb9 (correct), seq 1334967248, win 29200, options [mss 1460,sackOK,TS val 2453083948 ecr 0,nop,wscale 7], length 0
15:14:55.944755 IP (tos 0x0, ttl 59, id 32319, offset 0, flags [DF], proto TCP (6), length 60)
    10.31.109.208.50132 > 10.18.28.224.https: Flags [S], cksum 0x7cb9 (correct), seq 1334967248, win 29200, options [mss 1460,sackOK,TS val 2453083948 ecr 0,nop,wscale 7], length 0
15:14:55.944764 IP (tos 0x0, ttl 59, id 32319, offset 0, flags [DF], proto TCP (6), length 60)
    10.31.109.208.50132 > 10.18.28.224.https: Flags [S], cksum 0x7cb9 (correct), seq 1334967248, win 29200, options [mss 1460,sackOK,TS val 2453083948 ecr 0,nop,wscale 7], length 0
15:14:55.944952 IP (tos 0x0, ttl 59, id 32319, offset 0, flags [DF], proto TCP (6), length 60)
    10.31.109.208.50132 > 10.18.28.224.https: Flags [S], cksum 0x7cb9 (correct), seq 1334967248, win 29200, options [mss 1460,sackOK,TS val 2453083948 ecr 0,nop,wscale 7], length 0
15:14:55.944967 IP (tos 0x0, ttl 59, id 32319, offset 0, flags [DF], proto TCP (6), length 60)
    10.31.109.208.50132 > 10.18.28.224.https: Flags [S], cksum 0x7cb9 (correct), seq 1334967248, win 29200, options [mss 1460,sackOK,TS val 2453083948 ecr 0,nop,wscale 7], length 0
15:14:55.945140 IP (tos 0x0, ttl 59, id 32319, offset 0, flags [DF], proto TCP (6), length 60)
    10.31.109.208.50132 > 10.18.28.224.https: Flags [S], cksum 0x7cb9 (correct), seq 1334967248, win 29200, options [mss 1460,sackOK,TS val 2453083948 ecr 0,nop,wscale 7], length 0
15:14:55.945150 IP (tos 0x0, ttl 59, id 32319, offset 0, flags [DF], proto TCP (6), length 60)
    10.31.109.208.50132 > 10.18.28.224.https: Flags [S], cksum 0x7cb9 (correct), seq 1334967248, win 29200, options [mss 1460,sackOK,TS val 2453083948 ecr 0,nop,wscale 7], length 0
15:14:55.945322 IP (tos 0x0, ttl 59, id 32319, offset 0, flags [DF], proto TCP (6), length 60)
    10.31.109.208.50132 > 10.18.28.224.https: Flags [S], cksum 0x7cb9 (correct), seq 1334967248, win 29200, options [mss 1460,sackOK,TS val 2453083948 ecr 0,nop,wscale 7], length 0
15:14:55.945331 IP (tos 0x0, ttl 59, id 32319, offset 0, flags [DF], proto TCP (6), length 60)
    10.31.109.208.50132 > 10.18.28.224.https: Flags [S], cksum 0x7cb9 (correct), seq 1334967248, win 29200, options [mss 1460,sackOK,TS val 2453083948 ecr 0,nop,wscale 7], length 0
15:14:55.945506 IP (tos 0x0, ttl 59, id 32319, offset 0, flags [DF], proto TCP (6), length 60)
    10.31.109.208.50132 > 10.18.28.224.https: Flags [S], cksum 0x7cb9 (correct), seq 1334967248, win 29200, options [mss 1460,sackOK,TS val 2453083948 ecr 0,nop,wscale 7], length 0
15:14:55.945514 IP (tos 0x0, ttl 59, id 32319, offset 0, flags [DF], proto TCP (6), length 60)
    10.31.109.208.50132 > 10.18.28.224.https: Flags [S], cksum 0x7cb9 (correct), seq 1334967248, win 29200, options [mss 1460,sackOK,TS val 2453083948 ecr 0,nop,wscale 7], length 0
15:14:55.945701 IP (tos 0x0, ttl 59, id 32319, offset 0, flags [DF], proto TCP (6), length 60)
    10.31.109.208.50132 > 10.18.28.224.https: Flags [S], cksum 0x7cb9 (correct), seq 1334967248, win 29200, options [mss 1460,sackOK,TS val 2453083948 ecr 0,nop,wscale 7], length 0
15:14:55.945710 IP (tos 0x0, ttl 59, id 32319, offset 0, flags [DF], proto TCP (6), length 60)
    10.31.109.208.50132 > 10.18.28.224.https: Flags [S], cksum 0x7cb9 (correct), seq 1334967248, win 29200, options [mss 1460,sackOK,TS val 2453083948 ecr 0,nop,wscale 7], length 0

10.31.109.208 мой адрес. Пакеты продолжаются, даже когда я закрываю свой браузер. Перезапуск keepalived или Nginx не решает проблему. Перезагрузка - единственная вещь, которая, кажется, исправляет это. Когда это происходит, сервер даже не может общаться с самим собой на этом интерфейсе, что заставляет меня думать, что это не проблема маршрутизации.

-1

networking tcp keepalived

Источник

user907872 26 июл '19 в 22:35

1 ответ

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

user907872 16 авг '19 в 03:52 2019-08-16 03:52 · Answer 1 · 2019-08-16 03:52

Следуйте инструкциям здесь. Они старые, но они все еще применяются. http://gcharriere.com/blog/?p=339

Вам нужно добавить правило предварительной маршрутизации IPTables во вторую систему, чтобы пакеты не возвращались назад и вперед.

Примерно так: 192.168.9.100 - VIP:

iptables -A PREROUTING -t nat -d 192.168.9.100 -p tcp -j REDIRECT

Удостоверьтесь, чтобы удалить это всякий раз, когда эта машина становится главной. Правила IPTables можно добавлять более одного раза, поэтому перед добавлением убедитесь, что вы проверили, не существует ли он еще.