Современные
информационные технологии
Компьютерная
инженерия
И.А. Гаврилов,
Р.В. Бараненко
Херсонский национальный технический университет
Оптимизация РАБОТЫ шейпера на Linux, iproute2.
Переход от линейных списков фильтров
к хэш-таблицам
В настоящее время администраторы локальных
вычислительных сетей и интернет-провайдеры сталкиваются с проблемой ограничения
пропускной способности канала для отдельного узла сети ниже технических
возможностей канала до узла (шейпингом). Крупные провайдеры и компании используют
для ее решения специализированное оборудование от именитых производителей,
таких как Cisco, Juniper Networks, Redback, Huawei. Платформы этих
производителей запросто могут работать на скоростях в десятки гигабит, но их
цена достаточно высока. Поэтому предприятиями и Ethernet-операторами для целей
шейпинга чаще всего применяются PC-сервера с операционными системами Linux,
*BSD и т.п. На соответствующем аппаратном обеспечении они способны работать с
потоками 500-700 Мбит/с при pps около 100-120 тысяч пакетов в секунду. Для
задач шейпинга очень хорошо зарекомендовала себя операционная система Linux с
ее огромными возможностями по управлению трафиком.
На рис. 1 представлена структура типичной
ЛВС провайдера, либо сеть большого предприятия. При этом доступ к сети Интернет
может обеспечиваться не только посредством PPPoE, но и IPoE, PPTP и т.п. Задача
шейпинга (а также терминации туннелей) возлагается на BRAS.
Пусть имеется небольшая сеть 10.0.0.0/24. Типичная конфигурация шейпера
входящего трафика будет выглядеть следующим образом:
Рис. 1 Структура типичной ЛВС
tc qdisc add dev ifb0 root
handle 1:0 htb default 4
tc class add dev ifb0 parent 1:0 classid 1:100 htb rate 90Mbit
tc class add dev ifb0 parent 1:100 classid 1:1 htb ceil 1Mbit
tc class add dev ifb0 parent 1:100 classid 1:2 htb ceil 2Mbit
tc class add dev ifb0 parent 1:100 classid 1:3 htb ceil 512Kbit
.............
tc class add dev ifb0 parent 1:100 classid 1:fe htb ceil 8Mbit
tc filter add dev ifb0 protocol ip parent 1:0 u32 match u32 0x0a000001
0xffffffff at 16 classid 1:1
tc filter add dev ifb0 protocol ip parent 1:0 u32 match u32
0x0a000002 0xffffffff at 16 classid 1:2
.............
tc filter add dev ifb0 protocol ip parent 1:0 u32 match u32
0x0a0000fe 0xffffffff at 16 classid 1:fe
В случае использования данной конфигурации
среднее количество сравнений, выполняемых фильтрами, составляет около 128. При
достаточно большом суммарном трафике (достаточно 100 Мбит/с) и невысокой
производительности аппаратного обеспечения получается нагрузка на процессор
80-90%, нестабильная задержка прохождения пакетов и т.п.
Целью работы является оптимизация
механизма фильтрации пакетов с использованием хэш-таблиц фильтров iproute2.
Хэш-таблицу можно представить в виде
таблицы, имеющей 4095 строк и до 256 столбцов, имеющих собственный номер.
Образный пример такой таблицы показан на рис. 2.
1::
|
|
1:0: |
1:1: |
1:2: |
1:3: |
|
::0 |
|
1:1:0 |
|
|
|
::1 |
|
|
|
|
|
... |
... |
... |
... |
... |
|
::800 |
|
|
|
|
|
::801 |
|
|
1:2:801 |
|
|
... |
... |
... |
... |
... |
|
::ffe |
|
|
|
|
|
::fff |
|
|
|
|
Рис. 2 Представление хэш-таблицы
По умолчанию всегда создается таблица с
номером 800::, которая имеет один столбец. В нее изначально попадают все
пакеты. В каждой ячейке таблицы может быть правило. Если не указано, в какую
ячейку записывать правило, то оно по умолчанию записывается в ячейку с номером
800.
Смысл использования хэш-таблиц сводится к
тому, чтобы на основании какого-либо байта (или нескольких) в пакете сделать
вывод о расположении правила в таблице и сразу направить пакет к нему. Т.е.
вместо 254 проверок производится всего одна. Далее показан вариант
конфигурирования фильтров шейпера с использованием хэш-таблиц.
Для начала создается таблица с номером 1 и
256-ю столбцами:
tc filter add dev ifb0
protocol ip parent 1:0 handle 1:: u32 divisor 256
После этого в каждый столбец таблицы 1
отправляются пакеты, последний октет которых будет равен номеру столбца.
Например, пакет с адресом назначения 10.0.0.15 будет отправлен в 1:0f: (15-й
столбец таблицы 1):
tc filter add dev ifb0
protocol ip parent 1:0 u32 ht 800:: match u32 0x0a000000 0xffffff00 at 16
hashkey mask 0x000000ff at 16 link 1:
Стоит напомнить, что изначально правила
попадают в таблицу 800:: и именно к ней должно добавляться правило, которое
распределяет пакеты по другим таблицам. Ключевые слова hashkey mask 0x000000ff
at 16 говорят о том, что распределение по столбцам таблицы 1:: делается на
основании последних 8 бит адреса назначения.
После этого в каждый столбец добавляется
правило:
tc filter add dev ifb0 protocol ip parent 1:0 u32
ht 1:1: match u32 0x0a000001 0xffffffff at 16 classid 1:1
tc filter add dev ifb0 protocol ip parent 1:0 u32
ht 1:2: match u32 0x0a000002 0xffffffff at 16 classid 1:2
.........
tc filter add dev ifb0 protocol ip parent 1:0 u32
ht 1:fe: match u32 0x0a0000fe 0xffffffff at 16 classid 1:fe
При необходимости классификации и шейпинга
трафика хостов сетей размером более /24 (более 256 хостов), например сеть /20,
возможно использование следующих вариантов:
1) Модифицирование предыдущего примера:
хеширование провести по последнему байту адреса назначения, а в каждый столбец
вместо одного правила добавить 16 (24), которые будут отбирать
пакеты на основании предпоследнего октета. Например, для пакетов с адресами
назначения вида 10.0.Х.126, которые будут отправляться в столбец 7Е (126 в
десятичном виде) таблицы 1::
tc filter add dev ifb0 protocol ip parent 1:0 u32
ht 1:7e: match u32 0x0a00007e 0xffffffff at 16 classid 1:7e
tc filter add dev ifb0 protocol ip parent 1:0 u32
ht 1:7e: match u32 0x0a00017e 0xffffffff at 16 classid 1:17e
.........
tc filter add dev ifb0
protocol ip parent 1:0 u32 ht 1:7e: match u32 0x0a00087e 0xffffffff at 16
classid 1:87e
2) Создание таблицы на 16 столбцов и
распределение пакетов по ним (16 столбцам) на основании предпоследнего байта
адреса назначения, а в каждом столбце будет правило, отправляющее пакеты на
основании последнего байта адреса назначения в 16 таблиц на 256 столбцов:
tc filter add dev ifb0
protocol ip parent 1:0 u32
tc filter add dev ifb0
protocol ip parent 1:0 handle 100: u32 divisor 16
tc filter add dev ifb0
protocol ip parent 1:0 handle 1: u32 divisor 256
tc filter add dev ifb0
protocol ip parent 1:0 handle 2: u32 divisor 256
......
tc filter add dev ifb0
protocol ip parent 1:0 handle 16: u32 divisor 256
tc filter add dev ifb0
protocol ip parent 1:0 u32 ht 800:: match u32 0x0a000000 0xffff0000 at 16
hashkey mask 0x00000f00 at 16 link 100:
tc filter add dev ifb0
protocol ip parent 1:0 u32 ht 100:0: match u32 0x0a000000 0xffffff00 at 16
hashkey mask 0x000000ff at 16 link 1:
tc filter add dev ifb0
protocol ip parent 1:0 u32 ht 100:1: match u32 0x0a000100 0xffffff00 at 16
hashkey mask 0x000000ff at 16 link 2:
.......
tc filter add dev ifb0
protocol ip parent 1:0 u32 ht 100:f: match u32 0x0a000f00 0xffffff00 at 16
hashkey mask 0x000000ff at 16 link 16:
tc filter add dev ifb0
protocol ip parent 1:0 u32 ht 1:1: match u32 0x0a000001 0xffffffff at 16
classid 1:1
tc filter add dev ifb0
protocol ip parent 1:0 u32 ht 1:2: match u32 0x0a000002 0xffffffff at 16
classid 1:2
.........
tc filter add dev ifb0
protocol ip parent 1:0 u32 ht 1:ff: match u32 0x0a0000ff 0xffffffff at 16
classid 1:ff
tc filter add
dev ifb0 protocol ip parent 1:0 u32 ht 2:0: match u32 0x0a000100 0xffffffff at
16 classid 1:100
tc filter add
dev ifb0 protocol ip parent 1:0 u32 ht 2:1: match u32 0x0a000101 0xffffffff at
16 classid 1:101
.........
tc filter add
dev ifb0 protocol ip parent 1:0 u32 ht 2:ff: match u32 0x0a0001ff 0xffffffff at
16 classid 1:1ff
.........
.........
tc filter add
dev ifb0 protocol ip parent 1:0 u32 ht 16:0: match u32 0x0a000f00 0xffffffff at
16 classid 1:f00
tc filter add
dev ifb0 protocol ip parent 1:0 u32 ht 16:1: match u32 0x0a000f01 0xffffffff at
16 classid 1:f01
.........
tc filter add
dev ifb0 protocol ip parent 1:0 u32 ht 16:fe: match u32 0x0a000ffe 0xffffffff
at 16 classid 1:ffe
Предложенный способ повышает
производительность шейпера, который несколько сложнее в настройке, но может обеспечить
повышение производительности PC-сервера, выполняющего роль BRASа, в 10-20 раз,
что для BRASов существенно важно, так как шейпинг не единственная задача этого
класса устройств.
Литература:
1. http://www.opennet.ru/docs/RUS/LARTC/index.html
2. http://www.linuxfoundation.org/collaborate/workgroups/networking/iproute2