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

Проблема с фантомной сетевой картой, приводящая к отключению eth0 / 1

У нас возникла очень странная и неприятная проблема. У нашей компании есть серверы здесь, в Массачусетсе, а также в Калифорнии. Проблемы, которые мы наблюдаем, возникают только на оборудовании CA. В Калифорнии у нас есть несколько сотен серверов Dell R300 и Dell R310, подключенных к четырем коммутаторам HP Procurve 4208vl. Для каждой модели предусмотрено два коммутатора: один для внешней сети, а другой - для внутренней. Эти системы объединены в кластеры, и все они используются для различных тестов, которые мы проводим для тестирования нашей программной ОС, которую мы разрабатываем. Многие из этих тестов требуют успешных и / или повторяющихся перезагрузок. Многие, если не большинство тестов, повторно инициализируют узлы с помощью ОС. Проблема в том, что при наличии достаточного количества времени, по-видимому, случайным образом одна (или несколько) из этих систем будут иметь неработающий интерфейс eth0 или eth1.

Проблема в том, что узел будет периодически загружаться без подключения ни к eth0, ни к eth1, а иногда и к обоим. Обходной путь - подключиться по SSH через бэкэнд (если eth0 не работает) или внешний интерфейс (если eth1 не работает) и запустить ifdown / ifup на отключенном интерфейсе.

Список обходных путей: - перезапуск сервисной сети - если отключен eth1 (или eth0), затем ifup eth1 (или eth0) - переустановить сетевые кабели - перезагрузить сервер

Это огромная боль для команды разработчиков, поскольку это не позволяет целым кластерам запускать свои тесты до ручного вмешательства.

Хуже всего происходит, когда узел загружает busybox для установки ОС и eth0 отключается: в этом случае узел полностью недоступен, так как у нас нет eth1 в busybox, и установка ОС не может продолжаться, потому что не может поговорите с сервером PXE, чтобы загрузить последний образ ОС (поскольку eth0 не работает). Узлы, которые попадают в это состояние, будут застревать в таком состоянии до тех пор, пока я в следующий раз не позвоню кому-нибудь из CA и не заставлю его вручную перезагрузить узел.

Для решения этой, казалось бы, случайной и невоспроизводимой проблемы было сделано следующее:

Перед обновлением микропрограммы в журналах коммутатора HP Procurve отображается:

После обновления прошивки мы видим меньше этих ошибок, но они все еще сохраняются.

Для устранения неполадок я записывал обычную информацию:

ifconfig ; for n in 0 1; do ethtool eth$n;ethtool -i eth$n;ethtool -k eth$n;ethtool 
-S eth$n; done; dmesg | egrep 'eth|bnx|e1000'; cat /var/log/messages > /tmp/eth_issues

Вот несколько примеров вывода:

# ethtool -i eth0
driver: bnx2
version: 2.1.6
firmware-version: 6.4.5 bc 5.2.3 NCSI 2.0.11
bus-info: 0000:02:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes

# ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: on

 # ethtool -S eth0
 NIC statistics:
 rx_bytes: 0
 rx_error_bytes: 0
 tx_bytes: 5676016
 tx_error_bytes: 0
 rx_ucast_packets: 0
 rx_mcast_packets: 0
 rx_bcast_packets: 0
 tx_ucast_packets: 0
 tx_mcast_packets: 7
 tx_bcast_packets: 10495
 tx_mac_errors: 0
 tx_carrier_errors: 0
 rx_crc_errors: 0
 rx_align_errors: 0
 tx_single_collisions: 0
 tx_multi_collisions: 0
 tx_deferred: 0
 tx_excess_collisions: 0
 tx_late_collisions: 0
 tx_total_collisions: 0
 rx_fragments: 0
 rx_jabbers: 0
 rx_undersize_packets: 0
 rx_oversize_packets: 0
 rx_64_byte_packets: 0
 rx_65_to_127_byte_packets: 0
 rx_128_to_255_byte_packets: 0
 rx_256_to_511_byte_packets: 0
 rx_512_to_1023_byte_packets: 0
 rx_1024_to_1522_byte_packets: 0
 rx_1523_to_9022_byte_packets: 0
 tx_64_byte_packets: 1054
 tx_65_to_127_byte_packets: 7
 tx_128_to_255_byte_packets: 0
 tx_256_to_511_byte_packets: 0
 tx_512_to_1023_byte_packets: 9441
 tx_1024_to_1522_byte_packets: 0
 tx_1523_to_9022_byte_packets: 0
 rx_xon_frames: 0
 rx_xoff_frames: 0
 tx_xon_frames: 0
 tx_xoff_frames: 0
 rx_mac_ctrl_frames: 0
 rx_filtered_packets: 0
 rx_ftq_discards: 0
 rx_discards: 0
 rx_fw_discards: 0

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

Может ли кто-нибудь помочь мне отследить эту проблему до первопричины? Имейте в виду, что я никогда не знаю, когда и какая система будет виновником, и ОС часто подвергается перепроверке, поэтому установка программного обеспечения для ведения журнала бесполезна, поскольку она будет потеряна во время следующей подготовки продукта. Любая помощь или понимание, которое вы могли бы предоставить, будут оценены. Приветствуются также любые догадки или мысли. Пожалуйста, дайте мне знать, если вам нужна дополнительная информация или опубликованные результаты. Спасибо.

Ответ: приобретите более качественную сетевую карту и примите к сведению, что никогда больше не купите Broadcom:

http://blog.serverfault.com/2011/03/04/broadcom-die-mutha/

У нас есть несколько R300 и R310 - и никогда не возникало проблем после их загрузки. Кстати - что поддержка Dell говорит в вашем случае?

Итак, я предполагаю, что что-то не так на сетевой стороне оборудования (коммутаторы Procurve). Однако на вашем месте я бы написал простое решение:

Сценарий инициализации, который запускается на поздней стадии и выполняет ifdown / ifup, если на eth0 или eth1 не обнаружена ссылка.

Кстати: eth0 и eth1 есть на борту? Тогда оба должны иметь возможность выполнять PXE-загрузку (я сейчас не на работе, поэтому я не уверен в количестве встроенных интерфейсов - я обычно использую старших братьев R510, R710, ...).

Честно говоря, я сомневаюсь, что это проблема с оборудованием на данный момент ... и больше проблема с базовым драйвером в ОС, которую вы пытаетесь загрузить. По моему собственному опыту, драйвер bnx2 известен тем, что он довольно ужасен ... поскольку он написан Broadcom, чтобы попытаться осчастливить пользователей с открытым исходным кодом, но не более того. Вы пробовали скачивать / собирать драйверы прямо с Broadcom? Было бы интереснее посмотреть, что находится в безумном количестве широковещательных пакетов ... (прочтите это как попытку перехвата пакетов между сетевой картой и коммутатором) и бросьте это в Boadcom для обратной связи. Старый коммутатор (-ы), возможно, не жаловался, потому что они не беспокоились о работе с потоком плохих пакетов ... (на новом коммутаторе сообщается о большом количестве ошибок)