Лучший способ ограничить исходящую пропускную способность на сервере Apache (зеркало)

Вот рабочий пример на основе tc и iptables.

Шаг 1:
Замените очередь pfifo_fast по умолчанию на очередь PRIO.
Очередь PRIO - это классовая очередь, которая позволит нам позже присоединять фильтры для классификации различных типов трафика.

Проверить существующую очередь

tc -s qdisc ls dev eth0

Заменить на PRIO. Это создаст 3 диапазона по умолчанию.

tc qdisc add dev eth0 root handle 1: prio 

Что можно визуализировать, как показано ниже

      1:   root qdisc
     / | \ 
   /   |   \
   /   |   \
 1:1  1:2  1:3    classes

А теперь добавим классные очереди. Мы прикрепим их к полосам 1: 1, 1: 2 и 1: 3.

tc qdisc add dev eth0 parent 1:1 handle 10: sfq
tc qdisc add dev eth0 parent 1:2 handle 20: tbf rate 20kbit buffer 1600 limit 3000
tc qdisc add dev eth0 parent 1:3 handle 30: sfq 

Что можно визуализировать, как показано ниже

      1:   root qdisc
     / | \ 
   /   |   \
   /   |   \
 1:1  1:2  1:3    classes
  |    |    |
 10:  20:  30:    qdiscs    qdiscs
 sfq  tbf  sfq
  0    1    2     bands

На основе пакета TOS трафик будет идти в

• 1:10 - Интерактивный трафик
• 1:20 - Интерактивный трафик
• 1:30 - Массовый трафик

Но это не совсем то, что мы хотим, учитывая, что некоторые приложения фактически устанавливают значения TOS.
Мы хотим классифицировать трафик, инициированный с порта 80 (sport = 80), как 1: 2 (который мы формируем и ограничиваем скорость), а остальной трафик - как 1: 1.
Таким образом, остальной трафик не будет ждать HTTP-трафика и будет иметь приоритет. В противном случае медленный HTTP-трафик будет блокировать другой неинтерактивный трафик.

Итак, как это сделать?
Мы будем отмечать наши пакеты, инициированные с исходного порта 80, меткой 2 через iptables, а не HTTP-трафик - меткой 1.

iptables -t mangle -A OUTPUT -m tcp -p tcp --sport 80 -j MARK --set-mark 2          
iptables -t mangle -A OUTPUT -m tcp -p tcp ! --sport 80 -j MARK --set-mark 1        

И мы будем использовать фильтр tc, который будет маршрутизировать пакеты, помеченные тегом, на конкретную полосу

tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 2 fw flowid 1:2    ### Send traffic from source port 80 to tbf queue
tc filter add dev eth0 protocol ip parent 1:0 prio 2 handle 1 fw flowid 1:1    ### Send all other traffic to sfq queue 1:1

И теперь мы готовы к тестированию. Я инициирую загрузку CentOS iso с http-сервера, и в то же время я инициирую sftp-передачу того же образа с того же сервера. На картинке ниже мы видим, что если скорость передачи sftp составляет около 13 МБ / с, то передача http ограничена 20 кбит / с.

В этом примере полоса 1: 3 даже не используется.
Так что, возможно, было лучше использовать tbf на диапазоне 1: 3 и иметь 1: 1 и 1: 2 с sfq и приоритетами по умолчанию. Однако это был всего лишь быстрый тест, и его должно быть достаточно, чтобы, надеюсь, прояснить немного более запутанную документацию по tc.

Используемые ресурсы:

• http://lartc.org/howto/lartc.qdisc.classful.html
• http://www.lartc.org/howto/lartc.qdisc.filters.html
• http://www.lartc.org/howto/lartc.adv-filter.html
• man iptables (в CentOS6 в CentOS 7 очень мало man для iptables, поскольку это больше не метод управления брандмауэром по умолчанию)

Простым методом может быть создание нескольких физических интерфейсов, каждый со скоростью 1 Гбит / с. Поместите один во внешнюю подсеть, а другой - во внутреннюю. mirror.example.com общедоступен, но mirror.corp.example.com находится только в локальной сети.

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

Кроме того, это гораздо менее точный контроль, чем вы просили. Вам может понадобиться что-то более сложное, если превышение целевого значения 650 Мбит / с небезопасно.

Поскольку архитектура apache распределяет нагрузку на множество различных процессов / потоков, я не думаю, что ограничение / приоритезация на уровне apache поможет.

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

К сожалению, я сам этого не делал, но я понимаю, что основной документ по этому вопросу - это инструкции по расширенной маршрутизации и управлению трафиком в Linux.

я верю http://lartc.org/howto/lartc.qdisc.html это соответствующая глава.

Если у вас это работает, пожалуйста, вернитесь и напишите ответ, подробно описывающий, как вы заставили его работать.