форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение		[Проследить за развитием треда]

"Выбор traffic shaper'а для Linux."

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

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

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

	12. "Выбор traffic shaper'а для Linux."
	Сообщение от cMex (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]