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

Периодический no route to host

 , ,


0

1

Есть 3 виртуальных севереа, 2 севера apache(pm) и mysql, и 3ий(cc) сервер apache, который общаеться с mysql через pm. После создания snapshota и ребута cc сложилась такая картина.

Днём все работает хорошо, но наступает вечер и периодически сервера перестают коннектится, пингую cc к pm пишет: 

From cc: destination host unreachable

Пинг pm к cc в этот момент: 

From pm: destination host unreachable

Браузер клиента выдает no route to host по 80 порту.

CC route -n 

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         85.233.65.193   0.0.0.0         UG    0      0        0 eth0
10.11.63.145    10.11.128.1     255.255.255.255 UGH   0      0        0 eth1
10.11.128.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
85.233.65.192   0.0.0.0         255.255.255.192 U     0      0        0 eth0

CC ifconfig 

eth0      Link encap:Ethernet  HWaddr 00:50:56:93:4c:f3
          inet addr:85.233.65.240  Bcast:85.233.65.255  Mask:255.255.255.192
          inet6 addr: fe80::250:56ff:fe93:4cf3/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:352415 errors:0 dropped:0 overruns:0 frame:0
          TX packets:84626 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:42693182 (40.7 MiB)  TX bytes:55709336 (53.1 MiB)

eth1      Link encap:Ethernet  HWaddr 00:50:56:a7:52:cb
          inet addr:10.11.128.73  Bcast:10.11.128.255  Mask:255.255.255.0
          inet6 addr: fe80::250:56ff:fea7:52cb/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:314523 errors:0 dropped:29 overruns:0 frame:0
          TX packets:210055 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:25287564 (24.1 MiB)  TX bytes:23013097 (21.9 MiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:2944 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2944 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:301908 (294.8 KiB)  TX bytes:301908 (294.8 KiB)

PM route: 

root@bigpm2:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.11.63.145    10.11.128.1     255.255.255.255 UGH   0      0        0 eth1
85.233.74.6     10.11.128.1     255.255.255.255 UGH   0      0        0 eth1
85.233.65.192   0.0.0.0         255.255.255.192 U     0      0        0 eth0
10.11.128.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0         85.233.65.193   0.0.0.0         UG    0      0        0 eth0

pm ifconfig 

eth0      Link encap:Ethernet  HWaddr 00:50:56:93:4b:f2
          inet addr:85.233.65.239  Bcast:85.233.65.255  Mask:255.255.255.192
          inet6 addr: fe80::250:56ff:fe93:4bf2/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:336668472 errors:0 dropped:0 overruns:0 frame:0
          TX packets:193880080 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:38402945759 (35.7 GiB)  TX bytes:68415328348 (63.7 GiB)

eth1      Link encap:Ethernet  HWaddr 00:50:56:93:6e:e5
          inet addr:10.11.128.71  Bcast:10.11.128.255  Mask:255.255.255.0
          inet6 addr: fe80::250:56ff:fe93:6ee5/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2807092721 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2822987048 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2368728030140 (2.1 TiB)  TX bytes:397113113854 (369.8 GiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:15588572 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15588572 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1984623574 (1.8 GiB)  TX bytes:1984623574 (1.8 GiB)

traceroute днём, когда работает.

traceroute to pm2.citrt.net (85.233.65.239), 30 hops max, 60 byte packets
 1  pm2.citrt.net (85.233.65.239)  0.237 ms  0.246 ms  0.217 ms

netstat

root@cardcall2:~# netstat -anp |grep LISTEN
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      1347/exim4
tcp        0      0 0.0.0.0:10050           0.0.0.0:*               LISTEN      5651/zabbix_agentd
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      8628/mysqld
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      533/sshd
tcp6       0      0 ::1:25                  :::*                    LISTEN      1347/exim4
tcp6       0      0 :::443                  :::*                    LISTEN      991/apache2
tcp6       0      0 :::10050                :::*                    LISTEN      5651/zabbix_agentd
tcp6       0      0 :::80                   :::*                    LISTEN      991/apache2
tcp6       0      0 :::22                   :::*                    LISTEN      533/sshd
unix  2      [ ACC ]     STREAM     LISTENING     16407    2050/systemd        /run/user/0/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     7537     1/init              /run/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     7561     1/init              /run/lvm/lvmetad.socket
unix  2      [ ACC ]     SEQPACKET  LISTENING     7564     1/init              /run/udev/control
unix  2      [ ACC ]     STREAM     LISTENING     7567     1/init              /run/systemd/journal/stdout
unix  2      [ ACC ]     STREAM     LISTENING     11435    1/init              /var/run/dbus/system_bus_socket
unix  2      [ ACC ]     STREAM     LISTENING     11438    1/init              /run/acpid.socket
unix  2      [ ACC ]     STREAM     LISTENING     106685   8628/mysqld         /var/run/mysqld/mysqld.sock

Также CC вытаскивает для выпадающего списка данные с мускула, и они не вытягиваються иногда, даже при остуствии данной ошибки. Грешил на мускул, уже все перелопатил. Первоначальная проблема, та что в шапке, посмотрел все что в пределах моих знаний, ничего не нашел. Просьба помочь и направить. Куда смотреть? Что диагностировать? Как излечить сию нечистую?

Система на всех серверах debian.

Буду благодарен любому ответу.


← Удалить часть письма
SELinux. За и против. →

Пальцем в небо. Судя по ip могу только предположить что железки не далеко друг от друга, может между ними сетевое оборудование виновато?

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

dmesg

CC сделать не успел, соединение вернулось, тогда. Сегодня вечером скорее всего залью его выхлоп.

Выхлоп pm-a (получился большой, решил залить так, если вам удобнее по другому, скажите пожалуйста, перезалью)

https://drive.google.com/open?id=0B3z9E2sfjO9VUk8xT3MyZjVlTXM

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

Пальцем в небо. Судя по ip могу только предположить что железки не далеко друг от друга, может между ними сетевое оборудование виновато?

Я не имею доступа к железякам компов на которых расположены сервера, Суть в том что днём то все отлично работает. А те кто этим занимаются говорят что у них все хорошо, даже смотреть не будут, пока аргументировано не доказать что это в железе.Вот хочу разобраться, в чем вообще проблема.

Сменил в пятницу Dns сервера, думал попрет, в итоге в выходные проработал без сбоев и с пн на вт началось опять...

nairon
() автор топика
Ответ на: dmesg от nairon

Судя по выхлопу у тебя какая-то дикая жопа с I/O, такая что аж ядро в шоке - куча трейсов на ext4, возможно при этом сервер тупо «подвисает» и перестает отвечать на всё, ВКЛЮЧАЯ сеть.

Давай начнем снизу вверх, так сказать: у тебя всё в порядке с жесткими дисками? Выхлоп smartctl -a /dev/{твой_жесткий_диск} показать можешь?

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

Спасибо большое, за ваш ответ.

smartctl, в процессе, прописываю путь к пакету для его установки, будет чуть позже.

возможно при этом сервер тупо «подвисает» и перестает отвечать на всё, ВКЛЮЧАЯ сеть.

На сервер в этот момент можно зайти по ssh и открыть клиент в браузере по хосту, все нормально работает. Пинг по Ip - также вроде как проходит с обоих серверов. Я даже через 3ий компьютер этой сети пытался в этот момент пинговать их обоих по хосту - и он их пингует, что самое для меня непонятное. Тобишь к обоим серверам можно законектится по хосту в этот момент, но вот между собой они чет не хотят, хоть и не долго... Разве что ремарочку сделаю, в этот момент браузер СС открывает дольше.

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

Тобишь к обоим серверам можно законектится по хосту в этот момент, но вот между собой они чет не хотят, хоть и не долго

А трафик между тобой и каждым из серверов и между самими серверами идёт через одну сетевуху? А то может залипает только одна из них в таком случае...

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

dmesg CC

Выхлоп СС dmesg

https://drive.google.com/open?id=0B3z9E2sfjO9VdG1zYzRBMFRmS2M

При этом, посмотрел ifconfig, eth1 и eth0 работают, поискал в гугле как потестить трафик с определенной сетевухи, пока не нашел.

Я так подумал, если он по ip может а по dns записи нет, реально инет не работает, но по инету на сайт попасть ведь можно, а когда пингую IP - указываю ipшники местные и тож раз проходит, то с ними все нормально должно быть? dns менял вот на днях, не помогло.

nairon
() автор топика
Ответ на: dmesg CC от nairon

Pinkbyte хорошее замечание сделал. Они у вас между собой не пингуються по 10.11.128.х или по 85.233.65.х ?

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

Спасибо за ваш ответ.

Честно сказать, до того как вы написали, я и не додумался пропинговать по внешнему ip.

Не пингуеться по 85.233.65.х

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

Не пингуеться по 85.233.65.х

Тогда если они оба доступны по внешнему ip извне и при этом не доступны друг другу внутри сети то с большей вероятностью это проблемы внутри сети.
PS Насчет этого Периодический no route to host (комментарий) не забудьте посмотреть.

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

Спасибо, посмотрю обязательно, уже в процессе.

Не совсем понял, внутри сети, то ладно, искать проблему в железе или конфигурации? забиксом смотрел, в этот момент cpu перегрузок не чувствует.

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

К сожалению: 

root@bigpm2:~# smartctl -a /dev/sda1
smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

Device: VMware   Virtual disk     Version: 1.0
Device type: disk
Local Time is: Wed Mar 22 10:03:58 2017 GMT-3
Device does not support SMART

Error Counter logging not supported
Device does not support Self Test logging

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

У меня нет доступа к нему, сейчас спросил людей, которые за них ответственны. А это может играть сильную роль?

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

Ну, а другие ПК эти ipшники ведь пингуют.

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

Не совсем понял, внутри сети,

То что вы описали host1 доступен извне, host2 доступен извне и при этом они по этим же ip не доступны между собой. Всетаки похоже на внутренние проблемы между ними.

anc ★★★★★
()
Ответ на: dmesg от nairon

отсутствие arp-ответа в течении 3-х секунд обычно расценивается как «no route to host» или «destination host unreachable», а у тебя там обнаруживаются блокировки на более длительное время.

Если arp прибить статиком, то он ругаться не будет, а просто будет молчать.

А нет ядра без NOHZ для виртуалки?

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

Новая инфа: Сначала думал что просто совпадение но случилось так уже более 3 раз, когда оставляю на ночь пинговать сервера, ошибка вдруг не проявляется, на следующий (или через день) отключаю пинг, ошибка вдруг воспроизводится.

Я не совсем понимаю NOHZ, не особо силен пока в линуксе, беглый гугл создал ощущение что может быть взаимосвязь, (аля задержка пакетов), но что то боюсь утверждать. Направьте пожалуйста.

А NOHZ отключить (=off) нельзя для эксперимента? Или это не лучший путь?

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

Пока в arp-таблице есть MAC адрес, такую ошибку получать тяжело.

NOHZ - это вариант сборки ядра. Для мобильных устройств оно полезно, а для серверов IMHO вредно.

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

Ответили наконец.

Cisco UCS N20-B6625-1 2 x Intel Xeon X5680 192 GB RAM

nairon
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Удалить часть письма
Admin
SELinux. За и против. →