Изначально в сети могла использоваться конфигурация с портами 1/10G — такое подключение на абонентской стороне часто сохраняется до сих пор. Со временем нагрузка и объемы трафика увеличивались, и на новых участках сети стали появляться интерфейсы 25/40G. При этом трафик в сторону магистрали агрегируется и передается через несколько портов 100G. В результате в операторской инфраструктуре могут одновременно работать оборудование разных поколений с различной пропускной способностью интерфейсов.
Платформа СКАТ учитывает эту неоднородность и покрывает все основные сценарии установки (in-line, on-stick, mirror), в которых интерфейсы с разной пропускной способностью могут работать одновременно. Для этого в платформе предусмотрен набор «движков» — конфигураций dpdk-интерфейсов (data-портов), каждая из которых описывает свою комбинацию режимов работы. За одновременную поддержку разнотипных интерфейсов в рамках одной платформы отвечает конфигурация dpdk_engine=7.
Почему стандартные движки перестают справляться
Все прежние движки (dpdk_engine=0..6) используют одну схему распределения диспетчеров для всего кластера:
- dpdk_engine=0 — один диспетчер на весь кластер;
- dpdk_engine=1 — по диспетчеру на направление (in/out);
- dpdk_engine=2 — RSS-диспетчеры на направление;
- dpdk_engine=3 — диспетчер на каждый мост;
- dpdk_engine=4 — диспетчер на каждый порт;
- dpdk_engine=6 — RSS-диспетчеры на мост, для мощных карт 100G+.
Подробности по каждому режиму — в документации СКАТ.
Такая модель работает, пока порты одной пропускной способности. Но в операторской сети более часто встречается следующая ситуация: множество портов 10G на стороне абонентской сети и один-два порта 100G на стороне аплинка. Характерно, например, для подключения BRAS, где пропускная способность LAN и WAN сильно различается. Встречаются и более сложные конфигурации, где одновременно используются порты 100G, 40G и 10G с разными схемами распределения диспетчеров.
Для таких ситуаций общая схема уже не всегда оптимальна. Для одних портов ресурсов может быть больше чем требуется, а для других — недостаточно для эффективной обработки нагрузки.
Как независимо распределять диспетчеры с dpdk_engine=7
dpdk_engine=7, или движок с явным конфигурированием диспетчеров, позволяет вручную определить, какие порты обслуживает каждый диспетчер и какие ресурсы ему выделяются. В отличие от предыдущих режимов, где выбиралась одна фиксированная схема распределения для всей системы, новый движок дает возможность настроить обработку каждой группы портов независимо.
Для каждого диспетчера можно отдельно задать:
- список обслуживаемых портов;
- mempool — пул памяти для пакетов с заданным размером;
- при необходимости — RSS с нужным числом очередей.
В отличие от предыдущих режимов, здесь не нужно выбирать одну схему распределения для всего кластера. Порты можно разделить на группы и для каждой задать собственную конфигурацию обработки.
При этом dpdk_engine=7 является универсальным: через него можно реализовать любую схему распределения, доступную в dpdk_engine=0..6.
Например, «диспетчер на направление» (аналог dpdk_engine=1) записывается так:
in_dev=port1:port2 out_dev=port3:port4 dpdk_dispatch=port1,port2;mempool=main dpdk_dispatch=port3,port4;mempool=main dpdk_mempool=name=main;size=1600000
Можно настроить и смешанную схему, где часть портов работает через обычный диспетчер, а другая — через RSS:
in_dev=port1:port2 out_dev=port3:port4 dpdk_dispatch=port1:port2;mempool=main10G dpdk_dispatch=port3:port4;rss=16;mempool=main100G dpdk_mempool=name=main10G;size=1600000 dpdk_mempool=name=main100G;size=8000000
Здесь группа 10G обслуживается одним диспетчером с mempool main10G, а порты 100G — диспетчером с RSS (16 очередей) и отдельным, более крупным mempool main100G. Параметры обработки можно подобрать отдельно для групп портов с разной производительностью.
Рисунок 1 — Архитектура диспетчеризации dpdk_engine=7
Из ограничений — конфигурация будет считаться некорректной, если порт не попал ни в один dpdk_dispatch или попал сразу в несколько. Порт должен входить только в один dpdk_dispatch, а все порты внутри одного диспетчера должны относиться к одному кластеру.
Как выглядят смешанные конфигурации крупных операторов
Такая схема потребовалась оператору после модернизации аплинков. На верхнем уровне сети появились высокоскоростные интерфейсы, тогда как на нижнем сохранились 10G-подключения. Полностью модернизировать эти интерфейсы было нецелесообразно: замена оборудования и портов потребовала бы значительных ресурсов.
При этом трафик от разных источников сходился на одном сервере. Разносить его обработку по отдельным серверам означало бы дополнительно задействовать оборудование и нерационально расходовать вычислительные ресурсы.
Рисунок 2 — Схема сети оператора
Ранее СКАТ позволял собирать бриджи с интерфейсами одной пропускной способности. Для смешанной конфигурации требовалась возможность независимо настраивать обработку разных групп портов.
dpdk_engine=7 позволяет задать для каждой группы свое количество и тип диспетчеров. Это дает возможность учитывать разницу в пропускной способности интерфейсов и не распределять одинаковые ресурсы между портами с разной нагрузкой.
В результате систему не пришлось перестраивать под одну скорость интерфейсов или выносить обработку отдельных групп на дополнительные серверы. В итоге удалось адаптировать обработку под уже существующую конфигурацию сети и эффективнее использовать доступные аппаратные ресурсы.
Что дает dpdk_engine=7
dpdk_engine=7 снимает ограничение прежних движков — невозможность применить разные стратегии диспетчеризации к разным частям одного кластера. Это особенно важно для крупных инсталляций с гетерогенным набором карт, где точная настройка числа диспетчеров и памяти под конкретную группу портов напрямую влияет на производительность и экономию ядер.
Если при переходе на dpdk_engine=7 возникают вопросы по количеству диспетчеров, размеру mempool или другим параметрам — обращайтесь в техподдержку VAS Expert. Специалисты помогут подобрать конфигурацию под конкретную схему подключения и нагрузку на интерфейсы.
