Идеи по поводу шейпера

[shicoy]

Есть идея поставить между брасом (или ядром) и бордером, сервер в режиме моста, на котором шейпить и управлять доступом во внешнию сеть.

Заставить крутиться все это планирую под Linux.

 

Клиентские диапазоны подсетей (все сведения вымышленые):

Диапазон 1: 172.24.0.0/16 (тунельщики (pptp или pppoe) за NAT)

Диапазон 2: 91.114.0.0/19 (тунельщики с реальными IP)

Диапазон 3: 91.115.0.0/19 (клиенты со своими арендоваными реальными подсетями, т.е. маска от /30 до /25).

 

Классы обслуживания (в порядке убывания):

- Корпоратив VIP (крутые конторы, заводы и т.д.) 25% полосы гарантированно, 80% макс

- Корпоратив MIDDLE (все остальные) 20% полосы гарантированно, 80% макс

- Частный VIP (клиенты с предобплачиваемым трафиком) 25% полосы гарантированно, 80% макс

- Частный MIDDLE (клиенты на безлимах) 20% полосы гарантированно, 80% макс

- Частный LOW (клиенты на безлимах - безумные качальщики, с 1к открытых сессий и т.д.) 5% полосы гарантированно, 60% макс

 

Ориентировочная пропускная полоса: 500Мбит/сек

 

Если с ACL все достаточно просто и понятно: ipset + iptables, работает быстро и хорошо, то вот с шейпером не все так гладко.

 

Т.е. нужно создать 5 классов обслуживания? Это вроде бы классический случай и много раз описан в учебниках.

Но вот что делать и как отправлять в эти классы обслуживания клиентов с указаных диапазонов подсетей.

Задача усложнаяется тем, что любой из диапазонов IP, может быть включен в один из классов обслуживания.

 

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

Edited September 19, 2009 by shicoy

[disappointed]

Максимальную полосу для классов можно делать = внешнему каналу, зачем резать по 80% если всё равно это ceil и будет выдаваться только при простое полосы родительского класса.

И помимо rate, ещё нужно навернуть prio, так как весьма сильно влияет в реальной работе.

 

У вас получается нужно сделать 4 класса, безлимитчикам сделать ещё 2 подкласса внутри, normal и low priority. У нас я ещё разделил их на доп. подклассы внутри, main protocols и other (п2п как правило) их разрулил через prio чтобы при полке давился п2п трафик изначально и только потом основной(http итд).

 

На форуме есть примеры, ищите.

Edited September 19, 2009 by disappointed

[disappointed]

Ещё забыл, сам родительский класс подключённый к корневому на нём нужно оставить запас от полосы аплинка в 10%. Иначе вся система будет неэффективно работать.

[shicoy]

Пока сложность не в создании классов, а как красиво и без сильной потери производительности запихать трафик в эти классы.

 

для тунельщиков был бы хороший вариант с использованием ipset и tc flow, но он еще сырой в tc flow нет возможности указать из какого набора смотреть хэщи.

Edited September 19, 2009 by shicoy

[photon]

Я так понял, что per-user шейпинг не нужен, и много клиентов будет плавать в каком-то одном классе. Тогда для классификации надо использовать хэширующие фильтры u32, а в качестве краевой дисциплины что-то для равномерного распределения полосы (например, SFQ или WRR). Вот подходящий пример: http://lartc.org/howto/lartc.adv-filter.hashing.html

Edited September 19, 2009 by photon

[shicoy]

производительнее u32 вариантов нет?

[photon]

производительнее u32 вариантов нет?

Более производительных вариантов классификации, чем u32 с hashing filters нет. Под такую задачу желательно взять двухсокетную материнку с хорошими интегрированными сетевухами (Intel или Broadcom).

Edited September 20, 2009 by photon

[nuclearcat]

Каков смысл в двухсокетной? Все равно iptables сильно убивает SMP.

[photon]

Каков смысл в двухсокетной? Все равно iptables сильно убивает SMP.

Основную нагрузку будут создавать ksoftirqd, обрабатывающие нижние половины прерываний от сетевух. Вы еще скажите, что из-за iptables softirq перестают обрабатываться несколькими ядрами, и Linux превращается в тыкву 4.4BSD с кучей гигантских блокировок. К тому же, если не мудрить, то iptables на шейпирующем мосту должен использоваться по минимуму: два правила с -m set в цепочке FORWARD для пропускания трафика юзеров с положительным балансом. Более того, при наличии hashing filters можно вообще обойтись без iptables и ipset, блокируя должников с помощью filter actions:

tc filter change dev eth0 protocol all parent 1: prio 10 u32 ht $HT:$KEY: match ip src 172.16.0.1 police mtu 1 drop
tc filter change dev eth1 protocol all parent 1: prio 10 u32 ht $HT:$KEY: match ip dst 172.16.0.1 police mtu 1 drop

Edited September 21, 2009 by photon

[nuclearcat]

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

Вот пример, 2.6.31

9650.00 - 11.8% - 00000000f860813a : ipt_do_table [ip_tables]

7030.00 - 8.6% - 00000000c02b74ce : ip_route_input

4720.00 - 5.8% - 00000000c02fd06e : _spin_lock

4247.00 - 5.2% - 00000000f8301343 : e1000_clean_rx_irq [e1000]

3206.00 - 3.9% - 00000000f83028e9 : e1000_xmit_frame [e1000]

 

 

Есть еще такая штука cache coherency, и если вы пакет будете метать от процессора к процессору - обрабатываться он начнет на порядок медленнее.

И да, без multiqueue карт смысла в двухсокетных процах абсолютно нет.

Хороший Core i7 уделает большинство двухсокетных конфигураций более старых процессоров.

[photon]

Есть еще такая штука cache coherency, и если вы пакет будете метать от процессора к процессору - обрабатываться он начнет на порядок медленнее.

И да, без multiqueue карт смысла в двухсокетных процах абсолютно нет.

Хороший Core i7 уделает большинство двухсокетных конфигураций более старых процессоров.

Так я и думал про двухсокетные 1366 с поддержкой Core i7 или новых Xeon'ов. Что-то типа этой: http://www.supermicro.com/products/motherb...500/X8DAL-i.cfm Потому что диапазоны IP-адресов достаточно большие, есть куда расти. Но скорее всего выгоднее будет увеличивать число недорогих односокетных машин. Edited September 21, 2009 by photon