| ||
Апрель 2003
Перевод на русский: © Иван Песин.
История пересмотров | ||
---|---|---|
Пересмотр 1.0 | 2003-04-16 | Пересмотрено: tab |
Начальный пересмотр LDP | ||
Пересмотр 0.5 | 2002-04-01 | Пересмотрено: MAB |
передача в tldp, переименование в HOWTO | ||
Пересмотр 0.4 | 2002-03-31 | Пересмотрено: MAB |
новый пример, быстрый экскурс по буферам | ||
Пересмотр 0.3 | 2002-03-16 | Пересмотрено: MAB |
коррекция и замечания от Джакоба Теплитски (Jacob Teplitsky), raptor и Джошуа Хелинга (Joshua Heling) | ||
Пересмотр 0.2 | 2002-03-15 | Пересмотрено: MAB |
ссылки, чистка, публикация | ||
Пересмотр 0.1 | 2002-03-14 | Пересмотрено: MAB |
начальный пересмотр |
© 2003, Martin A. Brown
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no invariant sections, with no Front-Cover Texts, with no Back-Cover Text. A copy of the license is located at www.gnu.org/copyleft/fdl.html.
Этот документ представляет собой краткое руководство по использованию tcng (Traffic Control Next Generation) с HTB (Hierarchical Token Bucket) для ограничения трафика на Linux-машине.
Это руководство предназначено для системных администраторов,
которые имеют хотя бы базовое представление об управлении трафиком
которые в состоянии скомпилировать iproute2 и tcng из исходных текстов
или умеют собирать пакеты RPMS из существующих SRPM
работающих на системах, чьё ядро имеет поддержку модулей htb и dsmark
которые в состоянии скомпилировать ядро с поддержкой htb и dsmark
Этот документ не претендует на полноту изложения и абсолютную точность. Автор ждет позитивных и негативных откликов по адресу <mabrown@securepipe.com>. Исправления, дополнения и примеры приветствуются. Всегда. |
Управление трафиком -- название, объединяющее в себе все части подсистемы организации очередей в сети или сетевом устройстве. Управление трафиком состоит из нескольких операций: классифицирование (classification) -- механизм, позволяющий идентифицировать пакеты и помещать их в определенные потоки или классы; ограничение входящего трафика (policing) -- механизм, с помощью которого можно ограничить количество пакетов или байт в потоке, соответствующих определенной классификации; планирование (scheduling) -- процесс принятия решений, при котором пакеты упорядочиваются и переупорядочиваются для дальнейшей передачи; наконец, ограничение исходящего трафика (shaping) -- процесс при котором пакеты задерживаются и передаются таким образом, чтобы реализовать постоянную и предсказуемую скорость потока.
Все эти характеристики системы управления трафиком могут быть скомбинированы комплексными методами для резервирования или ограничения полосы пропускания для отдельных потоков (или приложений).
Одним из ключевых моментов управления трафиком является понятие токенов. Реализация ограничения входящего и исходящего трафиков требует вычисления количества пакетов или байт проходящих за момент времени для определения скорости. Каждый пакет или байт ( в зависимости от реализации) соответствует токену и передается только в случае наличия свободного токена. Общее образное хранилище, где находятся токены, называется буфером (bucket). Если кратко, то буфер характеризует две величины: количество токенов, которые могут быть одновременно использованы (размер буфера) и скорость, с которой буфер заполняется новыми токенами.
В секции 1.2 приведены примеры буферов системы управления трафиком в Linux.
В Linux, управление трафиком исторически сложная задача. Команда tc обеспечивает интерфейс со структурами ядра, ответственными за ограничение, планирование и классификацию трафика. Синтаксис этой команды, однако, весьма загадочен. Проект tcng предоставляет более дружественный пользователю интерфейс к такой мощной утилите как tc, определяя свой язык описания конфигурации. Его использование при написании конфигурации системы управления трафиком упрощает поддержку, облегчает понимание и, что важно, увеличивает переносимость.
Hierarchichal Token Bucket -- это классовая дисциплина обработки очереди, написанная Мартином Девером (Martin Devera) с упрощенным набором конфигурационных параметров по сравнению с CBQ. Есть много хорошей документации по HTB и ее применению на сайте автора и сайте Стефа Коэна (Stef Coene). Ниже приведено очень краткое описание системы HTB.
Идеологически, HTB представляет собой набор иерархически упорядоченных буферов токенов (да, наверно вы и сами догадались об этом [В переводе с английского HTB означает "иерархический буфер токенов" - Прим.пер.]). Давайте рассмотрим простейший сценарий. Главная дисциплина обработки исходящей очереди любого устройства, называется корневой (root qdisc).
Корневая дисциплина содержит один класс (в сложных конфигурациях корневая дисциплина может содержать несколько классов). Этот класс HTB создается с указанием двух параметров: rate и ceil. Значения этих параметров должны совпадать для корневого класса и задают общую полосу пропускания канала.
В HTB, rate задает гарантированную полосу пропускания для данного класса, а ceil, сокращение от ceiling, определяет максимальную полосу пропускания, которую класс может получить. Любая полоса пропускания, находящаяся между rate и ceil одалживается у родительского класса, откуда вытекает утверждение, что для корневого класса значение параметров rate и ceil должны совпадать.
В корневом классе можно определять подклассы, каждому из которых можно выделить некоторую часть доступной полосы пропускания родительского класса. У классов-потомков, значения параметров rate и ceil не обязаны совпадать с соответствующими значениями родительского класса. Это позволяет резервировать часть пропускной способности заданного класса. Кроме того, это позволяет HTB рассчитывать отношение, в котором должна быть разделена полоса пропускания между классами. Это станет ясней после рассмотрения примеров.
Hierarchical Token Bucket реализует классовый механизм формирования очередей для системы управления трафиком в linux; пользователю предоставляются параметры rate и ceil для контроля над полосой пропускания отдельных классов и задания отношения распределения пропускной способности в случае, когда часть полосы пропускания остается свободной (до значения ceil).
При указании пропускной способности вы должны помнить, что ограничение полосы пропускания будет работать только в том случае, если вы (машина, на которой выполняется управление трафиком - Прим.пер.) являетесь узким местом между ЛВС и Internet. Обычно, это используется в домашних и офисных сетях, где вся локальная сеть обслуживается DSL- или T1-соединением.
На деле это означает, что вам, вероятно, нужно будет установить значение пропускной способности равным реальной пропускной способности канала, минус небольшая ее часть.
Traffic Control Next Generation (tcng) -- это проект Вернера Альмесбергера (Werner Almesberger) призванный реализовать мощный, абстрактный и стандартизированный язык для описания структур управления трафиком. Синтаксический анализатор tcc из дистрибутива tcng преобразовывает язык tcng в различные форматы. По умолчанию, tcc читает входной файл (переданный в качестве аргумента или стандартный ввод) и выводит в стандартный вывод последовательности команд tc (смотрите ниже iproute2) необходимые для создания желаемой структуры управления трафиком в ядре.
Обратитесь к справочнику по параметрам tcng за информацией о поддерживаемых дисциплинах обработки очереди. Джакоб Теплитски (Jacob Teplitsky), активный участник списка рассылки LARTC и контрибьютор проекта tcng, написал поддержку htb для tcng.
Утилита tcc может генерировать вывод различных типов, но в этом документе мы будем рассматривать только стандартный вывод и вывод по умолчанию. За детальной информацией об использовании tcng обратитесь к руководству TCNG.
Программа tcsim -- имитатор системы управления трафиком, который работает с конфигурационными файлами tcng и имитирует поведение ядра при передаче данных, согласно структурам управления трафиком. Не смотря на то, что tcsim является значительной частью проекта tcng, в этом документе он вообще не рассматривается.
Есть некоторые требования по поддержке ядром HTB и DSMARK, поддержке HTB и DSMARK в tc и самому tcng.
В частности, поддержка HTB в ядре и tc абсолютно необходима, иначе вы не сможете воспользоваться советами, предоставляемыми данным руководством (обратите внимание на название, если у вас есть какие-то сомнения). Поддержка DSMARK, строго говоря, необязательна, однако некоторые примеры (алгоритм выбора класса, в частности, и возможно и другие) могут не работать без нее.
Удовлетворить требования к ядру очень просто. Ядро 2.4.20 и более новые включают поддержку HTB и dsmark, так что просто убедитесь, что эти опции включены в разделе QoS/Fair Queuing конфигурации ядра. За кратким описанием параметров для, которые нужно выбрать в конфигурации ядра, обращайтесь к заметкам по конфигурации ядра для проекта DiffServ.
Для ядер версии меньше 2.4.20 необходим патч (к сожалению патч существует только для ядер 2.4.17 и выше).
Команда tc является частью набора утилит iproute2. За общей документацией по iproute2, обращайтесь на сайт http://linux-ip.net/ и к руководству по iproute2. Само программное обеспечение доступно на FTP-архиве Алексея Кузнецова, но обычно они поставляются в виде пакетов с дистрибутивом Linux. Если ваш дистрибутив использует пакеты RPM, вы можете загрузить этот SRPM и скомпилировать у себя в системе.
Если вам придется компилировать iproute2 самим, то чтобы включить поддержку HTB в tc, возьмите патч к tc на сайте Мартина Дэвэра.
Кроме того, в tc потребуется поддержка dsmark, механизма маркировки diffserv. К счастью, его поддержка легко включается с помощью редактирования файла Config из пакета исходников iproute2. Просто измените строку TC_CONFIG_DIFFSERV=n на TC_CONFIG_DIFFSERV=y и скомпилируйте пакет.
Из этого SRPM можно собрать пакет iproute2 с поддержкой dsmark и HTB, которые требуются для примеров этого документа.
Компиляция tcng -- самый простая часть всего процесса. Просто распакуйте исходный код tcng и выполните: ./configure --no-tcsim перед компиляцией.
Если вы работаете с дистрибутивом, основанном на RPM, то можете использовать SPEC-файл tcng/build/tcng.spec для сборки пакета. Можно взять готовый SRPM здесь. Результатом сборки этого SRPM станут два пакета: tcc и tcc-devel. Для создания конфигураций вам понадобится только tcc.
Для работы с tcc вам понадобиться пакет cpp, поскольку tcc его использует в работе.
Приведенные в этом документе примеры представляют переработанные конфигурации, доступные по адресу http://linux-ip.net/code/tcng/.
Примеры могут использоваться как самостоятельные конфигурационные файлы для синтаксического анализатора tcc, или в комбинации с примером скрипта начальной загрузки для SysV. Данный скрипт начальной загрузки является модификацией скрипта, предложенного raptor'ом в списке рассылки LARTC.
Если вы собираетесь пользоваться этим скриптом начальной загрузки, посмотрите на пример файла /etc/sysconfig/tcng:
Пример 1. /etc/sysconfig/tcng
# - мета-конфигурационный файл tcng # # -- 2003-03-15 создание; -MAB # -- 2003-03-31 модификация для поддержки переопределения ENVAR; -MAB # # -- В этом каталоге будут храниться все конфигурационные файл tcng # для данного хоста # TCCONFBASEDIR=${TCCONFBASEDIR:-/etc/sysconfig/tcng-configs} # -- активная конфигурация для tcng # обратите внимание, что благодаря поддержке конструкции #include # модульность конфигурации tcng может быть встроена в # конфигурационные файлы в $TCCONFBASEDIR # TCCONF=${TCCONF:-$TCCONFBASEDIR/global.tcc} tcstats=${tcstats:-no} # -- подавляет вывод статистики tcstats=${tcstats:-yes} # -- передает ключ "-s" в tc tcdebug=${tcdebug:-0} # -- для повседневного использования tcdebug=${tcdebug:-1} # -- для вывода дополнительной информации tcdebug=${tcdebug:-2} # -- для вывода отладочной информации # # # -- в качестве дополнительной меры, вы можете переопределить местоположение утилит # tc и tcc, например: # # tc=/usr/local/bin/tc # tcc=/usr/local/tcng/bin/tcc # # |
Большинство основных идей представлено в этом примере. Этот пример может быть трансформирован в набор команд tc с помощью команды tcc class-selection-path.tcc.
Пример 2. /etc/sysconfig/tcng/class-selection-path.tcc
/* * Простой пример с комментариями файла управления трафиком для tcng. * * Martin A. Brown <mabrown@securepipe.com> * * Пример: Использование алгоритма выбора класса. * * */ #include "fields.tc" #include "ports.tc" #define INTERFACE eth0 dev INTERFACE { egress { /* при использовании алгоритма выбора класса, вначале указываются фильтры! DSmark */ class ( <$ssh> ) if tcp_sport == 22 && ip_tos_delay == 1 ; class ( <$audio> ) if tcp_sport == 554 || tcp_dport == 7070 ; class ( <$bulk> ) \ if tcp_sport == PORT_SSH || tcp_dport == PORT_HTTP ; class ( <$other> ) if 1 ; /* секция, в которой мы конфигурируем дисциплины обработки очередей и классы */ htb () { class ( rate 600kbps, ceil 600kbps ) { $ssh = class ( rate 64kbps, ceil 128kbps ) { sfq; } ; $audio = class ( rate 128kbps, ceil 128kbps ) { sfq; } ; $bulk = class ( rate 256kbps, ceil 512kbps ) { sfq; } ; $other = class ( rate 128kbps, ceil 384kbps ) { sfq; } ; } } } } |
Использование директив #include увеличивает гибкость определения переменных и подключения общих элементов управления трафиком.
За дальнейшей информацией обращайтесь к руководству tcng, раздел подключений.
За подробностями обращайтесь к разделу описания алгоритма выбора класса руководства по tcng.
Имена и номера портов одинаково допустимы.
Параметры rate и ceil должны быть знакомы всем, кто пользовался HTB. Это специфические параметры HTB и соответствующим образом обрабатываются утилитой tcc. Обратитесь к таблице аббревиатур скоростей tcng.
Если для подклассов не указаны дисциплины обработки очереди, то они используют стандартную дисциплину pfifo_fast qdisc. Включение стохастической дисциплины (sfq) для подклассов позволяет избежать превалирования одного соединения над остальными внутри класса.
Пример 3. /etc/sysconfig/tcng/two-rate-three-color-meter.tcc
/* * Простой пример с комментариями файла управления трафиком для tcng. * * Martin A. Brown <mabrown@securepipe.com> * * Пример: Использование измерителя. * * */ #define EXCEPTION 192.168.137.50 #define INTERFACE eth0 $meter = trTCM( cir 128kbps, cbs 10kB, pir 256kbps, pbs 10kB ); dev eth0 { egress { class ( <$full> ) if ip_src == EXCEPTION ; class ( <$fast> ) if trTCM_green( $meter ) ; class ( <$slow> ) if trTCM_yellow( $meter ) ; drop if trTCM_red( $meter ) ; htb { class ( rate 600kbps, ceil 600kbps ) { $fast = class ( rate 256kbps, ceil 256kbps ) { sfq; } ; $slow = class ( rate 128kbps, ceil 128kbps ) { sfq; } ; $full = class ( rate 600kbps, ceil 600kbps ) { sfq; } ; } } } } |
Приведенный в этом примере измеритель является двухскоростным трехцветным измерителем, самым сложным измерителем, доступным в языке tcng. Этот измеритель возвращает цвет -- зеленый, желтый и красный, в зависимости от скорости. Если измеренная скорость превышает гарантированную, измеритель возвращает желтый цвет, а если превышает пиковую скорость -- возвращается красный цвет.
С переменной $meter могут оперировать функции, работающие с типом измерителя. В нашем случае используются три функции, позволяющие проверить состояние $meter: trTCM_green, trTCM_yellow и trTCM_red. Для эффективности, обратите внимание на ускоренные аналоги.
Измеритель зеленый.
Измеритель желтый.
Измеритель красный.
К счастью, tcng положил конец маленькому неудобству в использовании tc. Ниже приводится таблица соответствия между сокращениями этих утилит с русским языком.
Таблица 1. Синтакс описания скорости: tcng против tc
tcng | Русский | tc |
---|---|---|
bps | бит в секунду | bit |
Bps | байт в секунду | bps (ух!) |
kbps | килобит в секунду | kbit |
kBps | килобайт в секунду | kbps |
Mbps | мегабит в секунду | mbit или Mbit |
MBps | мегабайт в секунду | mbps или Mbps |
pps | пакетов в секунду | ?? |
Обратите внимание, что это потребует небольшого привыкания для давних пользователей tc, но эти сокращения намного более понятны для тех, кто владеет английским языком.
Например, мы можем использовать традиционные обозначения скорости в конфигурации tcng: 100Mbps, 128kbps и даже 2Gpps. Посмотрите раздел руководства по tcng о единицах измерения.
Для эффективного управления трафиком важно понимать, где находятся узкие места сети. В большинстве случаев, управление трафиком вам придется выполнять именно в узком месте или рядом с ним.
Copyright (c) 2003, Martin A. Brown
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |