Назад | Перейти на главную страницу

Отключение сети / многопутевого

У меня проблема с несколькими Linux-системами, на которых запущен xen. Они действуют как гипервизоры и подключены к SAN с помощью настройки многопутевого режима для предоставления хранилища гостевым виртуальным машинам.

Время от времени происходит сбой одного из двух путей, но его можно быстро восстановить, запустив:

multipath
multipath -ll

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

kernel: BUG: soft lockup - CPU#0 stuck for 60s! [swapper:0]
kernel: BUG: soft lockup - CPU#2 stuck for 60s! [events/2:76]

Я вставлю полные журналы в конце этого поста, чтобы его было легко читать. Теперь немного подробнее о моей настройке:

Сервер:

Если кому-то нужна дополнительная информация, пожалуйста, дотроньтесь. Любая помощь будет высоко ценится.

Поскольку это похоже на настройку iSCSI, есть несколько областей, где может произойти переключение пути.

  • Простая ненадежность Ethernet. Пакет был сброшен, что привело к переключению на другой путь вместо ожидания повторной передачи и повторной сборки.
  • Менее простые проблемы с Ethernet. Порт коммутатора ненадолго щелкнул, вызвав аварийное переключение.
  • Что-то в стеке Multipath вызвало аварийное переключение. Многопутевость более чувствительна к странностям сети, чем обычный старый TCP / IP, поэтому не требует много времени для восстановления соединений; вместо этого произойдет сбой.
  • Что-то в сетевом стеке пошло не так. Здесь есть несколько возможностей, но, судя по вашему сообщению об ошибке, это, скорее всего, проблема.

Многопутевые настройки очень чувствительны к задержке на проводе, и iSCSI + Ethernet будет иметь больше, чем среда Fibre Channel. Некоторое хлопанье будет нормальным.

Поскольку это, кажется, происходит, когда HVM занят, это говорит о том, что пути NIC ядра либо перегружены данными, либо испытывают нехватку ресурсов ЦП (возможно, и того, и другого), что запускает переключение по нескольким путям. С этим мало что можно сделать, но вы можете сузить круг вопросов, чтобы лучше объяснить Зачем он делает то, что делает.

Загрузка сервера довольно проста, и похоже, что вы уже это сделали.

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

Фиксация проблема, вероятно, связана с драйвером, с возможностью некоторой настройки настраиваемых параметров стека TCP / IP.