Началась эта история с того, что к нам (админам) прибежал программер. “… он прибежал взволнован крайне и сообщеньем нас потряс…” Оказывается, что на наших Linux web-backend-ах наблюдаются стабильные потери пакетов на сетевых картах. В ходе разбирательства выяснилось, что теряются RX-пакеты.

web-backend9:/home/flycat # ifconfig
eth0      Link encap:Ethernet  HWaddr 00:1A:64:76:00:14
inet addr:10.10.10.11  Bcast:10.10.255.255  Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:1616158390 errors:0 dropped:4829045 overruns:0 frame:0
TX packets:1807335344 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4147984125 (3955.8 Mb)  TX bytes:3238300193 (3088.2 Mb)
Interrupt:106 Memory:dc000000-dc012100

На скорую руку я набросал параметр для Zabbix агента, который собирает статистику по потерям:

UserParameter=droppack,ifconfig eth0|grep "RX packets"|cut -f14 -d" "|cut -f2 -d":"

С его помощью выяснилось, что пакеты теряются на “железных” машинах в количестве около 200 штук в минуту. Вот как это видится на графике:

Конечно, это не бог весть какое количество, учитывая, какой трафик идёт на машину в целом. Но неприятно и “неаккуратненько как-то” (с). Поэтому сетевики бросились исследовать своё сетевое хозяйство, а меня начали “терзать смутные сомненья” на предмет самих сетевых карт и драйверов к ним. Удалось понять, что эффект обнаруживается на блейдах IBM eServer BladeCenter HS21 -[7995L6G]. В них была установлена сетевая карта Broadcom NetXtreme II BCM5708 1000Base-SX (B2) PCI-X с драйвером bnx2.

Гугление по словам “bnx2 sles10 dropped” быстро выдало ссылку на официальный Novell-овский документ: “BNX2 driver drops packets – erratic behavior of UDP-based applications and TCP slowness“. Как видите, Novell честно предупреждал, что эта ошибка в драйвере может послужить причиной как замедления передачи по TCP (переспросы), так ошибок при передаче по UDP (привет, DNS!). Но дальнейшие наши действия уже стали ясны и, как говорится, были делом техники: скачать ядро с обновлением из репозиториев, обновить, перезагрузить.

Но, как ни странно, этим всё не ограничилось. Попутно ещё нужно было пересобрать из исходников Multi-Path Proxy драйвер rdac (это такая прослойка между драйвером оптики и ядром, которая осуществляет переключение между путями HBA в случае падения одной из оптических линий). Казалось бы, всё несложно, однако initrd, собранный с новым linuxrdac-09.03.0C05.0214 наотрез отказывался находить корневой раздел на массиве.

С отчаянья мы попытались даже перейти на родной Linux-овый Multi-Path драйвер ядра. Но выяснилось, что в SLES10 корневой раздел на MultiPath не работает. И совершенно неясно, будет ли работать в SLES11. Опять гугление, выяснилось, что rdac теперь требует включения в initrd модуля sg.ko. Вот как теперь выглядит /etc/sysconfig/kernel:

INITRD_MODULES="sg ata_piix qla2xxx processor thermal fan jbd xfs edd mppVhba mppUpper"

После того как модуль sg включили, всё заработало, корневой раздел подмонтировался и загрузка пошла. Можно вздохнуть, вытереть пот со лба и проделать такую же процедуру ещё с десятком таких же production-серверов…