Linux под нагрузкой. Высокопроизводительный шейпер

[@xReaper]

Молодец, для меня эти шейперы всегда были краеугольным камнем. Как-то сильно запутано в линуксе, надо больше копать.
А может кто то подскажет решение для провайдера?
В общем имеем: клиенты adsl и sdsl, адсл приходит АТМ на сервер. Всё в принципе работает, все довольны. Проблема в том что вся настройка адсл / сдсл вручную. Все VPN настройка каждого интерфейса ppp, в общем всех плюшек руками. Порог входа высокий. Нужно решение с интерфейсом «для людей» Ну чтоб бы сказать там, да ваша АДСЛ не подключена, итд когда клиент звонит.

Cпасибо

[@dolgacheff]

Читал, курил, много думал =)

[@norguhtar]

Читать до просветления www.opennet.ru/docs/RUS/LARTC/

[@sandello]

Cisco ISG + RADIUS.
Мы делали решение, на котором RADIUS обслуживал 100 запросов/сек (авторизация, аккаунтинг).

[@erazer]

не у всех есть cisco asr

[@sandello]

То была контора, принимавшая на себя ADSL со всей области. И ISG там стояла не одна.

[@erazer]

Замечательно. Конторе очень повезло. Однако, мы здесь рассматриваем вариант несколько другой направленности.

[@erazer]

отлично. мы все ждем от вас подробнейшей статьи!

[@erazer]

Опять же — это типовое решение, в котором нет ничего нового. Боюсь, у вас поэтому опять случится когнитивный диссонанс :)

[@blaker]

А напишите, пожалуйста. Интересно. =)

[@rojer]

> Когда пакет от какого-то IP-адреса попадает на дерево фильтров [...] для сети по 24-й маске у нас будет в среднем 128 шагов для каждого пакета при поиске нужного для него класса.

больше похоже на список, чем на дерево. поиск в дереве — любом — всяко меньше O(n).

[@erazer]

А где ты здесь web gui увидел? Здесь все рукаим и писано.

[@erazer]

Я не нанимался заниматься обучением системного администратора — я предложил рабочий инструмент, избавляющий от необходимости изобретать велосипед. Делайте выводы.

[@dmitriko]

Спасибо за рабочее решение.
Однако PHP в качестве системного скрипта вызывает странные чувства )
Очень.

[@erazer]

А что отличает «системный скрипт» от «не системного»? Чем писать «системный скрипт» на shell лучше чем на perl или php?

[@dmitriko]

Для меня системный это тот который изменяет настройки ОС. Не системный, это например CGI.

Лучше на Python. Другим людям читать легче. Не нужно PHP устанавливать. И самое главное его знать.

Вы слышали чтобы разработчики любого дистрибутива исопользвали PHP в качестве скриптового языка?

[@erazer]

При чем здесь «разработчики любого дистрибутива»?
Я спрашиваю — чем конкретно PHP плох для написания подобных скриптов?
Насчет знать или не знать — это уж кому как нравится.

[@dmitriko]

Сис админ должен знать shell, perl, python. Нравится ему это или нет.

Но никто не будет требовать знания PHP при приеме на работу Unix парня.

Ваше решение использовано на работе, то есть должно отвечать фактическим
стандартам уставновленым в отрасли. А не кому как нравится.

[@erazer]

Это кто такое сказал? Это вы так решили?
А мне кажется, сисадмин должен знать хотя бы CCNA, а желательно дальше.
Питона как такового совсем недавно вообще не существовало.

Про отрасль — нигде не видел требования насчет питона в данной отрасли. Нравится вам это или нет. А при приеме на работу с вас могут требовать чего угодно.

[@dmitriko]

Лень спорить. Пойду лучше скрипт допишу. На Python ;) И буду уверен что мои клиенты, а это сис админы, смогут изменить в них что то легко.

[@dmitriko]

Я не хотел принизить достонства Вашего решения.

С точки зрения «используй то что знаешь хорошо» — все правильно.

Но если бы я, простой сис админ, пришел работать вместо Вас и увидел этот скрипт то ругался бы очень сильно. Расценил бы это как не уважение к своим коллегам.

Как написали ниже, испытал бы когнитивный диссонанс :)

[@erazer]

Я не знаю PHP хорошо. Более того — до текущего места работы я писал скрипты на perl. Здесь же пришлось еще и php освоить который я не переношу так же как и java.

В конечном итоге не имеет большого значения, на чем писать подобные вещи. Это всего лишь вспомогательный скрипт, выплевывающий на выходе готовый конфиг — написан он может быть на чем угодно.

Так что хоть бейте меня — я все же не понимаю причину диссонанса :)

[@CentALT]

на Linux портирован ipfw+dummynet в котором как вы все наверное знаете шейп делается на раз, два, три. Причем правила вполне себе читаемые.

Согласитесь куда уж проще организовать масс шейп

ipfw pipe 1 config bw 200Kbit/s mask dst-ip 0x000fffff
ipfw pipe 2 config bw 200Kbit/s mask src-ip 0x000fffff

ipfw add 11 pipe 1 ip from any to 172.16.0.0/12 out
ipfw add 12 pipe 2 ip from 172.16.0.0/12 to any in

ну либо использовать таблицы для различных тарифных планов.

[@norguhtar]

ipfw+dummynet не умеет разные дисциплины шейпинга. Опять же какой смысл использовать ipfw на linux? Нравится ipfw используйте FreeBSD.

[@Dyr]

>ipfw+dummynet не умеет разные дисциплины шейпинга

Да неужели. Давно читали man dummynet?

     The following parameters can be configured for a scheduler:

     type {fifo | wf2qp | rr | qfq}
             specifies the scheduling algorithm to use.
             cm fifo
                     is just a FIFO scheduler (which means that all packets
                     are stored in the same queue as they arrive to the sched-
                     uler).  FIFO has O(1) per-packet time complexity, with
                     very low constants (estimate 60-80ns on a 2Ghz desktop
                     machine) but gives no service guarantees.
             wf2qp   implements the WF2Q+ algorithm, which is a Weighted Fair
                     Queueing algorithm which permits flows to share bandwidth
                     according to their weights. Note that weights are not
                     priorities; even a flow with a minuscule weight will
                     never starve.  WF2Q+ has O(log N) per-packet processing
                     cost, where N is the number of flows, and is the default
                     algorithm used by previous versions dummynet's queues.
             rr      implements the Deficit Round Robin algorithm, which has
                     O(1) processing costs (roughly, 100-150ns per packet) and
                     permits bandwidth allocation according to weights, but
                     with poor service guarantees.
             qfq     implements the QFQ algorithm, which is a very fast vari-
                     ant of WF2Q+, with similar service guarantees and O(1)
                     processing costs (roughly, 200-250ns per packet).

>Опять же какой смысл использовать ipfw на linux?

Вам уже человек написал, вы плохо умеете читать? Сделайте подобную приведённой конфигурацию на iptables и tc, расскажете, сколько это займёт строк и настроек.

> Нравится ipfw используйте FreeBSD.

«Нравится quagga, используйте OpenBSD, нравится samba — используйте Windows»

[@norguhtar]

Да неужели. Давно читали man dummynet?

Давно. А теперь сделайте тоже самое для tc и посмотрите сколько там дисциплин доступно.

Вам уже человек написал, вы плохо умеете читать? Сделайте подобную приведённой конфигурацию на iptables и tc, расскажете, сколько это займёт строк и настроек.

На две строчки больше надо будет еще классы добавить.

Нравится quagga, используйте OpenBSD, нравится samba — используйте Windows

Я считаю, что надо использовать стандартные средства, а не натягивать ежа на глобус.

[@Dyr]

>Давно. А теперь сделайте тоже самое для tc и посмотрите сколько там дисциплин доступно.

Ну а теперь ещё скажите, что вы использовали/используете именно те, которые отсутствуют в dummynet. :)

>На две строчки больше надо будет еще классы добавить.
Пруфлинк/пример?

>Я считаю, что надо использовать стандартные средства, а не натягивать ежа на глобус.
Вы противник всего нового, что ли? ipfw работает нативно в линуксе, не под эмуляцией и т.п. хренью, чем вам это нестандартно? Намертво забитой привычкой пользоваться фронтендом iptables к файерволу ядра?

[@norguhtar]

Ну а теперь ещё скажите, что вы использовали/используете именно те, которые отсутствуют в dummynet. :)

htb я использую.

Пруфлинк/пример?

Читать до просветления lartc. Там все есть. Раз вы уж меня отправили в man я вас туда же направлю.

Вы противник всего нового, что ли? ipfw работает нативно в линуксе, не под эмуляцией и т.п. хренью, чем вам это нестандартно? Намертво забитой привычкой пользоваться фронтендом iptables к файерволу ядра?

Я не противник нового если оно новое, но вот ipfw точно не новое. В FreeBSD его активно заменяют pf и ipfw2 и причем вот на pf я еще соглашусь, но вот на ipfw и на ipfw2 точно нет. iptables является стандартным интерфейсом в linux не плодите сущностей. Вон в FreeBSD уже наплодили и зачем все это не понятно.

[@0Lexx0]

Абожымой! shaper.php — у меня одного это вызывает когнитивный диссонанс?
Кстате есть какие-нибудь цифры? Это конечно очень интересно — высокие нагрузки итд итп. А вот сколько именно кппс он может шейпить? Есть подобная статистика?

[@erazer]

ok. shaper.pl чем-то лучше? или shaper.sh может быть чем-то интереснее?
Может быть вы намекнете, чем shaper.sh лучше shaper.php? Или вы скрипты не пишете на сервере принципиально?

[@iDen]

пожалуйста, в начале статьи приведите ссылки на прошлые статьи

[@CentALT]

Есть кстати отличный проект sc sourceforge.net/projects/sc-tool/ работает на базе HTB, работает с БД, ночные увеличения скоростей, и пр. пр. пр.

[@EvilX]

Рассматривать будем шейпер под управлением Linux: эта ОС показала наилучшие результаты по производительности в условиях высоких нагрузок.

А какие же ещё ОСи рассматривались?

[@0Lexx0]

Кстати да. Что значит наилучшие результаты.

[@erazer]

Рассматривались OpenBSD — умерла моментально, и FreeBSD — не умерла, но нагрузку держала гораздо хуже — полный канал разогнать не удалось.

[@EvilX]

Это при каком трафике?
А какие сетевые платы? С какими параметрами собрано ядро?
Из практики, FreeBSD в качестве роутера и шейпера гораздо производительней Linux. Последний пример: PPPoE концентратор. 800+ пользователей онлайн. На каждое подключение 12 правил шейпинга. Нагрузка на CPU не превышает 30% при трафике около 1ГБит.

[@norguhtar]

Из практики после выхода 2.6.36 ядра это не так, теперь обработка потоков распределяется по ядрам как и в FreeBSD proof. Опять же в случае если у вас под FreeBSD, что-то отличное от сетевух Intel оно помирает ибо нормальных драйверов там все еще нет, конечно нет нормальных сетевух кроме Intel, но все же. Насчет PPPoE посмотрите новый AccelPPP для Linux. Опять же в linux на шейпинге надо использовать hash таблицы, это повышает производительность на треть.

[@EvilX]

Начнём и кончим тем, что кроме intel нет нормальных сетевух.
А во freebsd есть ng_car.

[@norguhtar]

Ну о чем тогда дальше разговаривать? Собственно не о чем. На Intel сетевухах что FreeBSD что Linux с ядром 2.6.36 покажут сравнимые результаты. Причем в linux еще и тюнинг сведется только к настройки параметров ядра, а не его пересборке.

[@EvilX]

Смешнее было бы так:
С:\>/usr/bin/php
Системе не удается найти указанный путь.

[@erazer]

Сами вы это самое.

[@Karroplan]

ну не скажите. нарисовать интерфейс для шейпера на php — это нормально, особой нагрузки не дает, то что раз в неделю кто-то попользуется этой страничкой, а таки удобнее чем каждый раз лазать в консоль.

но это не отменяет общей убогости самой статьи :) про htb все и так знают, плюсы/косяки его известны, а свою обвязку для него не писал разве что ленивый :)

[@erazer]

Какой такой интерфейс? Вы читали вообще о чем речь?
Нет никакого интерфейса. Все что делает этот скрипт — берет из базы список абонентов с параметрами скорости, и строит рабочий конфиг для tc. Запускается он по cron.
При чем здесь web gui, интерфейс и прочий бред?
Ваши комментарии более убоги.

[@Karroplan]

товарищ, а вы читаете что я пишу внимательно? сделаю упрощенку:

— смех-смехом, а позволить себе держать пхп на шейпере/роутере могут только недалекие линуксоеды
— нарисовать интерфейс для шейпера на php — это нормально

речь шла о наличии php на шейпере/роутере.

[@erazer]

Гражданин, я же и пытаюсь у вас выяснить — я чем по-вашему конкретно плохо держать PHP на шейпере/роутере? И на чем по-вашему труъ админы должны писать скрипты в таком случае?

[@Karroplan]

спрашиваю последний раз — вы дурак? я, именно я, написал, что «интерфейс для шейпера на php — это нормально». скрипт на php или страничка на php — всё это ИНТЕРФЕЙС. теперь ясно?

[@erazer]

Я фразу «позволить себе держать пхп на шейпере/роутере могут только недалекие линуксоеды» отнес почему-то к вам. очевидно, что вопрос по этому поводу должен был быть не в ваш адрес.

[@Karroplan]

вернемся к статье:
статья-то о чем? о конкретном маленьком скриптике, который генерит конфиг для htb? а почему названа «Linux под нагрзукой. Высокопроизводительный шейпер»? где тут нагрузка, высокая производительность, да и вообще какой-либо анализ? почему linux, а не juniper/cisco/netapp? почему htb, а не cbq? почему вообще-говоря шейпинг, а не полисинг? я вот точно могу сказать, что шейпинг со стороны оператора — полнейшее зло.

[@erazer]

1. о скриптике
2. так назвали
3. какой конкретно анализ вы хотите? один сервер успешно держит 5+ тыс абон-ов и 3+ гигбита интернета
4. потому что я решил написать про линукс, а не про джунипер. можно?
5. ибо я не собирался сравнивать cbq и htb изначально
6. потому что по задаче положен шейпинг. я про шейпинг и написал.
7. давайте не будем настолько далеко абстрагироваться? я не задаю политику оператора в отношении абон-ов.

[@Karroplan]

1) хорошо
2) название не соотвествует содержимому — убого
3) цифры, графики. что за сервер, почему именно «производительный» — засчет того что сервер толстый или магия над линуксом/шейпером? — ничего нет, значит убого
4) это к вопросу об анализе. но можно.
5) а htb хуже чем cbq, то есть вы предложили заведомо худшее решение, не исслодовав вопроса и только потому, что htb проще настраивать. убого
6) где постановка задачи? убого
7) будем, так как вы сами пишете, что шейпер обслуживает абонентов. шейпинг со стороны оператора — зло, как для абонентов, так и для самого оператора. попытка ухода от вопроса — убого.

итого: чем ваша статья отличается от маленького кусочка Linux Advanced Routing and Traffic Control how-to? налчием мега-скриптика от румынского(!) админа?

[@erazer]

Да, при этом ничего умного вы так и не смогли родить. Предоставить каких-то аргументов — тоже. Вывод — непопулярность ваших комментариев целиком справедлива и закономерна.

[@erazer]

Ну, может быть далекие линуксоиды расскажут здесь же — чем плох PHP на сервере? Или чем он хуже perl, shell, etc.? Или аргументов у далеких линуксоидов не найдется?

[@Dyr]

ППКС.

Товарищу уже с десяток хабровцев об этом же написали, но нет, «мыши кололись, плакали, но продолжали жрать кактус».

Спасибо ещё не на VisualBasic'е под Wine.

[@erazer]

А вы сможете дать определение «когнитивному диссонансу», не заглядывая в Википедию?

[@tzlom]

PHP рулез, все кто написал выше что мол «ты чё, пиши на питоне» — унылые питоны, смеяться будем над вами когда с вашей же подачки вся школоло пересядет на питон и будет ваять говнецо уже на нём
P.S. не холивар языков, в конце концов на питоне написан портаж, но унылые быдлокодеры питона уже бесят

[@EvilX]

Вообще для такой задачи достаточно cshell. Роутер не должен лазить в БД биллинга. Данные должны поставлять с сервера биллинга в текстовом виде.