Сеть / Multipath drop

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

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

multipath
multipath -ll

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

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

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

  • Доступ в Интернет настраивается через eth0 и eth2 (привязан)
  • Многопутевой доступ к SAN настраивается через eth1 и eth3

Сервер:

  • Supermicro SuperServer 6016T-NTRF
  • Процессор Intel(R) Xeon(R) E5645
  • Корпорация Intel 82576 Гигабитная сеть

  • CentOS релиз 5.7 (финальный) 2.6.18-274.18.1.el5xen

  • имя файла: /lib/modules/2.6.18-274.18.1.el5xen/kernel/drivers/net/igb/igb.ko

  • версия: 3.0.6-k2-1

  • Log 01

  • Журнал 02

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

Источник

1 ответ

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

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

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

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

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

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

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

Источник
Другие вопросы по тегам