iSCSI и Jumbo Frames: почему MTU 9000 решил половину проблемы с throughput
На новом iSCSI SAN обнаружили просадку throughput при крупных блоках. Оказалось, на коммутаторе не были включены Jumbo Frames. После правки - пропускная способность выросла вдвое.
iSCSI-хранилища набирают позиции как стандарт для СХД среднего бизнеса - без Fibre Channel и с обычными гигабитными коммутаторами
Несколько недель назад запустили iSCSI-хранилище у очередного клиента - средний производственный офис, около 30 серверов, задача переехать с локальных дисков на централизованный пул. Схема привычная: OpenFiler на отдельном железе, выделенная гигабитная сеть, Windows Server 2003 с Microsoft iSCSI Initiator как клиент, MPIO для отказоустойчивости - то, что мы уже делали и что работает предсказуемо.
Запустили. Базовые проверки прошли. Небольшие файлы - отлично. Тут начался SQL Server с порядочной аналитической нагрузкой, и картина стала другой.
Где проявилась проблема
При работе с крупными блоками - последовательное чтение больших таблиц, бэкап базы, массовая выгрузка - throughput был заметно ниже ожидаемого. Гигабитная сеть теоретически даёт около 110-120 МБ/с практических; мы видели примерно вдвое меньше. При этом на мелких блоках и OLTP-нагрузке всё было в порядке - задержки нормальные, IOPS не проседают.
Первая мысль - очередь на коммутаторе, насыщение uplink'а, что-то с буферами OpenFiler. Проверили через iperf между двумя серверами в том же сегменте - полоса в порядке. Значит, узкое место не в физическом канале и не в железе хранилища.
Посмотрели на iSCSI-трафик через tcpdump. Картина стала понятнее: пакеты дробятся. iSCSI передаёт данные блоками, и при крупных операциях стек пытается отправить большие куски - но если MTU стандартный (1500 байт), каждый такой кусок разбивается на множество мелких фреймов. Это фрагментация на уровне IP, дополнительный overhead на каждый пакет, и в сумме - потери пропускной способности именно на последовательных крупных операциях. На мелких IOPS это почти не заметно: там блоки и так небольшие.
Jumbo Frames и почему о них забыли
Jumbo Frames - это фреймы с MTU больше стандартных 1500 байт. Для хранилищ iSCSI обычно рекомендуют MTU 9000: один большой фрейм вместо шести стандартных, меньше заголовков, меньше прерываний CPU на обработку, выше throughput на последовательных операциях.
Про Jumbo Frames знали. Но при вводе в эксплуатацию - не включили. Точнее, включили на серверах (сетевые адаптеры настроили на MTU 9000), но забыли про коммутатор. А коммутатор в хранилищном сегменте - обычный управляемый гигабитный, где Jumbo Frames по умолчанию выключены и нужно включать явно на каждом порту и на VLAN.
Это типичная ловушка: MTU на всех участниках сессии должен совпадать, иначе коммутатор будет молча дробить фреймы обратно до 1500. Никаких ошибок в логах, никаких явных сигналов - просто throughput ниже расчётного.
Что поменяли
На коммутаторе включили Jumbo Frames на всех портах хранилищного VLAN - команда зависит от производителя, у нас был Cisco Catalyst, там это mtu 9000 на интерфейсе и ip mtu 9000 для L3 если нужно. Перезагрузки не потребовалось.
На серверах MTU уже стоял 9000 через свойства сетевого адаптера - не трогали.
На OpenFiler - сетевой интерфейс хранилища тоже поправили через /sbin/ip link set eth1 mtu 9000 и прописали в /etc/sysconfig/network-scripts/ifcfg-eth1 чтобы не слетело после перезагрузки.
После этого прогнали тест повторно. Последовательный throughput вырос примерно вдвое - до значений, близких к теоретическому максимуму гигабита. На мелких блоках разница минимальная, как и ожидали.
Что важно помнить при настройке
Несколько выводов, которые теперь войдут в наш чеклист для iSCSI-развёртываний:
Jumbo Frames - это настройка всей цепочки, а не отдельных узлов. Коммутатор, NIC на клиенте, NIC на хранилище - все три должны быть согласованы. Если хоть один участник не поддерживает или не настроен, фреймы дробятся без предупреждений.
Throughput-проблема проявляется на крупных блоках - OLTP с мелкими транзакциями может работать вполне прилично даже без Jumbo Frames, и тогда проблема вылезет только под нагрузкой бэкапа или аналитики.
Диагностика через tcpdump - смотреть на размер фреймов в реальном трафике. Если при MTU 9000 на серверах видны фреймы по 1500 байт - проблема в коммутаторе или промежуточном узле.
Проверка MTU после смены - ping -f -l 8972 <ip-хранилища> (Windows) или ping -M do -s 8972 <ip> (Linux) убеждается что большие пакеты проходят без фрагментации. Если падают с ICMP «fragmentation needed» - где-то в цепочке ещё есть стандартный MTU.
Для инфраструктур, которые мы ведём, добавляем этот пункт в стандартный acceptance-тест при вводе iSCSI-хранилища в эксплуатацию. Потому что находить это постфактум, когда клиент уже видит «что-то медленно», - некомфортно.