Delay pools squid windows

Ограничение скорости Интернет для разных категорий пользователей на прокси-сервере Squid (Delay pools)

В процессе использования прокси-сервера Squid при большом количестве пользователей и относительно небольшой пропускной способности каналов предоставленных интернет-провайдерами может возникнуть потребность ограничить пропускную способность доступа в интернет разным категориям пользователей. Один из основных механизмов позволяющих реализовать такие ограничения в Squid является механизм пулов задержки — Delay pools. Пулы задержки позволяют ограничить скорость получаемого прокси-сервером интернет-трафика в зависимости от разных условий, например в зависимости от того, какой пользователь запрашивает этот трафик. В конфигурации Squid по умолчанию механизм пулов задержки выключен, и поэтому при доступе к прокси-серверу между клиентами используется простая конкуренция по принципу “кто первый встал, того и тапки”.

Как примерно я понимаю работу Squid в конфигурации с включёнными пулами задержки:
— клиент запрашивает с прокси-сервера какой-либо http-объект;
— в случае если запрашиваемый объект есть в кэше Squid (статус TCP_HIT в access.log ), то прокси-сервер отдает этот объект клиенту на максимальной скорости
— в случае если запрашиваемого объекта нет в кэше (статусы TCP_MISS , TCP_TUNNEL и другие в access.log ), то прокси-сервер отдает этот объект клиенту с ограничениями настроенными в пулах задержки.

Далее мы рассмотрим простейший пример применения пулов задержки. В рассматриваемом примере будет использоваться три категории пользователей, для каждой из которых будет задано ограничение максимальной скорости интернет:
— Первая категория будет определять трудновоспитуемых пользователей, у которых большую часть интернет-трафика можно классифицировать как, мягко говоря, непрофильный. Эта категория будет иметь самую низкую скорость доступа в интернет;
— Вторая категория – это стандартные пользователи с ограничением скорости позволяющим выполнять более или менее комфортный интернет-серфинг;
— Третья категория – пользователи с повышенной границей пропускной способности в рабочее время и без ограничений в нерабочее время.

Для начала убедимся в том, что Squid собран с поддержкой Delay pools

Категоризацию пользователей мы будем выполнять на основе групп безопасности в домене Active Directory. Соответственно предварительно нам нужно создать эти группы доступа. К ранее описанной группе KOM-Internet-Standard , которая будет у нас определять рядовых пользователей, добавляем ещё две группы: KOM-Internet-Standard-Fast и KOM-Internet-Standard-Slow

Чтобы правила распределения пропускной способности для разных категорий пользователей работали правильно, необходимо чтобы членство в группах было взаимоисключающим, то есть если пользователь добавляется в одну группу (например KOM-Internet-Standard-Fast ), то его нужно исключить из других групп ( KOM-Internet-Standard и KOM-Internet-Standard-Slow ).
Не забываем включить эти группы в группу KOM-Internet-AllUsers , которая используется для объединения всех пользователей для компонент отчетности .

Создадим вспомогательные конфигурационные файлы (предполагается, что файл conf_param_groups_standard уже был создан нами ранее )

Открываем на редактирование файл конфигурации Squid

Определяемся c ACL:

Определяемся сколько пулов будем использовать, исходя из количества категорий, на которые будут поделены все пользователи. Например 3 пула – 1 (быстрый), 2 (стандартные ограничения), 3 (медленный).

Для каждого пула нужно назначить класс.

В текущей версии Squid есть 5 классов и их определения можно найти в squid.conf . Я истолковал для себя эти классы следующим образом:

Указываем отдельной строчкой классы для каждого из пулов по порядку в вид:
delay_class номер пула > класс >

Для каждого пула зададим параметры ограничения с помощью тэга delay_parameters . Состав этих параметров зависит от выбранного ранее класса для каждого из пулов. Информацию о том, какие параметры могут задаваться для пулов в зависимости от классов можно также найти в squid.conf

Вид записей delay_parameters в зависимости от класса пула должен иметь следующий вид:

Каждое из ограничений записывается в виде пары значений в формате restore / maximum , где restore — количество байт/сек. клиентских запросов которые могут поступать в пул, а maximum это максимально возможное количество байт/сек. которые способен обработать пул в одну единицу времени, то есть его возможная ёмкость. Если какое-либо из ограничений не требуется, то соответствующая пара значений заменяется ключевым словом “ none ”.

Рассчитаем параметры

Предположим, имеется заявленная интернет-провайдером скорость канала в 12 Mбит/с. Часть канала в качестве резерва оставляем под задачи отличные от Squid (1 Мбит/с). Поэтому далее отталкиваемся от условия что на Squid выделяется 11 Мбит/с. Распределяем гарантированную пропускную способность между пулами, например так:

Пул 1 — 3 Мбит/с — 3 000 000 Бит/с = 375 000 Байт/с.
Пул 2 — 8 Мбит/с — 8 000 000 Бит/с = 1 000 000 Байт/с
Пул 3 — не будет иметь гарантированной пропускной способности.

Для первого пула мы гарантируем скорость в 3 Mбит/с с простой конкуренцией между участниками пула. Каждый из участников этого пула может занять до 3 Mбит/с, если полоса пропускания не занята другими участниками пула.

Для второго пула мы гарантируем скорость в 7 Mбит/с. При этом, с учётом среднего количества одновременно работающих с прокси пользователей, например в 50, каждый из участников пула сможет использовать не более 200 Кбит/с.

Для третьего пула мы не будем ограничивать общую пропускную способность, но ограничим скорость доступа для одного участника пула до 50 Кбит/с

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

Другой вариант определения параметров пулов, при котором нет общих ограничений для отдельных пулов, но есть чёткие ограничения для каждого клиента в каждом из пулов:

Далее определяем доступ к пулам с использованием ранее заданных ACL. Тэг delay_access , по аналогии с тэгом http_access позволяет определить попадание пользователей в тот или иной пул, на основе ACL:

В нашем примере для первого пула используется дополнительный ACL WorkingTime , который означает то, что ограничение скорости действует лишь в указанный интервал времени суток (в остальное время ограничения не используются).

Проверка попадания в пул идет по порядку с пула 1, затем 2, … и т.д. до пула N. После первого же попадания в пул дальнейшие правила delay_access пропускаются. Если проверка всех правил не определяет запрос клиента ни к одному пулу, то запрос клиента идёт напрямую без каких-либо задержек.

Источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

Настраиваем ограничение скорости для пользователей в Squid

Тема ограничения скорости через прокси-сервер squid уже поднималась на страницах нашего блога, однако тогда мы рассмотрели вариант с ограничением для узлов сети и ее сегментов, не касаясь вопросов аутентификации пользователей. В тоже время перед администраторами крупных сетей встает вопрос об ограничении скорости именно пользователей и групп, в том числе на основе членства в группах Active Directory. Сегодня мы расскажем, как это можно сделать.

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

Как известно, первые три класса пулов работают с сетями, подсетями и конкретными узлами. Существуют распространенные заблуждения, что пулы работают с элементами ACL, а их содержимое не столь важно. Признаемся, мы сами одно время находились под их влиянием, но самый лучший способ развеять заблуждения — проверить все на собственном опыте.

Эмпирическим путем было выяснено, что если элемент ACL для пулов 1-3 классов не содержит описания сетей, подсетей или хостов, то его содержимое при работе delay pools будет проигнорировано. Таким образом для работы с пользователями следует применять только пулы 4 класса, которые кроме настроек для сетей и хостов содержат отдельную настройку для аутентифицированного пользователя.

И если описание пула 3-го класса выглядит так:

то в 4-ом классе к ним добавляются настройки пользователя

Поэтому в применяемом для пула 4-го класса элементе ACL обязательно должны присутствовать пользователи, в противном случае такой пул работать не будет.

Как применять данный класс пулов? Начнем с самой простой задачи: ограничим скорость всем пользователям, которые прошли проверку подлинности на прокси.

Прежде всего зададим элемент ACL для них:

Первой строкой мы указали количество пулов, затем перечислили их указав номер и класс, ниже разместили список доступа, разрешив работу с пулом только элементам ACL auth — т.е. всем аутентифицированным пользователям. И наконец задали ограничения скорости. Первые три опции мы выставили без ограничений, а в последней мы указали максимальную скорость для пользователя в 1,25 МБ/с = 10 Мбит/с.

При этом данный пул можно использовать и для ограничения скорости для узлов и подсетей. Для этого укажите там соответствующие настройки и добавьте еще один список доступа с ACL содержащим узлы и сети, в этом случае работа пула ничем не будет отличаться от пула 3-го класса, а настройки для пользователей будут проигнорированы.

Мы создали два элемента ACL: для некого публичного ПК, с которого доступ в сеть будет осуществляться без аутентификации, и для прошедших проверку подлинности пользователей. Затем разместили список доступа для публичного ПК выше списка доступа пользователей, в противном случае прокси прежде потребует аутентификацию.

И наконец задали два списка доступа для пула, в данном случае их порядок особо неважен, так как элементы ACL содержат разные типы данных и не перекрывают друг друга. В настройках пула мы задали скорость в 10 Мбит/с как для узла, так и для пользователя. Комбинируя настройки следует учитывать их вложенность, ограничения для пользователя также учитывают ограничения для узла, подсети и для пула в целом. Например, ограничив для узла скорость в 1 Мбит/с и оставив 10 Мбит/с для пользователя мы все равно не получим скорости выше 1 Мбит/с.

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

До сих пор мы оперировали общим понятием пользователи, но в большинстве случаев требуются ограничения для конкретных пользователей или групп. Если Squid самостоятельно занимается аутентификацией пользователей, то можно просто перечислить в описании ACL необходимые имена. Для примера разделим интернет в небольшой группе для босса и подчиненных.

Теперь у нас два элемента ACL, в первый попадает пользователь с именем boss, а во второй сотрудники Иванов, Петров и Сидоров.

Создадим два пула четвертого класса и укажем списки доступа для них:

Теперь зададим параметры пулов. Для босса ограничений нет и на первый взгляд было бы логично указать:

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

Поэтому следует явно указывать значения скорости, например, полную скорость канала, либо заведомо большее значение. В нашем случае укажем 100 Мбит/с для босса и 10 Мбит/с для сотрудников.

Если вы используете аутентификацию через внешние службы, например, через каталог Active Directory, то гораздо удобнее оперировать не пользователями, а группами. Для получения сведений о членстве пользователя в той или иной группе применяются внешние утилиты — хелперы, работа с которыми производится специальной директивой external_acl_ type. Более подробно об этом можно прочитать в статье:

Мы не будем подробно останавливаться на этом вопросе и возьмем в качестве примера настройки из указанной статьи. Мы будем проверять членство пользователей в двух доменных группах и на основании этого помещать их в один из элементов ACL:

Дальнейшая настройка ничем не отличается от вышеприведенного примера, достаточно только прописать в списки доступа ACL с авторизованными на основе групп доменными пользователями.

А как быть с теми, кто не попал ни в какой список? Если оставить все как есть, то никакие ограничения к ним не применятся. Поэтому создадим третий пул, убедившись перед этим, что у нас есть элемент ACL для всех пользователей.

Затем укажем для них список доступа и поставим его самым последним. Списки обрабатываются в порядке очередности и до первого совпадения, поэтому в него попадут только те, кто не попал ни в один другой список. Т.е. правильно будет так:

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

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

После чего в файл /var/log/squid3/cache.log будут записываться события связанные с пулами задержки. Взглянем на пример такого лога:

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

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

Источник