Jump to content

Recommended Posts

Posted

Здравствуйте,

 

Пишем свою биллинговую систему для Ubuntu под себя. Готовые модульные биллинговые системы не устаивают наличием ненужного функционала или отсутствием нужного (например, многие системы не поддерживают многоуровневый шейпинг) + непонятно как они работают и ЭТО ВООБЩЕ ПУГАЕТ: нет описания детальной логики работы шейпера, какой шейпер используется, непонятно какие правила добавляются в firewall и т.д. В нашей биллинговой системе в качестве шейпера планируется использовать HTB (он позволяет выстраивать целую иерархию классов и может шейпить их как будет сконфигурено). Например, по тарифам шейпить офисы, а внутри офиса неравномерно шейпить сотрудников (начальнику канал по-больше, всем остальным по-меньше).

 

Так вот, собственно вопрос, так как c помощью HTB мы можем организовать только безлимитные тарифы (HTB не умеет резать канал, после скачивания определенного объема трафика), какое средство в Linux можно использовать, чтобы работая совмесно с HTB оно позволяло ограничивать скорость после скачивания определенного объема трафика? Опционально (может будем вводить, а может и нет): после определенного числа скачанного - считать кол-во мегабитов (нужно для отдельной тарификации).

 

Также приветствуется вся инфа о шейперах для Linux, которые умеют это делать и позволяют так же как и HTB создавать иерархию.

 

--Михаил

Posted

Так если вы полноценный биллинг делаете, то пусть он и считает... а там уж выключить или ограничить полосу по событию не проблема.

Posted
Читайте LARTC до просветления, и будет вам счастье.

"Дисциплины обработки очередей для управления пропускной способностью" перечитывал несколько раз.

Про HTB вообще всё что можно прочитал и в русских источниках и английских.

 

Тут основной вопрос - это можно ли как нить с помощью каких нить дополнительных приблуд сделать лимитные тарифы на htb.

Если нет, то есть ли на Linux готовые решения для этого.

 

Posted
Пишем свою биллинговую систему для Ubuntu под себя. Готовые модульные биллинговые системы не устаивают наличием ненужного функционала или отсутствием нужного (например, многие системы не поддерживают многоуровневый шейпинг) + непонятно как они работают и ЭТО ВООБЩЕ ПУГАЕТ: нет описания детальной логики работы шейпера, какой шейпер используется, непонятно какие правила добавляются в firewall и т.д. В нашей биллинговой системе в качестве шейпера планируется использовать HTB (он позволяет выстраивать целую иерархию классов и может шейпить их как будет сконфигурено). Например, по тарифам шейпить офисы, а внутри офиса неравномерно шейпить сотрудников (начальнику канал по-больше, всем остальным по-меньше).
Сложные иерархии классов могут применяться, если у всех будут белые IP и когда нужно, чтобы юзеры имели воможность занимать неиспользуемую полосу. Если в офисах будет стоять маршрутизатор, за которым находятся серые IP, то нужно будет поднимать на нем отдельный шейпер, т.к. серые IP не будут видны на магистральном оборудовании.

 

Так вот, собственно вопрос, так как c помощью HTB мы можем организовать только безлимитные тарифы (HTB не умеет резать канал, после скачивания определенного объема трафика), какое средство в Linux можно использовать, чтобы работая совмесно с HTB оно позволяло ограничивать скорость после скачивания определенного объема трафика? Опционально (может будем вводить, а может и нет): после определенного числа скачанного - считать кол-во мегабитов (нужно для отдельной тарификации).
А почему HTB вообще должен это уметь? Это не дело для ядра. У tc есть встроенные счетчики отправленного трафика, которые можно увидеть, если выполнить команду tc -s -d class show dev eth0. Но я бы не стал полагаться только на них, т.к. они сбрасываются после удаления класса. По-нормальному должен быть поднят Netflow-коллектор, который скидывает данные в биллинг, а биллинг уже будет менять правила шейпинга в зависимости от объема скачанного трафика.
Posted
Так если вы полноценный биллинг делаете, то пусть он и считает... а там уж выключить или ограничить полосу по событию не проблема.

 

Не... Задача создания полноценного биллинга с нуля не стоит.

У меня сейчас есть несколько вариантов деревьев классов для HTB, которые работают и в котрых реализовано несколько тарифов (в каждом дереве - несколько тарифов).

Но все они безлимитные. HTB отлично работает, очень гибкую логику можно задать. Я понимаю, что для лимитных тарифов только на HTB это сделать нельзя. Поэтому и интересуюсь можно ли как нить сделать это с помощью дополнительных тулзов.

Posted
Не... Задача создания полноценного биллинга с нуля не стоит.

У меня сейчас есть несколько вариантов деревьев классов для HTB, которые работают и в котрых реализовано несколько тарифов (в каждом дереве - несколько тарифов).

Но все они безлимитные. HTB отлично работает, очень гибкую логику можно задать. Я понимаю, что для лимитных тарифов только на HTB это сделать нельзя. Поэтому и интересуюсь можно ли как нить сделать это с помощью дополнительных тулзов.

ну, если лимитный тариф в вашем случае не подразумевает шейпирования, то htb тут совсем не при чем...

Posted
Пишем свою биллинговую систему для Ubuntu под себя. Готовые модульные биллинговые системы не устаивают наличием ненужного функционала или отсутствием нужного (например, многие системы не поддерживают многоуровневый шейпинг) + непонятно как они работают и ЭТО ВООБЩЕ ПУГАЕТ: нет описания детальной логики работы шейпера, какой шейпер используется, непонятно какие правила добавляются в firewall и т.д. В нашей биллинговой системе в качестве шейпера планируется использовать HTB (он позволяет выстраивать целую иерархию классов и может шейпить их как будет сконфигурено). Например, по тарифам шейпить офисы, а внутри офиса неравномерно шейпить сотрудников (начальнику канал по-больше, всем остальным по-меньше).
Сложные иерархии классов могут применяться, если у всех будут белые IP и когда нужно, чтобы юзеры имели воможность занимать неиспользуемую полосу. Если в офисах будет стоять маршрутизатор, за которым находятся серые IP, то нужно будет поднимать на нем отдельный шейпер, т.к. серые IP не будут видны на магистральном оборудовании.

 

Так вот, собственно вопрос, так как c помощью HTB мы можем организовать только безлимитные тарифы (HTB не умеет резать канал, после скачивания определенного объема трафика), какое средство в Linux можно использовать, чтобы работая совмесно с HTB оно позволяло ограничивать скорость после скачивания определенного объема трафика? Опционально (может будем вводить, а может и нет): после определенного числа скачанного - считать кол-во мегабитов (нужно для отдельной тарификации).
А почему HTB вообще должен это уметь? Это не дело для ядра. У tc есть встроенные счетчики отправленного трафика, которые можно увидеть, если выполнить команду tc -s -d class show dev eth0. Но я бы не стал полагаться только на них, т.к. они сбрасываются после удаления класса. По-нормальному должен быть поднят Netflow-коллектор, который скидывает данные в биллинг, а биллинг уже будет менять правила шейпинга в зависимости от объема скачанного трафика.

 

Обрисую ситуацию более подробно.

Есть роутер (обычный комп) имеет два интерфейса, один смотрит на провайдера (провайдер дает 1 статический белый IP), другой интерфейс смотрит в локальную сеть, и через него каждому клиенту раздается серый IP адрес DHCP сервером. В DHCP есть привязка для каждого абонентского компа MAC+IP, то есть для каждого клиента, всегда один и тот же IP.

Я на роутере ставлю шейпер HTB, который работает c интерфейсом локальной сети и в каждом классе HTB указывается например серый IP адрес конечного клиента. Всё работает, трафик распределяется отлично.

И вот стоит задача - сделать как нить лимитные тарифы с распределением трафика. (Вот например, как я вижу - после определенного количества скаченного трафика, для какого-то i-го клиента, этот класc HTB переконфигурялся, там выставлялась другая скорость и происходило бы переопределение правил tc). Но вот КАК фиксировать, определять количество скачанного трафика я не представляю.

 

 

 

Posted (edited)
Обрисую ситуацию более подробно.

Есть роутер (обычный комп) имеет два интерфейса, один смотрит на провайдера (провайдер дает 1 статический белый IP), другой интерфейс смотрит в локальную сеть, и через него каждому клиенту раздается серый IP адрес DHCP сервером. В DHCP есть привязка для каждого абонентского компа MAC+IP, то есть для каждого клиента, всегда один и тот же IP.

Я на роутере ставлю шейпер HTB, который работает c интерфейсом локальной сети и в каждом классе HTB указывается например серый IP адрес конечного клиента. Всё работает, трафик распределяется отлично.

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

 

И вот стоит задача - сделать как нить лимитные тарифы с распределением трафика. (Вот например, как я вижу - после определенного количества скаченного трафика, для какого-то i-го клиента, этот класc HTB переконфигурялся, там выставлялась другая скорость и происходило бы переопределение правил tc). Но вот КАК фиксировать, определять количество скачанного трафика я не представляю.
Ну как я и говорил: поднимаем Netflow-коллектор, который скидывает инфу в биллинг, где вычисляется суммарный трафик по каждому клиенту. Далее, по достижении лимита трафика биллинг дает на шейпер команду tc class change ... и меняет там скорость. Либо шейпер сам периодически соединяется с базой биллинга и меняет у себя полосу. Edited by photon

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.