The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"Выбор traffic shaper'а для Linux."
Вариант для распечатки  
Пред. тема | След. тема 
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение [Проследить за развитием треда]

"Выбор traffic shaper'а для Linux."  
Сообщение от cMex email(ok) on 06-Фев-06, 11:10 
Приветствую всех!
Стоит следующая задача: есть несколько Linux-машин, которые используются для подключения клиентов по VPN, единовременно подключены до 300-350 человек, три четверти из которых - пользователи безлимитных тарифов с ограниченной скоростью. Нужно выбрать шейпер для Linux, который сможет адекватно обрабатывать такую систему. На данный момент используется shaperd, но, к сожалению при таком трафике (15-20 Мбит/с на каждой машине) и кол-ве подключений он начинает сильно перегружать машину, а у пользователей начинаются проблемы, связаные с увеличением времени отклика до удаленных узлов и потери пакетов до них.
Кто что сможет предложить?
Спасибо!
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

 Оглавление

Сообщения по теме [Сортировка по времени, UBB]


1. "Выбор traffic shaper'а для Linux."  
Сообщение от Den (??) on 06-Фев-06, 11:16 
если скоростя ~10 Мбит то тогда tc c дисциплиной red
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

2. "Выбор traffic shaper'а для Linux."  
Сообщение от cMex email(ok) on 06-Фев-06, 11:40 
>если скоростя ~10 Мбит то тогда tc c дисциплиной red
А примеры реализации есть? Вопрос: как будут уживаться на одном маршрутизаторе клиенты не лимитированные и резаные с помощью tc?
Как насчет CBQ? Что если трафик больше?

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

3. "Выбор traffic shaper'а для Linux."  
Сообщение от Den (??) on 07-Фев-06, 02:24 
>>если скоростя ~10 Мбит то тогда tc c дисциплиной red
>А примеры реализации есть? Вопрос: как будут уживаться на одном маршрутизаторе клиенты
>не лимитированные и резаные с помощью tc?
>Как насчет CBQ? Что если трафик больше?

вместо cbq лучше применять htb у него проблнм с таймингом меньше

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

4. "Выбор traffic shaper'а для Linux."  
Сообщение от cMex email(ok) on 09-Фев-06, 12:49 
>>>если скоростя ~10 Мбит то тогда tc c дисциплиной red
>>А примеры реализации есть? Вопрос: как будут уживаться на одном маршрутизаторе клиенты
>>не лимитированные и резаные с помощью tc?
>>Как насчет CBQ? Что если трафик больше?
>
>вместо cbq лучше применять htb у него проблнм с таймингом меньше


Подниму еще раз эту тему. Насколько я понимаю, дисциплина red является бесклассовой и немного не подходит на по критериям. Наиболее правильным выбором, если меня никто не опровергнет, мне кажется посоветованный Den'ом htb. Если ли у кого-нибудь практика внедрения такого шейпинга при кол-ве пользователей, которых нужно единовременно шейпить близко к 400, а траффик от них чуть больше 10-12 Мбит/с?
Какие методы используются для такого рода шейпинга интернет-провайдерами еще (как программные, так и аппаратные)?
Спасибо за овтеты!

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

5. "Выбор traffic shaper'а для Linux."  
Сообщение от vvvua email(ok) on 09-Фев-06, 16:36 
Наиболее правильным выбором, если
>меня никто не опровергнет, мне кажется посоветованный Den'ом htb. Если ли
>у кого-нибудь практика внедрения такого шейпинга при кол-ве пользователей, которых нужно
>единовременно шейпить близко к 400, а траффик от них чуть больше
>10-12 Мбит/с?
>Какие методы используются для такого рода шейпинга интернет-провайдерами еще (как программные, так
>и аппаратные)?

В случае HTB есть свои проблемы.
Я так понимаю, что 400 абсолютно разных клиентов сос своими правилами?

Нормально сделал такое только под FreeBSD. Использовал pipe в ipfw  и
приоритеты на очереди. Также можно использовать table в ipfw для обжимания траффика по направлениям.

С линухом пробовал СBQ, HTB. Есть для меня пока серьезное препятствие - грамотно обжать в линуксах гораздо сложнее, чем во фре.
Дело в том, что vpn интерфейсы динамические, и вставить правило HTB на несуществующий интерфейс невозможно. Т.е. надо добавлять правило при подъеме интерфейса. При этом сложно планировать иерархию... В принципе это решается хранением HTB конфига в базе данных вместе с инфой для авторизации. Надо не забывать, что CBQ и HTB умеет работать только с исходящим трафиком, поэтому вход от пользователя жмется через Жо.у !!!
Возникают также проблемы с NAT. Вот если жать на исходящем интерфейсе, как узнать от кого оно идет, если через NAT уже прошло? Есть модуль conntrack в iptables. С ним легче, но как мы с iptables в tc передадим правила обжима? - УРА. Есть маркировка в iptables, которую понимает tc.

Вроде всё решили, но подведя итог - в голову лезут одни маты.

P.S. Наблюдалось в ядре 2.4.20 c gr-security патчем раз в 1-2 мясяца затыкание траффика полностью HTB'ой. Приходилось перегружать правила HTB.
Они были сделаны с помощью описательной утилиты XML-htb. Не помню точно, как пишется. Конфиг был в XML и транслировался в скрипт с tc.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

6. "Выбор traffic shaper'а для Linux."  
Сообщение от cMex email(??) on 09-Фев-06, 16:54 
В принципе 400 клиентов одновременно, но все они работают скажем по 4-5 тарифам, то есть пять правил.
Почему проблемы с обжатием входящего от клиента? Один исходящий жмем на pppNN, исходящие в сторону пользователя жмем на WAN-интерфейсе.
Есть еще вариант - вразрез между pptpd серверами и граничным маршрутизатором поставить машину под управлением FreeBSD (NAT тогда организовать на пограничном маршрутизаторе, что снимет хотя бы одну проблему), тогда возникает следующий вопрос: какие характеристики может удовлетворить одна мощная машина под FreeBSD (трафик + одновременно зажимаемые пользователи)?
А в повседневной жизни провайдеры не самого большого уровня как справляются с зажимом по анлимным тарифом? каким софтом и железками, кто-нибудь из-за руля такой компании может сказать?
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

9. "Выбор traffic shaper'а для Linux."  
Сообщение от vvvua email(ok) on 10-Фев-06, 14:17 
>В принципе 400 клиентов одновременно, но все они работают скажем по 4-5
>тарифам, то есть пять правил.
Да, но нужно прописывать каждому индивидуально, даже одинаковые.
>Почему проблемы с обжатием входящего от клиента? Один исходящий жмем на pppNN,
>исходящие в сторону пользователя жмем на WAN-интерфейсе.
помоему, наоборот - исходящий от пользователя
>Есть еще вариант - вразрез между pptpd серверами и граничным маршрутизатором поставить
>машину под управлением FreeBSD (NAT тогда организовать на пограничном маршрутизаторе, что
>снимет хотя бы одну проблему), тогда возникает следующий вопрос: какие характеристики
>может удовлетворить одна мощная машина под FreeBSD (трафик + одновременно зажимаемые
>пользователи)?
>А в повседневной жизни провайдеры не самого большого уровня как справляются с
>зажимом по анлимным тарифом? каким софтом и железками, кто-нибудь из-за руля
>такой компании может сказать?
Пень3 500 уже много лет держит почтовик, ospf, bgp с одного прова и графики. Анлим клиенты до 256к каждый - штук 30. Плюс к этому около 1мбит/сек транзита. Сетевухи всякие - реалтек, винбонд - короче Г редкое.
Вот аптайм его: 0,24 0,44 0,54.
Но там сейчас exim стоит и 6.0  freebsd. exim с внешним mysql сервером.
Дохера берет проца система сбора трафика nacctd.

Вообще нужно ставить нормальные сетевухи с аппаратным чексумом пакетов - intel pro100 либо лучше, 3com 905b либо лучше, есть ряд SMC с боьшими микрухами (Etherpower 2 зовутся). Они ОЧЕНЬ помогают прохождению трафика и разгрузки сервака. Кстати, polling режим тоже дает прирост. К примеру на 4.7 freebsd замена 3-х realtek сетевух на intel дала 30%-е снижение загрузки на p3 700.

Промежуток - это лишняя часть, головная боль, если где-то допустить ошибку. Я видел провов с таким решением. У них есть отдельно шейпер, он-же локальный роутер и счетчик траффа (именно съем данных, а не учет - этим занимается вычислительный кластер из 3-х серваков под linux с Oracle на борту), а после него NAT машина. Количество обжимаемого трафика - до нескольких сотен мегабит на один тазик. Сеть имеет много ветвей. Что не на цисках - то обычно забекаплено с помощью vrrp.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

11. "Выбор traffic shaper'а для Linux."  
Сообщение от cMex email(??) on 10-Фев-06, 15:47 
Непонятки, ведь классов по сути придется создать не так много, а вот классификаторами (фильтрами) по IP, например, направлять такой-то адрес в такой-то класс?

>Пень3 500 уже много лет держит почтовик, ospf, bgp с одного прова
>и графики. Анлим клиенты до 256к каждый - штук 30. Плюс
>к этому около 1мбит/сек транзита. Сетевухи всякие - реалтек, винбонд -
>короче Г редкое.

Не, тут условия другие. 200-250 анлимщиков единовременно + около 10-12 Мбит/с трафика.

>Промежуток - это лишняя часть, головная боль, если где-то допустить ошибку. Я
>видел провов с таким решением. У них есть отдельно шейпер, он-же
>локальный роутер и счетчик траффа (именно съем данных, а не учет
>- этим занимается вычислительный кластер из 3-х серваков под linux с
>Oracle на борту), а после него NAT машина. Количество обжимаемого трафика
>- до нескольких сотен мегабит на один тазик. Сеть имеет много
>ветвей. Что не на цисках - то обычно забекаплено с помощью
>vrrp.

В принципе условия близки - шейпер стоит как раз на локальном роутере (за ним - граничный маршрутизатор), съем трафика в частности идет с них, обработка уже в другом месте.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

13. "Выбор traffic shaper'а для Linux."  
Сообщение от vvvua email(ok) on 14-Фев-06, 12:59 
>Непонятки, ведь классов по сути придется создать не так много, а вот
>классификаторами (фильтрами) по IP, например, направлять такой-то адрес в такой-то класс?
Тогда все, кто попадет в класс будут делить полосу между собой.
Для анлима с жесткой скоростью: сколько активных клиентов - столько и классов
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

14. "Выбор traffic shaper'а для Linux."  
Сообщение от cMex email(??) on 14-Фев-06, 13:23 
>>Непонятки, ведь классов по сути придется создать не так много, а вот
>>классификаторами (фильтрами) по IP, например, направлять такой-то адрес в такой-то класс?
>Тогда все, кто попадет в класс будут делить полосу между собой.
>Для анлима с жесткой скоростью: сколько активных клиентов - столько и классов
>

Опять не до конца понял. Смари (пример с www.linuximq.net),

- /sbin/tc class add dev imq1 parent 2: classid 2:1 htb rate 80000Kbit
- /sbin/tc class add dev imq1 parent 2: classid 2:2 htb rate 80000Kbit
- /sbin/tc class add dev imq1 parent 2:1 classid 2:10 htb rate 256kbit ceil 384kbit
- /sbin/tc class add dev imq1 parent 2:1 classid 2:20 htb rate 512kbit ceil 648kbit
- /sbin/tc filter add dev imq1 parent 2: protocol ip prio 1 u32 match ip dst ccc.ccc.ccc.ccc/dd match ip src aaa.aaa.aaa.aaa/bb flowid 2:10

Тут фильтром некто добавляется в потом 2:10, получается, что у этого некто скорость будет огнраничиваться 256 Кбит (в каком-то направлении, регулиуемом ус-вом), если фильтром добавить второго "некто" в это же flowid 2:10, то они поделят 256 пополам, да?
если да, то получается, что с подключением кадого пользователя мы должны создавать новую очередь (класс) с дисциплиной htb и неповторяющимся classid (2:nn в этом примере) + для нового подключения создаем фильтр. Так? пардон за кучу вопросов - новая для меня тема.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

7. "Выбор traffic shaper'а для Linux."  
Сообщение от nrvalex on 09-Фев-06, 20:33 
>С линухом пробовал СBQ, HTB. Есть для меня пока серьезное препятствие -
>грамотно обжать в линуксах гораздо сложнее, чем во фре.
>Дело в том, что vpn интерфейсы динамические, и вставить правило HTB на
>несуществующий интерфейс невозможно. Т.е. надо добавлять правило при подъеме интерфейса. При
>этом сложно планировать иерархию... В принципе это решается хранением HTB конфига
>в базе данных вместе с инфой для авторизации.

http://www.linuximq.net/
iptables -t mangle -A POSTROUTING -o ppp+ -j IMQ --todev 1
и shaper на интерфейс imq1

>Надо не забывать,
>что CBQ и HTB умеет работать только с исходящим трафиком, поэтому
>вход от пользователя жмется через Жо.у !!!

iptables -t mangle -A PREROUTING -i eth0 -j IMQ --todev 0

>Возникают также проблемы с NAT. Вот если жать на исходящем интерфейсе, как
>узнать от кого оно идет, если через NAT уже прошло? Есть
>модуль conntrack в iptables. С ним легче, но как мы с
>iptables в tc передадим правила обжима? - УРА. Есть маркировка в
>iptables, которую понимает tc.

http://www.linuximq.net/patchs/imq-nat.diff
и не надо  маркировки

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

8. "Выбор traffic shaper'а для Linux."  
Сообщение от cMex email(ok) on 10-Фев-06, 10:46 
>http://www.linuximq.net/
>iptables -t mangle -A POSTROUTING -o ppp+ -j IMQ --todev 1
>и shaper на интерфейс imq1

При каких условиях опробован этот подход?

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

10. "Выбор traffic shaper'а для Linux."  
Сообщение от vvvua email(ok) on 10-Фев-06, 14:49 
хммм... А вот это интересно.
Нужно будет попробовать.
спсб.
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

12. "Выбор traffic shaper'а для Linux."  
Сообщение от cMex email(ok) on 13-Фев-06, 21:31 
>http://www.linuximq.net/patchs/imq-nat.diff
>и не надо  маркировки

Уважаемый nrvalex, помучаю еще чуть-чуть :).
Выходит, что при наличии, предположим, четырых правил по ограничению мы создаем (четыре тарифа с разной скоростью, например) мы создаем четыре класса с дисциплиной HTB, а затем производит с помощью фильтра-классификатора u32 направление пользователя в зависимости от его данных по тарифу в определенный класс. Завешиваем при поднятии PPP-интерфейса динамически правила на вновь сформированные интерфейсы IMQ1/0 для кромсания обоих сторон потока трафика?

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2021 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру