«Виноват коммутатор» - первая рука, которую поднимают, когда вместо 12,5 ГБ/с на воротах едет 5,1.
Каждое железо по отдельности работало, как обещал паспорт. Сломалось сочетание. Решает размер кадра и то, сколько пакетов в секунду способен переварить принимающий.
Стандартный кадр - 1500 байт. Jumbo - 9000. На одном и том же MTU 1500 полезная полоса на графике доклада гуляет от 94,9 до 23,4 Гбит/с. Разница вчетверо при одном и том же кадре. Если узел держит 8 млн пакетов/с, кадр 1500 ещё живой. При потолке 4 млн пакетов/с узел не вывозит поток, пока MTU не дойдёт примерно до 3000. При потолке 2 млн - пока не дойдёт примерно до 6200.
Работа на пакет почти не зависит от его размера. Прерывание, заголовок, стек, копирование. Шесть маленьких пакетов стоят процессору примерно вшестеро дороже одного большого. Пока узел не упёрся в пакеты, MTU почти ничего не меняет. Упёрся - от кадра зависит полоса.
Коммутатор здесь задаёт MTU и выбрасывает слишком большие кадры. Потолок пакетов у его ASIC выше, чем у концов. ASIC держит 148 млн пакетов/с, это в 18 раз больше, чем нужно, чтобы прогнать 100 Гбит кадром 1500.
❗ Почему так происходит.
▪️ Ищут один виноватый этаж. Полоса просела на стыке. Сервер, коммутатор и контроллер по отдельности в паспорт укладывались.
▪️ Маленький кадр везёт те же байты большим числом пакетов. Потолок пакетов у контроллера общий на всех хостов.
▪️ Jumbo включён на одном конце. По пути кадр режется или дропается, и проверка на публичный адрес этого не показывает.
Выводы. Вы на грани той самой ошибки, если:
1️⃣ MTU 1500 на тракте до склада, а в закупке уже следующая карта.
2️⃣ Jumbo включили на сервере и не проверили кадр до контроллера.
3️⃣ Скорость порта в ethtool считаете полезной полосой.
4️⃣ Пакеты в секунду ни разу не снимали, смотрели только гигабиты в брошюре.
Что делать вместо:
✅ Посмотрите MTU интерфейса. Имя подставьте своё.
ip link show dev eth0
✅ Проверка кадра с запретом фрагментации есть на шпаргалке сети. ping -M do -s 1472 - это кадр 1500. Для jumbo 9000 размер полезной нагрузки 8972. Адрес - контроллер склада на этом тракте, не публичный DNS со шпаргалки. «Message too long» или тишина значит, что по пути MTU меньше.
ping -M do -s 1472 <адрес контроллера>
ping -M do -s 8972 <адрес контроллера>
✅ Пакеты за секунду - разница двух чтений счётчика. Повторите команду через секунду и вычтите.
cat /sys/class/net/eth0/statistics/rx_packets
✅ Поднять MTU можно одной строкой, и только после того, как большой ping прошёл весь путь. Иначе коммутатор начнёт дропать giants.
ip link set dev eth0 mtu 9000
То же самое на контроллере и на коммутаторе между ними. Потом снова ping -M do -s 8972.
📌 На стенде доклада. На 100 Гбит при MTU 1500 нужно 8,13 млн пакетов/с. На 9000 хватает 1,38 млн. GPU-сервер на TCP с GRO и TSO держит около 10 млн, один поток на одном ядре - 1,8. Контроллер на NVMe/TCP около 3 млн, на iSCSI с conntrack около 2. Netfilter и conntrack срезают ещё около трети. Потолок контроллера 2-4 млн пакетов делится на всех хостов. Это 23-47 Гбит на контроллер. Отсюда на воротах 5,1 ГБ/с вместо 12,5.
У вас на тракте до склада сейчас MTU 1500?
#tough_case #кейсы
Каждое железо по отдельности работало, как обещал паспорт. Сломалось сочетание. Решает размер кадра и то, сколько пакетов в секунду способен переварить принимающий.
Стандартный кадр - 1500 байт. Jumbo - 9000. На одном и том же MTU 1500 полезная полоса на графике доклада гуляет от 94,9 до 23,4 Гбит/с. Разница вчетверо при одном и том же кадре. Если узел держит 8 млн пакетов/с, кадр 1500 ещё живой. При потолке 4 млн пакетов/с узел не вывозит поток, пока MTU не дойдёт примерно до 3000. При потолке 2 млн - пока не дойдёт примерно до 6200.
Работа на пакет почти не зависит от его размера. Прерывание, заголовок, стек, копирование. Шесть маленьких пакетов стоят процессору примерно вшестеро дороже одного большого. Пока узел не упёрся в пакеты, MTU почти ничего не меняет. Упёрся - от кадра зависит полоса.
Коммутатор здесь задаёт MTU и выбрасывает слишком большие кадры. Потолок пакетов у его ASIC выше, чем у концов. ASIC держит 148 млн пакетов/с, это в 18 раз больше, чем нужно, чтобы прогнать 100 Гбит кадром 1500.
❗ Почему так происходит.
▪️ Ищут один виноватый этаж. Полоса просела на стыке. Сервер, коммутатор и контроллер по отдельности в паспорт укладывались.
▪️ Маленький кадр везёт те же байты большим числом пакетов. Потолок пакетов у контроллера общий на всех хостов.
▪️ Jumbo включён на одном конце. По пути кадр режется или дропается, и проверка на публичный адрес этого не показывает.
Выводы. Вы на грани той самой ошибки, если:
1️⃣ MTU 1500 на тракте до склада, а в закупке уже следующая карта.
2️⃣ Jumbo включили на сервере и не проверили кадр до контроллера.
3️⃣ Скорость порта в ethtool считаете полезной полосой.
4️⃣ Пакеты в секунду ни разу не снимали, смотрели только гигабиты в брошюре.
Что делать вместо:
✅ Посмотрите MTU интерфейса. Имя подставьте своё.
ip link show dev eth0
✅ Проверка кадра с запретом фрагментации есть на шпаргалке сети. ping -M do -s 1472 - это кадр 1500. Для jumbo 9000 размер полезной нагрузки 8972. Адрес - контроллер склада на этом тракте, не публичный DNS со шпаргалки. «Message too long» или тишина значит, что по пути MTU меньше.
ping -M do -s 1472 <адрес контроллера>
ping -M do -s 8972 <адрес контроллера>
✅ Пакеты за секунду - разница двух чтений счётчика. Повторите команду через секунду и вычтите.
cat /sys/class/net/eth0/statistics/rx_packets
✅ Поднять MTU можно одной строкой, и только после того, как большой ping прошёл весь путь. Иначе коммутатор начнёт дропать giants.
ip link set dev eth0 mtu 9000
То же самое на контроллере и на коммутаторе между ними. Потом снова ping -M do -s 8972.
📌 На стенде доклада. На 100 Гбит при MTU 1500 нужно 8,13 млн пакетов/с. На 9000 хватает 1,38 млн. GPU-сервер на TCP с GRO и TSO держит около 10 млн, один поток на одном ядре - 1,8. Контроллер на NVMe/TCP около 3 млн, на iSCSI с conntrack около 2. Netfilter и conntrack срезают ещё около трети. Потолок контроллера 2-4 млн пакетов делится на всех хостов. Это 23-47 Гбит на контроллер. Отсюда на воротах 5,1 ГБ/с вместо 12,5.
У вас на тракте до склада сейчас MTU 1500?
#tough_case #кейсы
Просмотры: 2