Назад | Перейти на главную страницу

Ограничение пропускной способности в Ubuntu Linux

Я нахожусь в ситуации, когда мне нужно моделировать P2P-среду (для моей магистерской диссертации по информатике). Для этого я использую Docker с Ubuntu для создания группы виртуальных машин, которые будут подключены к сети BitTorrent. Затем мне нужно убедиться, что скорость загрузки и скачивания одноранговых узлов может быть установлена, и я не могу делать это в клиенте (поскольку клиент использует спящий режим для имитации более низкой пропускной способности, что приводит к скачкам в ставка).

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

  1. Trickle Trickle, кажется, делает свое дело, но по какой-то причине, когда я запускаю более 5 контейнеров Docker, Trickle заставит многие из них выйти, не объясняя мне почему. Я пробовал разные настройки, но у вас не так много ручек, которые нужно повернуть, когда дело доходит до конфигурации, поэтому я не думаю, что Trickle будет вариантом в этом сценарии.
  2. Wondershaper Использование Wondershaper, похоже, работает или, по крайней мере, ограничивает пропускную способность. Единственная проблема здесь в том, что нет, казалось бы, понятной корреляции между значением, установленным в параметрах, и фактической пропускной способностью. Когда я настроил загрузку 2048 (что должно быть в килобитах), фактический диапазон загрузки колеблется от 550 до 900 КБ, что кажется действительно странным.
  3. tc Использование tc, как многие люди предлагают для аналогичных вопросов, действительно ограничивает пропускную способность, но независимо от того, какое значение я устанавливаю, оно всегда дает мне ту же пропускную способность (около 15-20 КБ / с).

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

Я ищу способ ограничить один экземпляр Linux, и тогда я смогу заставить это работать для нескольких контейнеров Docker.

--------------- РЕДАКТИРОВАТЬ----------------

Я пробовал несколько разных команд tc, но одна из них такая

DEV=eth0
tc qdisc del dev $DEV root
tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth 100mbit
tc class add dev $DEV parent 1: classid 1:1 cbq rate 256kbit allot 1500 prio  5 bounded isolated
tc filter add dev $DEV parent 1: protocol ip prio 16 u32 match ip src 0.0.0.0/0 flowid 1:1
tc qdisc add dev $DEV parent 1:1 sfq perturb 10

Независимо от того, какую скорость я установил, она всегда дает мне скорость загрузки около 12 КБ / с (загрузка по умолчанию без установленных ограничений составляет около 4 МБ / с)

------------ РЕДАКТИРОВАТЬ 2 (что я в итоге сделал) ------------

Оказывается, вы не можете надежно установить пропускную способность для контейнеров Docker внутри контейнеров, но всякий раз, когда вы создаете новый контейнер, на хост-машине создается виртуальный интерфейс, называемый vethsomething. Если вы используете, например, Wondershaper на этих виртуальных интерфейсах, ограничение будет иметь правильное поведение :)

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

У меня есть сервер, действующий как брандмауэр (он называется «брандмауэр» - очень творческий подход), а затем второй сервер за ним (называемый «mil102»). без каких-либо команд tc передача файла с mil102 на брандмауэр выполняется на полной скорости:

root@firewall:/data#scp mil102:/root/test.tgz test.tgz
test.tgz       100%  712MB  71.2MB/s   00:10

Добавление в mil102 следующих команд (проще сформировать отправку трафика):

#!/bin/sh
DEV=eth0
tc qdisc del dev $DEV root
tc qdisc add dev $DEV handle 1: root htb default 11
tc class add dev $DEV parent 1: classid 1:1 htb rate 4Mbps
tc class add dev $DEV parent 1:1 classid 1:11 htb rate 4Mbit
tc qdisc add dev $DEV parent 1:11 handle 11: sfq perturb 10

Теперь та же команда тормозит до 4Мб:

root@firewall:/data#scp mil102:/root/test.tgz test.tgz
test.tgz         0% 6064KB 467.0KB/s   25:48 ETA

Остановил передачу - слишком долго. Скорость, указанная в scp, указана в байтах, указана в tc в битах, поэтому 467 КБ * 9 = 4203 КБ, что близко к моему пределу в 4096 КБ (думал, что это будет * 8, но я предполагаю, что есть бит четности?).

Я попытался перейти на 10 Мбит, и мой scp показал, что я перемещаю данные со скоростью 1,1 МБ в секунду (1,1 * 9 = 9,9).

Последняя строка с директивой sfq perturb 10 была добавлена ​​для выравнивания потока трафика на загруженном соединении. Он направляет очередь принимать пакеты из каждого разговора на основе циклического хэша.

Вы можете протестировать как с, так и без - ssh на загруженной машине без него будет идти пачками, при этом будет намного плавнее (очень важно для VOIP). «Perturb 10» говорит ему пересчитывать алгоритм хеширования каждые 10 секунд, чтобы сделать его случайным.