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 перестают работать и скорость не "режется". Вопрос к знатокам. Как можно победить проблему "одностороннего" ограничения скорости? Share this post Link to post Share on other sites
vop Posted May 20, 2015 (edited) · Report post Либо использовать виртуальный-интерфейс, либо маркировать трафик через iptables -j CLASSIFY Edited May 20, 2015 by vop Share this post Link to post Share on other sites
kayot Posted May 20, 2015 (edited) · Report post Причем вирутальный - только IMQ, с IFB фокус не пройдет. Вообще плохая это идея, совмещать шейпер и НАТ, ведущая к вечному геморою. Как вариант - шейпинг заменить на полисинг и полисить на том же интерфейсе что и исход. Edited May 20, 2015 by kayot Share this post Link to post Share on other sites
NiTr0 Posted May 20, 2015 · Report post Причем вирутальный - только IMQ, с IFB фокус не пройдет. С чего бы это? Пройдет. Натится на выходе, в IFB заворачивается на входе. Share this post Link to post Share on other sites
kayot Posted May 21, 2015 · Report post Не проходит. Заворачивается уже подмененный трафик. Share this post Link to post Share on other sites
SABRE Posted May 21, 2015 (edited) · Report post kayot, нет, NiTr0 имеет ввиду заворачивать с внутреннего интерфеса - там нет ната. Трафик WAN->LAN для внутреннего интерфеса исходящий, а LAN->WAN редиректить на IFB на внутреннем интерфесе. Единственная ситуация, где нужен только IMQ, это когда нужно шейпить и трафик роутера. Edited May 21, 2015 by SABRE Share this post Link to post Share on other sites
kayot Posted May 21, 2015 · Report post SABRE Мда, это я еще прошлым тысячелетием живу, PPP-серверами где перехватывать трафик можно было только на внешнем интерфейсе, с НАТом :) Логично, ничто не мешает захватывать на локальном интерфейсе и делать что угодно. Share this post Link to post Share on other sites
NiTr0 Posted May 21, 2015 · Report post , PPP-серверами где перехватывать трафик можно было только на внешнем интерфейсе, с НАТом :) Элементарно на pppX перехватывается тоже, и заворачивается в ifb :) Share this post Link to post Share on other sites
photon Posted May 21, 2015 · Report post Проще всего повесить шейпер с полисером на внутренний интерфейс, где нет NAT. Share this post Link to post Share on other sites
yakov2000 Posted May 24, 2015 · Report post у меня работает нормально на ifb Share this post Link to post Share on other sites
911 Posted May 26, 2015 (edited) · Report post либо маркировать трафик через iptables -j CLASSIFY насколько большая нагрузка будет/ Edited May 26, 2015 by 911 Share this post Link to post Share on other sites
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 Share this post Link to post Share on other sites
911 Posted May 26, 2015 · Report post photon если бы еще сделали шейпер на несколько ип, цены бы вам не было! :) Share this post Link to post Share on other sites
photon Posted May 26, 2015 (edited) · Report post если бы еще сделали шейпер на несколько ип, цены бы вам не было! :) Эта возможность доступна в платной версии. Edited May 26, 2015 by photon Share this post Link to post Share on other sites
vop Posted May 26, 2015 (edited) · Report post Намного, т.к. хэш-фильтров нет, и каждый пакет будет проходить по куче правил iptables. Ну если влепить все адреса в корневую цепочку, и совершенно забыть о "процедурной" структуре iptables, то да, будет долго ходить по одномерной цепочке. :) Хотя возможность вставлять несколько групп адресов в один класс не так уж и важна, по видимому. :) Edited May 26, 2015 by vop Share this post Link to post Share on other sites
911 Posted May 26, 2015 · Report post если бы еще сделали шейпер на несколько ип, цены бы вам не было! :) Эта возможность доступна в платной версии. а что почем? Share this post Link to post Share on other sites
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 Share this post Link to post Share on other sites
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 Share this post Link to post Share on other sites
photon Posted May 28, 2015 · Report post По идее, лучше не совмещать функции BRAS и управления трафиком на одном устройстве. Тогда не будет необходимости во всяких костылях, вроде полисинга и псевдоустройтв. Share this post Link to post Share on other sites
lacost Posted June 3, 2015 · Report post По идее, лучше не совмещать функции BRAS и управления трафиком на одном устройстве. Тогда не будет необходимости во всяких костылях, вроде полисинга и псевдоустройтв. По отдельности все работает как часы. Сейчас в качестве эксперимента хотим на более производительной железке (с 10Г картами) попробовать реализовать то же что сейчас реализовано по отдельности. В принципе комбинируя полисинг и шейпинг удалось уложить все в одну корзину.... Но, при попытке нагрузить реальным трафиком - появился перекос по загрузке ядер. По одному ядру на каждом процессоре грузится в полку. Пока не знаем как решать. Вот тут в параллельной ветке (http://forum.nag.ru/forum/index.php?showtopic=104964) аналогичная картина. Share this post Link to post Share on other sites
photon Posted June 3, 2015 · Report post В принципе комбинируя полисинг и шейпинг удалось уложить все в одну корзину.... Но, при попытке нагрузить реальным трафиком - появился перекос по загрузке ядер. По одному ядру на каждом процессоре грузится в полку. Пока не знаем как решать. Вот тут в параллельной ветке (http://forum.nag.ru/forum/index.php?showtopic=104964) аналогичная картина. Полисинг тоже на хэш-фильтрах сделан или нет? Share this post Link to post Share on other sites
hsvt Posted June 4, 2015 · Report post Господа, а желательно ли использовать сейчас Jumbo Frame между сервером с NAT и коммутатором? Share this post Link to post Share on other sites
s.lobanov Posted June 4, 2015 · Report post Господа, а желательно ли использовать сейчас Jumbo Frame между сервером с NAT и коммутатором? в этом нет никакого смысла в типовых задачах Share this post Link to post Share on other sites
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 в принципе нагрузка по ядрам выравнивается, но вместо того чтобы снять лишнее с перегруженных ядер нагрузка вырастает на остальных до придела перегруженных. В итоге от этого баланса толку нет. И может кто нибудь скажет в двух словах, что именно делают эти магические команды Share this post Link to post Share on other sites
Ivan_83 Posted June 4, 2015 · Report post Похоже что ffffff - битовая маска указывающая на каких ядрах проца выполнять конкретную очередь. Нагрузка то выравнивается но и растёт, за счёт того что потоки как горные козлы скачут по ядрам а процу за ними приходится кеш тягать, это его напрягает. Share this post Link to post Share on other sites
