klink0v | Шейпирование трафика в Linux (Reply)

Есть у меня две технические площадки в двух разных ЦОДах. На одной помимо прочего размещены зеркала репозиториев и кеширующее docker registry. А на другой площадке зело худосочный канал, и оттуда клиенты периодически хотят что-нибудь стянуть или с одного, или с другого. И если у всяких там dnf и apt есть настройки, которыми можно ограничить их аппетиты касаемо download speed, то вот у доцкера ничего такого я найти не смог. Соответственно, вытягиванием докер-образа можно вполне неиллюзорно в одно рыло забить весь канал и ничего не оставить остальным.

Полез смотреть как линуксе делается шейпирование трафика. Блин, а там адЪ, Израиль и правый берег реки Иордан. Все эти дисциплины (QDisc), они же планировщики, иерархические очереди, классы трафика, токены, правила для Traffic Control (tc), IFB-устройства. Агр-р-р-р-рх, кабздец! Теперь я чуть лучше понимаю почему народ так любит всякие "специализированные" сетевые железки наподобие тех же Juniper-ов и прастихоспади Mikrotik-ов, где всё это делается одной-двумя строчками в конфиге.

Так-то понятно, что на самом деле надо один раз как следует разобраться, и всё это перестанет быть тарабарщиной. На как-то не хочется всерьёз "въезжать" во всё в это ради решения единственной "проходной" не самой критичной задачи.

Ради интереса глянул, тот же Nginx умеет ограничивать скорость отдачи. И в нём как раз это настраивается просто и понятно, но... только per-client. В том смысле, что если кто-то будет тащить с Nginx-а в два потока, например, то он и получит "два лимита". В принципе, применительно к docker registry наверное это вариант. Но так конечно тоже не ахти какое решение.

В разное время возникали проекты наподобие шейпирования в userspace через nf_queue, отдельный модуль ядра с nf_hook и питоновские скрипты, которые сами рулят tc-ом. Первый не прижился потому что его не вывозили CPU того времени, да и вообще не промышленное это решение (хотя я в свое время NeTAMS в таком режиме гонял, бггг). У второго функционал не то чтобы развесистый, а третий в основном под локальные процессы заточен. Короче говоря, ничего лучше чем tc+htb за много лет в линуксе так и не придумали. Да и с этими немного печалька, потому что требуют отключать TCP Segmentation Offload, иначе не будут работать.

Так что я всё-таки наверное посмотрю в сторону "включить шейпирование на Juniper-е". Если он конечно умеет такое на st-интерфейсах...