LINUX.ORG.RU
Форум — Admin  

Странная проблема с Keepalived

 ,


0

1

Есть у меня некий сервер (CentOS 6.7, ядро 3.10), на нём на интерфейсе eth0 висит DNS-сервер NSD.

Есть ещё два интерфейса, eth2 и eth3, IP-адресами на которых управляет Keepalived. Сами же хартбиты VRRP между Keepalived ходят по eth0 уникастом.

Так вот, пока Keepalived не запущен, NSD работает хорошо - долблю его dnsperf-ом, около 200к запросов в сек обслуживает. Как только же запускаю keepalived и он поднимает несколько адресов на eth2 и eth3 (и, в принципе, никоим образом не должен влиять на eth0) - NSD сразу ломается: отвечает на 7-10 запросов и замирает на насколько секунд.. потом ещё отвечает на несколько и опять замирает.

На выходе примерно такая картина: 

  Queries sent:         1537
  Queries completed:    37 (2.41%)
  Queries lost:         1000 (65.06%)
  Queries interrupted:  500 (32.53%)

Причём, если потушить Keepalived - ничего не лечится. Только ребут, только хардкор. После всё так же - до запуска Keepalived всё хорошо, потом - ахтунг. В tcpdump ничего интересного не видно - пачка запросов приходит, а ответов уходит только на несколько.

При этом я рулю сервером именно через этот eth0 по SSH - никаких проблем не наблюдается.

Что-то я уже всё перебрал - не могу понять причин такого поведения...

★★★★★

Последнее исправление: cetjs2 (всего исправлений: 1)
← Аномальная активность jbd2 при исчерпании места на разделе с ext4
агрегирующий top →

NSD отвечает только за свои зоны или должен обращаться к другим серверам?

Ну ещё можно попробовать strace на nsd позапускать, просто посмотреть, получает ли он dns запросы.

mky ★★★★★
()

rp_filter как настроен ?

Может это проблема nsd ? Я бы после запуска keepalived посмотрел через lsof на nsd.

посмотри «ip li && ip a» до старта keepalived, после и после остановки keepalived.

vel ★★★★★
()
Ответ на: комментарий от mky

Только за свои, он рекурсию не умеет by-design.

В общем, проблему вроде как нашёл, похоже мой косяк. Так как на сервере 4 разных подсети (3 внутренних и одна внешка) и нужно чтобы он на всех трёх отвечал через ихние дефолтные шлюзы, то был настроен policy routing с тремя таблицами.

А в таблицы я добавил только дефолтный маршрут, без scope link типа такого: 

10.1.253.0/24 dev eth0  scope link
Поэтому, когда я из этой же подсети долбил его тестами, возникали какие-то косяки непонятные - я бы понял если пакеты вообще не ходили бы - но так странно, 1% запросов проходит... После добавления в каждую таблицу маршрутов локальных всё встало на свои места.

НО. Остаётся вопрос: как оно работало до запуска Keepalived и как он ломал всё...

blind_oracle ★★★★★
() автор топика
Ответ на: комментарий от vel

rp_filter включен.

ip я ессесно смотрел со всех сторон - единственно отличие, что пока keepalived работает - он добавляет ip-адреса на подшефные интерфейсы. Больше ничего не увидел...

blind_oracle ★★★★★
() автор топика
Ответ на: комментарий от blind_oracle

а если руками добавить эти самые адреса? поинт в том, что возможно keepalived тут не при чем, а проблема в маршрутизации - rp_filter тут не зря помянули

Pinkbyte ★★★★★
()
Ответ на: комментарий от blind_oracle

policy-routing вещь не такая простая как кажется.

Самая большая проблема в том, что прямые маршруты нужно обязательно просматривать сразу после таблицы local. А про это забывают почти все.

vel ★★★★★
()
Ответ на: комментарий от blind_oracle

он рекурсию не умеет by-design.

Но, вроде, он умеет быть slave'ом или быть master'ом и уведомлять slave'ов об изменениях...

Но, раз проблема в маршрутах, то действительно странно. Может у вас сломаный rp_filter. Введите систему в это состояние, когда keepalived выключен, проходит ответ на 1% запросов и попробуйте разные значение (0,1,2) для rp_filter на этот интерфейс. Может надо bug-репорт слать.

mky ★★★★★
()
Ответ на: комментарий от blind_oracle

ядро при добвлении адресов на интерфейс добавляет прямые маршруты только в main. Keepalived добавляет адреса, но не знает про policy-routing. IMHO в notify_{master|backup} нужно добавить создание/удаление маршрутов в доп. таблицы.

vel ★★★★★
()
Ответ на: комментарий от mky

Но, вроде, он умеет быть slave'ом или быть master'ом и уведомлять slave'ов об изменениях...

Это да, но как только он скачал зону - при запросах клиентов он ни к кому не обращается. А зона скачана и валидна у него :)

Но, раз проблема в маршрутах, то действительно странно. Может у вас сломаный rp_filter. Введите систему в это состояние, когда keepalived выключен, проходит ответ на 1% запросов и попробуйте разные значение (0,1,2) для rp_filter на этот интерфейс. Может надо bug-репорт слать.

Попробовал - никакой разницы.

Вот пинг флуд на хост с запущенным KeepAlived и без локального маршрута в таблице policy routing (с хоста из той же подсети): 

host-test# ping 10.1.253.102 -f -c 1000
PING 10.1.253.102 (10.1.253.102) 56(84) bytes of data.
.................................................................................................................................................................................................................................................................................................................................................................
--- 10.1.253.102 ping statistics ---
1000 packets transmitted, 647 received, 35% packet loss, time 6466ms
rtt min/avg/max/mdev = 0.495/0.715/3.860/0.152 ms, ipg/ewma 6.473/0.666 ms
35% потерь... добавляем маршрут: 
host-keepalived# ip route add 10.1.253.0/24 dev eth0 table 143

host-test# ping 10.1.253.102 -f -c 1000
PING 10.1.253.102 (10.1.253.102) 56(84) bytes of data.
 
--- 10.1.253.102 ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 551ms
rtt min/avg/max/mdev = 0.427/0.480/0.940/0.048 ms, ipg/ewma 0.552/0.461 ms
Вуаля... остаётся вопрос - почему именно треть потерь? И почему после однократного запуска keepalived?

blind_oracle ★★★★★
() автор топика
Ответ на: комментарий от vel

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

Мне интересно только почему происходит именно так :)

blind_oracle ★★★★★
() автор топика
Ответ на: комментарий от mky

Причём, если пинговать 100 пакетов в секунду - потерь почти нет: 

# ping 10.1.253.102 -i 0.01 -c 1000
...
1000 packets transmitted, 986 received, 1% packet loss, time 10429ms

blind_oracle ★★★★★
() автор топика
Ответ на: комментарий от Pinkbyte

Если руками добавлять - всё то же самое, если хотя бы 1 адрес на 1 интерфейс повесишь - труба. Удаляешь - не восстанавливается. Так что да, KeepAlived не причём.

blind_oracle ★★★★★
() автор топика
Последнее исправление: blind_oracle (всего исправлений: 1)
Ответ на: комментарий от blind_oracle

ну так сравнить «ip ro get 10.1.253.102» до и после добавления маршрута.

ну и хорошо бы на 10.1.253.102 посмотреть куда ответ отсылается.

Вопрос где оно теряется - при передаче или при приеме.

Могут терятся например только первые 300 пакетов, а потом без потерь.

vel ★★★★★
()
Ответ на: комментарий от vel

Могут терятся например только первые 300 пакетов, а потом без потерь.

Теряется более или менее равномерно: 

...
64 bytes from 10.1.253.102: icmp_seq=10 ttl=63 time=0.557 ms
64 bytes from 10.1.253.102: icmp_seq=11 ttl=63 time=0.547 ms
64 bytes from 10.1.253.102: icmp_seq=12 ttl=63 time=0.593 ms
64 bytes from 10.1.253.102: icmp_seq=14 ttl=63 time=0.716 ms
64 bytes from 10.1.253.102: icmp_seq=16 ttl=63 time=0.804 ms
64 bytes from 10.1.253.102: icmp_seq=18 ttl=63 time=0.774 ms
64 bytes from 10.1.253.102: icmp_seq=20 ttl=63 time=0.650 ms
64 bytes from 10.1.253.102: icmp_seq=21 ttl=63 time=0.742 ms
...
64 bytes from 10.1.253.102: icmp_seq=989 ttl=63 time=0.762 ms
64 bytes from 10.1.253.102: icmp_seq=990 ttl=63 time=0.682 ms
64 bytes from 10.1.253.102: icmp_seq=993 ttl=63 time=0.852 ms
64 bytes from 10.1.253.102: icmp_seq=994 ttl=63 time=0.769 ms
64 bytes from 10.1.253.102: icmp_seq=996 ttl=63 time=0.683 ms
64 bytes from 10.1.253.102: icmp_seq=998 ttl=63 time=0.692 ms
64 bytes from 10.1.253.102: icmp_seq=1000 ttl=63 time=0.766 ms

--- 10.1.253.102 ping statistics ---
1000 packets transmitted, 536 received, 46% packet loss, time 5540ms
rtt min/avg/max/mdev = 0.539/0.996/129.077/5.539 ms, pipe 25

ну так сравнить «ip ro get 10.1.253.102» до и после добавления маршрута.

Ты имел в виду роут на айпишник машины с которой я пингую? Там ничего особенного, судя по всему get смотрит таблицу по-умолчанию, а указать другую ему нельзя: 

# ip ro get 10.1.253.157 
10.1.253.157 dev eth0  src 10.1.253.102 
    cache

При этом ответные пакеты на пинги (от 102 к 157), судя по редиректам от шлюза, улетают в него: 

# tcpdump -i eth0 'icmp'
...
16:31:18.587017 IP 10.1.253.254 > 10.1.253.102: ICMP redirect 10.1.253.157 to host 10.1.253.157, length 36
Так что, похоже, потери связаны с тем как шлюз обрабатывает эти пакеты.. Причем, отключение приёма редиректов никак не влияет на ситуацию.

blind_oracle ★★★★★
() автор топика
Ответ на: комментарий от blind_oracle

Вот и ответ на следующий вопрос, который я хотел задать «а нет ли там icmp-redirect»

При этом ответные пакеты на пинги (от 102 к 157), судя по редиректам от шлюза, улетают в него:

А почему они туда периодически улетают? Может «ip monitor» на .102 даст подсказку ?

vel ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Аномальная активность jbd2 при исчерпании места на разделе с ext4
Admin
агрегирующий top →