mirk Опубликовано 20 мая, 2015 Всем привет Есть у нас связка из 2х Debian серверов. У каждого на борту по одному Xeon® CPU E31270 @ 3.40GHz На первом делаем шейпинг трафика средствами tc. Второй сервер организует NAT. Сервера сами по себе не особенно мощные но свою работу делают и пропускают до 3.6 Mbit/sec Немного подробностей о шейпинге. Для повышения производительности tc используем хеш таблицы и фильтры u32. т.е. Шейпинг происходит на основании src_ip пакета. Мир не стоит на месте и у нас появился новый более производительный сервер. И захотели мы совместить задачи двух серверов в одном. Но тут появилась проблема. После объединения шейпинга и ната выяснилось что скорость "режется" только в одну сторону. Это происходит потому что ограничение работает только на исходящем интерфейсе, а пока пакет до него доходит происходит NAT и src_ip в заголовке меняется. Соответственно наши фильтры в tc перестают работать и скорость не "режется". Вопрос к знатокам. Как можно победить проблему "одностороннего" ограничения скорости? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vop Опубликовано 20 мая, 2015 (изменено) Либо использовать виртуальный-интерфейс, либо маркировать трафик через iptables -j CLASSIFY Изменено 20 мая, 2015 пользователем vop Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 20 мая, 2015 (изменено) Причем вирутальный - только IMQ, с IFB фокус не пройдет. Вообще плохая это идея, совмещать шейпер и НАТ, ведущая к вечному геморою. Как вариант - шейпинг заменить на полисинг и полисить на том же интерфейсе что и исход. Изменено 20 мая, 2015 пользователем kayot Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 20 мая, 2015 Причем вирутальный - только IMQ, с IFB фокус не пройдет. С чего бы это? Пройдет. Натится на выходе, в IFB заворачивается на входе. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 21 мая, 2015 Не проходит. Заворачивается уже подмененный трафик. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SABRE Опубликовано 21 мая, 2015 (изменено) kayot, нет, NiTr0 имеет ввиду заворачивать с внутреннего интерфеса - там нет ната. Трафик WAN->LAN для внутреннего интерфеса исходящий, а LAN->WAN редиректить на IFB на внутреннем интерфесе. Единственная ситуация, где нужен только IMQ, это когда нужно шейпить и трафик роутера. Изменено 21 мая, 2015 пользователем SABRE Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 21 мая, 2015 SABRE Мда, это я еще прошлым тысячелетием живу, PPP-серверами где перехватывать трафик можно было только на внешнем интерфейсе, с НАТом :) Логично, ничто не мешает захватывать на локальном интерфейсе и делать что угодно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 21 мая, 2015 , PPP-серверами где перехватывать трафик можно было только на внешнем интерфейсе, с НАТом :) Элементарно на pppX перехватывается тоже, и заворачивается в ifb :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 21 мая, 2015 Проще всего повесить шейпер с полисером на внутренний интерфейс, где нет NAT. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
yakov2000 Опубликовано 24 мая, 2015 у меня работает нормально на ifb Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
911 Опубликовано 26 мая, 2015 (изменено) либо маркировать трафик через iptables -j CLASSIFY насколько большая нагрузка будет/ Изменено 26 мая, 2015 пользователем 911 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 26 мая, 2015 (изменено) насколько большая нагрузка будет/ Намного, т.к. хэш-фильтров нет, и каждый пакет будет проходить по куче правил iptables. В общем, не маемся херней с псевдоустройствами, а берем sc (http://sourceforge.net/projects/sc-tool/), ставим limit_method = hybrid, вешаем на внутренний интерфейс, и никаких проблем с NAT. Изменено 26 мая, 2015 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
911 Опубликовано 26 мая, 2015 photon если бы еще сделали шейпер на несколько ип, цены бы вам не было! :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 26 мая, 2015 (изменено) если бы еще сделали шейпер на несколько ип, цены бы вам не было! :) Эта возможность доступна в платной версии. Изменено 26 мая, 2015 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vop Опубликовано 26 мая, 2015 (изменено) Намного, т.к. хэш-фильтров нет, и каждый пакет будет проходить по куче правил iptables. Ну если влепить все адреса в корневую цепочку, и совершенно забыть о "процедурной" структуре iptables, то да, будет долго ходить по одномерной цепочке. :) Хотя возможность вставлять несколько групп адресов в один класс не так уж и важна, по видимому. :) Изменено 26 мая, 2015 пользователем vop Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
911 Опубликовано 26 мая, 2015 если бы еще сделали шейпер на несколько ип, цены бы вам не было! :) Эта возможность доступна в платной версии. а что почем? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mirk Опубликовано 27 мая, 2015 (изменено) да почем такой функционал ? Решил попробовать сделать так, как предлагает 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 Изменено 27 мая, 2015 пользователем mirk Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 27 мая, 2015 (изменено) да почем такой функционал ? Ответил в ПМ. Только у меня есть небольшая проблема с полисингом я не могу нигде найти пример как можно сделать полисинг для нескольких ip одного договора. В случае с шейпингом всё просто было использовал htb, а это классовая дисциплина, соответственно все ip договора заворачивал в один класс. Но с полисингом не получается классифицировать пакеты. Конечно можно просто разделить скорость договора на число ip договора, но это крайний вариант. Насколько я знаю, одним фильтром можно полисить подсеть адресов (если используются хэш-фильтры, маска должна быть больше /24), но не список IP из произвольных подсетей. Однако, если tc уже поддерживает логические операторы из серии "match ip src 192.168.1.1 or ip src 172.16.1.1", тогда можно и списком. Надо проверить. Я бы раздал всем юзерам на upload по скорости договора, а на download будет шейпинг и деление общей полосы. Это же upload, его все равно будет мало. Изменено 28 мая, 2015 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 28 мая, 2015 По идее, лучше не совмещать функции BRAS и управления трафиком на одном устройстве. Тогда не будет необходимости во всяких костылях, вроде полисинга и псевдоустройтв. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lacost Опубликовано 3 июня, 2015 По идее, лучше не совмещать функции BRAS и управления трафиком на одном устройстве. Тогда не будет необходимости во всяких костылях, вроде полисинга и псевдоустройтв. По отдельности все работает как часы. Сейчас в качестве эксперимента хотим на более производительной железке (с 10Г картами) попробовать реализовать то же что сейчас реализовано по отдельности. В принципе комбинируя полисинг и шейпинг удалось уложить все в одну корзину.... Но, при попытке нагрузить реальным трафиком - появился перекос по загрузке ядер. По одному ядру на каждом процессоре грузится в полку. Пока не знаем как решать. Вот тут в параллельной ветке (http://forum.nag.ru/forum/index.php?showtopic=104964) аналогичная картина. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 3 июня, 2015 В принципе комбинируя полисинг и шейпинг удалось уложить все в одну корзину.... Но, при попытке нагрузить реальным трафиком - появился перекос по загрузке ядер. По одному ядру на каждом процессоре грузится в полку. Пока не знаем как решать. Вот тут в параллельной ветке (http://forum.nag.ru/forum/index.php?showtopic=104964) аналогичная картина. Полисинг тоже на хэш-фильтрах сделан или нет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hsvt Опубликовано 4 июня, 2015 Господа, а желательно ли использовать сейчас Jumbo Frame между сервером с NAT и коммутатором? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 4 июня, 2015 Господа, а желательно ли использовать сейчас Jumbo Frame между сервером с NAT и коммутатором? в этом нет никакого смысла в типовых задачах Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mirk Опубликовано 4 июня, 2015 Вот тут 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 в принципе нагрузка по ядрам выравнивается, но вместо того чтобы снять лишнее с перегруженных ядер нагрузка вырастает на остальных до придела перегруженных. В итоге от этого баланса толку нет. И может кто нибудь скажет в двух словах, что именно делают эти магические команды Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 4 июня, 2015 Похоже что ffffff - битовая маска указывающая на каких ядрах проца выполнять конкретную очередь. Нагрузка то выравнивается но и растёт, за счёт того что потоки как горные козлы скачут по ядрам а процу за ними приходится кеш тягать, это его напрягает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...