У меня была проблема с теми же симптомами. В моем случае был другой хост с тем же IP-адресом на vlan, который я использовал в мосте. Иногда другой хост будет быстрее отвечать на запрос ARP (несмотря на то, что это другая физическая машина), и в этот момент гость lxc сохранит неправильный MAC-адрес в своей таблице ARP и продолжит отправку кадров Ethernet на неправильный адрес до следующего запроса ARP "решил" проблему.

Я диагностировал это с помощью пинга с отметкой времени от хоста к гостю:

# ping -n 10.70.70.10 | perl -nle 'BEGIN {$|++} print scalar(localtime), " ", $_' |tee -a ping10707010.log
[...]
Sun Jul 31 09:18:53 2016 64 bytes from 10.70.70.10: icmp_seq=3389 ttl=64 time=0.035 ms
Sun Jul 31 09:18:54 2016 64 bytes from 10.70.70.10: icmp_seq=3390 ttl=64 time=0.035 ms
Sun Jul 31 09:18:55 2016 64 bytes from 10.70.70.10: icmp_seq=3391 ttl=64 time=0.027 ms
Sun Jul 31 09:19:45 2016 64 bytes from 10.70.70.10: icmp_seq=3441 ttl=64 time=0.064 ms
Sun Jul 31 09:19:46 2016 64 bytes from 10.70.70.10: icmp_seq=3442 ttl=64 time=0.038 ms
Sun Jul 31 09:19:47 2016 64 bytes from 10.70.70.10: icmp_seq=3443 ttl=64 time=0.036 ms

а также tcpdump на хосте и госте:

# tcpdump -n -i brv3001 # on the host
[...]
09:18:55.724751 IP 10.70.0.1 > 10.70.70.10: ICMP echo request, id 26519, seq 3391, length 64
09:18:55.724768 IP 10.70.70.10 > 10.70.0.1: ICMP echo reply, id 26519, seq 3391, length 64
09:18:56.336109 ARP, Request who-has 10.70.70.10 tell 10.70.0.1, length 42
09:18:56.336147 ARP, Reply 10.70.70.10 is-at 00:16:3e:46:46:0a, length 28
[...]
09:19:44.728738 ARP, Request who-has 10.70.70.10 tell 10.70.0.1, length 28
09:19:44.728769 ARP, Reply 10.70.70.10 is-at 00:16:3e:46:46:0a, length 28
# tcpdump -n -i infra0 # on the guest
[...]
09:18:55.724757 IP 10.70.0.1 > 10.70.70.10: ICMP echo request, id 26519, seq 3391, length 64
09:18:55.724767 IP 10.70.70.10 > 10.70.0.1: ICMP echo reply, id 26519, seq 3391, length 64
09:18:56.336123 ARP, Request who-has 10.70.70.10 tell 10.70.0.1, length 42
09:18:56.336144 ARP, Reply 10.70.70.10 is-at 00:16:3e:46:46:0a, length 28
[...]
09:19:44.728745 ARP, Request who-has 10.70.70.10 tell 10.70.0.1, length 28
09:19:44.728766 ARP, Reply 10.70.70.10 is-at 00:16:3e:46:46:0a, length 28

что позволило мне увидеть это примерно в момент, когда сеть отключится и когда она снова активируется, отправлялись запросы ARP и ответил. Казалось, что запросы ARP в порядке (с использованием правильных MAC-адресов), но я все равно решил проверить факты, видимые ОС, поэтому я зарегистрировал таблицы ARP на хосте и госте с отметками времени:

# while true; do date; arp -n; sleep 1; done > arp.log 2>&1 # on the host
[...]
Sun Jul 31 09:18:55 CEST 2016
Address                  HWtype  HWaddress           Flags Mask            Iface
10.70.70.10              ether   00:16:3e:46:46:0a   C                     brv3001
Sun Jul 31 09:18:56 CEST 2016
Address                  HWtype  HWaddress           Flags Mask            Iface
10.70.70.10              ether   00:16:3e:46:46:0a   C                     brv3001
# while true; do date; arp -n; sleep 1; done > arp.log 2>&1 # on the guest
Sun Jul 31 09:18:55 CEST 2016
Address                  HWtype  HWaddress           Flags Mask            Iface
10.70.0.1                ether   00:1e:68:4a:03:b0   C                     infra0
Sun Jul 31 09:18:56 CEST 2016
Address                  HWtype  HWaddress           Flags Mask            Iface
10.70.0.1                ether   c4:34:6b:22:b6:7c   C                     infra0

что позволило мне понять, что у хоста не было неисправного MAC гостя, но гость каким-то образом прибыл на неисправный MAC хоста. К сожалению, это не нашло отражения в информации tcpdump. (NB: где-то в libpcap или стеке ip может быть состояние гонки, расследование которого будет полезно)

Обнаружив ошибочный MAC-адрес, я посмотрел, какому поставщику принадлежит ошибочный MAC-адрес, и, таким образом, смог найти неисправную машину. Если бы эта информация была более неоднозначной, я уверен, что у моего коммутатора были бы функции, которые помогли бы мне найти правильный порт коммутатора.

Я предполагаю, что повышение / понижение уровня ядер и некоторые инструменты пользовательского уровня изменится и, возможно, даже удалит все или некоторые симптомы из-за изменения таймингов, немного другого поведения, активности других сетевых служб и т. Д. Например, пинг от гостя к хосту надежно " исправить "проблему в моем случае.

Также не забывайте, что IP-адреса, которые вы можете видеть с ifconfig не все IP-адреса, используемые системой. ip addr ls будет более подробным о Linux и, возможно, даже более продвинутым iptables конфигурации тоже могут сыграть роль. Если вам не повезло, хост, отвечающий на arps, может даже иметь сломанный стек IP. Вы даже можете получать ответы ARP от других клиентов вашего интернет-провайдера, если ваша сеть не изолирована должным образом.

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

Я думаю, ваша проблема с базой данных может быть связана с конфигурацией rg. Apache / Piwik / MySQL.

Но мы наблюдаем проблемы с подключением к SSH (и другим приложениям), начиная с «в соединении отказано» и заканчивая случаями, подобными описанным вами (подключение появляется, отображается подсказка, затем подключение молча умирает).

Точно так же несколько приложений (Mail, Web) "кажутся медленными" (для нас и, по крайней мере, для одного из наших клиентов корневого сервера), и в настоящее время я предполагаю, что клиенты (Mailclients, Webbrowsers) выполняют несколько попыток подключения и / или повторно подключаются. , достаточно, чтобы замедлить их, но не настолько серьезно, чтобы появлялись сообщения об ошибках (или чтобы запускать предупреждения от трех наших внешних мониторов Icange).

Установка не нова, она выполнялась безупречно с Debian Wheezy + OpenVZ-Kernel + OpenVZ (материал OpenVZ из репозитория OpenVZ debian) в течение 2 лет.

Мы совсем недавно (пару дней назад) перешли на ядро ​​Debian Jessie + backports (из-за исправлений DRBD) + LXC, ничего не меняя (те же две пары негабаритного серверного оборудования, тот же центр размещения, те же виртуализированные гостевые системы).

Итак, в качестве 1-го вывода, мы тоже получаем «ощущение», что что-то не так, либо ошибка ядра, либо некоторые ограничения LXC, связанные с TCP, о которых никто не знает.

«Ощущение» немного расплывчато, но на данный момент определить его сложно. Но мы знаем, что у нас есть проблема, которая возникает слишком часто, чтобы слишком много разных клиентов могли винить что-то еще.

Кстати, проблемы кажется чтобы поразить LXC в первую очередь тех гостей, которые какое-то время бездействовали, большую часть времени ничего не делают.

Также кажется, что это помогает «разбудить их» с помощью SSH-соединений с сетевой активностью LAN / DMZ и WAN, такой как эхо-запросы.

Мы используем сетевые настройки в стиле veth / br0 с индивидуальными MAC-адресами для гостей.

Когда-то у меня был фантомный IP-адрес от остановленного гостя LXC (узнаваемый по MAC), но я думаю, что сошел с ума от ошибки изменения конфигурации гостя LXC между запуском и остановкой этого гостя.

Версия ядра Debian: 4.3.0-0.bpo.1-amd64 # 1 SMP Debian 4.3.3-5 ~ bpo8 + 1 (2016-01-07) x86_64

PS:

Вопросы @ Антонио Тапиадор: Какую версию ядра вы используете? Вы используете VLAN?

Мы обсуждали, есть ли этот патч мы нашли в 4.3.4 журнал изменений может помочь.

PPS: Почему я должен использовать «ответ», чтобы комментировать?

PPPS, AKA наше решение: Переход с ядра 4.3.3 на 4.2.6 (оба в jessie-backports), похоже, решил нашу проблему.

Конечно, трудно быть уверенным, что проблема возникала периодически. Если вы используете ядро ​​jessie 3.16, я предлагаю вам попробовать обновиться до 4.2 с jessie-backports, то есть из пакета linux-image-4.2.0-0.bpo.1-amd64.

4.2 также не имеет долгосрочной поддержки со стороны kernel.org, но, по крайней мере, Canonical утверждает это для Ubuntu 15.10, а дистрибутив виртуализации на основе Debian Proxmox теперь также использует 4.2 (как и мы, они переключаются с OpenVZ на LXC).

Обновление 2016-04-07: проблема не исчезла полностью с 4.3. Обновление до 4.4 (LTS с Kernel.org и Ubuntu) тоже не помогло. Но мы собираемся попробовать временную линию LTE, чтобы быть на 100% уверенными, что это не наш провайдер доступа ...

Обновление 2016-08-29: Теперь мы уверены, что проблемы были. Плохое ядро ​​4.3 и поставщик жилья, который мы просто оставляем позади. У нас есть еще одна серьезная проблема с 4.4 / 4.6 и LXC / DRBD, но здесь это было бы оффтопом.