Почему блокировка сервера выбивает другие серверы из сети?

У нас есть пара дюжин серверов Proxmox (Proxmox работает на Debian), и примерно раз в месяц один из них будет испытывать панику ядра и зависать. Наихудшая часть этих блокировок заключается в том, что, когда это сервер, который находится на отдельном коммутаторе, чем мастер кластера, все остальные серверы Proxmox на этом коммутаторе перестанут отвечать, пока мы не найдем действительно сбойный сервер и перезагрузим его.

Когда мы сообщали об этой проблеме на форуме Proxmox, нам посоветовали перейти на Proxmox 3.1, и мы занимались этим уже несколько месяцев. К сожалению, один из серверов, которые мы перенесли на Proxmox 3.1, был заблокирован с паникой ядра в пятницу, и снова все серверы Proxmox, которые были на том же коммутаторе, были недоступны по сети, пока мы не смогли найти сбойный сервер и перезагрузить его.

Ну, почти все серверы Proxmox на коммутаторе ... Мне было интересно, что серверы Proxmox на том же коммутаторе, которые все еще были на Proxmox версии 1.9, не пострадали.

Вот снимок экрана консоли аварийного сервера:

введите описание изображения здесь

Когда сервер заблокирован, остальные серверы на том же коммутаторе, на которых также работал Proxmox 3.1, стали недоступными и издали следующее:

e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
...etc...

uname -a вывод заблокированного сервера:

Linux ------ 2.6.32-23-pve #1 SMP Tue Aug 6 07:04:06 CEST 2013 x86_64 GNU/Linux

Вывод pveversion -v (сокращенно):

proxmox-ve-2.6.32: 3.1-109 (running kernel: 2.6.32-23-pve)
pve-manager: 3.1-3 (running version: 3.1-3/dc0e9b0e)
pve-kernel-2.6.32-23-pve: 2.6.32-109

Два вопроса:

Любые подсказки, что будет вызывать панику ядра (см. Изображение выше)?
Почему другие серверы на том же коммутаторе и версии Proxmox будут отключены от сети до перезагрузки заблокированного сервера? (Примечание. На том же коммутаторе были другие серверы, на которых работала более старая версия 1.9 Proxmox, которые не были затронуты. Также не были затронуты другие серверы Proxmox в том же кластере 3.1, которые не были подключены к тому же коммутатору.)

Заранее благодарю за любой совет.

— Curtis
источник

Можете ли вы дать полный crashdump? На картинке выше отрезаны интересные детали. Кроме того, вы опубликовали краш-дамп на lkml ? Однако, если посмотреть еще раз, это довольно старое ядро, есть ли планы обновить Debian до текущей стабильной версии?

— ckujau

К сожалению, у нас нет аварийного дампа. Я добавил его в свой список для настройки последовательной консоли и / или kdump. Что касается старого ядра, Proxmox использует ядро OpenVZ, которое является ветвью основного ядра. Итак, как только я смогу запустить аварийные дампы, я обращусь за помощью к разработчикам OpenVZ. Спасибо за ваш комментарий ... это помогло мне указать правильное направление.

— Кертис

Что за переключатель?

— ETL

Проблема произошла с 3 различными коммутаторами (один dlink и 2 cisco). У меня нет номеров моделей на двух предыдущих коммутаторах, но последний - Cisco SG102-24. Поскольку это влияет только на серверы на коммутаторе, на которых запущено одно и то же ядро, и поскольку я нахожусь на своем третьем коммутаторе, кажется маловероятным, что коммутатор виноват (хотя это тоже была моя первоначальная мысль).

— Кертис

Я получил уведомление по электронной почте, что кто-то разместил следующий комментарий здесь ... «У меня есть похожая проблема, за исключением того, что я могу сделать мой сбой с парой контейнеров, выполняющих жесткое ядро ...» К сожалению, он был отключен там, и когда я пришел здесь автор удалил свой комментарий, поэтому я не знаю, что это было за остальное. Но я добавлю, что я заметил, что проблема, по-видимому, возникает чаще всего при интенсивном сетевом трафике (например, при выполнении резервного копирования). Возможно, этот комментарий был "жесткие передачи по сети"?

— Кертис

Ответы:

Я почти уверен, что ваша проблема вызвана не одним-единственным фактором, а комбинацией факторов. Что это за отдельные факторы, неизвестно, но, скорее всего, одним из них является либо сетевой интерфейс, либо драйвер, а другой фактор находится на самом коммутаторе. Следовательно, вполне вероятно, что проблема может быть воспроизведена только с этой конкретной маркой коммутатора в сочетании с этой конкретной маркой сетевого интерфейса.

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

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

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

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

Это наводит меня на мысль, что вероятен недостаток дизайна коммутатора.

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

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

Если это триггер, то на других серверах что-то идет не так. Поскольку пакетный шторм не должен вызывать такого рода ошибки на сетевом интерфейсе. Reset adapter unexpectedlyне похоже на пакетный шторм (который должен просто вызывать падение производительности, но не приводит к ошибкам как таковым), и это не похоже на проблему со связью (которая должна была привести к сообщениям о сбое ссылок, но не к ошибке, которой вы являетесь видя).

Таким образом, вполне вероятно, что имеется какое-то изъян в оборудовании или драйвере сетевого интерфейса, которое вызывается коммутатором.

Несколько предложений, которые могут дать дополнительные подсказки:

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

— kasperd
источник

Спасибо за ваш вдумчивый ответ. С точки зрения ваших 3 предложений: 1) Какого типа оборудование / программное обеспечение будет делать это? 2) Хотел бы я, но там задействовано много серверов, и я не знаю, где проблема будет дальше. 3) Я уже пробовал 3 разных переключателя (3 разных модели, 2 разных бренда). Также интересно то, что затрагиваются только серверы в той же версии Proxmox. В Proxmox есть механизм синхронизации кластеров, поэтому я подозреваю, что это как-то связано с этим. К счастью, прошло уже несколько месяцев с тех пор, как проблема возникла сейчас.

— Кертис

Для просмотра трафика на коммутаторе я думал подключить обычный ПК с помощью tcpdump и / или wireshark. Очевидно, что вы хотели бы избежать установки уязвимого программного обеспечения на этот ПК. Но похоже, что в коде, который Proxmox устанавливает в ядро, должна быть ошибка. Если это случается так редко, что вы видите его только один раз в месяц и только по одному переключателю за раз, тогда может потребоваться много времени, чтобы отследить его. Я подумаю об этом и прокомментирую, если появятся новые идеи.

— Касперд

Для меня это звучит как ошибка в драйвере Ethernet или аппаратном / программном обеспечении, это красный флаг:

e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly

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

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

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

Также замена оборудования Ethernet может исправить это. Либо замените, либо добавьте новую (Intel) сетевую карту и используйте ее вместо этого. Скорее всего, если проблема в аппаратном / микропрограммном обеспечении, исправлена более новая карта (или более старая?).

— aseq
источник

Все машины имеют двойные порты Ethernet, однако эта ошибка возникает на нескольких серверах одновременно, которые находятся на одном коммутаторе в тот момент, когда одна из машин блокируется. В момент отключения питания одного заблокированного сервера все затронутые серверы снова становятся доступными. Похоже, это указывает на то, что заблокированный сервер не полностью заблокирован, но каким-то образом затопляет перезагрузку машин на том же коммутаторе. Было бы интересно посмотреть, может ли помочь обновление драйвера, но я не думаю, что активация другой карты Ethernet может помочь, основываясь на доказательствах.

— Кертис

Старый поток, но даже с Intel E1000e NIC Model 82574L и одной из более новых версий ProxMox 5.0-23 / af4267bf проблемы с сетью все еще остаются. Я могу вывести свой ноутбук с Windows (разбудить из спящего режима или просто войти в систему), подключенный к тому же коммутатору, и сервер ProxMox перезагружается практически каждый раз. Я также видел, что он просто периодически перезагружался, когда не подключен к коммутатору. И он перезагрузится, когда я впервые подключу его к коммутатору. Текущий драйвер - 3.3.5.3, а есть 3.3.5.10, 3.3.6 и 3.4.0.2, так что я, вероятно, попробую собрать и использовать их. Мой .02c.

— JGlass