Что значит rate limit

Cisco Router + «rate-limit» ( Лимитирование трафика групп пользователей с помощью «rate-limit». )

23 октября 2010 (обновлено 31 января 2015)

OS: Cisco IOS 12.4/15.1.

Полагаю, практически все сталкивались с ситуацией, когда один канал ограниченной пропускной способности необходимо делить между потребителями. Иногда это несколько серверов, иногда это группы пользователей, каждый из которых рад бы полностью утилизировать весь канал «торрентами» и просмотром фильмов «on-line».

В маршрутизаторах Cisco задать потолок пропускной способности для произвольно описываемого трафика достаточно легко с помощью команды «rate-limit». Есть ещё «traffic-shape», но, если я верно понял, это будет работать только применительно к входящему трафику и потребует больше ресурсов.

Предположим, мы хотим ограничить пользователей под-сети «192.168.1.0/24» и предоставить им возможность воспользоваться пропускной способностью в 512 килобит в секунду, а пользователей под-сети «192.168.2.0/24» лимитировать 768 килобитами в секунду.

Для начала, опишем с помощью «листов доступа» интересующий нас трафик:

Следует помнить о том, что в рамках каждой группы пользователей описанных одним «листом доступа» мы ограничиваем всех её пользователей, а не каждого по отдельности. То есть, всей группе «листа доступа» «2001» будет предоставлена пропускная в 512 килобит в секунду, а не каждому из её членов (как думают многие).

Описываем в свойствах интерфейса параметры лимитирования:

Не знаю, чем это обусловлено, но лимитирование заработало только после принудительного отключения поддержки технологии CEF (Cisco Express Forwarding) на интерфейсе.

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

[ уже посетило: 13672 / +2 ] [ интересно! / нет ]

Поблагодарить автора ( сделайте свой денежный вклад в хорошее настроение )

Источник

rate limit

Англо-русский словарь технических терминов . 2005 .

Смотреть что такое «rate limit» в других словарях:

rate limit — rate restriction, instruction to buy or sell securities only within a set range of prices; restrictions on price ranges … English contemporary dictionary

rate-cap — rate caps, rate capping, rate capped 1) VERB: usu passive In Britain, when a local council was rate capped, the government prevented it from increasing local taxes called rates, in order to force the council to reduce its spending or make it more … English dictionary

rate-capping — rateˈ capping noun The setting by central government of an upper limit on the rate that can be levied by a local authority • • • Main Entry: ↑rate … Useful english dictionary

rate cap — ˈrate cap f2 [rate cap] noun (in the US) a limit placed on the amount of interest banks, etc. may charge … Useful english dictionary

Limit (mathematics) — This is an overview of the idea of a limit in mathematics. For specific uses of a limit, see limit of a sequence and limit of a function. In mathematics, the concept of a limit is used to describe the value that a function or sequence approaches… … Wikipedia

Rate of convergence — In numerical analysis, the speed at which a convergent sequence approaches its limit is called the rate of convergence. Although strictly speaking, a limit does not give information about any finite first part of the sequence, this concept is of… … Wikipedia

limit — lim|it1 [ lımıt ] noun count *** 1. ) the largest or smallest amount or the highest or lowest level of something that is allowed: speed/spending limits limit on: There are strict limits on presidential power. limit to: There has to be a fair… … Usage of the words and phrases in modern English

limit */*/*/ — I UK [ˈlɪmɪt] / US verb [transitive] Word forms limit : present tense I/you/we/they limit he/she/it limits present participle limiting past tense limited past participle limited 1) to prevent a number, amount, or effect from increasing past a… … English dictionary

limit — limitable, adj. limitableness, n. /lim it/, n. 1. the final, utmost, or furthest boundary or point as to extent, amount, continuance, procedure, etc.: the limit of his experience; the limit of vision. 2. a boundary or bound, as of a country, area … Universalium

Rate function — In mathematics mdash; specifically, in large deviations theory mdash; a rate function is a function used to quantify the probabilities of rare events. It is required to have several nice properties which assist in the formulation of the large… … Wikipedia

rate — 1. n. & v. n. 1 a stated numerical proportion between two sets of things (the second usu. expressed as unity), esp. as a measure of amount or degree (moving at a rate of 50 miles per hour) or as the basis of calculating an amount or value (rate… … Useful english dictionary

Источник

Celery throttling — настраивам rate limit для очередей

​ В этой статье я покажу как решить одну из проблем, возникающих при использовании распределенных очередей задач — регулирование пропускной способности очереди, или же, более простым языком, настройка ее rate limit’a. В качестве примера я возьму python и свою любимую связку Celery+RabbitMQ, хотя алгоритм, который я использую, никак не зависит от этих инструментов и может быть реализован на любом другом стэке.

So what’s the problem?

​ Для начала пара слов о том, какую проблему я вообще пытаюсь решить. Дело в том, что 99.9% сервисов в интернете запрещают бесконтрольно закидывать их сотнями/тысячами запросов в секунду, угрожая дать в ответ какой-нибудь 403 или 500. Нет, ну правда, жалко им чтоле? Иногда таким сервисом может выступать даже своя собственная БД… Вобщем, доверять нынче нельзя никому, поэтому приходится себя как-то сдерживать.

​ Конечно, если вся работа ведется внутри 1го процесса, то никакой проблемы нет, но т.к мы работаем с Celery, то у нас может быть не только N процессов (далее воркеров), но и M машин, и задача все это дело синхронизировать уже не кажется столь тривиальной.

What’s in the box

​ Первое, на что натыкаешься, когда ищешь, как же настроить throttling в celery, это встроенный параметр rate_limit класса Task . Звучит как то, что надо, но, копнув чуть глубже, замечаем, что:

Нельзя задать rate limit на группу задач.
Это неудобно, т.к зачастую доступ к какому-то лимитированому ресурсу размазан между разными тасками.

Этот лимит работает только внутри воркера, то есть он локальный и у каждого воркера свой.

​ Конечно, можно еще раз поделить лимит, теперь взяв в расчет еще и количество воркеров. Но все это начнет работать дико неэффективно, если таски будут прилетать неравномерно, например в какую-то минуту мы получим 60 вызовов get_github_api1() и 0 вызовов get_github_api2() — будут выполнены только 30 вызовов первого типа, хотя могли бы быть все 60. К тому же каждый раз, как появится новая таска, которой нужен доступ к этому ресурсу, придется снова везде пересчитывать все лимиты. Вобщем фича конечно полезная, но только для самых простых вариантов.

Bringing decision

Token Bucket

​ Решением проблемы для меня стал Token Bucket — алгоритм, использующийся для контроля полосы пропускания канала в компьютерных и телекомуникационных сетях. Опишу его в 2ух словах: пакет данных, чтобы пройти проверку канала на лимит, должен иметь при себе токен, который он взял из хранилища; в то же время в хранилище токены поступают с некоторой частотой. То есть пропускная способоность канала ограничивается скоростью выпуска токенов, которую нам и надо регулировать.
​ В нашем же случае вместо пакета данных мы имеем таску, а хранилищем токенов будут выступать очереди RabbitMQ.

Wrting some code

Чтож, приступим к написанию кода. Создадим файл main.py и зададим базовые настройки:

Не забудьте развернуть Rabbit, я предпочитаю делать это 1ой строчкой докера:

Теперь запустим celery beat — это специальный воркер celery , запускаемый всегда в единственном экземпляре и отвечающий за запуск периодических задач.

После этого в консоли раз в секунду начнут появляться сообщения:

Отлично, мы наладили выпуск токенов для нашего ‘ведра’. Осталось только научить наших воркеров из него брать. Попробуем оптимизировать код, который мы написали ранее для запросов в github. Добавим эти строчки к main.py :

А теперь проверим, как это все работает. В дополнение к уже запущенному beat добавим 8 воркеров:

И создадим отдельный маленький скрипт для запуска этих задач, назовем его producer.py :

Запускаем — python producer.py , и смотрим в логи воркеров:

Несмотря на то, что у нас целых 8 рабочих процессов, таски выполняются примерно раз в секунду, отправляясь в конец очереди, если на момент их выполнения не оказалось токена. Также, я думаю, вы уже заметили, что на самом деле мы накладываем rate limit не совсем на очередь, а скорее на какую-то логически связанную группу задач, которые на самом деле могут находится как в разных очередях, так и в одной. Таким образом наш контроль становится даже более детальным и гранулированным.

Putting it all together

​ Конечно, количество таких групп задач не ограничено (разве что возможностями брокера). Соберем весь код в кучку, расширим и причешим его:

Таким образом суммарные вызовы задач группы google не превысят 100/мин, а группы github — 60/мин. Заметьте, что для того, чтобы настроить такой throttling, понадобилось меньше 50 строк. Как по мне, достаточно просто.

Moving further

​ Ну, вот все и работает как надо, причем без каких-либо сторонних примочек, средствами только самого брокера. Но зачем останавливаться на достигнутом ;)? Грамотно используя данный алгоритм, можно пойти дальше и создать намного более сложные и гибкие стратегии. Например, некоторые таски могут брать не 1, а несколько токенов (возможно даже из разных очередей, если обращение идет к нескольким сервисам), таким образом у нас появится понятие ‘веса’ задачи, или же расширить размер нашего ‘ведра’ токенов, позволив им накапливаться, тем самым компенсируя периоды простоя. Вобщем, пространство для маневра просто огромное и ограничено только вашим воображением и инженерными навыками) Всем спасибо, всем удачи!

Источник

Использование Rate Limiters, Meters и Scheduling в коммутаторах Extreme

Как правило, в повседневной жизни сетевые администраторы сталкиваются с необходимостью ограничить входящий или исходящий трафик на порту или VLAN коммутатора. Для этого используются технологии Rate Limiting и Meters. Кроме того, существует технология Scheduling, использующаяся для распределения различного рода трафика внутри одного канала. В представленной ниже статье описывается процесс настройки данных механизмов.

Общая схема компонентов QoS для коммутаторов серий BlackDiamond и Summit представлена на схеме ниже:

Данная схема показывает, где и в какой момент применяются механизмы QoS, и упрощает знакомство с компонентами QoS на коммутаторах Extreme. Основные компоненты QoS подробно описаны ниже.

Rate Limiting

Технология rate limiting используется для ограничения исходящего трафика из порта коммутатора.
Для настройки rate limiting используется команды:

configure ports rate-limit egress [no-limit | [Kbps | Mbps |
Gbps] ]

Параметр max-burst-size указывать нужно обязательно, так как по умолчанию, в зависимости от коммутатора, он равен 128 или 256 Мбайт. Соответственно, прогнав, например, 10 МБайт тафика, может показаться, что фильтр не работает.

Для просмотра настроек rate limiting на порту коммутатора, необходимо выполнить команду:

show ports information

Например, для настройки на порту 3:1 ограничение 3 Мбит/с на исходящий трафик, необходимо выполнить команду:

configure port 3:1 rate-limit egress 3 Mbps max-burst-size 5 Mb

Эта же команда используется и для storm control:

configure ports rate-limit flood [broadcast | multicast | unknown-destmac] [no-limit | ]

Команда ограничивает входящий в порт коммутатора broadcast, multicast или трафик с неизвестными MAC адресами.

Meters

Meters используются для ограничения входящего в порт коммутатора а так же и для исходящего из порта моделей BlackDiamond c-, xl-, xm-series а так же Summit X480, X650, и X670.
Кроме того, meters можно использовать и для ограничения трафика в VLAN.
Настройка производится следующим образом:

Создание ACL, использующего meter:

Привязка ACL к интерфейсу:

Пример настройки meter, ограничивающего полосу пропускания VLAN vl22 до 8 Mbit/s.

create meter POLICE
configure meter POLICE committed-rate 8 Mbps max-burst-size 16 Mb out-actions drop
X460-24x.2 # show policy detail

Policies at Policy Server:
Policy: POL
entry cl <
if match all <
destination-address 255.255.255.255/32 ;
>

then <
packet-count COUNT ;
meter POLICE ;
>

configure access-list POL vlan vl22 ingress

Для проверки работы meters используется команды:

show access-list meter ports

Кроме того, можно посмотреть текущую загрузку интерфейса в реальном времени:

При ограничении полосы пропускания на интерфейсах, находящихся в LAG (Link Aggregation Group), ограничения применяются не только на master порт, а на все порты, находящиеся в LAG.

Вне зависимости от количества портов в LAG группе (2, 3, 4,5, итд), а так же при любом срезе трафика, выбрав алгоритм балансировки можно добиться равномерного распределения трафика по каналам. Исходя из этого, на каждый порт LAG нужно накладывать ограничение, пропорциональное количеству интерфейсов в LAG.

Scheduling

ExtremeXOS поддерживает следующие механизмы scheduling:

Strict priority queuing;

Для выбора метода обработки QoS профайлов на коммутаторе, используется команда:

configure qosscheduler [strict-priority | weighted-round-robin]

Для настройки определенного QoS профайла как strict priority, необходимо выполнить команду:

configure qosprofile use-strict-priority

Пример настройки QoS профайлов:

create qosprofile qp5
configure dot1p type 4 qosprofile qp5
configure qosprofile qp1 weight 1
configure qosprofile qp5 weight 2

Источник