mirk Posted May 20, 2015 · Report post Всем привет Есть у нас связка из 2х Debian серверов. У каждого на борту по одному Xeon® CPU E31270 @ 3.40GHz На первом делаем шейпинг трафика средствами tc. Второй сервер организует NAT. Сервера сами по себе не особенно мощные но свою работу делают и пропускают до 3.6 Mbit/sec Немного подробностей о шейпинге. Для повышения производительности tc используем хеш таблицы и фильтры u32. т.е. Шейпинг происходит на основании src_ip пакета. Мир не стоит на месте и у нас появился новый более производительный сервер. И захотели мы совместить задачи двух серверов в одном. Но тут появилась проблема. После объединения шейпинга и ната выяснилось что скорость "режется" только в одну сторону. Это происходит потому что ограничение работает только на исходящем интерфейсе, а пока пакет до него доходит происходит NAT и src_ip в заголовке меняется. Соответственно наши фильтры в tc перестают работать и скорость не "режется". Вопрос к знатокам. Как можно победить проблему "одностороннего" ограничения скорости? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vop Posted May 20, 2015 (edited) · Report post Либо использовать виртуальный-интерфейс, либо маркировать трафик через iptables -j CLASSIFY Edited May 20, 2015 by vop Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
kayot Posted May 20, 2015 (edited) · Report post Причем вирутальный - только IMQ, с IFB фокус не пройдет. Вообще плохая это идея, совмещать шейпер и НАТ, ведущая к вечному геморою. Как вариант - шейпинг заменить на полисинг и полисить на том же интерфейсе что и исход. Edited May 20, 2015 by kayot Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NiTr0 Posted May 20, 2015 · Report post Причем вирутальный - только IMQ, с IFB фокус не пройдет. С чего бы это? Пройдет. Натится на выходе, в IFB заворачивается на входе. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
kayot Posted May 21, 2015 · Report post Не проходит. Заворачивается уже подмененный трафик. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
SABRE Posted May 21, 2015 (edited) · Report post kayot, нет, NiTr0 имеет ввиду заворачивать с внутреннего интерфеса - там нет ната. Трафик WAN->LAN для внутреннего интерфеса исходящий, а LAN->WAN редиректить на IFB на внутреннем интерфесе. Единственная ситуация, где нужен только IMQ, это когда нужно шейпить и трафик роутера. Edited May 21, 2015 by SABRE Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
kayot Posted May 21, 2015 · Report post SABRE Мда, это я еще прошлым тысячелетием живу, PPP-серверами где перехватывать трафик можно было только на внешнем интерфейсе, с НАТом :) Логично, ничто не мешает захватывать на локальном интерфейсе и делать что угодно. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NiTr0 Posted May 21, 2015 · Report post , PPP-серверами где перехватывать трафик можно было только на внешнем интерфейсе, с НАТом :) Элементарно на pppX перехватывается тоже, и заворачивается в ifb :) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
photon Posted May 21, 2015 · Report post Проще всего повесить шейпер с полисером на внутренний интерфейс, где нет NAT. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
yakov2000 Posted May 24, 2015 · Report post у меня работает нормально на ifb Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
911 Posted May 26, 2015 (edited) · Report post либо маркировать трафик через iptables -j CLASSIFY насколько большая нагрузка будет/ Edited May 26, 2015 by 911 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
photon Posted May 26, 2015 (edited) · Report post насколько большая нагрузка будет/ Намного, т.к. хэш-фильтров нет, и каждый пакет будет проходить по куче правил iptables. В общем, не маемся херней с псевдоустройствами, а берем sc (http://sourceforge.net/projects/sc-tool/), ставим limit_method = hybrid, вешаем на внутренний интерфейс, и никаких проблем с NAT. Edited May 26, 2015 by photon Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
911 Posted May 26, 2015 · Report post photon если бы еще сделали шейпер на несколько ип, цены бы вам не было! :) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
photon Posted May 26, 2015 (edited) · Report post если бы еще сделали шейпер на несколько ип, цены бы вам не было! :) Эта возможность доступна в платной версии. Edited May 26, 2015 by photon Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vop Posted May 26, 2015 (edited) · Report post Намного, т.к. хэш-фильтров нет, и каждый пакет будет проходить по куче правил iptables. Ну если влепить все адреса в корневую цепочку, и совершенно забыть о "процедурной" структуре iptables, то да, будет долго ходить по одномерной цепочке. :) Хотя возможность вставлять несколько групп адресов в один класс не так уж и важна, по видимому. :) Edited May 26, 2015 by vop Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
911 Posted May 26, 2015 · Report post если бы еще сделали шейпер на несколько ип, цены бы вам не было! :) Эта возможность доступна в платной версии. а что почем? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
mirk Posted May 27, 2015 (edited) · Report post да почем такой функционал ? Решил попробовать сделать так, как предлагает photon Проще всего повесить шейпер с полисером на внутренний интерфейс, где нет NAT. Только у меня есть небольшая проблема с полисингом я не могу нигде найти пример как можно сделать полисинг для нескольких ip одного договора. В случае с шейпингом всё просто было использовал htb, а это классовая дисциплина, соответственно все ip договора заворачивал в один класс. Но с полисингом не получается классифицировать пакеты. Конечно можно просто разделить скорость договора на число ip договора, но это крайний вариант. Если я не ошибаюсь photon является автором sc было бы интересно услышать мнение эксперта по вопросам tc сам скрипт генератор у меня есть и мне не хватает только дописать полисинг под несколько ip вот несколько команд которыми ограничиваю скорость на одном ip tc filter add dev eth2 parent 1:0 prio 30 handle 2: protocol ip u32 divisor 256 tc filter add dev eth2 parent ffff: prio 30 handle 2: protocol ip u32 divisor 256 tc filter add dev eth2 protocol ip parent 1:0 prio 30 u32 ht 800:: match ip dst 192.168.222.0/24 hashkey mask 0x000000ff at 16 link 2: tc filter add dev eth2 protocol ip parent ffff: prio 30 u32 ht 800:: match ip src 192.168.222.0/24 hashkey mask 0x000000ff at 12 link 2: tc filter add dev eth2 parent 1: protocol ip prio 30 u32 ht 2:c7 match ip dst 192.168.222.199 flowid 1:a03 tc filter add dev eth2 parent ffff: protocol ip prio 30 u32 ht 2:c7 match ip src 192.168.222.199 police rate 4096000 burst 409600b drop flowid ffff: tc class add dev eth2 parent 1:1 classid 1:a03 htb rate 4096000 Edited May 27, 2015 by mirk Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
photon Posted May 27, 2015 (edited) · Report post да почем такой функционал ? Ответил в ПМ. Только у меня есть небольшая проблема с полисингом я не могу нигде найти пример как можно сделать полисинг для нескольких ip одного договора. В случае с шейпингом всё просто было использовал htb, а это классовая дисциплина, соответственно все ip договора заворачивал в один класс. Но с полисингом не получается классифицировать пакеты. Конечно можно просто разделить скорость договора на число ip договора, но это крайний вариант. Насколько я знаю, одним фильтром можно полисить подсеть адресов (если используются хэш-фильтры, маска должна быть больше /24), но не список IP из произвольных подсетей. Однако, если tc уже поддерживает логические операторы из серии "match ip src 192.168.1.1 or ip src 172.16.1.1", тогда можно и списком. Надо проверить. Я бы раздал всем юзерам на upload по скорости договора, а на download будет шейпинг и деление общей полосы. Это же upload, его все равно будет мало. Edited May 28, 2015 by photon Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
photon Posted May 28, 2015 · Report post По идее, лучше не совмещать функции BRAS и управления трафиком на одном устройстве. Тогда не будет необходимости во всяких костылях, вроде полисинга и псевдоустройтв. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
lacost Posted June 3, 2015 · Report post По идее, лучше не совмещать функции BRAS и управления трафиком на одном устройстве. Тогда не будет необходимости во всяких костылях, вроде полисинга и псевдоустройтв. По отдельности все работает как часы. Сейчас в качестве эксперимента хотим на более производительной железке (с 10Г картами) попробовать реализовать то же что сейчас реализовано по отдельности. В принципе комбинируя полисинг и шейпинг удалось уложить все в одну корзину.... Но, при попытке нагрузить реальным трафиком - появился перекос по загрузке ядер. По одному ядру на каждом процессоре грузится в полку. Пока не знаем как решать. Вот тут в параллельной ветке (http://forum.nag.ru/forum/index.php?showtopic=104964) аналогичная картина. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
photon Posted June 3, 2015 · Report post В принципе комбинируя полисинг и шейпинг удалось уложить все в одну корзину.... Но, при попытке нагрузить реальным трафиком - появился перекос по загрузке ядер. По одному ядру на каждом процессоре грузится в полку. Пока не знаем как решать. Вот тут в параллельной ветке (http://forum.nag.ru/forum/index.php?showtopic=104964) аналогичная картина. Полисинг тоже на хэш-фильтрах сделан или нет? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
hsvt Posted June 4, 2015 · Report post Господа, а желательно ли использовать сейчас Jumbo Frame между сервером с NAT и коммутатором? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted June 4, 2015 · Report post Господа, а желательно ли использовать сейчас Jumbo Frame между сервером с NAT и коммутатором? в этом нет никакого смысла в типовых задачах Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
mirk Posted June 4, 2015 · Report post Вот тут http://forum.nag.ru/...howtopic=104964 для ровного распределения нагрузки рекомендуют сделать вот так echo ffffff >/sys/class/net/eth0/queues/rx-0/rps_cpusecho ffffff >/sys/class/net/eth0/queues/rx-1/rps_cpusecho ffffff >/sys/class/net/eth0/queues/rx-2/rps_cpusecho ffffff >/sys/class/net/eth0/queues/rx-3/rps_cpusecho ffffff >/sys/class/net/eth0/queues/rx-4/rps_cpusecho ffffff >/sys/class/net/eth0/queues/rx-5/rps_cpusecho ffffff >/sys/class/net/eth0/queues/rx-6/rps_cpusecho ffffff >/sys/class/net/eth0/queues/rx-7/rps_cpus в принципе нагрузка по ядрам выравнивается, но вместо того чтобы снять лишнее с перегруженных ядер нагрузка вырастает на остальных до придела перегруженных. В итоге от этого баланса толку нет. И может кто нибудь скажет в двух словах, что именно делают эти магические команды Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Ivan_83 Posted June 4, 2015 · Report post Похоже что ffffff - битовая маска указывающая на каких ядрах проца выполнять конкретную очередь. Нагрузка то выравнивается но и растёт, за счёт того что потоки как горные козлы скачут по ядрам а процу за ними приходится кеш тягать, это его напрягает. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
