У нас есть пара дюжин серверов 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, которые не были подключены к тому же коммутатору.)
Заранее благодарю за любой совет.
источник
Ответы:
Я почти уверен, что ваша проблема вызвана не одним-единственным фактором, а комбинацией факторов. Что это за отдельные факторы, неизвестно, но, скорее всего, одним из них является либо сетевой интерфейс, либо драйвер, а другой фактор находится на самом коммутаторе. Следовательно, вполне вероятно, что проблема может быть воспроизведена только с этой конкретной маркой коммутатора в сочетании с этой конкретной маркой сетевого интерфейса.
Похоже, что причиной проблемы является то, что что-то происходит на одном отдельном сервере, который затем испытывает панику ядра, которая имеет эффекты, которые каким-то образом распространяются через коммутатор. Это звучит правдоподобно, но я бы сказал, что примерно так же вероятно, что триггер находится где-то еще.
Возможно, что-то происходит на коммутаторе или сетевом интерфейсе, что одновременно вызывает панику ядра и проблемы со связью на коммутаторе. Другими словами, даже если бы ядро не имело паники ядра, триггер вполне мог повредить связность на коммутаторе.
Необходимо спросить, что может произойти на отдельном сервере, что может повлиять на другие серверы. Это не должно быть возможно, поэтому объяснение должно включать недостаток где-то в системе.
Если это была просто связь между сбойным сервером и коммутатором, который вышел из строя или стал нестабильным, то это не должно влиять на состояние связи с другими серверами. Если это произойдет, это будет считаться недостатком в коммутаторе. А в случае трафика другие серверы должны видеть чуть меньше трафика после того, как сбойный сервер потерял связь, что не может объяснить, почему они видят проблему, которую делают.
Это наводит меня на мысль, что вероятен недостаток дизайна коммутатора.
Однако проблема со связью - это не первое объяснение, которое нужно искать, пытаясь объяснить, как проблема на одном сервере может вызвать проблемы на других серверах коммутатора. Широковещательный шторм был бы более очевидным объяснением. Но может ли быть связь между сервером, имеющим панику ядра и широковещательный шторм?
Многоадресная передача и пакеты, предназначенные для неизвестных MAC-адресов, более или менее обрабатываются так же, как широковещательные рассылки, поэтому шторм таких пакетов также будет учитываться. Может ли сервер в состоянии паники пытаться отправить по сети аварийный дамп на MAC-адрес, не распознанный коммутатором?
Если это триггер, то на других серверах что-то идет не так. Поскольку пакетный шторм не должен вызывать такого рода ошибки на сетевом интерфейсе.
Reset adapter unexpectedlyне похоже на пакетный шторм (который должен просто вызывать падение производительности, но не приводит к ошибкам как таковым), и это не похоже на проблему со связью (которая должна была привести к сообщениям о сбое ссылок, но не к ошибке, которой вы являетесь видя).Таким образом, вполне вероятно, что имеется какое-то изъян в оборудовании или драйвере сетевого интерфейса, которое вызывается коммутатором.
Несколько предложений, которые могут дать дополнительные подсказки:
источник
Для меня это звучит как ошибка в драйвере Ethernet или аппаратном / программном обеспечении, это красный флаг:
Я видел это раньше, и он может выбить сервер в автономном режиме. Я точно не помню, было ли это на картах Intel Ethernet, но я верю в это. Это может даже быть связано с ошибкой в самих картах Ethernet. Я помню, что читал что-то о конкретных картах Intel Ethernet, имеющих такие проблемы. Но я потерял ссылку на статью.
Я полагаю, что триггер для этого зависит частично от используемого драйвера (версии), и тот факт, что более старая версия программного обеспечения работает нормально, кажется, подтверждает это. Вы говорите, что поставщик использует свое собственное ядро, попробуйте обновить модуль драйвера Ethernet, который используется для вашего конкретного оборудования Ethernet. Либо от вашего поставщика, либо от официального дерева исходного кода ядра.
Также обратите внимание на соединение вашего оборудования Ethernet, обычно сервер имеет два порта Ethernet, встроенных и / или дополнительных карт. Таким образом, если у одной сетевой карты возникнет эта проблема, другая подхватит. Я использую слово «карта», но оно, конечно, относится к любому оборудованию Ethernet.
Также замена оборудования Ethernet может исправить это. Либо замените, либо добавьте новую (Intel) сетевую карту и используйте ее вместо этого. Скорее всего, если проблема в аппаратном / микропрограммном обеспечении, исправлена более новая карта (или более старая?).
источник