Чому блокування сервера збиває інші сервери з мережі?

У нас є кілька десятків серверів 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 - вихід із заблокованого сервера:

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

Два питання:

1. Будь-які підказки, що спричинило б паніку ядра (див. Зображення вище)?

2. Чому інші сервери на тому ж комутаторі та версії Proxmox будуть збиті з мережі, поки заблокований сервер не перезавантажиться? (Примітка. На цьому ж комутаторі були й інші сервери, на яких працювала старіша версія 1.9 Proxmox, які не впливали. Також жодних інших серверів Proxmox у тому ж кластері 3.1 не було задіяно, які не були на тому самому комутаторі.)

Заздалегідь дякую за будь-яку пораду.

Я майже впевнений, що ваша проблема викликана не одним-єдиним фактором, а скоріше поєднанням факторів. Що це за окремі фактори не є певним, але, швидше за все, один фактор є або мережевим інтерфейсом, або драйвером, а інший фактор знаходиться в самому комутаторі. Отже, цілком ймовірно, що проблема може бути відтворена лише з цією маркою комутатора в поєднанні з цією маркою мережевого інтерфейсу.

Вам здається, що тригером проблеми є щось, що відбувається на одному окремому сервері, який потім має паніку ядра, що має ефекти, які якимось чином вдаються поширити через комутатор. Це звучить ймовірно, але я б сказав, що приблизно так само ймовірно, що тригер є десь в іншому місці.

Можливо, щось відбувається на комутаторі або мережевому інтерфейсі, що одночасно викликає паніку ядра та проблеми з зв’язком на комутаторі. Іншими словами, навіть якщо в ядрі не було паніки з ядром, тригер, можливо, дуже зрушив зв'язок на комутаторі.

Потрібно запитати, що може трапитися на окремому сервері, що могло б мати такий вплив на інших серверах. Це не повинно бути можливим, тому пояснення повинно містити дефект десь у системі.

Якщо це був лише зв'язок між збійним сервером і комутатором, який знизився або став нестабільним, то це не повинно впливати на стан зв’язку з іншими серверами. Якщо це станеться, це вважатиметься вадою в комутаторі. А по дорозі інші сервери повинні бачити трохи менше трафіку, коли збійний сервер втратив зв’язок, що не може пояснити, чому вони бачать проблему, яку вони роблять.

Це змушує мене повірити, що ймовірний недолік дизайну на комутаторі.

Однак проблема зв’язку - це не перше пояснення, яке слід шукати, намагаючись пояснити, як проблема на одному сервері може спричинити проблеми іншим серверам на комутаторі. Більш очевидне пояснення могла б штормова трансляція. Але чи може бути зв’язок між сервером, що має паніку з ядром, та штормовою трансляцією?

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

Якщо це тригер, то на інших серверах щось відбувається не так. Оскільки пакетна буря не повинна викликати подібних помилок у мережевому інтерфейсі. Reset adapter unexpectedlyне звучить як штормовий пакет (який повинен просто спричинити падіння продуктивності, але помилок як такого), і це не звучить як проблема з посиланням (що повинно було призвести до того, що повідомлення про посилання знижуються, але не помилка ви бачачи).

Тому, швидше за все, є якийсь недолік у апаратному забезпеченні або драйвері мережевого інтерфейсу, який спрацьовує комутатором.

Кілька пропозицій, які можуть дати додаткові підказки:

1. Чи можете ви підключити якесь інше обладнання до вимикача і подивитися, який трафік ви бачите на комутаторі, коли з’являється проблема (я прогнозую, що він затихне, або ви побачите потоп).
2. Чи можна було б замінити мережевий інтерфейс на одному з серверів іншим брендом, використовуючи інший драйвер, щоб побачити, як результат виходить інакше?
3. Чи можна замінити один з вимикачів іншою маркою? Я думаю, що заміна комутатора забезпечить проблему більше не впливати на кілька серверів. Що цікавіше знати, якщо це також зупиняє паніку ядра від виникнення.

Мені це звучить як помилка в драйвері 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-картах. Я пам'ятаю, як щось читав про конкретні картки Ethernet, що мають такі проблеми. Але я втратив посилання на статтю.

Я б міг уявити, що тригер для цього частково залежить від використовуваного драйвера (версії), але, здається, це підтверджує і стара версія версії програмного забезпечення. Ви кажете, що постачальник використовує власне власне ядро, спробуйте оновити модуль драйверів Ethernet, який використовується для вашого конкретного обладнання Ethernet. Або один від вашого постачальника або один з офіційного дерева джерела ядра.

Крім того, погляньте на з'єднання обладнання для Ethernet, як правило, сервер має два порти Ethernet, бортовий та / або додавання на картки (картки). Таким чином, якщо одна проблема з мережею Ethernet матиме цю проблему, інша підбере. Я використовую слово "карта", але воно, звичайно, стосується будь-якого обладнання Ethernet.

Також заміна апаратного забезпечення Ethernet може це виправити. Або замініть або додайте новіші (Intel) Ethernet-карти та використовуйте це замість цього. Швидше за все, якщо проблема в апаратній / прошивці, новіша карта має виправлення (або старіша?).