На графике LB всё выглядит подозрительно: три backend’а работают, healthcheck зелёный, но один получает 80–90% запросов.
Проверять сам алгоритм балансировки недостаточно. В L4 балансировке решение часто принимается для соединения, а не для каждого запроса.
Для начала можно посмотреть распределение TCP-сессий на backend’ах:
ss -Htn state established '( sport = :443 )' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nrЕсли перекос уже здесь, проблема появилась до уровня HTTP.
Дальше интересно посмотреть, как LB выбирает backend для разных потоков. При ECMP или L4 hashing одинаковые параметры потока могут постоянно попадать в один и тот же bucket.
ipvsadm -Ln --stats
Для IPVS здесь хорошо видны реальные counters по backend’ам, а не только состояние healthcheck.
Ещё одна ловушка - connection reuse.
Несколько тысяч HTTP-запросов могут ехать внутри небольшого количества долгоживущих TCP-соединений.
ss -Htn state established | awk '{print $4}' | sort | uniq -c | sort -nr | headПоэтому RPS между backend’ами может отличаться в разы даже при идеально работающем алгоритме распределения соединений.
Если используется persistence, sticky sessions или hash по source IP, перекос становится ещё сильнее: несколько крупных клиентов фактически могут “забрать” один backend целиком.
И тогда проблема выглядит как сломанный балансировщик, хотя LB честно выполняет выбранную ему стратегию.
N.A.
