LINUX.ORG.RU
ФорумAdmin

Равномерное распределение пропускной способности между интерфейсами

 , , ,


0

1

Доброго всем времени суток!

Есть железка на которой 3 ethernet-интерфейса (аплинки). Для тестирования пока используются только 2, 3-й для подключения по SSH и прочих служебных нужд.

Прогнал простой тестовый сценарий для определения пропускной способности при большой нагрузке:
1) Каждый из двух тесируемых интерфейсов в своей подсети (1 - 10.10.10.0/24 и 2 - 20.20.20.0/24)
2) За каждым из этих интерфейсов (за некими шлюзами) существует по еще одной подсети (100.100.100.0/24 за 1 и 200.200.200.0/24 за 2)
3) Настроил маршрутизацию, получилось 2 маршрута - по 1 на подсеть
4) Запустил одновременно тестовый трафик из подсетей 100.100.100.0/24 и 200.200.200.0/24 «на встречу» друг-другу, трафик - UDP, размер кадра - 64 байта
5) Замерил скорости на обоих аплинках, в итоге: на первом интерфейсе в среднем около 70Мбит/с, а на втором около 260Мбит/с.

Из всего этого видно, что железка в простом сценарии маршрутизации выдает приблизительно 330 мбит/с, но общая пропускная способность делится неравномерно.

Собственно, вопрос: можно ли как-то распределить нагрузку, пусть даже с некоторой потерей производительности, так, чтобы она распределялась более-менее равномерно на каждый интерфейс?

P.S. Слышал что-то про планировщики типа FQ и FQ_Codel, но они, вроде как, распределяют нагрузку только внутри одного интерфейса. Возможно, не так понял.

Какая железяка, какая там ОС?

Обычно принято различать производительность в Мегабитах и в пакетах в секунду и пакеты 64 байта это скорее pps.

Какую именно скорость вы измерили? Может у вас исходно разный поток с аплинков на железяку шёл.

mky ★★★★★ ()
Ответ на: комментарий от mky

Железяку не имею права говорить. Коммерческая поделка.
Ядро Linux 4.1

Трафик генерировался на тестовом стенде Ixia, соответсвтенно, трафик однотипный и тут всё ок. Чтобы не быть голословным - пускали тот же трафик на один из маршрутизаторов, который оказался под рукой, там распределение оказалось равномерным. Про скорости не скажу, не записывал уже.

Lorence ()
Ответ на: комментарий от devl547

Агрегация двух интерфейсов в один? Если это имелось ввиду, то мне это не подходит.

Необходимо, чтобы при полной нагрузке общая пропускная способность железа делилась поровну на все интерфейсы, а сейчас она делится по принципу - кто первым отхватил канал, того и скорость.

Lorence ()
Ответ на: комментарий от Lorence

а сейчас она делится по принципу - кто первым отхватил канал

ты же понимаешь, что если через TCP сокет шлются данные, то пакеты не могут поочерёдно идти то через один, то через другой интерфейс?

zolden ★★★★★ ()
Ответ на: комментарий от zolden

Никто не подразумевал, что пакет должен сначала идти то через один, то через другой интерфейс. И я написал, что интерфейсы находятся в разных подсетях и трафик в них не пересекается. Соответственно, ядро просто должно обоим потокам данных выдать одинаковый приоритет и отбалансировать пропускную способность (в pps, я так понимаю) каким-либо из доступных способов, например, на одном из каналов искуственно отодвигая/отбрасывая пакеты в случае необходимости.

Я не специалист по сетям, конечно, но учитывая, что один из производителей маршрутизаторов в своих прошивках на Linux смог такое реализовать, то берусь предположить, что это можно воспроизвести и на других железках.

Lorence ()
Ответ на: комментарий от Lorence

Не очень понятен профиль вашего трафика и почему нельзя использовать аггрегацию линков.
Если профиль позволяет, то надо смотреть в сторону балансировки на уровне маршрутизации.
Если нет - то только аггрегация линков с каким-нибудь LACP

zolden ★★★★★ ()
Ответ на: комментарий от zolden

Интерфейсы должны остаться независимыми. Т.к. они будут находиться в разных подсетях и выполнять роль пограничного маршрутизатора дял офиса (сейчас там только 3 аплинк-интерфейса, а будет 8 ланов, 3 аплинка для подлючения к операторам и прочих нужд + wi-fi карточка). Вот теперь представьте,что будет, если без настройки QoS появится в сети клиент, который займёт всю пропускную способность железа (все каналы гигабитные).

Т.е. мне хотелось бы добиться более-менее справедливой балансировки всего трафика проходящего через ядро даже без полноценной настройки QoS. FQ_CoDel это должен делать, но как я понял он балансирует только трафик на интерфейсе, а не весь, как мне надо.

Lorence ()
Ответ на: комментарий от zolden

Если я правильно понял, то у ТС вобще нет задачи агрегации.

Он каким-то образом загружает трафиком два интерфейса, на пределе возможносей железа, и хочет получить одинаковые числа.

mky ★★★★★ ()
Ответ на: комментарий от mky

Почти.

Про «каким-то образом» еще раз поясню - тестовый стенд Ixia, 2 маршрута UDP трафика. Это, как показывается практика, достаточное условие чтобы выжать все соки из железок без аппаратного ускорения маршрутизации.

Про «получить одинаковые числа» - не совсем, я хочу чтобы в синтетических условиях одинаковый вид трафика балансировался на два одинаковых интерфейса приблизительно равномерно. А не в соотношении 1/5 как это сейчас есть.

Lorence ()
Ответ на: комментарий от mky

Если я правильно понял, то у ТС вобще нет задачи агрегации

Ну тут это же больше как очевидный инструмент, а не как цель или как задача

zolden ★★★★★ ()
Ответ на: комментарий от Lorence

Железка просто форвардит IP пакеты с одного интерфейса на второй, и со второго на первый. Про скорости непонятно. По идее есть pps форвардинга с первого на второй, есть pps форвардинга со второго на первый, есть суммарный pps. Pps форвардинга с первого на второй надо смотреть по счетчикам output packets на втором интерфейсе, pps форвардинга со второго на первый надо смотреть по счетчикам output packets на первом интерфейсе.

Если генератор UDP трафика генерирует одинаковые потоки дейтаграмм в обоих направлениях, а pps форвардинга разные, значит железка перегружена, и дропает пакеты. Почему дропает больше пакетов, входящих через один интерфейс, чем входящих через второй? Наверное аппаратно интерфейсы разные, с разной величиной буфера, с разными возможностями и/или скоростями передачи пакетов из буфера в оперативку хоста.

iliyap ★★★★★ ()
Последнее исправление: iliyap (всего исправлений: 1)
Ответ на: комментарий от iliyap

Так всё и есть. pps на форвардинге разные, т.к. железка работает на пределе. Про «интерфейсы разные, с разной величиной буфера» и все такое отпадает, т.к. большую пропускную способность на форвардинге показывает тот интерфейс, на который первым начали генерировать трафик. Т.е., повторюсь, какой интерфейс первым занял пропускную способность канала, тот и держит её.

Lorence ()
Ответ на: комментарий от zolden

Схема сети тут не причем, пример и задача чисто синтетические. Всё это делалось для определения максимальной пропускной способности железа в некоторых условиях и выявления огрехов в распределении нагрузки.

Мне надо просто настроить систему так, чтобы планировщик равномерно распределял пропускную способность по всем интерфейсам. Я уже не знаю как еще можно обьяснить.

Lorence ()
Ответ на: комментарий от Lorence

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

Попробуйте зажать максимальную входную полосу интерфейса через tc ingress policer, может полегчает.

mky ★★★★★ ()
Ответ на: комментарий от mky

Это SoC, там сетевых карт нет, всё встроено... только PHY на шину посажен и всё. Потому думаю вряд ли тут дело в приоритете прерываний, но поиграться с ingress policer, всё же, попробую. Спасибо.

Lorence ()
Ответ на: комментарий от iliyap

Не помогло. Прерывания распределены ровно, но баланса по трафику по прежнему нету.

Lorence ()
Ответ на: комментарий от Lorence

Мне не очень понятна схема прохождения пакетов.
Как я понимаю, у вас весь трафик - транзитный, то есть генерируется где-то ниже.
Почему вопрос вообще к интерфейсам, а не к отправителям?

zolden ★★★★★ ()
Ответ на: комментарий от zolden

Трафик генерируется на тестовом стенде Ixia. К нему вопросов быть не может, т.к. маршрутизаторы некоторых общеизвестных производителей на том же стенде, с аналогичными настройками, при тех же условиях, этот сценарий отрабатывают корректно. Т.е. показатели pps на любой паре тестируемых интерфейсов равны в пределах погрешности.

Потому вопрос о корректности формируемых пакетов, методики тестирования (за основу брался RFC2544) и схемы подключения можно считать исчерпанным и более не поднимать.
Проблема либо в ПО установленном на устройстве, либо в самом железе. Если ПО, то можно исправить, если железо, то печаль-беда.

Lorence ()
Ответ на: комментарий от Lorence

И я написал, что интерфейсы находятся в разных подсетях и трафик в них не пересекается.

Соответственно, ядро просто должно обоим потокам данных выдать одинаковый приоритет и отбалансировать пропускную способность

Я не специалист по сетям

Хотел было спросить, как видится механизм такой невероятной балансировки, и, вдруг...

один из производителей маршрутизаторов в своих прошивках на Linux смог такое реализовать,

Кто, и что именно сделал ?

AS ★★★★★ ()
Ответ на: комментарий от Lorence

Вот теперь представьте,что будет, если без настройки QoS появится в сети клиент, который займёт всю пропускную способность железа (все каналы гигабитные).

Или имеется ввиду балансировка мощности CPU для обработки трафика на всех интерфейсах ?

AS ★★★★★ ()
Ответ на: комментарий от AS

Например, приносили на тесты коммерческий образец маршрутизатора ZTE, он выдавал стабильные показатели PPS поровну разделенные на все интерфейсы: на ZTE задействовали 4 интерфейса, производительность получилась (цифра с потолка, точных данных не помню) в пределах 200k pps, на каждом интерфейсе высчитали приблизительно по 50k pps. И это без настройки QoS, только маршрутизация. То же самое для 2,3,5 интерфейсов. Само-собой, с увеличением количества задействованных интерфейсов и настроенных маршрутов общая производительность падала, но распределение pps на интерфейсы сохранялась.

Lorence ()
Ответ на: комментарий от Lorence

Да, такая формулировка корректнее будет) я же говорю, что не спец в этом.

Тогда в голову только вариант с обработкой прерываний приходит, как уже успели написать. В любом случае, копать больше некуда. А «распределены ровно» - там несколько ядер ? А по скольку очередей у сетевых интерфейсов ? Там /proc/interrupts есть ?

Настройка QoS к этому отношения вообще никакого не имеет, это другой уровень балансировки совсем. Разве что отъедает мощность CPU дополнительно, и только.

AS ★★★★★ ()
Ответ на: комментарий от AS

А «распределены ровно» - там несколько ядер ? А по скольку очередей у сетевых интерфейсов ? Там /proc/interrupts есть ?

Да, там 4 ядра. Как я понял по 1 очереди на интерфейс. Да, само-собой. Ядро Linux 4.1 с патчами для поддержки данного SoC и сопутствующего железа.

Lorence ()
Ответ на: комментарий от AS

Примерно так:

116:   0    0    0  550   OpenPIC   116 Level     Queue-manager portal 3
117:   0    0    0    0   OpenPIC   117 Level     Buffer-manager portal 3
118:   0    0  550    0   OpenPIC   118 Level     Queue-manager portal 2
119:   0    0    0    0   OpenPIC   119 Level     Buffer-manager portal 2
120:   0  556    0    0   OpenPIC   120 Level     Queue-manager portal 1
121:   0    0    0    0   OpenPIC   121 Level     Buffer-manager portal 1
122: 548    0    0    0   OpenPIC   122 Level     Queue-manager portal 0
123:   0    0    0    0   OpenPIC   123 Level     Buffer-manager portal 0


Количество прерываний, само-собой, растёт с течением времени.

Lorence ()
Ответ на: комментарий от Lorence

portal 0-3, как я понимаю, сетевые карты ? Так, а что-то ещё есть, что грузит ядра при прохождении трафика, и грузит какие ? И ради эксперимента, если все portal навесить на одно ядро, что будет ? Производительность должна просесть, но вот одинаковость не появится ли ?

AS ★★★★★ ()
Ответ на: комментарий от AS

portal 0-3, как я понимаю, сетевые карты ?

Почти. Там интегрировано всё в SoC. 5 или 6 гигабитных каналов раскиданы вот так вот на 4 портала.

Так, а что-то ещё есть, что грузит ядра при прохождении трафика, и грузит какие ?

Больше ничего не грузит именно при прохождении трафика. Статично всё.

И ради эксперимента, если все portal навесить на одно ядро, что будет ? Производительность должна просесть, но вот одинаковость не появится ли ?

Производительность просела в 3-3.5 раза примерно. Потоки так же дерьмово распределены по интерфейсам, даже хуже =)

Что-то мне подсказывает, что дело либо в железе, либо в кривости драйвера/еще_чего_нибудь_там в ядре Linux, которые разрабатывает этот вендор.

Lorence ()
Последнее исправление: Lorence (всего исправлений: 1)

Весь тред не читал.

Единственный способ шейпить трафик идущий в разные подсети через разные интерфейсы - это загнать его в промежуточный интерфейс типа ifb (средствами iproute2/tc на входе) или типа imq (средствами iptables на входе и/или выходе)

vel ★★★★★ ()
Ответ на: комментарий от vel

Весь тред не читал.

А надо. Для меня понятно стало к концу только, что ТС хочет.

Единственный способ шейпить трафик идущий

Ему не трафик шейпить надо, а распределить процессорное время поровну. Другими словами, нужно обеспечить равномерный PPS по интерфейсам.

AS ★★★★★ ()
Ответ на: комментарий от Lorence

Что-то мне подсказывает, что дело либо в железе, либо в кривости
драйвера/еще_чего_нибудь_там в ядре Linux, которые разрабатывает этот вендор.

Может быть. А вендору написать ? Кстати, ещё можно попробовать перетасовать прерывания/ядра, чтобы понять, проблема к ядру привязана, или к интерфейсу. Для полноты картины. Ещё можно стенд аналогичный на PC сделать, чтобы исключить ядро, либо наоборот.

AS ★★★★★ ()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от AS

Ведору писать бесполезно. А всё остальное проверю в рабочий день, спасибо)

Lorence ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.