Запуск нескольких сайтов с различными SLA

От переводчика (А.К.): SLA (от англ. Service Level Agreement) означает «Соглашение об Уровне Обслуживания» — основной документ, регламентирующий взаимоотношения между ИТ-компанией и заказчиком.

Сделать это можно несколькими способами. Прежде всего следует упомянуть, что Apache поддерживает подобную функциональность в виде модулей, но мы продемонстрируем как добиться этого средствами операционной системы. Эти строки взяты из примера, представленного Джамалом Хади (Jamal Hadi).

Допустим, что у нас есть два клиента, которые арендуют некоторую долю нашего канала под http, ftp и потоковое audio. Первый клиент арендует полосу в 2 Мбита, второй — 5 Мбит. Для начала назначим нашим клиентам виртуальные IP-адреса на нашем сервере:

Решение проблемы о том, как назначить правильные IP-адреса различным службам, оставляем за вами. Практически все популярные демоны поддерживают такую возможность.
Присоединяем CBQ qdisc к eth0:

Создаем классы клиентов:

И добавляем фильтры к классам:

FIXME: Почему нет token bucket filter?

Ограничение скорости для отдельного хоста или подсети

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

Эти три строки сделают все что вам нужно:

Первая строка — назначает базовую дисциплину на заданный интерфейс и сообщает ядру, что пропускная способность интерфейса составляет 10 Мбит/сек. Если вы установите неверное значение, то особого вреда не будет, однако, всегда стремитесь устанавливать верные значения, это повысит точность вычислений.

Вторая строка создает класс с полосой пропускания 512 Кбит/сек. Подробное описание CBQ содержит раздел Дисциплины обработки очередей для управления пропускной способностью.

Последняя строка говорит о том, какой трафик должен формироваться классом, определенным выше. Трафик, не подпадающий под заданное в фильтре условие, НЕ ОГРАНИЧИВАЕТСЯ! Более сложные примеры назначения условий (подсети, порт отправителя, порт адресата), вы найдете в разделе Наиболее употребимые способы фильтрации.

Если вы внесли какие-либо изменения в сценарий и желаете перезапустить его — предварительно запустите команду tc qdisc del dev $DEV root, чтобы очистить существующую конфигурацию.

Сценарий может быть немного улучшен, за счет добавления в конец дополнительной строки tc qdisc add dev $DEV parent 1:1 sfq perturb 10. За подробным описанием обращайтесь к разделу Stochastic Fairness Queueing.

Пример подключения локальной сети к Интернет через NAT, с организацией QoS

Меня зовут Педро Ларрой (Pedro Larroy) <piotr%member.fsf.org>. Здесь я расскажу об общих принципах настройки соединения локальной сети, в которой имеется большое число пользователей, к Интернет через маршрутизатор, работающий под управлением Linux. Маршрутизатор имеет реальный IP-адрес и производит Трансляцию Сетевых Адресов (NAT). Я живу в университетском общежитии, где проложена локальная сеть на 198 пользователей. Эта сеть соединена с Интернет через маршрутизатор, который я администрирую. Пользователи очень интенсивно работают в пиринговых сетях, что требует соответствующего управления трафиком. Надеюсь, что этот пример будет интересен читателям lartc.

Прежде всего я опишу процесс настройки своего маршрутизатора шаг за шагом, и в заключение расскажу, как сделать этот процесс автоматическим, выполняющимся в процессе загрузки системы. Сеть, к которой относится этот пример, является локальной (LAN). Она подключена к Интернет через маршрутизатор, который имеет единственный реальный IP-адрес. Разделение единственного реального IP-адреса между всеми пользователями в локальной сети осуществляется с помощью нескольких правил iptables. Для этого необходимо:

Ядро Linux 2.4.18 или выше
На ядро нужно наложить заплату, для поддержки HTB.
iproute
Убедитесь, что tc поддерживает HTB. Скомпилированная версия распространяется вместе с HTB.
iptables

Начнем с оптимизации пропускной способности.

Для начала создадим несколько дисциплин (qdiscs), которые будут обслуживать трафик. Первой создается htb qdisc с 6-ю классами и различными приоритетами. Каждому классу назначена определенная пропускная способность, но при этом они могут задействовать неиспользуемую пропускную способность, если она не занята другими классами. Напомню, что классы с более высоким приоритетом (т.е. с более низким числом prio) будут получать «излишек» канала первыми. Подключение к Интернет осуществляется через модем ADSL, с пропускной способностью для входящего трафика 2 Мбит/сек, исходящего — 300 Кбит/сек. Я ограничиваю исходящую пропускную способность величиной в 240 Кбит/сек по той простой причине, что это максимальное значение, при котором время ожидания отклика остается минимальным. Величина этот параметра может быть определена экспериментально, путем наблюдения за изменением времени отклика при изменении величины пропускной способности.

Для начала, присвойте переменной CEIL величину, составляющую 75% от общей пропускной способности для исходящего трафика. Там, где я использую eth0 — назначьте свой интерфейс, который «смотрит» в Интернет. Сценарий (на языке командной оболочки), выполняющий настройку, начинается со следующих строк:

Эти строки создают одноярусное дерево HTB:

classid 1:10 htb rate 80kbit ceil 80kbit prio 0
Это класс с наивысшим приоритетом. Пакеты, попадающие в этот класс, будут иметь самую низкую задержку и получат избыток канала в первую очередь. Сюда будет направляться интерактивный трафик: sshtelnetdnsquake3irc, а так же пакеты с установленным флагом SYN.
classid 1:11 htb rate 80kbit ceil ${CEIL}kbit prio 1
Это первый класс, через который будет проходить довольно объемный трафик. В моем случае — это трафик от локального WEB-сервера и запросы к внешним WEB-серверам, исходящий порт 80 и порт назначения 80, соответственно.
classid 1:12 htb rate 20kbit ceil ${CEIL}kbit prio 2
В этот класс помещаются пакеты, с установленным битом Maximize-Throughput в поле TOS, а так же иной трафик, который генерируется локальными процессами на маршрутизаторе, отправляемый в Интернет. Таким образом, все последующие классы будут иметь дело только с перенаправляемым трафиком.
classid 1:13 htb rate 20kbit ceil ${CEIL}kbit prio 2
Высокоприоритетный класс, обслуживающий объемный трафик, поступающий от компьютеров из локальной сети.
classid 1:14 htb rate 10kbit ceil ${CEIL}kbit prio 3
Этот класс обслуживает почтовый трафик (SMTP,pop3…) и пакеты, с установленным битом Minimize-Cost в поле TOS.
classid 1:15 htb rate 30kbit ceil ${CEIL}kbit prio 3
Последний класс. Он обслуживает прочий трафик, поступающий от компьютеров из локальной сети. Сюда попадает все, что относится к работе в пиринговых сетях, т.е. kazaa, edonkey и пр.

Классификация пакетов.

Мы создали различные классы обработки трафика, но классификация пока отсутствует, поэтому, к настоящему моменту, весь трафик пойдет через класс 1:15 ( который назначен классом по-умолчанию: tc qdisc add dev eth0 root handle 1: htb default 15 ). Теперь самое главное — нужно распределить трафик по имеющимся классам.

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

Здесь задаются соответствия между специфическими значениями FWMARK ( handle x fw ) и классами (classid x:x). Теперь рассмотрим процесс установки меток на пакеты.

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

Далее я буду исходить из предположения, что всем таблицам назначена политика по-умолчанию -P ACCEPT. Наша локальная сеть относится к классу B, с адресами 172.17.0.0/16. Реальный IP-адрес — 212.170.21.172

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

Проверим, что пакеты уходят через класс 1:15:

Добавим в цепочку PREROUTING, таблицы mangle, правила для установки меток на пакеты:

Теперь вы должны наблюдать увеличение значения счетчика пакетов в классе 1:10, при попытке ping-ануть из локальной сети какой-нибудь сайт в Интернете.

Действие -j RETURN предотвращает движение пакетов по всем правилам. Поэтому все ICMP-пакеты будут проходить только это правило. Добавим еще ряд правил, которые будут изменять биты в поле TOS:

Поднимем приоритет для ssh-пакетов:

а так же для пакетов, с которых начинается TCP-соединение, т.е. SYN-пакетов:

И так далее. После того, как в цепочку PREROUTING, таблицы mangle, будут внесены все необходимые правила, закончим ее правилом:

Это заключительное правило отправит оставшиеся немаркированные пакеты в класс 1:15. Фактически, это правило можно опустить, так как класс 1:15 был задан по-умолчанию, но тем не менее, я оставляю его, чтобы сохранить единство настроек и кроме того, иногда бывает полезно увидеть счетчик пакетов для этого правила.

Нелишним будет добавить те же правила в цепочку OUTPUT, заменив имя цепочки PREROUTING на OUTPUT (s/PREROUTING/OUTPUT/). Тогда трафик, сгенерированный локальными процессами на маршрутизаторе, также будет классифицирован по категориям. Но, в отличие от вышеприведенных правил, в цепочке OUTPUT, я устанавливаю метку -j MARK —set-mark 0x3, таким образом трафик от маршрутизатора получает более высокий приоритет.

Дополнительная оптимизация

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

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

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

Уверен, что можно найти множество способов, чтобы произвести настройку маршрутизатора во время загрузки. Для себя я создал скрипт /etc/init.d/packetfilter, который принимает команды [start | stop | stop-tables | start-tables | reload-tables]. Он конфигурирует дисциплины (qdiscs) и загружает необходимые модули ядра. Этот же сценарий загружает правила iptables из файла /etc/network/iptables-rules, которые предварительно могут быть сохранены утилитой iptables-save и восстановлены —iptables-restore.

http://docstore.mik.ua/manuals/ru/LARTC/x2755.html

Защита от SYN flood

Пример взят из документации к iproute, написанной Алексеем и адаптирован для совместной работы с netfilter. Если этот пример заинтересует вас, измените числовые значения на наиболее подходящие для вашей системы.

Этот сценарий был написан для защиты отдельного хоста, а не сети. Учитывайте это обстоятельство.

Для его работы желательно иметь самую последнюю версию iproute2.

 

Ограничение пропускной способности для ICMP-пакетов, с целью предотвращения DDoS-атак

Основная задача — настроить фильтры таким образом, чтобы пакеты, с исходящими адресами, не принадлежащими вашей сети, не смогли бы покинуть ее. Это предотвратит возможность отправки всякой «гадости» в Интернет.

Прежде, чем приступить к делу, нарисуем схему подключения локальной сети к Интернет:

[Интернет] —— [Linux router] — [Офис]
eth1 eth0

Зададим начальные условия:

Если у вас более высокоскоростное подключение — измените эти цифры соответствующим образом. Теперь необходимо определиться с «шириной» канала для ICMP-трафика. Чтобы найти типовое значение для вашей сети, можно воспользоваться утилитой tcpdump, запустив ее с перенаправлением вывода в файл. Затем, с помощью этого файла, вы сможете подсчитать количество ICMP-пакетов, отправляемых вашей сетью в единицу времени.

Если вариант подсчета экспериментальным путем вам не подходит, попробуйте ограничиться 10% общей пропускной способности. Построим наш класс:

Он ограничивает пропускную способность канала величиной 100 Кбит/сек. А теперь подключим к нему фильтр для ICMP-пакетов:

 

http://docstore.mik.ua/manuals/ru/LARTC/x2502.html