Как я могу устранить неполадки производительности перенаправления маршрутизатора / брандмауэра Linux с Intel 10 Gbe?
У нас есть брандмауэр Linux с двумя внешними адаптерами 10Gbe (Intel 82599EB) и одним внутренним адаптером 10Gbe (Intel 82598EB).
Проблема, с которой я сталкиваюсь, заключается в том, что брандмауэр будет пересылать входящий трафик только с очень низкой скоростью: примерно < 2 Мбит / с. Однако прямое соединение с брандмауэром с "внутренней" машиной получает ~6 Гбит / с, а прямое соединение с брандмауэром с внешней машины - ~1 Гбит / с. Есть некоторые настройки, которые должны быть сделаны четко, но они демонстрируют скорости Gbps.
Мы недавно обновили Intel ixgbe драйвер с версии 2.1.4 до 3.7.14 из-за проблем со стабильностью с драйвером 2.1.4 (блокировки), и это, кажется, когда начались проблемы с пропускной способностью.
Я также попробовал выпуск 3.7.17, но это дало производительность, аналогичную 3.7.14. При возврате к драйверу 2.1.4 (перекомпилированному для обновленного ядра с IXGBE_NO_LRO и IXGBE_NO_NAPI) мне удалось получить пропускную способность ~Gbps (хорошо ~900 Мбит / с с iperf по TCP с 3 потоками).
Это решает непосредственную проблему, но я предпочел бы иметь возможность использовать текущую версию драйвера, так как я хотел бы идти в ногу с исправлениями ошибок и т.д., поэтому мой вопрос
- Как я могу устранить неполадки производительности перенаправления маршрутизатора / брандмауэра Linux?
В частности, как я могу узнать, где ядро / iptables / сетевой драйвер и т. Д. Тратят свое время при пересылке пакетов?
Любые соответствующие советы будут оценены.
4 ответа
Действительно странно, что вы получаете только 1 Гбит / с производительности маршрутизации (даже жесткая фильтрация обычно означает 2 копии в пространстве ядра для одного устройства, вероятно, 4x для маршрутизации) - год назад было сообщение LKML, в котором вы можете получить 120 Гбит / с производительности маршрутизации на 2.6.3X серии с ixgbe устройства. Я в основном использую сетевые карты Intel 10GbE и обычно получаю 1000MByte/s+ с iperf через коммутируемую инфраструктуру.
Сначала вам нужно проверить, как система работает для простого TCP с чем-то вроде iperf между вашими конечными точками. Это должно дать вам базовый уровень. Помните, что многие вещи вступают в игру, если вам нужна скорость передачи 10 Гбит / с. На платформах до Nehalem этого даже невозможно достичь. Также загрузка системы должна соответствовать расположению NUMA, и сетевые адаптеры должны быть подключены к одному и тому же PCI-комплексу (это важно, если вы застряли на скорости < 8 Гбит / с). В исходном дистрибутиве ixgbe есть сценарий закрепления IRQ (который также отключает такие функции, как энергосбережение и irqbalancer, который только испортит кэш и не знает топологии), который должен распределять очереди RX-TX равномерно по всем ядрам (не проверял их в какое-то время).
Что касается вашего вопроса о таймингах, вам нужно ядро, скомпилированное с поддержкой профилирования, и профилировщик системного уровня, такой как oprofile,
Прежде чем включить фильтрацию или маршрутизацию пакетов и опубликовать их, выясните производительность конечной точки и конечной точки.
Несколько месяцев назад я приложил немало усилий для оптимизации Linux для гигабитной маршрутизации с высокой скоростью и большим количеством маленьких пакетов. Это было для балансировщика нагрузки (IPVS), а не брандмауэра NAT. Вот несколько советов, основанных на этом.
- Обновите ядро Linux до версии не ниже 2.6.30 (нам нужен был обновленный драйвер Broadcom bnx2)
- Используйте ifconfig для проверки интерфейса на наличие ошибок, ошибок и т. Д.
- Загрузите и скомпилируйте последнюю версию ethtool, чтобы убедиться, что она полностью поддерживает драйвер NIC.
- Используйте ethtool для поиска более подробной статистики
- Используйте ethool для настройки параметров объединения, NAPI и т. Д., Чтобы свести к минимуму прерывания
- Посмотрите на irqbalance, чтобы убедиться, что они сбалансированы между ядрами процессора
- Посмотрите на потоки ядра, такие как ksoftirqd... они используют много процессора?
- ПОЛНОСТЬЮ отключите iptables, выгрузив модули ядра с помощью rmmod. Особенно NAT и conntrack могут оказать огромное негативное влияние, даже если вы сбросили все правила и имеете пустые цепочки. Я видел огромное увеличение производительности при этом. Вы упомянули, что это брандмауэр, но я все равно временно выгрузил бы модули NAT и conntrack, чтобы увидеть, если это что-то меняет.
Я еще не видел разбивки по времени, затрачиваемому на сетевую функцию ядра, такую как переключение между маршрутизацией, брандмауэром и всем остальным.
Iptables действительно эффективный брандмауэр для систем Linux. Он может обрабатывать огромное количество трафика без узкого места, если вы написали хороший набор правил.
Вы можете отключить iptables, сбросив все правила и установив значения по умолчанию. FORWARD политика в ACCEPT, Таким образом, вы можете устранить любые опасения по поводу реализации iptables. После этого вы можете посмотреть на сетевой драйвер и попытаться отладить проблему, если она не устранена.
В качестве совета, будьте осторожны и не отключайте iptables на общедоступной машине, если вы не знаете, что делаете.
Производительность односторонней загрузки может быть вызвана проблемами с разгрузкой сегментации tcp и другими настройками сетевой карты. Во многих случаях это может быть замечено, например, с трафиком VM или VPN, проходящим через физический NIC. Его легко отключить с помощью ethtool и проверить производительность, поэтому стоит попробовать (не забудьте отключить его на обеих конечных точках для тестирования).
/usr/sbin/ethtool -K eth0 tso off
/usr/sbin/ethtool -K eth0 lro off
Вот еще немного предыстории:
http://www.peerwisdom.org/2013/04/03/large-send-offload-and-network-performance/ https://social.technet.microsoft.com/Forums/windowsserver/en-US/bdc40358-45c8-4c4b-883b-a695f382e01a/very-slow-network-performance-with-intel-nic-when-tcp-large-send-offload-is-enabled?forum=winserverhyperv