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...