Ламповый чатик для своих людей: @devopsbrain_chat
Собрал в одном месте все самые полезные посты - изучайте, применяйте!
---
🔖 Полезные теги на канале
---
#ai #cicd #career #clickhouse #docker #dotnet #external_links #facts #fun #golang #github_actions #haproxy #kafka #linux #kubernetes #macos #management #networking #opentelemetry #proxmox #simulators #study #tools
------
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Сегодня поговорим как разогнать скорость передачи по сети на максимум всего за пару команд. В качестве примера представим, что у нас распределенная инфраструктура, которая живет в разных регионах. Также у нас есть какой то VPN между ЦОД-ами, который решает проблему связности ресурсов и безопасности. И есть требование: каждый час надо скачивать бекап на 50GB и разворачивать в другом регионе.
И вот вы настроили свой cronjob, запустили его и пошли пить чай и брать следующую таску в работу. Через какое то время обнаруживаете что скорость во время скачивания бекапа серьезно проседает, ну и плюс периодически могут теряться пакеты, а RTT вообще 30ms. И вот бекап уже даже за пару часов не может скачаться.
Это классическая история для алгоритма управления перегрузкой (Congestion Control Algorithms) CUBIC. Эти алгоритмы встроены в ядро операционных систем и работают автоматически, без вашего участия.
Но не все так плохо - Google начал придумывать более оптимальный алгоритм еще в 2016 и назвал его BBR (Bottleneck Bandwidth and Round-trip time). Алгоритм BBR проходит через несколько фаз, но для простоты можно выделить его основную логику:
1. Разведка: BBR периодически ненадолго увеличивает скорость отправки данных, чтобы проверить, не выросла ли пропускная способность канала (вдруг «трубу» расширили?).
2. Дренаж: После разведки он наоборот, немного снижает скорость, чтобы «осушить» возможные очереди из пакетов, которые могли скопиться в буферах маршрутизаторов, уменьшая задержку.
3. Стабильная работа: Основное время BBR работает на рассчитанной оптимальной скорости, которая обеспечивает максимальную пропускную способность при минимальной задержке.
Ключевое отличие в том, что CUBIC реагирует на потери, а BBR реагирует на изменения в сети (сравнение CUBIC и BBR на реальных устройствах от компании ESNet https://internet2.edu/wp-content/uploads/2022/12/techex22-AdvancedNetworking-ExploringtheBBRv2CongestionControlAlgorithm-Tierney.pdf)
BBR вы можете включить на свежих ядрах как Linux так и Windows:
# linux
echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p
# windows
NetTCPSetting | Select SettingName, CongestionProvider
netsh int tcp set supplemental template=Internet congestionprovider=BBR2
netsh int tcp set supplemental template=InternetCustom congestionprovider=BBR2
netsh int tcp set supplemental template=Datacenter congestionprovider=BBR2
netsh int tcp set supplemental template=DatacenterCustom congestionprovider=BBR2
netsh int tcp set supplemental template=Compat congestionprovider=BBR2
Где можно попробовать включать: между облаками/ЦОДами (NAT и VPN-шлюзы), а также конечные сервера где требуется просасывать большие объемы трафика.
На моей практике включение BBR на конечных серверах и VPN-инстансах дало буст по сетке x6. Но вы должны иметь ввиду, что BBR может быть довольно агрессивен по отношению к соседям использующим CUBIC - поэтому после включения стоит понаблюдать за ситуацией. А сравнить эффективность вы можете через
iperf3 -c YOUR_IP -t 60 -P 16.#linux #networking
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16
В практике иногда встречаются кейсы когда нужно проверить как себя ведет приложение при сетевых проблемах. На помощь спешит tc netem (аббревиатура от Network Emulator) — инструмент Linux для эмуляции сетевых проблем.
netem — это qdisc (queueing discipline) в Linux — часть подсистемы управления трафиком (tc из iproute2). Его задача симулировать реальные сетевые проблемы: задержки, потери пакетов, дубликации, неправильный порядок, ограничение пропускной способности и т.д.
Когда и зачем использовать
Тестирование протоколов — например, TCP или VoIP, если хочешь увидеть, как они ведут себя при потере и/или задержке.
Разработка приложений, чтобы убедиться, что сценарии “плохой сети” обрабатываются корректно.
Реалистичная нагрузка — эмуляция загруженных сетей или мобильных сетей, где часто бывают потери, задержки, “хвосты” задержек.
Добавить фиксированную задержку
sudo tc qdisc add dev eth0 root netem delay 100ms
Добавить задержку + джиттер с корреляцией
Эта команда, которая эмулирует не просто "плохую" сеть, а нестабильную сеть с "памятью". Гораздо ближе к реальным условиям (например, к мобильным сетям 3G/4G/5G или перегруженным каналам).
sudo tc qdisc change dev eth0 root netem delay 100ms 10ms 25%
delay 100ms средняя задержка, вокруг которой будут "колебаться" ваши пакеты. 10ms — джиттер (величина, на которую задержка может случайным образом отклоняться). В данном случае задержка каждого пакета будет выбираться случайным образом из диапазона от 90ms до 110ms (100ms ± 10ms). Без корреляции это были бы просто случайные, независимые друг от друга значения.
Корреляция 25% это параметр, который определяет, насколько задержка текущего пакета зависит от задержки предыдущего пакета. Без корреляции (0%) джиттер дает абсолютно случайные и независимые скачки задержки. Это не очень реалистично для многих реальных сетей. С корреляцией 25%: если предыдущий пакет имел задержку (например, 110 мс), то высока вероятность, что и следующий пакет тоже будет иметь задержку выше среднего. Таким образом мы получаем некий эффект "памяти" сети. Это дает более реальное поведение сетей для тестирования.
Добавить "нормальное" распределение задержек
Большинство пакетов получают задержку, близкую к среднему значению. Крайние значения (сильные отклонения) маловероятны, но возможны. Данный тип использует Гауссово распределение. Существуют и другие:`uniform`,
pareto, paretonormal.
sudo tc qdisc change dev eth0 root netem delay 100ms 20ms distribution normal
Потеря пакетов
sudo tc qdisc change dev eth0 root netem loss 20%
Дубликация пакетов
Эта команда инструктирует ядро Linux изменить текущие сетевые правила на сетевом интерфейсе eth0 так, чтобы он случайным образом дублировал 1% всех исходящих сетевых пакетов. Допустим, что ваше приложение отправляет 1000 пакетов. При включенном правиле duplicate 1%: ~990 пакетов дойдут до получателя в нормальном, единственном экземпляре. ~10 пакетов будут дублированы. Получатель получит их в двух одинаковых копиях, одна сразу за другой. Полезно при тестирование устойчивости протоколов и приложений. Например, как поведет себя кодек или игровой движок.
sudo tc qdisc change dev eth0 root netem duplicate 1%
Ограничение пропускной способности + учёт overhead
Использование overhead позволяет ограничить скорость именно на уровне полезных данных, которую увидит приложение, что критически важно для корректного тестирования пропускной способности. Для грубого ограничения "лишь бы было медленнее" можно использовать просто rate 5mbit, но для точных реалистичной эмуляции канала связи учет overhead обязателен.
sudo tc qdisc change dev eth0 root netem rate 5mbit 20 1500 5
rate 5mbit скорость полезной нагрузки
20 размер заголовков канального уровня (L2)
1500 размер MTU
5 размер в байтах сетевого и транспортного уровня (L3+L4)
Почистить за собой
sudo tc qdisc delete dev eth0 root netem
#linux #networking
Please open Telegram to view this post
VIEW IN TELEGRAM
👏8👍7🔥4