[nuclearcat]

Сижу пишу кратко "теорию" работы динамического распределенного шейпера и готовлю алгоритм для программы.

 

Суть в том, что обычный шейпер далеко не всегда справляется с задачами, т.к. например не всегда шейпинг происходит в одной точке, да и может быть много "зависимостей".

 

Если вкратце, допустим есть три клиента.

У клиента существуют три параметра: железный минимум, гарантированно выделяемая полоса, максимальный бурст.

Общая полоса 30Мбит

1)Мин всегда доступная скорость 1бит (т.е. может подождать до активации полосы несколько секунд, если был выключен), "гарантированная" 5Мбит, максимальный бурст 10Мбит

2)... 1Мбит, ... 10Мбит, бурст 30Мбит

3)... 1Мбит, ... 15Мбит, бурст 20Мбит

 

К примеру бывают ситуации, когда клиент 3 выключен, а у 1 и 2 есть потребность в скорости.

 

Замечательно, когда есть одна железяка которая их отшейпит с древовидными классами в реалтайме (или близко к тому), но далеко не всегда это возможно. Бывает, что на канал стоит простенький полисер, и у клиентов тоже полисеры.

 

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

1)Полоса режется полисерами у клиентов и в "центре". Обычно это недорогие циски, а то и l3 свичи. Правда подозреваю что время исполнения команды будет достаточно большое, если полисеры не меняются через SNMP, не рассматривал в деталях.

 

2)Есть общая полоса провайдера, есть ограниченные полосы на POP-ы, но суммарно превышающие общую полосу провайдера и плавающие по потреблению в разной степени в течении дня, и есть клиентам суммарный бурст которых превышает полосу на POP (oversubscribed как всегда) и все вместе суммарно превышают полосу провайдера.

И это надо как-то контролировать, и сохранять баланс, а не надеяться на "авось", упираясь в потолок, и пытаться решить проблему костылями типа уменьшения приоритетов сервисов (режем торренты).

 

В таком случае нужно или ставить древовидный шейпер у провайдера (но не решает проблему upload от клиентов, будут траблы если на BRAS или вскоре после них есть NAT), или все таки таким решением правильно отсыпать полосу клиентам "по потреблению".

 

Систему потом можно усложнять, и к примеру "классифицировать" приоритеты юзерам в зависимости от полученной суммы оплаты, кол-ва потребления трафика в ЧНН (если жрет полосу только в ЧНН, постепенно снижаем им в ЧНН приоритет для бурста, а то и гарантированно выделяемую полосу, но это так, планы если вообще все пойдет.

 

Прошу высказать соображения и вообще интересно ли это кому-то, или даже для поговорить :)

[Deac]

Даже для поговорить. :)

Надо бы картиночку. Из того же Visio.

[nuclearcat]

Visio сложно, у меня винда только на компе в лабе, а он для работы с windows-only "железом", лишнее вешать неохота.

Вот более детальный пример:

 

Канал 100 Мбит

из центра три выделенных канала на точки присутствия, каждый по 50 Мбит(скажем релейки), причем на POP1 скажем преимущественно корпораты(полосу юзают днем), POP3 хомяки(вечер ночь), а в третьем поровну (день, вечер, ночь).

 

И суммарно 1000 юзеров по мегабиту.

 

Технически просто режем юзерам по потреблению, днем скорее всего на POP2 будет "недобор", и этот недобор лучше дать POP1. Ну и опять же, внутри самого POP1 кто-то из хомяков в idle, и их полосу лучше отдать корпоратам, которые "нуждаются".

 

Брас шейпить умеет, на остальных точках традиционно в лучшем случае полисеры без приоритетов. Если работает такая система - хватит шейперов на BRAS, общую полосу (100Мбит) можно не шейпить вообще, шейпер будет следить, чтоб общий лимит не выходил за максимальный.

[Deac]

"Ночь. Улица. Фонарь. Аптека." ©

FreeBSD. DUMMYNET. PIPE. QUEUE(GRED). net.inet.ip.dummynet.io_fast

[nuclearcat]

Неужели? :-) Про HTB, HFSC, CBQ и прочее я тоже знаю. Но.

Вы предполагаете, что на входе(где собственно магистральный канал 100Мбит) можно шейпить, причем вы будете видеть IP-шники юзеров (т.е. сможете шейпить поюзерно).

 

А предположим что у нас на входе только стоечка с немножко "U" достаточных только для приема канала (L3 свитч) и дальше все расходится релейками (ODU на крыше) к BRAS-ам, где собственно и NAT-ы находяться.

 

Кроме того, даже если можно шейпить в центре, как вы сбалансируете upload?

На "авось" не подходит, ибо:

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

Шейпить "после" узкого места также бесполезно, ибо необязательно аплоадится будет траффик с congestion control, uTP яркий пример этому.

[mschedrin]

Другими словами это простой скрипт, который ходит и меняет значения шейперов/полисеров на циске? Или это настоящий шейпер на писюке с dpi?

[nuclearcat]

Кстати в моем случае остается та же засада, входящий траффик шейпится до узкого места, и в какой-то мере "авось" остается. С другой стороны можно слепить простейший PID контроллер, который будет закладывать разницу между реальным траффиком на вход, и установленными лимитами в шейперах и применять этот процент к шейперу. По результатам наблюдений на очень оверсабскрайбенном канале это может составлять до 25% разницы (чтоб не упираться в потолок).

 

Первый UDP флуд быстро остановит перфекционизм, но технически это решается, и если NAT-а скажем нет, можно заблекхолить атакуемый IP. Да и с NAT-ом при желании решаемо.

[Deac]

Поясню.

 

FreeBSD - ну потому что так. :)

 

DUMMYNET - ну потому что ALTQ не умеет шэйпить на вход.

 

PIPE - в трубе указываем общую полосу.

 

QUEUE - в очередях указываем вес каждого типа трафика.

 

GRED - указываем бережно относится к пакетам.

 

net.inet.ip.dummynet.io_fast - при "1", пускаем пакеты мимо очередей, если общий трафик меньше указанного в трубе; при "0" - всегда гоним в трубу.

 

Работает и на вход и на выход, делит оч. честно и раскидывает оч. плавно.

Веса могут меняться внешним скриптом.

 

Проверенно многолетней практикой.

[nuclearcat]

Другими словами это простой скрипт, который ходит и меняет значения шейперов/полисеров на циске? Или это настоящий шейпер на писюке с dpi?

 

В моем понимании это программа на C которая принимает (по UDP скорее всего, хотя это детали) "телеметрию" с сенсоров (текущее потребление на юзерах, каналаx) и принимает решение об отнимании-выделении полосы на конечных точках(юзерах) как можно ближе к реальному времени.

 

Поясню.

 

FreeBSD - ну потому что так. :)

 

DUMMYNET - ну потому что ALTQ не умеет шэйпить на вход.

 

PIPE - в трубе указываем общую полосу.

 

QUEUE - в очередях указываем вес каждого типа трафика.

 

GRED - указываем бережно относится к пакетам.

 

net.inet.ip.dummynet.io_fast - при "1", пускаем пакеты мимо очередей, если общий трафик меньше указанного в трубе; при "0" - всегда гоним в трубу.

 

Работает и на вход и на выход, делит оч. честно и раскидывает оч. плавно.

Веса могут меняться внешним скриптом.

 

Проверенно многолетней практикой.

Вы не читаете, что я пишу.

У вас нет возможности поставить шейпер на центральном узле или же нет возможности разделить канал "поюзерно" там же.

Что такое шейпер с древовидной структурой я прекрасно знаю. К слову в Линуксе он не менее замечательно делается, и более разнообразно.

[Deac]

У вас нет возможности поставить шейпер на центральном узле или же нет возможности разделить канал "поюзерно" там же.

В таком случае, кто и в каком месте будет принимать решения и чем оно будет управлять?

Нельзя шэйпить то, что через тебя не проходит.

Откуда и как будут браться данные об оверхеде?

[nuclearcat]

Конечно обратная связь, PID контроллер (на случай если юзер снижает нагрузку при уменьшении скорости и еще несколько случаев), снимать статистику с центрального узла обычно тоже можно, даже банальным SNMP (для подсчета расхождения с шейперами на юзерах), плюс (или взамен) на каждом юзере обычно есть статистика drop rate.

Т.е. достаточно легко узнать, если бы прошейпили юзеров на BRAS суммарно на мегабит, а прилетело полтора, но надо уменьшить цифры. Но я думаю если алгоритмически сделать подстройку, и учитывать что кто-то упирается в потолок, а кто-то недобирает полосу, и лимиты выставлять с "вилкой" - то цифры будут соответствовать требуемым. Главная засада как сделать не на глазок, а алгоритмически правильно.

 

Кстати опять же можно усовершенствовать схему. Скажем если мы режем юзера на положенный ему мегабит, он может засандалить торренты так, что на него все равно будет лететь скажем 1.3Мбита. Соответственно контроллер пересчитает лимит, и (упрощаю, надо изучать вопрос подробнее) зарежет его на 76.9%, т.е. 769Kbit, и с его превышением ему теоретически прилетит мегабит, это если превышение линейно процентное. Опять же даже если нет, систему можно сделать обучаемой, или применить в подсчете закладываемого "запаса" что-то типа Байеса. Тут моих текущих знаний пока не хватает, буду изучать.

[Deac]

Всё это оч. непросто и плюсы не очевидны.

[nuclearcat]

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

Но проблема с шейпингом "входа" "после узкого места" актуальна даже для шейпинга на магистрали. Магистраль обычно провайдеры подают без раскрашивания и приоритетов выставленных по вашему желанию и выбор невелик, или упираемся в потолок и имеем потери или задержки, или держим с запасом и теряем немалую часть полосы. В случае одного из моих клиентов это ~$10k в месяц.

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

Но задача непростая, действительно.

[jab]

Всё это оч. непросто и плюсы не очевидны.

 

Баловство, демон собирает статистику с устройств, делает развесовку полос по заранее заданному закону, и по результатам манипулирует шейперами/полисерами.

Можно даже обучающегося демона сделать. Но 100-мегабитные анлимиты убивают какую-то осмысленность этих действий.

[Deac]

собирает статистику с устройств

В каждом по своему, стандарта то нет.

 

делает развесовку полос по заранее заданному закону

Вот сам закон и является непростым делом.

 

манипулирует шейперами/полисерами

Опять же разношёрстными.

 

Можно даже обучающегося демона сделать.

Резать всё под ноль, вот и всё обучение.

 

Баловство

Вот тут согласен. :)

[vitalyb]

Поддерживаю jab, делал такую штуку. Грубо можно описать так - 1 роутер, 2 источника трафика - приоритетный и нет. На неприоритетном источнике HTB в сторону роутера, раз в минуту запускается скрипт, смотрит на SNMP counter'ы на роутере и меняет доступные полосы. При необходимости приоритетный источник съедает вообще всё, пинги по приоритетному направлению, когда задавлен неприоритетный, понятное дело, не страдают.

[adron2]

Помоему вполне реализуемая идея. Правда я бы писал не на Си а на Perl по причине более простого отлова багов. С центрального L3 свитча сливать NetFlow на хост который будет считать сколько реально льется на абонентов(на отдельный ip или подсеть) и уже на основании этих подсчетов дергать NAS-ы или полисеры на конечных свитчах.

Ну а с congestion control можно поспупить просто. Если скорость которую уже установили на полисере отличается от той что подсчитали по netflow(то есть перелив идет трафика) то просто берем и режем еще ниже скорость на конечном к абоненту свитче. Просто с небольшим шагом дискретизации. Возможно так же и обратная логика. При недоливе абоненту трафика и свободной полосе увеличивать скорость на полисере абонентского свитча.

 

Ну а логика самой программы управления полисерами на свитчах, NAS-ах по типу того же HTB. То есть древовидная структура.

 

Правда время перестройки такого дерева(применения изменений на удаленных свитчи) думаю будет не сильно быстрым. В районе 10 секунд(Обсчет реальных скоростей исходя из NetFlow, перестройка полисеров)

 

В общем как то так. Сесть написать а потом долго допиливать(отлаживать) до идеального алгоритма работы.

[Дятел]

Всё это напоминает шаманство порядка 10 лет назад. Оказалось, что все лечится увеличением апстримов.

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

[nuclearcat]

Дятел - ой ли? Если говорить о том, что дескать у вас в Европах расширили канал и настало счастье :-)

А плачи царевен о том, что вконтакте тормозит или ютуб медленно качается разве не тут раздаются? :-) И где эти расширения полос?

Т.к. тупо полисят, или даже не полисят, а все зависит от очереди в перегруженном интерфейсе. Иногда все упирается в новое волокно, иногда в дорогостоящий интерфейс или даже новый роутер.

 

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

А можно к примеру мониторить количество dupack на каждое направление/подсеть или критичные сервисы, хотя простыми шейперами на своей стороне уже не обойдешься.

 

Все это ИМХО будет актуально, просто в других масштабах и другом ракурсе.

Кроме того я потихоньку работаю в KSA, там хоть и деньги есть, но полосой никто не разбрасывается, и в пустыню особо оптику не потягаешь.

 

Помоему вполне реализуемая идея. Правда я бы писал не на Си а на Perl по причине более простого отлова багов. С центрального L3 свитча сливать NetFlow на хост который будет считать сколько реально льется на абонентов(на отдельный ip или подсеть) и уже на основании этих подсчетов дергать NAS-ы или полисеры на конечных свитчах.

Ну а с congestion control можно поспупить просто. Если скорость которую уже установили на полисере отличается от той что подсчитали по netflow(то есть перелив идет трафика) то просто берем и режем еще ниже скорость на конечном к абоненту свитче. Просто с небольшим шагом дискретизации. Возможно так же и обратная логика. При недоливе абоненту трафика и свободной полосе увеличивать скорость на полисере абонентского свитча.

 

Ну а логика самой программы управления полисерами на свитчах, NAS-ах по типу того же HTB. То есть древовидная структура.

 

Правда время перестройки такого дерева(применения изменений на удаленных свитчи) думаю будет не сильно быстрым. В районе 10 секунд(Обсчет реальных скоростей исходя из NetFlow, перестройка полисеров)

 

В общем как то так. Сесть написать а потом долго допиливать(отлаживать) до идеального алгоритма работы.

Netflow слишком инертен, он ведь скидывает состояние по flow, даже если его заставить делать это почаще. Хотя можно агрегировать наверное и оставить деталью только dst ip, и отсылать апдейты каждую секунду.

И конечно пойдет, если ничего другого нет.

[jab]

Хотя может я конечно отстал от времени?

 

Лет на пять причем.

[Yokodzun]

Жалобы на ю-туб и вконтакт не от узкой полосы домонетчика, а от политических игр их аплинков.

А от этих проблем хитрый шейпер не лечит.

Все эти забавы с выпиливанием вундервафель лобзиком, томленье духа и суета.

[Дятел]

Дятел - ой ли? Если говорить о том, что дескать у вас в Европах расширили канал и настало счастье :-)

А плачи царевен о том, что вконтакте тормозит или ютуб медленно качается разве не тут раздаются? :-) И где эти расширения полос?

А я не спорю, у нас страна большая, у части населения интернет может быть и хуже ливанского ))

У населения крупных городов и особенно во внутриМКАДье и ближайшем заМКАДе - всё запиписично, никто давно ничего не режет, все проблемы решаются расширением каналов.

В прямом эфире - вот такие объявления.

5 штук американских за гиг полосы - хорошая цена )))

[sirmax]

nuclearcat желает странного =) По-моему надо отрубить ему голову.

 

PS

У меня желание городить хитрые шейпера отбило именно взрывное уведичение полосы на юзера. На 5-10 мбитах уже никто ничего не замечает.

[adron2]

Дятел - ой ли? Если говорить о том, что дескать у вас в Европах расширили канал и настало счастье :-)

А плачи царевен о том, что вконтакте тормозит или ютуб медленно качается разве не тут раздаются? :-) И где эти расширения полос?

Т.к. тупо полисят, или даже не полисят, а все зависит от очереди в перегруженном интерфейсе. Иногда все упирается в новое волокно, иногда в дорогостоящий интерфейс или даже новый роутер.

 

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

А можно к примеру мониторить количество dupack на каждое направление/подсеть или критичные сервисы, хотя простыми шейперами на своей стороне уже не обойдешься.

 

Все это ИМХО будет актуально, просто в других масштабах и другом ракурсе.

Кроме того я потихоньку работаю в KSA, там хоть и деньги есть, но полосой никто не разбрасывается, и в пустыню особо оптику не потягаешь.

 

Помоему вполне реализуемая идея. Правда я бы писал не на Си а на Perl по причине более простого отлова багов. С центрального L3 свитча сливать NetFlow на хост который будет считать сколько реально льется на абонентов(на отдельный ip или подсеть) и уже на основании этих подсчетов дергать NAS-ы или полисеры на конечных свитчах.

Ну а с congestion control можно поспупить просто. Если скорость которую уже установили на полисере отличается от той что подсчитали по netflow(то есть перелив идет трафика) то просто берем и режем еще ниже скорость на конечном к абоненту свитче. Просто с небольшим шагом дискретизации. Возможно так же и обратная логика. При недоливе абоненту трафика и свободной полосе увеличивать скорость на полисере абонентского свитча.

 

Ну а логика самой программы управления полисерами на свитчах, NAS-ах по типу того же HTB. То есть древовидная структура.

 

Правда время перестройки такого дерева(применения изменений на удаленных свитчи) думаю будет не сильно быстрым. В районе 10 секунд(Обсчет реальных скоростей исходя из NetFlow, перестройка полисеров)

 

В общем как то так. Сесть написать а потом долго допиливать(отлаживать) до идеального алгоритма работы.

Netflow слишком инертен, он ведь скидывает состояние по flow, даже если его заставить делать это почаще. Хотя можно агрегировать наверное и оставить деталью только dst ip, и отсылать апдейты каждую секунду.

И конечно пойдет, если ничего другого нет.

 

Да. С NetFlow может и не получиться из за его инертности. То есть получается что узнать сколько реально льется на абонента трафика через uplink не выйдет. Разве что порт uplink-а миррорить на какой нибудь сервак но опять таки у вас нет места для установки этого сервака.

Можно еще попробовать по статистике дропов полисера на абонентских коммутаторах(если такая статистика там вообще есть) попытаться определить насколько абоненту переливается трафик. Если дропов слишком много то подрезать скорость еще больше(700 kbit вместо 1 mbit)

Изменено 10 ноября, 2011 пользователем adron2

[alex_001]

По трафику статистику можно собирать по sflow (некоторые access свитчи даже могут отдавать). (+) В меньшей инертности чем netflow (собственно как таковых там потоков нет , есть выборки из потока + счетчики с интерфейса , ну и выборки нормализуются по счетчикам с интерфейса). Соответственно получаем стабильно определенное количество flows/sec (max) , в отличие от netflow ..

 

Распределенный аналог HTB в принципе тоже наверное можно сделать , но только на pc routers , реализация на железках динамического шейпинга/полисинга - IMHO слишком сложна из за особенностей каждой конкретной железки..

 

И еще - чтото было на тему взаимодействия узлов для управления траффиком у авторов pspacer - но раньше они это в public не отдавали полностью , но в исходниках psp чтото лежало..