Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Быстрый вердикт: когда виноват dual-stack

Первое практическое правило простое: не тюньте модель, batching и GPU, пока не сравнили один и тот же запрос по IPv4 и IPv6. Разница между curl -4 и curl -6 — не финальный диагноз, но сильный локализатор. Если DNS-ответ, TLS-настройки и payload одинаковы, а connect или time to first byte расходятся только по семье адресов, зона поиска сужается до resolver policy, source address selection, маршрута, ACL, ICMPv6 и конкретного edge.

Happy Eyeballs делает пользовательский опыт лучше: клиент получает A и AAAA, формирует упорядоченный список адресов и запускает конкурирующие попытки с небольшим разносом. Победившее соединение остается, остальные отменяются. Поэтому общий request success может быть зеленым, хотя IPv6 неделями деградирует: IPv4 просто выигрывает гонку. Знакомая картина — synthetic check проходит, но мобильные клиенты или отдельный runtime дают длинный хвост latency из-за другой реализации алгоритма и иного пула соединений.

Квалифицирующий симптом для этого runbook: dual-stack hostname, непостоянная задержка до TLS или первого байта, различие между принудительными семьями либо расхождение по клиентским сетям. Disqualifier тоже важен: если -4 и -6 одинаково быстры на connect, но оба ждут первый токен, переходите к gateway и inference. Здесь поможет отдельный разбор L4/L7 proxy и SSE streaming, а не смена IP-стека.

• Сеть подозреваем первой, когда расходятся connect/TLS и выбранная семья.
• Приложение подозреваем первой, когда peer стабилен, а растут TTFT, очередь или partial responses.
• DNS failover не смешиваем с Happy Eyeballs: первый меняет набор адресов во времени, второй выбирает между доступными кандидатами в рамках соединения.

Как Happy Eyeballs выбирает путь и что скрывает

RFC 8305 описывает Happy Eyeballs v2 как последовательность из четырех фаз: асинхронное разрешение имени, сортировка адресов, запуск попыток подключения и отмена проигравших после установления одного соединения. Документ заменил исходный RFC 6555. Важно читать эту схему как клиентский механизм устойчивости, а не как доказательство здоровья IPv6.

Результат зависит не только от сети. Runtime решает, когда отправлять A и AAAA, как упорядочить кандидатов, какой интервал выдержать и можно ли переиспользовать уже открытое соединение. Например, актуальная документация curl описывает --happy-eyeballs-timeout-ms и текущий default libcurl 200 мс. Это не универсальная константа для всех приложений: браузер, Java, Go, Python-библиотека и service mesh могут вести себя иначе.

Мини-кейс. IPv6 SYN уходит в black hole, явного reject нет. Клиент ждет свой fallback delay, затем открывает IPv4 и успешно получает ответ. В метрике «request success» все хорошо, но к каждому новому connection добавляется задержка. Если keepalive живет долго, дефект проявляется всплесками после deploy, scale-out или ротации edge — именно тогда создаются свежие соединения.

Поэтому соберите три раздельные метрики: какую семью пробовали первой, какой remote peer действительно победил и что увидел пользователь. Без этой тройки спор «IPv6 или модель» превращается в угадайку. Общий обзор перехода на IPv6 объясняет базовые причины внедрения; здесь фокус уже: operational path selection для AI API.

Три evidence gate: DNS-кандидаты, фактический peer, outcome

Gate 1 — resolver evidence. Зафиксируйте A и AAAA с того же namespace, контейнера или node, где работает клиент. Ответ локального ноутбука не заменяет ответ pod resolver. Сохраняйте TTL и порядок получения ответов, но не делайте вывод о соединении только по DNS. AAAA в ответе означает «кандидат существует», а не «трафик пошел по IPv6».

Gate 2 — selected peer и path. Нужны remote IP, address family, interface/source address и точка TLS termination. У HTTP gateway может быть два плеча: client → edge и edge → inference. Первое способно работать по IPv6, второе по IPv4; агрегированная метрика скроет границу. Для каждого плеча назначьте owner: клиентская команда, platform, network или vendor edge.

Gate 3 — application outcome. Измерьте DNS, connect, TLS, time to first byte, time to first token, полную длительность и тип завершения stream. Первый байт HTTP-заголовков не равен первому токену, а успешный status не исключает обрыв после начала SSE. Сравнивайте одинаковый короткий запрос без повторов: retries превращают один сетевой сбой в несколько попыток и размывают картину.

Рабочий контрфакт выглядит так: принудительный IPv4 и IPv6 получают один DNS snapshot и одинаковый payload, но создают новые соединения. Если расходится connect — исследуем путь. Если connect одинаков, а расходится TLS — termination и crypto policy. Если оба этапа одинаковы, а TTFT разный, проверяем routing на втором плече, очередь gateway и backend selection. Этот порядок продолжает подход из материала про DNS failover для LLM API, но не повторяет его: здесь адреса стабильны, меняется победитель гонки.

• Положительный gate: выбранный peer и outcome совпадают с ожиданием.
• Отрицательный контроль: принудительная другая семья дает предсказуемо иной peer.
• Stop condition: нет возможности увидеть remote IP — сначала добавьте telemetry, затем меняйте policy.

Базовая диагностика на Linux без изменения production

Начните из effective namespace клиента. Для systemd service это может быть host, для pod — отдельный network namespace, для sidecar — еще одно transport-плечо. Один и тот же hostname с jump host и из приложения способен разрешаться через разные resolver и выходить через разные egress gateway.

Снимите DNS snapshot и серию чистых запросов. В команде ниже нет «магических» порогов: сравнивайте собственный baseline. Поля remote_ip, time_namelookup, time_connect, time_appconnect и time_starttransfer позволяют разделить этапы. Не используйте production API key в shell history; для проверки достаточно безопасного health endpoint или тестового tenant.

HOST=api.example.net
dig +short A "$HOST"
dig +short AAAA "$HOST"

for family in -4 -6; do
  curl "$family" --connect-timeout 5 --max-time 20     -sS -o /dev/null     -w 'peer=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} code=%{http_code}\n'     "https://$HOST/health"
done

Повторите серию с новым процессом или отключенным reuse там, где это допустимо: иначе вы измерите старое keepalive-соединение, а не выбор пути. Затем выполните обычный dual-stack запрос и сопоставьте его remote peer с принудительными тестами. Полезно временно увеличить детализацию client logs, но не логировать Authorization и пользовательские prompts.

Если -6 отвечает явным Network unreachable, зона поиска близка: адрес, route или policy. Если попытка молчит до timeout, проверьте firewall drop, недоступный next hop и ICMPv6. Если connect быстр, а TLS медленный, сравните SNI, certificate chain и termination point. А если первый токен тормозит при обеих семьях, не обвиняйте Happy Eyeballs: сеть уже прошла свой gate.

Где ломается IPv6-путь: route, NDP, firewall и PMTU

IPv6 — не «IPv4 с длинным адресом». На локальном сегменте Neighbor Discovery заменяет ARP, router advertisements влияют на маршруты и source address, а ICMPv6 выполняет критические функции. Фильтр «запретить весь ICMP» особенно опасен: он может сломать диагностику и Path MTU Discovery, оставив мелкие пакеты рабочими, а крупные TLS records или streaming traffic — зависающими.

Проверьте адреса и route в effective namespace, затем путь и PMTU. tracepath умеет выбирать -4/-6 и обнаруживать MTU вдоль пути без root. Однако отсутствие ответа от промежуточного hop не всегда означает разрыв: фильтрация diagnostic traffic возможна. Главный критерий — конечный application outcome плюс packet evidence на контролируемых точках.

ip -6 addr show
ip -6 route show
ip -6 route get 2001:db8::10
ip -6 neigh show

tracepath -6 api.example.net
ping -6 -c 3 api.example.net

На edge сравните счетчики firewall отдельно для IPv4 и IPv6. RFC 9099 подчеркивает operational reality dual-stack: вы управляете двумя стеками и должны поддерживать согласованные security policy. Типичная ловушка — разрешить TCP/443 в IPv4 ACL, забыть эквивалентное правило для IPv6 и получить silent drop вместо быстрого reject.

Для packet capture задайте узкое окно, host и порт. Увидели SYN/SYN-ACK по IPv6 — transport handshake прошел. SYN без ответа локализует дефект дальше по пути; отсутствие исходящего SYN указывает на resolver/address selection/runtime. TLS ClientHello без ServerHello переносит расследование к termination. Не храните payload: для этой задачи достаточно заголовков и timing.

sudo tcpdump -ni any 'host 2001:db8::10 and tcp port 443'
ss -tnp '( dport = :443 )'
nstat -az | grep -E 'Ip6|Icmp6|Tcp'

Dual-stack в Kubernetes: проверяем не YAML, а effective path

Kubernetes поддерживает dual-stack networking как stable feature с версии 1.23; актуальная официальная документация описывает SingleStack, PreferDualStack и RequireDualStack. Но поле в Service не гарантирует end-to-end готовность. CNI, node routes, cloud или bare-metal load balancer, firewall, egress и upstream DNS должны поддерживать выбранную семью.

Сначала прочитайте живой объект, а не manifest в репозитории. Порядок ipFamilies влияет на primary family Service, но клиентский runtime все равно может разрешать внешний hostname и выбирать адрес самостоятельно. Для egress к стороннему LLM API особенно важны node/pod source address и фактический gateway. Если используется FQDN policy, отделяйте этот слой от выбора соединения; подробнее — в runbook про Cilium FQDN egress, DNS cache и IP churn.

kubectl get svc llm-gateway -o jsonpath='{.spec.ipFamilyPolicy}{"\n"}{.spec.ipFamilies}{"\n"}{.spec.clusterIPs}{"\n"}'
kubectl get pod -o wide
kubectl exec deploy/llm-client -- sh -c 'getent ahosts api.example.net'
kubectl exec deploy/llm-client -- sh -c 'curl -4 -sS -o /dev/null https://api.example.net/health'
kubectl exec deploy/llm-client -- sh -c 'curl -6 -sS -o /dev/null https://api.example.net/health'

Canary pod должен иметь те же sidecar, DNS config, NetworkPolicy и resource limits, что production, иначе сравниваются разные системы. Проверьте оба направления: client → gateway и gateway → backend. В service mesh ingress может принять IPv6, а upstream cluster остаться IPv4-only — это нормальная архитектура, если она документирована и наблюдаема.

Не переводите Service сразу в RequireDualStack ради эксперимента. Начните с отдельного canary hostname или небольшого client pool. Stop condition — рост connect errors, несогласованный peer, пропажа telemetry или невозможность быстрого возврата. Dual-stack rollout ценен только тогда, когда отказ одной семьи не остается невидимым.

Runtime, DNS-кэш и connection pools: почему тест curl не равен приложению

curl — хороший диагностический скальпель, но production client живет дольше одного процесса. Он может кэшировать DNS, держать HTTP/2 connection, использовать proxy environment, собственный resolver или библиотеку, которая иначе реализует fallback. Поэтому положительный curl gate доказывает доступность пути из данного namespace, но не доказывает поведение runtime.

Составьте owner map: кто разрешает имя, кто сортирует адреса, где хранится DNS cache, кто создает connection pool и какой слой выполняет retry. Для каждого параметра запишите effective value из процесса или конфигурации, а не ожидание из документации. После deploy старые соединения могут продолжать идти к прежнему peer; тестируйте новые connection establishment отдельно от steady-state reuse.

Мини-кейс: приложение на Java держит несколько HTTP/2 connections, а synthetic curl запускается каждую минуту. После частичной деградации IPv6 curl быстро уходит на IPv4 и зеленеет. Java-пул продолжает переиспользовать ранее установленный IPv6 connection, где растут retransmits и stalls. Оба наблюдения честные, но отвечают на разные вопросы. Нужно связать connection id, remote peer и request outcome.

Не начинайте с уменьшения fallback delay. Маленький интервал может скрыть дефект еще лучше и увеличить число параллельных попыток. Сначала почините path или осознанно выключите неготовую семью на контролируемой границе. Таймаут — policy, а не лекарство. Аналогично, retries допустимы только для безопасных операций: повтор streaming request после partial response может задвоить работу и расходы.

• Соберите runtime/version и сетевую библиотеку.
• Проверьте proxy variables и sidecar interception.
• Разделите fresh connect и reused connection.
• Логируйте remote family без секретов и payload.
• Сопоставляйте client result с gateway request id.

Canary, rollout и rollback без самообмана

Надежный rollout начинается не с переключателя IPv6, а с baseline. Зафиксируйте распределение connect, TLS, TTFT, errors и выбранных peer для стабильного IPv4-пути. Затем создайте изолированный canary с тем же workload, версией клиента и endpoint semantics. Меняется одна переменная — доступность или приоритет IPv6.

Подавайте на canary повторяемый безопасный трафик. Не выдумывайте «нормальную» задержку: сравнивайте с собственным SLO и baseline. Сегментируйте результаты по node, zone, ISP/client network и runtime. Happy Eyeballs должен оставаться страховкой, но метрика fallback rate обязана быть видна. Рост IPv4 winners после включения IPv6 — не успех dual-stack, а сигнал, что новый путь проигрывает.

Failure drill нужен до расширения. Заблокируйте IPv6 только в canary-контуре и убедитесь, что клиент быстро и безопасно выбирает IPv4. Затем верните policy и проверьте, что новые соединения снова используют ожидаемый peer. Не ломайте production для теста и не вмешивайтесь в чужие сети. Для PMTU и VPN-сценариев полезна отдельная методика из статьи про WireGuard MTU и PMTUD.

Rollback должен быть симметричен rollout: тот же traffic slice, те же метрики, тот же наблюдаемый remote peer. Если после отката показатели не возвращаются, у вас остались connection pools, DNS cache или config drift. В таком случае rollout нельзя считать доказанным, даже если средняя latency стала ниже.

• Расширяем, когда обе семьи проходят path gate, policy симметрична, fallback rate объясним, application SLO сохранен.
• Останавливаем, когда есть silent drop, неизвестный peer, потеря telemetry или рост partial responses.
• Откатываем, когда canary не возвращается к baseline тем же измерением.

Когда отдельный VPS или dedicated edge действительно помогает

Коммерческий вывод здесь не «IPv6 требует новый сервер». По умолчанию инфраструктуру менять не нужно, пока не доказан bottleneck и его owner. Ошибочный AAAA, stale DNS, несимметричный ACL или connection reuse останутся ошибками и на более мощном железе. Это обязательный disqualifier.

Отдельный VPS или dedicated edge становится разумным, когда canary показал проблему на общей границе: вы не контролируете route policy, firewall lifecycle, версию proxy, telemetry или change window. Изолированный узел дает воспроизводимый network baseline, собственные IPv4/IPv6 policy, возможность packet capture, staged rollout и быстрый rollback. Ценность — в управляемости и ownership, а не в обещании меньшей latency.

Сравните три варианта. Оставить текущий shared edge — правильный default, если обе семьи проходят SLO и policy наблюдаема. Выделить VPS edge — полезно для небольшого controlled gateway, где важны отдельные ACL, адреса и быстрые изменения. Dedicated edge оправдан при высоком потоке, строгом change control, аппаратной сетевой политике или необходимости одинакового профиля между регионами. Managed load balancer остается хорошим выбором, когда provider прозрачно показывает health каждой семьи и поддерживает rollback.

Decision helper должен завершаться владельцем действия. Network team исправляет route/ACL; platform team — Service/CNI/egress; application team — resolver, pool и retry semantics; hosting provider — адресацию и edge path в своей зоне ответственности. Когда граница доказана, команда KingServers может помочь собрать отдельный VPS или dedicated baseline для canary, но acceptance criteria все равно задают ваши remote peer, fallback rate и application SLO.

Итоговый runbook: сначала докажите путь, потом меняйте policy

Happy Eyeballs — полезная защита пользователя, но плохой заменитель наблюдаемости. Он способен превратить сломанный IPv6 в «чуть медленный, зато успешный» запрос, поэтому обычный uptime не показывает реальное состояние dual-stack. Надежное расследование держится на трех доказательствах: какие A/AAAA получил клиент, какой peer и path действительно использован, что произошло с connect, TLS и первым токеном.

Начните с принудительных curl -4/curl -6 из effective namespace, затем подтвердите route, NDP, firewall и PMTU. После этого проверьте runtime: DNS cache, Happy Eyeballs policy, connection reuse и retries. В Kubernetes читайте live Service и проверяйте CNI, load balancer и egress end to end. Наконец, проведите canary с неизменным baseline и симметричным rollback.

Практический следующий шаг на сегодня: добавьте remote address family и peer в client или gateway telemetry, снимите десять безопасных fresh-connect проб по каждой семье и запишите owner каждого расхождения. Если обе семьи проходят SLO, ничего не усложняйте. Если одна системно проигрывает, у вас будет не ощущение, а конкретный участок пути, критерий исправления и понятный план отката.

Так dual-stack перестает быть фоновым источником случайности. Он становится двумя измеряемыми production-путями, каждый из которых можно тестировать, обслуживать и включать осознанно.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Почему FQDN egress ломается не там, где кажется

Типичный инцидент выглядит обманчиво просто: pod с inference-gateway вчера обращался к внешнему API по доменному имени, а сегодня часть запросов висит до таймаута. DNS из shell отвечает, сертификат валиден, соседний namespace работает. Команда расширяет CIDR, перезапускает CoreDNS или временно снимает policy, и связь возвращается. Причина при этом остаётся неизвестной, а следующий IP-rotation повторяет сбой.

В Cilium правило toFQDNs не является статическим allowlist домена. Агенту нужно увидеть DNS-ответ от конкретного endpoint, связать имя с адресами, обновить FQDN cache и materialize разрешение в effective policy. После этого новый TCP/TLS flow должен попасть под эту policy. Здесь минимум четыре разных состояния: ответ resolver, содержимое cache, политика endpoint и результат приложения. Зелёный индикатор на одном слое не делает зелёной всю цепочку.

Представьте сервис, который обращается к API провайдера через имя api.vendor.example. Провайдер меняет A-запись, JVM продолжает использовать старый адрес, а Cilium уже удалил его после TTL. Новый connection к старому IP будет отброшен, хотя имя в YAML написано верно. Обратный сценарий тоже возможен: приложение получило свежий IP, но DNS-запрос прошёл не через наблюдаемый proxy, поэтому адрес не появился в policy.

Поэтому default для расследования такой: не увеличивать TTL и не расширять egress «на всякий случай». Сначала докажите, где расходятся desired state, effective network state и application outcome. Этот подход отделяет ошибку selector от DNS lifecycle и не превращает временное восстановление в постоянную дыру.

Как toFQDNs превращает имя в разрешённый сетевой путь

Стандартный Kubernetes NetworkPolicy работает с pod selectors, namespaces, ports и CIDR. Он не задаёт переносимое правило «разрешить любой адрес, на который сейчас указывает это DNS-имя». CiliumNetworkPolicy добавляет FQDN-aware egress: matchName подходит для точного имени, matchPattern — для контролируемого шаблона. Но обе формы зависят от DNS visibility.

Рабочая цепочка начинается с DNS allow rule к вашему resolver. Запрос обычно идёт к CoreDNS на UDP/53, но production-клиент может использовать TCP при усечённом ответе, NodeLocal DNSCache или отдельный корпоративный resolver. Если policy разрешает только привычный kube-dns label, а workload фактически обращается к local listener, toFQDNs не получает исходное событие. Проверьте реальный destination, а не архитектурную схему в wiki.

После ответа Cilium хранит данные на нескольких уровнях. В документации описаны per-endpoint DNS cache, global cache и zombie mapping для адресов, чей TTL истёк, но существующие соединения ещё учитываются connection tracking. Это важно: «адрес исчез из свежего ответа» и «адрес немедленно запрещён для любого пакета» — не одно и то же. Новые соединения и уже установленные flows живут по разным правилам.

Наконец, FQDN selector должен превратиться в identities и попасть в effective policy нужного endpoint. Если labels не выбирают workload, pod работает с hostNetwork или запущен до корректной установки Cilium, вы исследуете не тот enforcement point. Официальная инструкция Cilium по troubleshooting прямо советует сначала убедиться, что pod управляется Cilium, а уже затем разбирать policy.

Снимите baseline до изменения policy

Хороший runbook начинается не с YAML, а с карточки инцидента. Запишите namespace, pod UID, node, service account, labels и Cilium endpoint ID. Затем из того же container network namespace получите A и AAAA, TTL, адрес resolver и время запроса. Не заменяйте этот шаг запросом с ноутбука: корпоративный DNS, split horizon и search domains легко дадут другой ответ.

Следом сохраните два Hubble-среза: DNS traffic на 53 и попытку соединения к API на 443. Для каждого нужны source identity, destination IP, verdict и drop reason. Третий снимок — effective policy endpoint. Desired CiliumNetworkPolicy из Kubernetes API показывает намерение, но не гарантирует, что selector выбрал именно этот pod и правило уже применено на его node.

Определите application outcome до эксперимента. Для streaming LLM API это может быть успешный TLS handshake, получение HTTP headers, первый SSE event и штатное завершение stream. Не смешивайте эти точки: быстрый connect без ответа модели доказывает только transport. В соседнем материале о HTTP/2 GOAWAY и graceful drain показано, почему connection event и судьба отдельного request не равны.

Нужен и отрицательный контроль. Оставьте один pod или namespace на прежней policy либо запросите заведомо неразрешённое имя. Если после изменения начинают проходить и целевой, и запрещённый destination, это не успех, а потеря границы. Отрицательный контроль особенно полезен при объединении нескольких additive policies: порядок правил не важен, разрешения складываются, и неожиданно широкий allow может прийти из другого объекта.

kubectl -n ai get pod inference-gateway-0 -o wide --show-labels
kubectl -n kube-system exec ds/cilium -- cilium-dbg endpoint list
kubectl -n ai exec inference-gateway-0 -- getent ahosts api.vendor.example
hubble observe -P --since 5m --namespace ai --pod inference-gateway-0
kubectl -n kube-system exec ds/cilium -- cilium-dbg fqdn cache list

Соберите минимальную CiliumNetworkPolicy без широкого allow

Минимальная policy должна отвечать на два разных вопроса: куда workload разрешено отправлять DNS-запросы и к какому FQDN разрешено подключаться. Это две egress rules, а не одна магическая запись. В DNS rule выбирайте фактический resolver и разрешайте DNS L7 rule только для нужных имён либо осознанно для более широкого набора. В FQDN rule задайте TCP/443, если провайдер действительно использует HTTPS.

Ниже — скелет, а не готовый универсальный манифест. Labels CoreDNS отличаются между дистрибутивами; NodeLocal DNSCache может потребовать entity или CIDR-модель, совместимую с вашей установкой. Точное имя предпочтительнее шаблона. Шаблон *.example.com не означает «example.com и все уровни поддоменов» во всех ожидаемых трактовках, поэтому проверяйте спецификацию и фактический match.

Не добавляйте IPBlock параллельно «для надёжности»: он маскирует ошибку DNS path и превращает динамический allowlist в ручной список. Если API публикует CDN-адреса, диапазон может быть большим и общим с чужими сервисами. Разрешение по CIDR снимает пользу domain-based boundary, а обслуживание такого списка становится вашим on-call debt.

После apply проверьте статус policy и endpoint, затем повторите ровно тот же запрос. В статье о PROXY protocol v2 для LLM API мы разделяли физического peer, заявленную metadata и effective identity; здесь логика похожа: имя в объекте, IP в cache и identity в datapath — самостоятельные факты.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: inference-api-egress
  namespace: ai
spec:
  endpointSelector:
    matchLabels:
      app: inference-gateway
  egress:
    - toEndpoints:
        - matchLabels:
            k8s:io.kubernetes.pod.namespace: kube-system
            k8s:k8s-app: kube-dns
      toPorts:
        - ports:
            - port: "53"
              protocol: ANY
          rules:
            dns:
              - matchName: api.vendor.example
    - toFQDNs:
        - matchName: api.vendor.example
      toPorts:
        - ports:
            - port: "443"
              protocol: TCP

Разберите TTL, FQDN cache и IP churn

Самый неприятный класс сбоев появляется не сразу после rollout, а через TTL. Cilium по умолчанию учитывает TTL DNS-ответа. Приложение при этом может кешировать адрес дольше, использовать собственный resolver или держать connection pool часами. Если после истечения TTL оно открывает новый connection к старому IP без нового DNS lookup, policy закономерно блокирует flow. Это не случайный drop: network state больше не подтверждает связь имени с адресом.

Сравните четыре времени: TTL в ответе, момент записи в per-endpoint cache, срок DNS-кеша runtime и возраст connection. Например, Java, Go, Envoy и sidecar могут иметь разные resolver semantics. Не переносите вывод из dig в поведение процесса без проверки. Внешний curl создаёт новый lookup и connection, поэтому часто «лечит» тест, который приложение продолжает проваливать.

Параметр минимального TTL Cilium может смягчить короткие TTL, но это компромисс, а не первая помощь. Слишком большой минимум задерживает отзыв адреса и расширяет окно, когда новый connection идёт к устаревшему backend. Прежде чем менять его, воспроизведите drop после TTL, подтвердите отсутствие повторного lookup и проверьте, что провайдер действительно допускает более долгую жизнь адреса.

AAAA — отдельная ветка. Workload может получить IPv4 и IPv6, а policy или инфраструктура поддерживает только один path. Happy Eyeballs скроет часть проблем, пока порядок адресов или latency не поменяются. Записывайте оба набора и Hubble flows по каждой семье. Похожая дисциплина описана в статье о DNS failover для LLM API, но здесь owner состояния — FQDN policy cache конкретного endpoint, а не только resolver и клиентское соединение.

Команда ниже полезна для корреляции, но формат вывода зависит от версии Cilium. На дату подготовки stable-документация показывает ветку 1.20.2; перед автоматизацией сверяйте CLI вашей установленной версии. Наличие IP в cache означает, что toFQDNs может построить identity, но не доказывает выбор endpoint или успешный application request.

Официальный разбор FQDN cache также описывает zombie mappings: истёкшие записи могут удерживаться, пока connection tracking считает адрес используемым. Поэтому простой подсчёт строк cache без временной шкалы даёт ложную уверенность.

Докажите решение через Hubble и effective policy

Hubble отвечает на вопрос «что произошло с flow на управляемом Cilium endpoint». Начните с DNS. Вы должны увидеть запрос и ответ между workload и resolver; при включённой DNS visibility доступны имя и response details. Затем отфильтруйте destination IP из ответа и TCP/443. Если DNS FORWARDED, а TLS DROPPED, проблема находится после resolution: cache, identity propagation, selector или port rule.

Если flow отсутствует, не делайте вывод «Cilium ничего не блокирует». Hubble Relay может не быть подключён к node, временное окно слишком узко, pod не управляется Cilium или traffic идёт через host network. Официальная инструкция Hubble предлагает сначала проверить status и connected nodes. Только после этого отсутствие события становится полезным фактом.

Effective policy следует читать для endpoint ID проблемного pod. Сопоставьте labels, policy revision и разрешённые identities. Kubernetes policies additive: другой allow может сделать эксперимент зелёным, а deny-модель Cilium — изменить итог в зависимости от выбранного формата и версии. Не ограничивайтесь сообщением «policy imported». Оно означает, что объект принят, но не описывает результат конкретного endpoint.

Application gate завершает доказательство. Для LLM streaming сохраните HTTP status, time to headers, time to first event, число завершённых streams и причины разрыва. Не приписывайте Cilium улучшение TTFT, если исчез только сетевой timeout. Сетевая policy управляет доступом; очередь inference, overload и backpressure остаются другими слоями. Для них уместен отдельный runbook про Envoy под перегрузкой LLM API.

hubble status -P
hubble observe -P --since 10m --namespace ai --pod inference-gateway-0 --protocol DNS
hubble observe -P --since 10m --namespace ai --pod inference-gateway-0 --port 443
kubectl -n kube-system exec ds/cilium -- cilium-dbg fqdn cache list
kubectl -n ai exec inference-gateway-0 -- curl -sS -o /dev/null -w '%{http_code}\n' https://api.vendor.example/health

Rollout и rollback: меняйте одну границу за раз

Не накатывайте новую egress policy сразу на все inference pods. Создайте canary label или отдельный deployment с тем же образом, service account, resolver и переменными окружения. Единственное различие — новая policy. Baseline должен остаться активным: он показывает, изменилась ли внешняя сторона одновременно с вашим экспериментом.

Сначала выполните positive control к разрешённому FQDN, затем negative control к соседнему запрещённому имени и прямому IP. Прямой IP особенно важен: toFQDNs relies on наблюдаемый DNS lookup. Если обход без lookup проходит, проверьте другие additive policies. После этого дождитесь как минимум одного естественного TTL transition или воспроизведите контролируемую смену адреса в тестовом домене, которым владеете.

Stop condition запишите до rollout. Например: любой рост сетевых timeouts canary относительно baseline, появление drops для разрешённого destination после свежего DNS response или прохождение запрещённого destination. При срабатывании не расширяйте правило на лету. Верните canary к предыдущему selector/policy и повторите те же DNS, cache, flow и application проверки.

Rollback считается успешным, когда восстановилось не только число запросов, но и прежняя граница доступа. Удаление policy может сделать все egress разрешённым и визуально «починить» приложение. Это не возврат к безопасному baseline. Сохраните YAML, policy revision и Hubble evidence до и после отката; иначе расследование останется рассказом без контрфакта.

Когда выделенная инфраструктура помогает, а когда нет

Выделенный VPS, dedicated edge или отдельный Kubernetes node pool полезны, когда вам нужен контроль над resolver, Cilium version, network path, firewall policy, Hubble retention и change window. На shared-платформе часть этих границ принадлежит провайдеру: вы видите application timeout, но не можете сопоставить его с datapath verdict. Собственный edge делает evidence chain воспроизводимой и уменьшает число неизвестных владельцев.

Это не означает, что новое железо исправит FQDN policy. Оно не починит stale DNS cache внутри приложения, ошибочный endpointSelector, connection reuse старого IP или отсутствие DNS visibility. Disqualifier простой: если canary на тех же node и network path проходит после исправления selector или resolver, capacity upgrade не является лечением.

Для небольшого сервиса разумный default — не усложнять. Оставьте обычный egress через контролируемый gateway, если команда не готова сопровождать Cilium CRD, Hubble и DNS lifecycle. FQDN-aware policy оправдана, когда внешний API меняет адреса, CIDR allowlist непрактичен, а domain boundary действительно нужна для compliance или ограничения blast radius.

Когда нагрузка и требования растут, сравнивайте варианты по ownership. Managed egress снимает часть on-call debt, dedicated gateway даёт версии и change windows, а отдельный Kubernetes pool добавляет полный datapath control. Коммерческий смысл KingServers здесь не в обещании меньшей latency, а в возможности закрепить предсказуемый network baseline для canary и расследований. Архитектурный контекст для такого выбора есть в руководстве про Private AI API на своих серверах.

Итог: доменное имя — начало доказательства, а не готовое разрешение

Cilium FQDN egress полезен именно там, где IP внешнего LLM API меняются, а широкие CIDR неприемлемы. Но надёжность появляется не от строки matchName. Её даёт цепочка доказательств: DNS-запрос прошёл через наблюдаемый resolver, свежий IP оказался в cache, identity попала в effective policy нужного endpoint, Hubble показал ожидаемый verdict, а приложение завершило реальный запрос.

Начните с baseline и отрицательного контроля. Затем примените минимальную policy к canary, дождитесь TTL transition и проверьте rollback теми же командами. Если ошибка остаётся, не расширяйте allowlist наугад: локализуйте owner между runtime DNS cache, Cilium endpoint и внешним API.

Практический следующий шаг прост: возьмите один некритичный deployment, сохраните DNS/cache/policy/flow evidence и проведите controlled rollout по чек-листу из статьи. Когда для этого не хватает контроля над resolver, datapath или change window, выделенный egress-контур становится обоснованным инфраструктурным решением — с ясной причиной и проверяемым результатом.

Rate limit внезапно блокирует всех пользователей сразу, а в audit log у каждого запроса один и тот же адрес load balancer. Для LLM API это не мелкая неточность: вы теряете границу tenant, разрешаете обход дорогих квот или останавливаете очередь из-за одного клиента. PROXY protocol v2 и X-Forwarded-For решают задачу только при правильно заданном доверии. Ниже — production-runbook: как выбрать механизм, настроить NGINX, Envoy и Kubernetes, доказать защиту от spoofing и провести rollout с отрицательным контролем.

Почему все запросы внезапно приходят с одного IP

Инцидент начинается не с сети, а с бизнес-симптома. Лимит срабатывает сразу для всех, аудит показывает адрес балансировщика, а расследование злоупотребления упирается в одну строку лога. Сам LLM отвечает, GPU загружен нормально, ошибки 5xx не растут — но контроль доступа уже работает не по тем субъектам.

Причина проста: TCP-соединение до приложения устанавливает последний proxy hop. Для ядра именно он является peer, поэтому приложение честно видит адрес NGINX, Envoy или load balancer. Реальный клиентский адрес существует раньше по цепочке и должен быть передан отдельным механизмом.

Для LLM API ошибка дороже обычной неточности. Запросы длинные, квоты считают токены или параллельные генерации, а один пользователь способен занять очередь. Если limiter ключуется по адресу общего proxy, шумный клиент блокирует всех; если приложение верит произвольному header, атакующий меняет IP и обходит лимит.

Сопоставьте три значения на canary-запросе: TCP peer на gateway, asserted address из metadata и effective IP, который попал в limiter и audit. Если поля смешаны, сначала чините trust boundary, а не увеличивайте лимиты.

Есть важный disqualifier: когда effective IP уже совпадает с клиентом, проблема может жить в API key, tenant mapping, NAT большого корпоративного пользователя или retry storm. Не переписывайте сеть без этого контрфакта.

Сначала нарисуйте trust boundary, потом выбирайте заголовок

Client IP — не факт из запроса, а утверждение конкретного узла. Оно заслуживает доверия, только когда получатель знает отправителя и исключил прямой обход. Выпишите каждый hop: интернет-клиент, внешний L4 LB, TLS termination, L7 proxy, ingress и приложение.

Для каждого ребра задайте три вопроса. Кто устанавливает TCP-соединение? Кто имеет право сообщить исходный адрес? Может ли клиент подключиться к получателю напрямую? Если да, X-Forwarded-For или PROXY header на этом listener становится способом spoofing.

Спецификация HAProxy требует принимать PROXY protocol только от доверенных прокси. Header идёт до HTTP и меняет представление о peer для всего соединения, поэтому ошибка влияет и на TLS audit, и на HTTP controls.

Практический default: доверяйте точным CIDR или security groups балансировщиков, закройте backend firewall-ом и логируйте физический peer вместе с восстановленным адресом. Не используйте всю приватную сеть как удобный allowlist.

Owner у каждого утверждения должен быть один. Если CDN добавляет XFF, WAF переписывает его, а ingress снова добавляет адрес, документируйте порядок и версию trust list. Иначе следующая миграция создаст тихую дыру.

PROXY v2, X-Forwarded-For или source IP: быстрый выбор

PROXY protocol работает на L4. Отправитель добавляет служебный header в начало нового соединения, а получатель читает source и destination до TLS или HTTP. Версия 2 бинарная, поддерживает IPv4, IPv6 и TLV. Это выбор для TCP load balancer или когда адрес нужен на TLS termination.

X-Forwarded-For и стандартный Forwarded принадлежат L7. Их проще читать, зато proxy должен понимать HTTP и очищать цепочку. Первый элемент не становится достоверным автоматически: алгоритм отбрасывает trusted hops и выбирает последний недоверенный адрес.

Source IP без metadata возможен, если маршрут не делает SNAT. В Kubernetes externalTrafficPolicy: Local сохраняет адрес, но обслуживает только node-local endpoints. Это обмен fidelity на свободу распределения, а не бесплатный флаг.

Не смешивайте механизмы на одном порту без ясного контракта. Listener, ожидающий PROXY header, не является обычным TLS listener: неверный клиент получит handshake failure. Раздельные адреса проще защищать и откатывать.

Выбор определяет owner: L4 metadata контролирует сетевой балансировщик, L7 header — HTTP edge, packet source — routing plane. Выбирайте механизм, чей owner действительно находится в вашей зоне изменений.

NGINX: принимаем PROXY protocol только от доверенного LB

В NGINX два шага независимы. Параметр proxy_protocol у listen заставляет сокет ожидать header. Модуль realip затем решает, можно ли заменить $remote_addr значением из него. Без allowlist адрес клиента превращается в пользовательский ввод.

ngx_http_realip_module сохраняет исходный peer в $realip_remote_addr, а $remote_addr после обработки содержит effective IP. Логируйте оба: одинаковые значения у трафика через LB укажут на неприменённый realip.

CIDR в примере нельзя копировать буквально. Он должен соответствовать вашим LB, а не всей RFC1918-сети. Перед reload проверьте, собран ли HTTP realip module, затем отправьте canary через LB и прямой запрос к backend — второй обязан быть заблокирован.

После восстановления адреса не добавляйте старую пользовательскую XFF-цепочку автоматически. Если NGINX становится authoritative edge, безопаснее сформировать header из проверенного $remote_addr по явному контракту.

Отдельно наблюдайте соединения без header и malformed header. Резкий рост после rollout часто означает, что health checks или один из upstream LB ходит на новый порт по старому протоколу.

http {
  set_real_ip_from 10.20.0.0/24;
  real_ip_header proxy_protocol;
  log_format identity '$request_id peer=$realip_remote_addr proxy=$proxy_protocol_addr effective=$remote_addr';
  server {
    listen 443 ssl proxy_protocol;
    access_log /var/log/nginx/llm_identity.log identity;
    location /v1/ {
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $remote_addr;
      proxy_pass http://llm_upstream;
    }
  }
}

X-Forwarded-For: очищайте цепочку, а не выбирайте первый IP

Клиент может сам прислать X-Forwarded-For. Внешний proxy должен удалить header и создать его заново либо добавить адрес так, чтобы следующий hop мог отбросить доверенную часть. Правило «брать первый IP» ломается, как только атакующий подставляет значение слева.

В NGINX сочетание real_ip_header X-Forwarded-For, точного set_real_ip_from и real_ip_recursive on ищет последний недоверенный адрес. Но результат верен только при полном списке proxies.

Для цепочки CDN → WAF → ingress → API составьте контракт: какой hop удаляет пользовательский header, какой добавляет адрес и какой вычисляет effective IP. Сохраняйте версию trust list рядом с request ID.

Если пропустить ingress, приложение увидит его адрес. Если доверить лишний CIDR, пользователь сможет влиять на identity. Эти два failure mode выглядят одинаково в одном поле client_ip, поэтому physical peer обязателен.

Rate limits и квоты становятся полезными после этого шага: дорогой LLM-запрос нельзя честно ограничивать по IP, пока происхождение IP не доказано.

set_real_ip_from 10.30.0.0/24;
set_real_ip_from 10.31.0.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
log_format xff '$request_id peer=$realip_remote_addr xff="$http_x_forwarded_for" effective=$remote_addr';

Envoy: listener filter раньше HTTP-фильтров

В Envoy PROXY protocol разбирается listener filter-ом до HTTP filter chain. После успешного разбора downstream remote address используется access log, RBAC и rate-limit integration. Обычное соединение без обязательного header отклоняется.

Документация Envoy описывает v1/v2 и counters для found, malformed, disallowed и missing. Опция allow_requests_without_proxy_protocol ослабляет контракт и годится только для полностью доверенного источника.

Proxy Protocol filter не равен Original Source filter. Первый извлекает координаты клиента. Второй использует downstream address как source upstream-соединения и требует capabilities и policy routing. Для IP-aware limiter чаще достаточно первого.

Canary доказывает три слоя: filter принял header; effective address попал в access log; приложение и limiter приняли то же значение. Счётчик found без application outcome ещё не успех.

Добавьте отрицательный контроль: соединение без header и соединение с запрещённой версией должны вести себя предсказуемо. Иначе permissive listener переживёт миграцию и станет постоянной дырой.

listener_filters:
- name: envoy.filters.listener.proxy_protocol
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.filters.listener.proxy_protocol.v3.ProxyProtocol
    disallowed_versions:
    - V1
    stat_prefix: llm_edge

Kubernetes: source IP без SNAT имеет цену

У Service с externalTrafficPolicy: Cluster пакет может попасть на node без нужного Pod и быть переслан с SNAT. Приложение увидит node address. Local ограничивает маршрутизацию локальными endpoints и сохраняет source IP, но node без endpoint отбрасывает трафик.

Официальный tutorial Kubernetes показывает компромисс. Для LoadBalancer Kubernetes выделяет healthCheckNodePort, чтобы внешний LB исключал nodes без локальных endpoints.

Представьте два gateway Pod на десяти nodes. Local сохранит IP, но только два узла примут запрос. Если LB шлёт на все десять, восемь путей становятся чёрной дырой. Проверяйте health-check membership и topology spread вместе.

Если LB уже умеет PROXY v2, иногда лучше передать metadata и оставить Cluster routing. Local оправдан, когда packet-level source IP нужен network policy или L4 audit, но тогда availability зависит от распределения Pod.

Архитектура private AI API помогает выбрать границу. Новое железо здесь не исправит неверный health check: сначала доказательство маршрута, затем capacity decision.

apiVersion: v1
kind: Service
metadata:
  name: llm-gateway
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  selector:
    app: llm-gateway
  ports:
  - name: https
    port: 443
    targetPort: 8443

Негативный контроль: докажите, что IP нельзя подделать

Положительный тест показывает, что механизм работает. Негативный — что им не может воспользоваться клиент. Отправьте через публичный endpoint поддельный XFF и убедитесь, что edge заменил его. Затем попробуйте backend напрямую: соединение блокируется до приложения.

Для PROXY protocol используйте canary из доверенной сети и источник вне allowlist на staging listener. Ожидаемый результат: trusted LB меняет effective IP, недоверенный peer не получает такой возможности.

Третий тест — рассинхронизация. Подайте разные адреса в PROXY metadata и XFF. Заранее выберите authoritative слой и создайте событие при конфликте. Молчаливый выбор превращает смену topology в уязвимость.

WAF, limiter и audit обязаны использовать одну identity. Атакующий найдёт самый слабый consumer. Материал про firewall, WAF и DDoS полезен как карта разных controls, но не заменяет trust boundary.

Повторяйте negative control после каждого изменения CIDR, LB pool или ingress. Это короткий synthetic test, который часто ценнее ещё одного dashboard: он проверяет именно невозможность обхода.

Наблюдаемость: храните доказательство, а не только итоговый IP

Один столбец client_ip удобен, но плох для расследования. Минимум — connection peer, asserted address, effective address, mechanism, trust-list version и request ID. Для HTTP сохраните исходную XFF-цепочку в защищённом логе, но не используйте её напрямую как ключ.

Не превращайте каждый IP в label Prometheus: кардинальность раздует series. Метрики считают accepted, missing, malformed, spoof attempt и mismatch, а конкретные адреса остаются в logs и traces с ограниченным retention.

Свяжите signal с outcome LLM API: 401/403/429, active streams, TTFT и завершённые ответы. После исправления identity 429 может вырасти правильно, потому что обход квот прекратился. Сравнивайте tenant behavior.

Различайте быстрый отказ до upstream и обрыв начатого stream. Первый защищает GPU, второй уже потратил compute. Runbook про Envoy overload раскрывает эту границу.

Для privacy сократите retention адресов и ограничьте доступ к raw chain. Доказательство доверия не означает бессрочное хранение персональных сетевых данных.

Rollout и rollback без потери контроля доступа

Начинайте с отдельного canary listener. Baseline использует старый путь, а canary пишет расширенный identity log и shadow-решение limiter. Не применяйте блокировки сразу: сначала сравните решения и причины расхождений.

Порядок rollout следует зависимости. Сначала sender формирует PROXY header или очищает XFF, затем receiver включает parsing на отдельном порту, после этого приложение меняет limiter key. Обратный порядок даёт handshake errors либо общий адрес proxy.

Stop conditions: рост malformed, missing identity на доверенном пути, mismatch gateway/app, потеря health-check nodes или рост незавершённых streams. У каждого условия должны быть owner и команда возврата.

Rollback симметричен: вернуть трафик на baseline, восстановить прежний ключ, проверить тот же canary и только затем отключать parser. Не оставляйте публичный permissive listener «на всякий случай».

Dedicated edge имеет смысл после доказанной причины: он даёт контроль firewall, версий и change window. Но новый сервер не исправляет spoofable header, неполный allowlist или небезопасную retry policy.

Итог: реальный IP начинается с доверенного пути

Надёжный client IP не появляется от одной директивы. Это цепочка: известный TCP peer, защищённый канал от trusted proxy, однозначный механизм, effective address в gateway и тот же ключ в приложении, аудите и limiter.

Default прост: L4 LB — PROXY v2 на закрытом listener; L7 — очищенный XFF с точным allowlist; Kubernetes Local — только когда вы готовы ограничить topology. Во всех вариантах bypass невозможен.

Не покупайте edge-сервер как лекарство от неверного trust list. Выделенный VPS или dedicated gateway уместен, когда нужны собственные firewall rules, контролируемые версии NGINX/Envoy и воспроизводимый canary.

Следующий шаг — протянуть один запрос через все hops. Зафиксируйте peer, asserted и effective IP, повторите с подделанным header и через rollback. Только после обеих проверок включайте реальные квоты.

Зафиксируйте эту проверку как регулярный regression test: после смены балансировщика, CIDR, ingress-контроллера или сетевой политики прогоняйте тот же positive/negative canary. Такой контроль быстро замечает drift до того, как он превратится в ложные блокировки или обход лимитов.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Что происходит с VPN и где проходит безопасная граница

Для инфраструктурной команды важно разделить три разных явления: ограничение доступа к конкретному сервису, деградацию определённого сетевого пути и общий сбой у оператора. Снаружи они похожи: туннель не поднимается, сессия обрывается, удалённый сотрудник теряет доступ к внутреннему AI API. Но выводы и ответственные стороны различаются.

Официальные и правовые источники подтверждают, что в России действуют меры против VPN-сервисов, не исполняющих требования законодательства. В письме Минцифры от 27 апреля 2026 года говорится о мерах против таких сервисов и возможности ограничения доступа при невыполнении требований. Одновременно критерии, действующие с 1 марта 2024 года, охватывают материалы, которые объясняют способы обхода блокировок, побуждают к нему или предлагают доступ к VPN именно для обхода. Поэтому эта статья не описывает способы обхода, маскировку трафика, смену портов, подбор протоколов для противодействия фильтрации и доступ к запрещённым ресурсам. Источники: письмо Минцифры и разъяснение о критериях.

Наша задача уже и практичнее: помочь владельцу легальной корпоративной системы понять, почему пропадает доступ к собственным ресурсам, какие доказательства собрать, как снизить зависимость от одного канала и как согласовать непрерывность с юристами, ИБ и провайдером. Это статья про resilience, а не про обход. Если организация работает в регулируемой отрасли или обрабатывает чувствительные данные, конкретную схему следует отдельно проверить с юридической службой.

Полезный первый вопрос: «Что именно недоступно и у кого?» Если не открывается один внешний ресурс, это одна история. Если из двух офисов и домашней сети одновременно недоступен ваш разрешённый корпоративный gateway, это уже инцидент доступности, которому нужны факты и владелец.

Почему отказ удалённого доступа особенно болезнен для AI API

В обычном веб-приложении пользователь иногда может дождаться восстановления или продолжить работу локально. В AI-контуре за одной точкой доступа часто стоят prompt gateway, хранилище документов, векторная база, GPU inference, аудит и система квот. Обрыв пути выключает не один экран, а целую рабочую цепочку: поддержка не получает подсказки, разработчик не проверяет модель, агент не завершает операцию.

Типичная ловушка — считать VPN самостоятельным продуктом. На практике это лишь транспортный слой. До первого токена запрос проходит через DNS, сеть оператора, точку удалённого доступа, проверку identity, policy engine, API gateway и очередь inference. Ответ затем должен вернуться по тому же или корректно согласованному пути. Сбой любого звена выглядит для пользователя как «AI не работает».

Составьте service map от пользователя до результата. Для каждого звена запишите владельца, SLO, способ проверки и допустимый fallback. Например, команда сети отвечает за достижимость gateway, IAM — за выдачу и отзыв identity, платформа — за AI API, владелец продукта — за корректность ответа. Эта карта отделяет отказ транспорта от истёкшего сертификата, ошибки авторизации, переполненной очереди GPU и проблем клиентского приложения.

Близкие материалы блога помогают развести уровни: архитектура Private AI API описывает сам сервис, а сравнение VPN, mTLS и IP allowlist показывает, какую identity доказывает каждый механизм. Здесь же фокус на непрерывности и управлении инцидентом.

Как отличить ограничение от обычного сетевого инцидента

Фраза «нас заблокировали» удобна, но плохо подходит для postmortem. Она объединяет разные причины и провоцирует рискованные изменения. Начните с воспроизводимого симптома: время, оператор, тип подключения, адрес разрешённого корпоративного endpoint, стадия соединения, доля затронутых пользователей и длительность.

Проверка должна быть безвредной и относиться только к вашей инфраструктуре. Используйте штатный клиент, официально разрешённый endpoint и согласованные тестовые учётные данные. Сравните офисную сеть, мобильного и фиксированного оператора, но не пытайтесь менять сигнатуру трафика или скрывать назначение соединения. Для каждого теста фиксируйте DNS-ответ, достижимость транспортной точки, успешность аутентификации и результат простого запроса к health endpoint собственного AI API.

Симптомы дают направление, а не окончательный вердикт. Timeout до gateway может означать маршрут, перегрузку, ACL, DDoS-защиту или ограничение на пути. Быстрый отказ после соединения чаще указывает на policy или authentication. Успешный вход с медленным первым токеном ведёт к очереди inference, модели или storage. Проверяли ли вы, что «сетевой» инцидент исчезает при обращении к тому же сервису из внутреннего сегмента?

Нужен и отрицательный контроль. Выберите другой разрешённый сервис на том же uplink и тот же AI API из доверенной внутренней сети. Если оба внешних сервиса деградируют, проблема шире VPN. Если внутренний запрос тоже медленный, смена доступа не вылечит GPU или базу. Такой контрфакт экономит часы и защищает от хаотичного тюнинга.

• Не делайте вывод по одному пользователю и одному оператору.
• Не смешивайте отказ соединения и отказ авторизации.
• Не принимайте успешный ping за доказательство работы приложения.
• Не меняйте прод без зафиксированного baseline и владельца rollback.

Карта зависимостей: USER → ACCESS → ID → AI API → OBS

Устойчивая архитектура начинается не со второго туннеля, а с границ ответственности. У пользователя есть устройство и локальная сеть. ACCESS отвечает за достижимость корпоративной точки. ID подтверждает личность или workload. AI API применяет авторизацию, квоты и маршрутизацию. OBS доказывает, что запрос действительно прошёл и дал приемлемый результат.

Эти уровни нельзя считать взаимозаменяемыми. Сетевой адрес не равен личности, наличие туннеля не означает право вызвать модель, а валидный токен не гарантирует достижимость endpoint. Если резервный транспорт автоматически наследует более широкие права, вы обменяли availability incident на security incident. Именно поэтому в плане непрерывности сначала фиксируют invariant: identity, least privilege, аудит и запрет прямого доступа к inference остаются неизменными.

Для каждого уровня запишите положительный и отрицательный тест. ACCESS: разрешённый endpoint доступен, а прямой origin закрыт. ID: активный сотрудник входит, отозванная credential отклоняется. AI API: тестовый запрос получает ожидаемый тип ответа, а запрос без scope — 403. OBS: событие видно в журнале с correlation ID, но секреты и содержимое чувствительных prompt не попадают в лог.

IETF в RFC 3809 рассматривает availability и stability VPN как отдельные требования и подчёркивает цену резервирования. Для практической команды вывод простой: разнообразие пути полезно только тогда, когда оба пути наблюдаемы, управляемы и не размывают модель доступа.

Observability до инцидента: что измерять без анализа содержимого

Если метрики появились после жалобы, команда уже работает вслепую. Нужен синтетический canary, который из согласованных точек проверяет ваш корпоративный endpoint и минимальный application outcome. Он не должен обходить контроль, передавать реальные данные или постоянно генерировать дорогие запросы к модели. Его задача — дать временную шкалу и разделить слои.

Минимальный набор включает успешность DNS, время установления транспортной сессии, результат аутентификации, HTTP-код health endpoint, latency gateway и отдельное время до первого токена тестовой модели. Добавьте operator/region label, но избегайте персональных данных. Для long-lived соединений отдельно учитывайте обрывы уже установленной сессии: они не видны в метрике connect success.

Не стройте детектор на одной средней. Пять минут полного отказа у одного оператора могут раствориться в глобальном 99,9%. Полезнее видеть долю ошибок по независимым vantage point, p95 установления сессии и число повторных подключений. Однако эти метрики не должны превращаться в обещание конкретного SLA без данных вашей системы.

Для AI workload добавьте очередь inference и saturation GPU. Иначе команда примет медленный первый токен за сетевую фильтрацию. Хороший alert отвечает на вопрос: «На каком слое началась деградация?» Плохой сообщает только: «VPN down». В материале про MTU и PMTUD для LLM API показан тот же принцип: низкоуровневый сигнал подтверждает механизм, а application canary подтверждает результат.

Практичная временная шкала

• T0: первый синтетический отказ и список затронутых vantage point.
• T+5: проверка gateway, IdP, сертификатов и внутреннего AI API.
• T+10: сравнение независимых операторов и открытие тикета провайдеру.
• T+15: решение incident commander по согласованному плану непрерывности.

Архитектура непрерывности без обхода ограничений

Правильный default — не изобретать «незаметный» протокол. Для законной корпоративной системы рассматривайте только согласованные каналы: операторскую корпоративную связность, частные межплощадочные услуги, доступ через разрешённые точки присутствия, локальную обработку критичных функций и организационные fallback-процессы. Конкретный выбор зависит от юрисдикции, договора, класса данных и заключения юристов.

Первый архитектурный приём — убрать единственную точку отказа за пределами вашей зоны контроля. Два gateway в одном дата-центре и один uplink не дают path diversity. Разные DNS-имена, ведущие в тот же балансировщик, тоже. Нарисуйте физический путь: last mile, оператор, межоператорское соединение, точка присутствия, firewall, identity и приложение. Затем спросите, какие элементы действительно независимы.

Второй приём — отделить доступ человека от server-to-server интеграций. Критичный batch, который вызывает частный AI API из вашего же серверного сегмента, не обязан зависеть от домашнего удалённого доступа сотрудника. Workload identity, отдельные квоты и service accounts уменьшают blast radius. Но не переносите пользовательские полномочия в безличный общий ключ: это разрушает аудит.

Третий приём — graceful degradation. Если AI-функция не является safety-critical, продукт может временно перейти в очередь, read-only режим или ручную обработку. Например, система поддержки сохраняет заявку и показывает оператору, что генерация подсказки задержана, вместо бесконечных retry. Это сохраняет данные и не создаёт шторм на gateway после восстановления.

Наконец, заранее согласуйте stop conditions. Если резервный канал не прошёл identity negative control, журналирование или проверку прямого origin, его нельзя активировать ради красивой зелёной метрики. Availability без security и compliance не считается восстановлением.

Runbook инцидента: DETECT → DECIDE → RECOVER

Runbook нужен не для того, чтобы автоматически менять сетевую схему при первом timeout. Его задача — быстро собрать факты, назначить владельца решения и восстановить разрешённый сервис предсказуемым способом. Incident commander должен быть один; сеть, ИБ, платформа, support и юристы дают ему данные в заранее оговорённом формате.

DETECT: зафиксировать симптом

Сохраните время начала, оператора, географию, тип сети и correlation ID тестов. Проверьте внутренний AI API, IdP, сертификат и доступность gateway из доверенного сегмента. Сравните не меньше двух независимых разрешённых vantage point. Не объявляйте причину до завершения этих проверок.

DECIDE: выбрать допустимое действие

Сверьте incident с юридически и технически утверждённой матрицей. Можно ли активировать заранее согласованный корпоративный канал? Должен ли продукт перейти в очередь или ручной режим? Кто уведомляет сотрудников и клиентов? Решение должно содержать scope, owner, время следующей оценки и stop condition. «Попробовать другой протокол» без согласования в такой матрице не является планом.

RECOVER: доказать результат

После изменения повторите ту же цепочку: ACCESS, ID, AI API, OBS. Проверьте положительный canary, отрицательный identity test и закрытый origin. Затем наблюдайте error rate, reconnect storm, очередь gateway и inference saturation. Возвращение одной сессии не означает восстановление сервиса.

Rollback симметричен rollout. Верните baseline тем же механизмом управления, повторите те же тесты и сохраните временную шкалу. Если переключение нельзя отменить контролируемо, его не следует выполнять в разгар инцидента. В postmortem отделите подтверждённые факты от предположений о внешней причине.

Право, безопасность и коммуникации: что нужно согласовать заранее

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

У плана должны быть три подписи: технического владельца, ИБ и legal/compliance. Технический владелец подтверждает работоспособность и rollback. ИБ проверяет identity, сегментацию, журналирование и секреты. Юристы оценивают назначение канала, контрагентов, трансграничную передачу данных, рекламу и применимые ограничения. Для персональных данных добавляется владелец privacy-процесса.

Коммуникация сотрудникам должна быть скучной и точной. Не отправляйте в общий чат непроверенные «лайфхаки» и ссылки на случайные клиенты. Сообщите статус, затронутые функции, разрешённый временный процесс, канал поддержки и время следующего обновления. Если доступа нет, так и напишите; не подталкивайте людей к самостоятельным экспериментам на рабочих устройствах.

Внешнее сообщение ещё строже. Называйте пользовательский эффект, а не недоказанную причину. Формула «часть пользователей из некоторых сетей не может подключиться; данные сохранены; работает ручной fallback; следующее обновление в 14:00» полезнее, чем «нас блокирует РКН», если подтверждения нет. Это снижает юридический риск и помогает support отвечать одинаково.

Храните решение об активации fallback рядом с incident timeline: кто разрешил, на каком основании, какие данные проходят по пути, когда решение истекает. Временное исключение без срока быстро становится постоянной дырой.

Когда помогают VPS, dedicated и операторская связность

Новая инфраструктура помогает только после доказанного bottleneck и понятной границы контроля. VPS может быть разумной площадкой для небольшого корпоративного gateway, synthetic probes или изолированного canary, если провайдер, юрисдикция и назначение соответствуют требованиям компании. Выделенный сервер полезен, когда нужны предсказуемый resource envelope, собственное change window и отсутствие noisy neighbor на сетевом или криптографическом контуре.

Но железо не исправляет всё. Новый dedicated server не лечит истёкший сертификат, ошибочную policy, retry storm, утечку соединений, перегруженную модель или юридически недопустимый сценарий. Два сервера за одним uplink не дают независимости. А перенос gateway без сохранения identity lifecycle способен увеличить риск сильнее, чем исходный downtime.

Операторская корпоративная связность часто дороже и медленнее внедряется, зато даёт договорную границу, техническую поддержку и возможность обсуждать SLA. Для критичных площадок это может быть сильнее случайного набора интернет-туннелей. IETF отдельно отмечает сложность гарантировать высокую доступность через нескольких провайдеров без согласования уровня сервиса; резервирование требует ресурсов и управления.

Практичный decision helper сравнивает варианты по пяти колонкам: owner пути, identity, data jurisdiction, change window и rollback. Добавьте стоимость on-call, а не только аренды. Чем больше независимых компонентов, тем больше сертификатов, журналов, тестов и людей должны работать ночью. Иногда лучший выбор — не усложнять сеть, а вынести критичный server-to-server workload внутрь контролируемого сегмента и дать пользователям graceful degradation.

При выборе площадки для AI-контура полезно отдельно оценить compute и access. GPU может жить на выделенном GPU-сервере, а gateway — на иной управляемой точке с меньшим blast radius. Не связывайте жизненный цикл модели и удалённого доступа одним изменением.

Как провести безопасное учение и не устроить настоящий outage

План, который существует только в документе, почти наверняка подведёт. Но учение не должно имитировать регуляторное ограничение методами сокрытия трафика. Достаточно контролируемо отключить один разрешённый тестовый путь в собственной среде или изолировать canary-группу на уровне вашего gateway. Цель — проверить людей, наблюдаемость и переключение, а не соревноваться с внешней фильтрацией.

Начните с tabletop exercise. Дайте участникам сценарий: часть сотрудников у одного оператора теряет доступ, внутренний AI API здоров, gateway доступен не со всех vantage point. Пусть команда назовёт владельца, первые четыре проверки, канал legal approval, сообщение пользователям и stop condition. Уже на этом этапе обычно находятся отсутствующие телефоны и непонятные полномочия.

Затем проведите технический canary на малой группе. Зафиксируйте baseline, окно, максимальную длительность и автоматический возврат. Проверьте не только connect success, но и identity negative control, application outcome, журналирование и закрытый origin. Если растёт очередь, появляются повторные подключения или теряется аудит, остановите тест.

Метрики учения должны описывать управляемость: время до обнаружения, время до правильной классификации, время до утверждённого решения, доля успешных canary, полнота журнала и время rollback. Не выдумывайте универсальные целевые минуты: они зависят от бизнеса и SLO. Важнее сравнить повторные учения одной команды и закрыть конкретные пробелы.

После возврата к baseline удалите временные исключения, отзовите тестовые credential, приложите логи к отчёту и назначьте владельцев action items. Проверяли ли вы, что временный fallback действительно выключен, а не просто перестал использоваться?

Вывод: устойчивость начинается с доказательств, а не с обходных приёмов

Ограничения работы VPN-сервисов и нестабильность отдельных путей — реальный риск для компаний, которые построили удалённый доступ к внутренним AI-системам вокруг единственного канала. Но безопасный ответ состоит не в поиске маскировки или очередного «неблокируемого» протокола. Он состоит в том, чтобы знать цепочку USER → ACCESS → ID → AI API → OBS, различать симптомы, заранее согласовать допустимые каналы и уметь доказать application outcome.

Начните с малого: нарисуйте service map, назначьте владельцев, добавьте два независимых canary и проведите tabletop exercise. Затем вместе с ИБ и юристами решите, нужна ли операторская связность, отдельный VPS, dedicated gateway, локальный server-to-server путь или всего лишь исправление сертификата и retry policy. Default простой: не меняйте инфраструктуру, пока не доказана причина.

Финальный дисклеймер: KingServers и автор не предлагают обход блокировок, доступ к запрещённым ресурсам или сокрытие назначения трафика. Материал посвящён только законной эксплуатации собственной инфраструктуры, безопасности и непрерывности бизнеса. Перед внедрением конкретной сетевой схемы проверьте актуальное законодательство, требования к данным и договоры с операторами.

Если вашей команде нужен контролируемый baseline для частного AI API, gateway или наблюдаемости, начните с инвентаризации workload и failure domain. Так разговор о VPS или выделенном сервере будет предметным: какой ресурс изолируем, какой SLO проверяем и как откатываемся. Хороший план непрерывности не обещает отсутствие инцидентов. Он делает следующий шаг понятным, разрешённым и проверяемым.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Почему LLM-шлюз перегружается не как обычный API

У обычного REST API запрос часто живёт миллисекунды или секунды. У LLM один SSE- или gRPC-поток держит соединение заметно дольше: ждёт первый токен, затем передаёт сотни небольших фрагментов. Поэтому QPS выглядит спокойным, а число активных streams, память буферов и занятые upstream-слоты уже растут. CPU Envoy ещё не достиг потолка, но новые запросы получают задержку, потому что старые не освобождают capacity.

Не настраивайте breaker по одному QPS. Зафиксируйте downstream active connections и streams, upstream active и pending requests, retries и пользовательский outcome: TTFT, межтокеновые паузы, долю завершённых ответов. Если растёт только TTFT при стабильных очередях Envoy, bottleneck, вероятно, внутри inference. Если растут pending и 503, шлюз уже видит дефицит upstream capacity.

Отдельно отметьте форму нагрузки. Короткий non-streaming запрос и длинный agent workflow занимают разные ресурсы, хотя оба дают единицу QPS. Полезная единица планирования — не только запрос, но и занятый stream во времени. Для расследования возьмите один повторяемый prompt, одну модель, фиксированный max_tokens и несколько заранее известных уровней concurrency.

Envoy разделяет два механизма. Circuit breaking защищает upstream-кластеры и быстро возвращает backpressure. Overload manager защищает процесс Envoy по давлению ресурсов. Они дополняют друг друга, но не заменяют admission control, который понимает токены, tenant-квоты и KV-cache.

Сначала найдите owner очереди и состояния

До изменения YAML нарисуйте фактический путь запроса: клиент, внешний балансировщик, Envoy, inference server и обратный streaming response. На каждом плече отметьте protocol, termination point, timeout, retry owner и место, где ответ считается начатым. Один и тот же «timeout на gateway» может быть downstream idle timeout, upstream response timeout или пауза генератора после отправленных HTTP headers.

Практический контрфакт: отправьте одинаковую небольшую нагрузку напрямую в inference endpoint и через Envoy. Если upstream TTFT одинаков, но через proxy появляются gaps между chunks, исследуйте buffering, flow control и downstream backpressure. Если обе траектории деградируют синхронно, breaker может ограничить ущерб, однако причиной остаётся GPU queue или scheduler. Transport lifecycle подробно разобран в материале про HTTP/2 GOAWAY и gRPC keepalive.

Для каждой гипотезы нужны три доказательства: состояние Envoy, фактическое состояние upstream и результат клиента. Успешный config reload доказывает только desired state. Нулевой pending при растущем TTFT не доказывает здоровье модели. Снижение 503 ценой зависших потоков ухудшает outcome. Такая цепочка удерживает команду от красивого, но неверного тюнинга.

Уточните также owner ретрая. Если запрос могут повторить клиентская библиотека, внешний gateway и Envoy, единичный отказ превращается в три новых попытки. Во время перегрузки это положительная обратная связь. Составьте таблицу: кто ретраит, по каким кодам, до какого commitment и с каким jitter. Всё неизвестное временно считайте риском amplification.

Соберите baseline: какие метрики смотреть

Начните с admin endpoint, но не публикуйте его наружу: интерфейс содержит служебные данные и поддерживает изменяющие операции. Envoy отдаёт Prometheus через /stats/prometheus. Для breaker полезны cluster..circuit_breakers..rq_open, rq_pending_open, rq_retry_open и overflow counters. Метрики remaining_* появляются только при track_remaining: true.

Снимайте baseline на повторяемом workload: одинаковая модель, длина prompt, max_tokens, streaming mode и concurrency. Нельзя сравнивать утренние короткие ответы с вечерними агентными цепочками. Отдельно маркируйте 503 с x-envoy-overloaded: это сигнал преднамеренного load shedding, а не обязательно авария upstream.

На application-стороне запишите TTFT, интервал между токенами, completion rate и число ответов, оборванных после headers. Последняя метрика критична: запрос мог получить HTTP 200, начать stream и всё равно не выполнить задачу. Для сети добавьте retransmits и queueing, чтобы не перепутать gateway pressure с транспортной очередью; здесь полезен runbook про BBR и fq для LLM-стриминга.

Собирайте percentiles и counts вместе. Средний TTFT может не измениться, если небольшая доля клиентов уже ждёт неприемлемо долго. А gauge breaker показывает состояние в момент scrape и легко пропускает короткие открытия. Поэтому рядом нужны counters overflow и rate за окно. Коррелируйте их с одним request id или trace, иначе совпадение графиков останется только предположением.

curl -fsS 'http://127.0.0.1:9901/stats?format=prometheus&usedonly' \
  | grep -E 'circuit_breakers|upstream_rq_(active|pending|overflow)|overload' \
  | tee "envoy-baseline-$(date +%s).prom"
curl -fsS http://127.0.0.1:9901/ready

Настройте circuit breakers по capacity, а не по догадке

В cluster thresholds есть отдельные пределы для connections, pending requests, active requests, retries и connection pools. Они применяются на кластер и priority. Значения по умолчанию не являются рекомендацией: лимит, нормальный для короткого API, может быть огромным для GPU worker с небольшим числом sequence slots.

Безопасный старт — измерить concurrency, при котором application SLO ещё держится, и поставить max_requests ниже точки резкого роста TTFT. max_pending_requests ограничивает очередь: небольшая очередь сглаживает короткий burst, длинная превращает быстрый отказ в дорогое ожидание. Длина очереди должна соответствовать времени восстановления, а не желанию избежать 503.

retry_budget предпочтительнее неограниченных параллельных ретраев, поскольку связывает retry capacity с активной нагрузкой. Но для streaming нельзя автоматически повторять запрос после application commitment: клиент мог получить часть ответа или tool-call. Если operation неидемпотентна, один ретрай способен продублировать действие даже без видимой второй генерации.

Disqualifier: circuit breaker не знает длину context, ожидаемые output tokens и состояние KV-cache. Два запроса для него одинаковы, хотя один занимает GPU в десять раз дольше. Когда capacity зависит от признаков запроса, добавьте admission logic выше или внутри inference gateway. Envoy останется сетевым предохранителем, а не планировщиком токенов.

Пределы должны быть различимы по tenant или workload, если трафик действительно неоднороден. Смешивание интерактивного чата и batch summarization в одном upstream cluster заставляет выбирать между плохой изоляцией и чрезмерным запасом. Иногда два кластера и две политики проще, чем «умный» общий breaker.

clusters:
- name: llm_upstream
  circuit_breakers:
    thresholds:
    - priority: DEFAULT
      max_connections: 128
      max_pending_requests: 32
      max_requests: 96
      retry_budget:
        budget_percent: { value: 10.0 }
        min_retry_concurrency: 1
      track_remaining: true

Защитите сам Envoy через overload manager

Breaker upstream может работать идеально, а процесс Envoy всё равно страдает от downstream connections, буферов и медленных клиентов. Overload manager наблюдает давление ресурса от 0 до 1 и связывает его с actions. Для контейнера рассмотрите cgroup memory monitor: он соотносит usage с cgroup limit. Fixed heap monitor доступен, но документация помечает его как механизм с ограниченным production burn time.

Выстраивайте ступени, а не кнопку паники. На раннем пороге можно перестать принимать новые streams на keepalive-соединениях; выше — прекратить новые requests; ещё выше — ограничить connections. reduce_timeouts способен сокращать timers, но для LLM-streaming это острый инструмент: агрессивный минимум закроет легитимный поток во время длинной паузы модели.

Memory limit должен отражать реальную границу контейнера. Если cgroup не имеет лимита, memory monitor может не дать ожидаемого pressure. С другой стороны, искусственно завышенный max_memory_bytes отодвинет защиту до OOM. Проверьте effective cgroup внутри того же namespace, где запущен Envoy, а не только значения deployment manifest.

Проверяйте семантику каждого action на вашей версии. На дату подготовки актуальная стабильная ветка Envoy — 1.39, а GitHub releases показывал 1.39.1 с security fixes. Не переносите пример из latest в старый binary без versioned docs. Patch-релизы вокруг HTTP/2, HTTP/3 и фильтров могут содержать security fixes.

Само срабатывание overload action не является успехом. Успех — процесс остаётся жив, новые запросы получают предсказуемый ответ, существующие потоки ведут себя согласно политике, а после снятия давления система возвращается в норму без ручного рестарта. Для этого нужны отдельные alarms на pressure, action state и application outcome.

overload_manager:
  refresh_interval: 0.25s
  resource_monitors:
  - name: envoy.resource_monitors.cgroup_memory
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.resource_monitors.cgroup_memory.v3.CgroupMemoryConfig
      max_memory_bytes: 2147483648
  actions:
  - name: envoy.overload_actions.disable_http_keepalive
    triggers:
    - name: envoy.resource_monitors.cgroup_memory
      threshold: { value: 0.90 }
  - name: envoy.overload_actions.stop_accepting_requests
    triggers:
    - name: envoy.resource_monitors.cgroup_memory
      threshold: { value: 0.95 }

Не ломайте SSE и gRPC: timeout, retry и partial response

У streaming-запроса есть как минимум три времени: ожидание первого байта, пауза между событиями и полная длительность. Один timeout скрывает различие. Route timeout, idle timeout и per-try timeout действуют в разных местах, а overload manager масштабирует только поддерживаемые timers. Проверяйте, какой таймер закрыл конкретное соединение.

Для SSE headers часто отправляются до завершения генерации. После первого chunk автоматический retry может создать второй ответ, повторить side effect tool-call или запутать клиентский state. Перед retry нужен idempotency и commitment gate: можно ли доказать, что upstream не начал значимую работу и клиент не получил результат? Для gRPC так же разделяйте connection event и outcome stream.

Не отключайте idle timeout бездумно. Envoy предупреждает, что этот timeout нужен при недоверенных downstream; ноль снимает защиту на уровне connection manager, хотя per-route override может остаться. Лучше выбрать предел по наблюдаемой максимальной межтокеновой паузе и отдельно ограничить абсолютную длительность бизнес-логикой.

Backpressure должен доходить до клиента. Если frontend без ограничений читает поток медленно, proxy хранит больше данных и memory pressure растёт независимо от GPU. Проверьте response buffering, flow-control windows и поведение клиента при 503 или reset. Тестовый клиент обязан читать с реалистичной скоростью: мгновенный /dev/null не воспроизводит мобильного пользователя.

Ловушки buffering, timeout и retries разобраны в статье про L4/L7 proxy для LLM API; здесь добавлен overload-контур. Не переносите решение между HTTP/1.1 SSE и HTTP/2 gRPC без проверки protocol boundary: connection reuse и stream accounting различаются.

Проведите canary с отрицательным контролем

Менять все пределы одновременно опасно: вы не узнаете, какой control сработал. Создайте отдельный listener, route или небольшой пул Envoy и отправьте туда повторяемую долю трафика. Baseline оставьте неизменным отрицательным контролем. На canary меняйте один слой: pending/request limits, затем retry budget, затем overload action.

У каждого шага три gates. Route acceptance: конфигурация применена, listener готов, запросы действительно попадают в canary. Effective state: открываются ли breaker gauges, растут ли overflow counters, срабатывает ли action при контролируемом давлении. Application outcome: сохраняются ли TTFT, completion rate и корректность streaming, а отказ приходит быстро и распознаваемо.

Сделайте failure drill. Создайте ограниченный burst, сократите capacity тестового upstream или используйте mock endpoint, но не экспериментируйте на общем GPU pool без stop condition. Ожидаемый результат: canary раньше baseline возвращает контролируемый 503 новым запросам, активные потоки не обрываются без политики, upstream queue не растёт без границы.

Не увеличивайте долю canary по времени. Условие перехода должно быть событийным: минимум два сопоставимых окна, отсутствие роста partial responses, подтверждённый breaker behavior и стабильный SLO. Если workload меняется между окнами, сравнение недействительно. Сохраните параметры генерации и распределение prompt lengths.

Затем выполните симметричный rollback и убедитесь, что те же метрики возвращаются в исходный коридор. Rollback, который только применил старый YAML, не завершён: runtime override мог остаться, connections могли не drain, а клиентский retry продолжит нагрузку. Нужны те же три gates в обратном направлении.

for host in baseline.example canary.example; do
  echo "== $host =="
  curl -sS -D /tmp/headers.txt \
    -H 'content-type: application/json' \
    --data '{"model":"test-model","stream":true,"messages":[{"role":"user","content":"health probe"}]}' \
    "https://$host/v1/chat/completions" >/dev/null
  grep -iE 'HTTP/|x-envoy-overloaded|retry-after' /tmp/headers.txt
done

Когда нужен отдельный VPS или dedicated edge

Инфраструктуру стоит менять после доказанного bottleneck и ownership boundary. Если Envoy живёт на shared VM, вы не контролируете noisy neighbor, memory limit, kernel settings или окно обновления, отдельный VPS для gateway создаёт воспроизводимый baseline. Dedicated edge оправдан, когда нужны предсказуемые CPU, NIC queues, большой connection fan-out и изолированный blast radius.

Сравнивайте варианты по контролю, а не ядрам. Shared VM подходит, если нагрузка мала, breaker не открывается, SLO стабилен. VPS даёт собственный cgroup envelope, версию Envoy и change window. Dedicated узел добавляет физическую изоляцию и свободу сетевого пути, но увеличивает долг: HA, обновления, spare capacity и дежурство остаются вашей ответственностью.

Сначала оцените failure domain. Один мощный gateway может выдерживать больше, но его restart затронет весь трафик. Два меньших узла дают canary и drain, однако требуют согласованной конфигурации, health checks и capacity на случай потери одного. Резерв должен считаться при отказе, а не только в нормальном режиме.

Главный disqualifier: новое железо не исправит client connection leak, retry storm, неверный idle timeout или очередь внутри vLLM. Сначала докажите pressure именно на gateway и повторите canary на том же workload. Если нужен стенд, инфраструктуру KingServers можно использовать как отдельный edge-пул рядом с GPU inference, чтобы закрепить hardware profile и проверить rollback без смешивания с production.

Коммерческое решение становится честным, когда описано через право изменения и наблюдаемость: кто обновляет Envoy, кто меняет kernel/network limits, где доступны admin stats, как изолирован canary и сколько длится rollback. Если эти ответы не требуют нового узла, не покупайте его ради красивого графика.

Короткий incident runbook и stop conditions

Во время инцидента задача не «подкрутить всё», а определить слой. Сначала сохраните stats и конфигурацию, затем сравните прямой upstream и путь через Envoy. Если memory pressure растёт только у proxy, ограничьте новый admission и проверьте downstream lifetime. Если pending растёт вместе с GPU queue, откройте breaker раньше и уменьшите retry amplification.

Если transport показывает loss или MTU-проблему, не лечите её лимитом запросов; для tunnel path используйте диагностику WireGuard MTU и PMTUD. Если растут TLS handshakes при стабильной application concurrency, проверьте connection reuse и session resumption по отдельному runbook про TLS handshake storm.

Stop condition: растёт доля оборванных после headers потоков, canary 503 неотличимы от ошибок upstream, retries увеличивают active requests, либо baseline outcome ухудшается. Верните runtime limits или предыдущий bootstrap, снимите повторные метрики и только потом меняйте следующую гипотезу. Rollback без проверки — команда, а не доказательство восстановления.

Коммуникация во время инцидента должна называть отказ честно. «Envoy перегружен» слишком расплывчато. Лучше: «pending breaker открыт для llm_upstream, новые requests получают локальный 503, активные SSE продолжаются, GPU queue стабилизируется». Такая формулировка сразу показывает owner, control и ожидаемый пользовательский эффект.

После стабилизации зафиксируйте capacity envelope: версию Envoy, protocol на каждом плече, предел active/pending, retry budget, memory limit, monitor, SLO и условия открытия breaker. Добавьте synthetic streaming probe с известным небольшим ответом. Следующая смена увидит механизм, границы и способ безопасного возврата.

Версии, безопасность и эксплуатационные оговорки

Не оставляйте admin interface доступным из клиентской сети. Он раскрывает имена кластеров, статистику и служебное состояние, а некоторые endpoints меняют процесс. Привяжите listener к loopback или management network, ограничьте доступ и собирайте Prometheus через контролируемый scrape. Публичный /stats превращает диагностику в источник информации для атакующего.

Версию Envoy фиксируйте в incident artifact вместе с image digest. На дату запуска последним стабильным релизом в официальном списке был 1.39.1; он включал security fixes, в том числе для HTTP/2 и HTTP/3. Это не означает, что всем нужно немедленно менять major/minor в инциденте. Сначала прочитайте release notes, проверьте совместимость filters и control plane, затем катите отдельным canary.

Поля конфигурации и experimental-статусы проверяйте в versioned docs. Страница latest может отражать development 1.40, поэтому рабочую ссылку для production review лучше закрепить на 1.39.1. Fixed heap monitor официально имеет оговорку про ограниченный production burn time; cgroup memory monitor тоже требует корректного cgroup limit.

Секреты, ключи и prompts пользователей не должны попадать в high-cardinality labels. Для расследования достаточно request id, tenant class и агрегированных length buckets. Не добавляйте raw prompt в Envoy access log ради удобства: это создаёт отдельный риск утечки, а под перегрузкой ещё и увеличивает I/O.

Вывод: сначала доказательство, затем предохранитель

Envoy помогает удержать LLM API в предсказуемом состоянии, если роли механизмов не смешаны. Circuit breakers защищают upstream и передают backpressure. Overload manager защищает процесс proxy. Application admission учитывает токены, контекст, tenant и реальную capacity модели. Один слой не заменяет остальные.

Начните с повторяемого baseline, разделите Envoy state, upstream state и пользовательский outcome, затем включайте controls по одному на canary. Сохраняйте отрицательный контроль и проверяйте rollback той же цепочкой метрик. Так контролируемый 503 становится полезнее медленного зависания, а новый сервер появляется только там, где нужна граница контроля.

Практический следующий шаг: снимите active, pending, retries, memory pressure, TTFT и completion rate на одном известном workload. Зафиксируйте версию Envoy и owner каждого retry. Этого набора хватит, чтобы первая настройка breaker была инженерным решением, а не гаданием.

Если потребуется изолировать gateway или canary-пул, заранее определите stop condition, capacity при отказе одного узла и способ возврата runtime overrides. Маленький доказанный rollout ценнее большого изменения, после которого команда видит только то, что графики стали другими.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Короткий вердикт: когда Inference Extension действительно нужен

Default-решение простое: не меняйте обычный Kubernetes Service, пока не доказали, что равномерное сетевое распределение создаёт перекос именно для LLM inference. Gateway API Inference Extension полезен там, где запросы различаются длиной prompt, состоянием KV cache, наличием LoRA-адаптера, очередью и стоимостью обработки. В таком пуле две формально одинаковые реплики через минуту уже находятся в разном состоянии.

Проект строит model-aware routing поверх Gateway API: HTTPRoute выбирает backend-пул, а Endpoint Picker (EPP) предлагает конкретный model-server endpoint. Официальная документация называет InferencePool стабильным API начиная с v1.0.0; актуальный на дату материала patch-релиз проекта — v1.6.2. Это важная граница: стабильность API не означает, что любая reference-реализация EPP автоматически готова к вашему production.

Qualifying condition — наблюдаемый hotspot: одна реплика копит pending requests или теряет cache locality, пока соседняя простаивает. Disqualifier — bottleneck в клиентском connection pool, gateway CPU, сетевой очереди, storage cold start или самой модели. Новая схема маршрутизации это не исправит. Если симптомы пока смешаны, начните с измерений и только потом добавляйте новый control plane.

Почему round-robin ломается на длинных LLM-запросах

Обычный балансировщик видит endpoints, readiness и соединения, но не знает, сколько токенов уже генерирует каждая реплика и насколько полезен её cache для следующего prompt. Короткий health check может быть зелёным, когда внутри model server уже растёт очередь. При SSE или gRPC streaming соединение остаётся занятым дольше обычного HTTP-запроса, поэтому счётчик соединений тоже не всегда отражает реальную работу GPU.

Представьте четыре vLLM-пода. На первый попали два длинных запроса с большим контекстом, на второй — серия коротких completion, третий держит нужный LoRA-адаптер, четвёртый только прогрел веса. Round-robin продолжит ходить по кругу. Model-aware picker может учитывать eligibility, queue state, cache или adapters, но только если production-реализация получает достоверные metrics and capabilities от model servers.

Не смешивайте network latency и model latency. В статье про BBR и fq для LLM-стриминга сетевой queue проверяется отдельно от TTFT. Здесь действует тот же принцип: снижение времени выбора endpoint ещё не доказывает снижение TTFT, а ровный GPU utilization не гарантирует отсутствие 5xx. Нужны независимые evidence gates.

Как устроен путь запроса: Gateway, HTTPRoute, EPP и InferencePool

Путь начинается привычно: Gateway принимает HTTP-запрос, а HTTPRoute выбирает backend. Если backend — InferencePool, gateway вызывает endpoint selection extension для этого пула. EPP оценивает доступный набор endpoints, возвращает один или несколько адресов, после чего data plane направляет запрос к выбранной реплике. Официальное описание request flow именно так разделяет ответственность маршрута и выбора конкретного model server.

InferencePool принадлежит platform owner: selector описывает группу однородных Pods, targetPorts — целевой порт, endpointPickerRef — связь с picker service. Один EPP относится к одному пулу, но HTTPRoute может ссылаться на несколько пулов. Это полезно для canary разных моделей или hardware profiles, однако backend failover и endpoint retry остаются разными механизмами; их нельзя объединять в один непрозрачный retry policy.

Endpoint Picker Protocol использует Envoy ext_proc. Для streaming EPP обязан поддерживать full-duplex обработку; выбранный endpoint передаётся data plane через согласованные header/metadata. Если список endpoints исчерпан, протокол предусматривает 503, а для осознанного shedding — 429. Практический вывод: gateway logs должны позволять связать request id, pool, выбранный endpoint и финальный backend, иначе схема неотлаживаема.

Есть ещё организационная граница. HTTPRoute обычно контролирует networking-команда, InferencePool — platform-команда, а model-server labels и adapters — ML platform. Если один владелец меняет selector, а другой не видит rollout модели, EPP получает технически валидный, но семантически неправильный набор endpoints. Зафиксируйте контракт labels и targetPorts так же строго, как API между сервисами: изменение label schema должно проходить canary и review обеих команд.

Версия v1.6.2: что стабильно, а что нельзя принимать за production default

На 21 сентября 2026 года последний release — v1.6.2. Он исправляет reference в conformance manifest и включает fixes Lightweight EPP из v1.6.1: порядок ext_proc stream events для chunked body, body mutation в FULL_DUPLEX_STREAMED и multi-arch сборку для linux/arm64. Если тесты запускаются с v1.6.1 manifest, они могли незаметно поднять образ v1.6.0; именно это исправлено в v1.6.2.

Главное изменение ветки v1.6 произошло раньше: полнофункциональные EPP, Body-Based Routing и Latency Predictor переехали в экосистему llm-d. Сам репозиторий GAIE сосредоточился на спецификациях, CRD и conformance, а LWEPP позиционируется как минимальная reference-реализация для проверки совместимости. Поэтому формула «установили официальный chart — получили production scheduler» неверна.

InferencePool v1 стабилен, а endpointPickerRef начиная с v1.5 может быть optional. Но поддержка omission зависит от конкретного gateway implementation. Проверяйте документацию controller, supported features и conformance report. Не полагайтесь только на то, что Kubernetes API принял объект: admitted resource ещё не доказывает, что data plane применил inference-aware behavior.

kubectl api-resources | grep -E 'InferencePool|HTTPRoute'
kubectl get crd inferencepools.inference.networking.k8s.io   -o jsonpath='{.spec.versions[*].name}{"\n"}'
kubectl -n inference-system get deploy,pod   -o custom-columns='KIND:.kind,NAME:.metadata.name,IMAGE:.spec.template.spec.containers[*].image'
kubectl get gatewayclass,gateway,httproute -A

Минимальная конфигурация: начните с однородного пула

Первый canary должен быть скучным. Возьмите одну модель, одинаковый accelerator type, одинаковый model-server image и один target port. Не добавляйте одновременно LoRA, heterogeneous GPU, prefix-cache routing и новый autoscaler: если результат изменится, вы не поймёте, какой механизм сработал.

Ниже — форма InferencePool из официального примера. Selector должен точно совпасть с labels model-server Pods. В примере FailOpen означает: если EPP не отвечает или не выбирает endpoint, gateway может отправить запрос к endpoint, выбранному своим fallback-механизмом. Это повышает availability, но скрывает деградацию model-aware routing, поэтому нужен отдельный alert на fallback.

apiVersion: inference.networking.k8s.io/v1
kind: InferencePool
metadata:
  name: vllm-qwen3-32b
  namespace: llm-canary
spec:
  selector:
    matchLabels:
      app: vllm-qwen3-32b
  targetPorts:
    - number: 8000
  endpointPickerRef:
    name: vllm-qwen3-32b-epp
    port:
      number: 9002
    failureMode: FailOpen

До привязки HTTPRoute проверьте три вещи: все выбранные Pods действительно готовы; EPP видит тот же набор endpoints; порт model server доступен с data plane. Типичная ловушка — selector выбрал лишнюю реплику из соседнего rollout или не выбрал ничего из-за различия labels. Проверяли ли вы фактический список адресов, а не только YAML в Git?

Для более общей архитектуры Kubernetes inference используйте материал про KServe, GPU Operator, Kueue и autoscaling. Здесь scope уже: мы меняем только путь выбора backend и сохраняем стабильный Service как контроль.

Три evidence gate: desired state, effective routing и application outcome

Успешный apply — это только desired state. Первый gate проверяет API: InferencePool существует, conditions не содержат отказа, HTTPRoute принят нужным parent и backendRef разрешён. Ошибка ReferenceGrant, неподдерживаемый group/kind или несовпадающий namespace должна остановить rollout до трафика.

Второй gate — effective state. Нужны logs или traces, где видны pool, вызов EPP, предложенный endpoint и endpoint, который фактически обслужил запрос. Протокол специально передаёт served endpoint обратно EPP, потому что data plane может идти по упорядоченному списку при retry. Если наблюдаемость показывает только «200 от gateway», вы не доказали работу picker.

Третий gate — workload outcome. Сравнивайте TTFT, inter-token latency, end-to-end latency, ошибки и saturation каждого model server. Добавьте negative control: тот же набор запросов через обычный Service. Если EPP меняет распределение endpoints, но SLO не улучшается, причина могла находиться в model compute, client concurrency или gateway path. Это нормальный результат эксперимента, а не повод придумывать выигрыш.

kubectl -n llm-canary get inferencepool vllm-qwen3-32b -o yaml
kubectl -n llm-canary describe httproute llm-canary
kubectl -n llm-canary logs deploy/vllm-qwen3-32b-epp --since=10m
curl -sS -D /tmp/canary.headers   -H 'content-type: application/json'   --data @request.json https://canary.example/v1/chat/completions
curl -sS -D /tmp/baseline.headers   -H 'content-type: application/json'   --data @request.json https://baseline.example/v1/chat/completions

Canary rollout: меняйте один routing layer за раз

Безопасный rollout строится рядом с текущим path. Оставьте baseline HTTPRoute на Service, создайте отдельный hostname или header match для InferencePool и подайте небольшой репрезентативный поток. Canary должен включать короткие и длинные prompts, streaming, cancellation и запросы к моделям/адаптерам, которые реально используют клиенты.

Не начинайте с процента трафика, который невозможно быстро отличить в telemetry. Удобнее отдельный route key, tenant или тестовый hostname: так каждый request однозначно относится к canary. Затем можно перейти к weighted routing, если controller поддерживает нужный сценарий. Stop conditions задайте заранее: рост 5xx/429, ухудшение TTFT относительно baseline, EPP not ready, рассинхронизация endpoints или повторяющийся fallback.

Rollback должен быть симметричным: вернуть backend на Service, убедиться, что новые запросы идут по baseline, дождаться drain активных streams и повторить тот же application probe. Не удаляйте EPP первым: вы потеряете evidence о текущих запросах. Подход похож на graceful drain в runbook по HTTP/2 GOAWAY и gRPC keepalive: сначала перестаём назначать новую работу, затем наблюдаем завершение уже принятой.

kubectl -n llm-canary patch httproute llm-canary --type merge   -p '{"spec":{"rules":[{"backendRefs":[{"name":"vllm-baseline","port":8000}]}]}}'
kubectl -n llm-canary get httproute llm-canary -o yaml
kubectl -n llm-canary logs deploy/vllm-qwen3-32b-epp --since=5m
curl -sS --data @request.json   -H 'content-type: application/json'   https://canary.example/v1/chat/completions

Какие метрики отделяют хороший picker от красивой схемы

Метрики делятся на четыре слоя. Gateway layer: request rate, 4xx/5xx, upstream connect failures, ext_proc latency и timeouts. EPP layer: decisions, eligible endpoints, pick errors, fallback, readiness и возраст данных. Model-server layer: running/pending requests, KV-cache pressure, tokens per second и cancellations. Application layer: TTFT, inter-token latency, completion success и пользовательский timeout.

Связь между слоями важнее отдельного dashboard. Например, TTFT растёт, EPP быстро отвечает, но pending requests концентрируются на одном pod. Это указывает на eligibility/scoring или stale metrics. Другой случай: распределение ровное, но ext_proc latency выросла — bottleneck появился в control path. Третий: gateway и EPP здоровы, а все GPU насыщены; маршрутизация уже не создаст capacity.

Добавьте trace attributes: pool, requested model, selected endpoint, served endpoint, fallback reason и rollout cohort. При этом не пишите prompts и чувствительные payloads в обычные логи. Для host/network диагностики полезен eBPF observability, но eBPF подтверждает transport/kernel mechanism, а не качество выбора модели. Application canary остаётся финальным доказательством.

Failure modes: FailOpen, 429, 503 и stale state

FailOpen сохраняет доступность, когда EPP недоступен, но gateway теряет интеллектуальный выбор. Это разумный default для первого canary, если fallback endpoint безопасен. Цена — silent degradation: без метрики fallback команда может неделями считать, что model-aware routing работает. FailClosed лучше сохраняет семантику policy, но превращает EPP в жёсткую зависимость request path.

429 и 503 означают разные вещи. 429 может быть осознанным load shedding при тяжёлой нагрузке; клиенту нужен ограниченный retry с backoff и idempotency. 503 используется, когда подходящих endpoints нет. Бесконтрольный retry обоих кодов создаёт feedback loop: очередь растёт именно из-за реакции клиента. Укажите retry owner и budget на одном уровне, а не одновременно в SDK, gateway и service mesh.

Stale state опаснее явного падения. EPP отвечает быстро, но принимает решение по старым queue/cache данным. Проверяйте age метрик и сравнивайте picked endpoint с фактическим served endpoint. Ещё одна ловушка — mixed versions: CRD уже новая, controller старый, а data plane не поддерживает поле или режим streaming. Именно поэтому version lock должен включать API, controller, gateway и router images.

• Нет ready endpoints: остановить canary и проверить selector/readiness.
• EPP not ready: проверить datastore sync и leader state.
• 500 на chunked streaming: сверить ext_proc implementation и patch release.
• Рост 429: отделить корректный shedding от stale saturation signal.
• Fallback без алерта: считать это дефектом observability.

Отдельно проверяйте cancellation. Пользователь может закрыть streaming response, но backend продолжит генерацию, если отмена не проходит через gateway и model server. Тогда endpoint выглядит занятым, хотя с точки зрения клиента запрос уже исчез. Такой «невидимый» compute меняет queue metrics и вводит picker в заблуждение. В canary включите раннее закрытие соединения и убедитесь, что served endpoint освобождает ресурсы.

При multi-backend HTTPRoute не переносите endpoint list между пулами. Endpoint Picker Protocol привязывает упорядоченный список к конкретному InferencePool; если route-level failover выбирает другой pool, data plane должен вызвать его EPP заново. Иначе retry может попасть на endpoint с другой моделью или hardware policy. Это особенно важно при blue-green версии модели, где оба пула отвечают на совместимый API, но имеют разные weights или adapters.

Service, InferencePool или llm-d router: практическая матрица выбора

Service остаётся лучшим вариантом, когда replicas действительно взаимозаменяемы, нагрузка короткая, cache locality не влияет на SLO, а команда не готова владеть дополнительным control path. Это не «упрощённая» архитектура, а корректный выбор при отсутствии qualifying condition.

InferencePool с минимальной реализацией полезен для conformance, лаборатории и проверки совместимости gateway. Он показывает API flow, но не заменяет production scheduler. Официальная документация прямо рекомендует для production собственный EPP или существующую реализацию, например llm-d-router.

Production router нужен, когда ценность доказана: model-aware eligibility, queue/cache signals, LoRA placement, приоритеты или сложный rollout. Вместе с возможностями вы получаете ownership версий, metrics freshness, failure policy, capacity EPP и on-call. Не выбирайте самый сложный вариант только потому, что он «AI-native».

Коммерческий вывод тоже должен быть честным. Выделенная инфраструктура полезна, когда нужно закрепить hardware profile, изолировать canary, контролировать network path и повторять тесты на предсказуемом GPU/CPU baseline. Но новый сервер не исправит stale metrics, ошибочный selector, unsafe retry или отсутствие client pooling.

Где заканчивается routing и начинается capacity planning

Model-aware routing перераспределяет работу, но не создаёт GPU memory, compute и network bandwidth. Если все replicas одновременно близки к saturation, picker лишь выбирает наименее плохой endpoint. Capacity plan должен учитывать модель, максимальный контекст, concurrency, KV-cache budget, batch policy и headroom на отказ одной реплики.

Разделите capacity gateway/EPP и model servers. Gateway может упереться в CPU, TLS, ext_proc connections или streaming buffers раньше GPU. EPP может требовать собственный HPA и PodDisruptionBudget, но масштабирование picker не должно менять смысл scoring. Model servers масштабируются по другой причине: pending requests, latency и accelerator pressure. Один общий CPU-based HPA для всей схемы обычно скрывает причинность.

Для private AI API добавьте границы доступа, quotas и tenant attribution; общий план разобран в материале о внутреннем аналоге OpenAI API. Здесь Inference Extension — только routing layer. Auth, billing, content policy и data governance остаются выше него.

На VPS удобно держать management-компоненты, тестовый gateway и observability, если нагрузка это позволяет. GPU model servers чаще требуют выделенного predictable hardware. Выбирайте инфраструктуру после canary evidence: сначала докажите bottleneck и нужную границу контроля, затем закрепляйте конфигурацию как воспроизводимый baseline.

Production-чеклист: что должно быть записано в runbook

Runbook обязан отвечать не только «как установить», но и «кто принимает решение при деградации». За API/CRD, gateway controller, EPP/router и model servers могут отвечать разные команды. У каждой зависимости нужен owner, версия, сигнал readiness, alert и способ отката.

• Version matrix: Kubernetes, Gateway API, controller, GAIE CRD, router и model server.
• Resource ownership: кто меняет InferencePool, HTTPRoute и scoring policy.
• Evidence chain: accepted object, effective picked/served endpoint, application SLO.
• Stop conditions: 5xx/429, EPP readiness, metric age, TTFT delta и fallback rate.
• Rollback: Service backend, drain, проверка baseline и сохранение incident bundle.
• Security: mTLS/NetworkPolicy для control path, минимальные RBAC и защита telemetry.
• Capacity: headroom gateway, EPP и GPU проверяются раздельно.

Сохраните before/after evidence: manifests, conditions, image digests, короткий срез logs, route status и результаты canary probes. Это сокращает спор во время инцидента. Через месяц команда должна суметь доказать, почему traffic идёт через InferencePool, а не просто обнаружить это по имени ресурса.

Проведите game day до расширения трафика: остановите EPP, сделайте один model server NotReady, задержите metrics source и верните старый HTTPRoute. Команда должна заранее увидеть ожидаемые сигналы и пройти rollback без редактирования manifests на ходу. Если fail-open выбран осознанно, тест обязан показать не только доступность API, но и явный alert о потере model-aware decisions.

Наконец, не смешивайте rollout приложения и rollout routing. Обновление модели, container image и InferencePool в одном change window делает rollback неоднозначным. Сначала стабилизируйте model servers за обычным Service, затем меняйте path выбора endpoint. При следующем обновлении повторите порядок: working baseline, canary нового слоя, evidence, расширение трафика.

Вывод: сначала доказательство, затем умная маршрутизация

Gateway API Inference Extension решает реальную проблему LLM-пулов: network-level round-robin не видит queue, cache, adapters и фактическую стоимость запроса. InferencePool v1 даёт стабильную Kubernetes-модель ресурса, а EPP добавляет выбор endpoint. Но в актуальной ветке v1.6 важно не перепутать спецификацию и conformance tooling с готовым production scheduler.

Начните с одного однородного пула и отдельного canary route. Зафиксируйте версии, проверьте API desired state, затем picked/served endpoint и только после этого TTFT, ошибки и saturation. Обязательно держите обычный Service как negative control и rollback path. Если улучшение не повторяется на application layer, вернитесь к baseline: возможно, bottleneck находится в client, gateway, сети или GPU capacity.

Следующий практический шаг — взять один реальный workload trace, прогнать его через Service и InferencePool и заполнить checklist из статьи. Когда evidence показывает устойчивый выигрыш и понятную границу владения, закрепляйте production router и подходящий infrastructure baseline. Если нужен изолированный стенд или предсказуемый GPU/сетевой профиль для такого canary, команда KingServers поможет подобрать конфигурацию без обещаний «ускорить всё» до измерений.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

GOAWAY не равен аварии: сначала прочитайте frame

HTTP/2 GOAWAY — это frame уровня соединения. По RFC 9113, раздел 6.8, endpoint отправляет его, когда перестаёт принимать новые streams на текущем connection, но может закончить уже начатые. Поэтому запись received GOAWAY без error code, Last-Stream-ID и точки отправки почти бесполезна: она сообщает о событии, но не о причине.

Смотрите на три поля. NO_ERROR часто сопровождает плановый drain или ограничение возраста соединения. ENHANCE_YOUR_CALM вместе с debug data too_many_pings указывает на несовместимую keepalive policy. PROTOCOL_ERROR, FLOW_CONTROL_ERROR и другие коды требуют проверки конкретного hop и реализации. Last-Stream-ID отделяет streams, которые могли быть обработаны, от тех, которые endpoint гарантированно не принял.

Мини-кейс: во время rolling restart два клиента видят GOAWAY/NO_ERROR. Первый бесшовно открывает новый connection, второй роняет streaming RPC. Причина не в самом GOAWAY, а в том, что второй клиент не умеет корректно пережить drain уже начатого вызова. Главный вопрос к инциденту: что произошло с конкретным RPC, а не «почему сервер прислал GOAWAY».

Найдите владельца каждого HTTP/2 connection

В production один логический запрос обычно проходит несколько transport-плечей: клиент → edge/LB, edge → gateway, gateway → inference backend. На каждом плече свой HTTP/2 connection, свои PING, idle timeout, max connection age и drain. Настройка gRPC-клиента не меняет upstream connection Envoy, а TCP keepalive в NGINX не заменяет gRPC HTTP/2 PING. Пока команда не нарисовала эти границы, она меняет параметры наугад.

Составьте карту: кто инициирует connection, где завершается TLS, какой компонент отправил GOAWAY и где RPC становится application work. Сопоставьте request ID или trace ID на входе и выходе gateway. Если событие видно только downstream, проверяйте edge и клиентскую библиотеку. Если upstream cluster одновременно закрывает много streams, ищите drain, max connection duration, рестарт sidecar либо backend gRPC server.

Полезный контрфакт: временно направьте небольшой canary напрямую к тому же backend через отдельный контролируемый hop. Если GOAWAY исчез, это не доказывает вину GPU-сервера; оно локализует проблему в исключённом intermediary. Близкие темы — TLS handshake storm на LLM gateway и HTTP/3 для AI API, но здесь нас интересует именно lifecycle HTTP/2 connection.

Соберите evidence chain до изменения таймаутов

Нужны три независимых доказательства. Первое — transport evidence: error code, debug data, Last-Stream-ID, направление и момент GOAWAY. Второе — effective state: фактические параметры клиента, proxy и сервера на затронутом pod или узле, а не только desired YAML в репозитории. Третье — application outcome: доля успешных RPC, TTFT, завершение stream, wasted GPU work и повторная обработка.

Начните со структурированного access log. Envoy умеет записывать protocol, response flags, duration, upstream host и request ID; официальный формат описан в документации access logging. Добавьте channelz или transport logs в gRPC-клиенте там, где библиотека это поддерживает. Не делайте packet capture единственным источником: при TLS он покажет TCP lifecycle, но не расшифрует HTTP/2 frames без ключевого материала.

Пример: deployment считает rollout успешным, readiness зелёный, но пик UNAVAILABLE точно совпадает с завершением старых pods. Transport log показывает NO_ERROR, а application trace — что часть streams уже получила response headers. Значит, проблема не в detection мёртвого connection: shutdown grace короче реальной длительности stream или клиент повторяет committed вызов.

curl -fsS http://127.0.0.1:9901/stats?filter='http2|cx_destroy|cx_drain|upstream_cx' > /tmp/envoy-http2-stats.txt
kubectl get pods -n inference -o wide > /tmp/inference-pods.txt
kubectl get events -n inference --sort-by=.lastTimestamp > /tmp/inference-events.txt
journalctl -u envoy --since '-15 min' > /tmp/envoy-journal.txt

Согласуйте gRPC keepalive, не создавая ping storm

gRPC keepalive использует HTTP/2 PING, чтобы проверить живость transport, и не равен TCP keepalive. Официальное руководство gRPC отдельно предупреждает: клиентские параметры нужно согласовывать с владельцем сервиса. Если клиент шлёт PING чаще, чем разрешает сервер, тот может закрыть connection через GOAWAY с debug data too_many_pings.

Сначала ответьте, зачем нужен keepalive. Для коротких unary RPC он редко является главным механизмом: deadline и обычная ошибка подключения дают более понятную семантику. Для долгого streaming RPC PING помогает обнаружить сломанный path, когда данные временно не идут. Но слишком агрессивный интервал повышает CPU/traffic overhead и может конфликтовать с policy gateway или managed load balancer.

Меняйте policy в безопасном порядке: сначала сделайте server enforcement совместимым с будущим клиентом, затем раскатывайте клиентские интервалы. Откат — в обратном порядке. Не копируйте «магические 20 секунд» из чужого примера: timeout должен учитывать RTT, потери, TCP retransmission и возможные pause процесса. Disqualifier прост: если active stream регулярно передаёт DATA, а обрывы совпадают с max connection age, keepalive не лечит корень проблемы.

Разведите graceful drain, idle timeout и max connection age

Три таймера часто называют одним словом «таймаут», хотя они решают разные задачи. Idle timeout закрывает неиспользуемый connection. Max connection duration периодически обновляет transport и может распределять клиентов между backend после изменения topology. Drain timeout задаёт окно между уведомлением о закрытии и финальным прекращением connection. У Envoy для HTTP/2 drain предусмотрена последовательность GOAWAY; актуальные поля и поведение проверяйте в официальной таблице timeout.

Для LLM streaming критично сравнить grace window с наблюдаемой длительностью полезного stream, а не со средним unary latency. Если генерация может идти дольше, короткий drain уничтожит работу после уже отправленных токенов. Бесконечный grace тоже плох: старые pods не уходят, rollout зависает, а connection pinning сохраняет неравномерную нагрузку.

Практичный canary: один gateway получает новый max age и drain policy, другой остаётся baseline. Создайте длинный stream, затем инициируйте плановый drain. Новые RPC должны перейти на новый connection; текущий stream — завершиться в пределах согласованного grace. После теста верните canary к baseline и повторите: это отрицательный контроль, который доказывает связь результата именно с policy.

http_connection_manager:
  stat_prefix: llm_gateway
  drain_timeout: 45s
  common_http_protocol_options:
    max_connection_duration: 30m

Не повторяйте committed RPC вслепую

HTTP/2 даёт полезную границу: streams с номером выше Last-Stream-ID из GOAWAY считаются не обработанными и могут быть повторены на новом connection. Для streams с меньшим или равным ID такой гарантии нет. Если connection оборвался без GOAWAY, неопределённость ещё выше. Это особенно важно для LLM API, где POST может уже запустить GPU-работу, списать квоту или записать историю диалога.

gRPC также различает transparent retry и настраиваемую retry policy. В официальном руководстве Retry указано: после получения response headers RPC считается committed, и автоматический retry прекращается. Для application retry одной ошибки UNAVAILABLE недостаточно — нужна идемпотентность, request ID или серверный dedup, оставшийся deadline budget и лимит попыток с backoff.

Streaming response после первого токена нельзя «прозрачно продолжить» на новом connection, если протокол приложения не поддерживает resume token или offset. Правильнее вернуть клиенту явный статус и решить на уровне продукта: начать заново, показать частичный результат или возобновить с checkpoint. Скрытый retry способен удвоить GPU work и создать дубликат операции, хотя transport graph выглядит здоровее.

{
  "methodConfig": [{
    "name": [{"service": "inference.v1.Model", "method": "Generate"}],
    "timeout": "30s",
    "retryPolicy": {
      "maxAttempts": 3,
      "initialBackoff": "0.2s",
      "maxBackoff": "2s",
      "backoffMultiplier": 2,
      "retryableStatusCodes": ["UNAVAILABLE"]
    }
  }]
}

Проведите canary-тест, который отделяет transport от модели

Хороший тест воспроизводит событие и содержит negative control. Подготовьте два одинаковых gateway-пути: baseline и canary. На обоих используйте один backend pool, одну модель и одинаковый prompt-набор. Разница должна быть только в одной policy — например, client keepalive или drain window. Иначе снижение ошибок нельзя приписать конкретному изменению.

Проверьте минимум четыре сценария: короткий unary RPC, долгий server-streaming RPC, idle channel без active call и плановый drain во время активного stream. Для каждого сохраните transport frame/error, фактический peer, gRPC status, количество client attempts и application result. Deadline задавайте явно: по документации gRPC по умолчанию клиент может ждать фактически бесконечно.

Stop condition нужен заранее. Если canary увеличивает retry attempts, wasted GPU work, хвост TTFT или долю незавершённых streams, откатывайте policy даже при уменьшении числа GOAWAY в логах. Снижение transport-событий не является победой, если SLO приложения ухудшился. Проверяли ли вы это после последнего обновления gateway, а не только в synthetic health check?

grpcurl -max-time 30 -H 'x-canary: baseline' gateway.example:443 list
grpcurl -max-time 30 -H 'x-canary: candidate' gateway.example:443 list
# Для production-метода используйте безопасный тестовый tenant и idempotency key.

Алерт должен видеть последствия, а не любой GOAWAY

Алерт на каждый GOAWAY быстро превращается в шум: graceful restart обязан их генерировать. Разделите события по error code, debug data, sender hop и причине drain. Отдельно считайте connections, которые закрылись без GOAWAY, и streams, завершившиеся после получения response headers. Эти категории имеют разную retry semantics и разный риск дубликатов.

На application-слое свяжите transport с четырьмя метриками: доля успешных RPC, TTFT, длительность и completion rate streams, а также wasted work после client cancellation. Добавьте количество attempts на логический request ID. Если attempts растут быстрее полезных завершений, retry маскирует инцидент и умножает нагрузку на GPU.

Не забудьте deployment context: версия client library, gateway build, backend revision и причина shutdown. Для Envoy admin interface держите endpoint на localhost или в защищённой сети: официальная документация предупреждает, что он содержит чувствительные данные и допускает изменяющие операции.

Выберите платформу по границе контроля, а не по обещанию latency

Сначала исправьте client pooling, retry storm и несовместимую keepalive policy. Новое железо этого не лечит. Но placement gateway определяет, чем команда действительно управляет: версией proxy, TLS termination, connection age, drain hooks, conntrack limits, kernel policy и change window. Именно эта граница контроля — честная причина обсуждать VPS или выделенный edge.

Shared VM подходит, когда нагрузка умеренная, transport policy стандартна и допустим небольшой noisy-neighbor risk. Отдельный VPS для gateway даёт изоляцию процесса и понятный rollout, сохраняя быстрый reprovision. Выделенный сервер оправдан, когда нужны стабильный network path, высокий connection churn, точный kernel/IRQ baseline и независимый canary-пул. Managed LB снижает on-call burden, но часть PING, timeout и drain semantics остаётся политикой провайдера.

Decision helper: если вы не можете назвать владельца GOAWAY и измерить application outcome, оставайтесь на текущей платформе и улучшайте observability. Если причина доказана и исправление требует control plane, которого нет, переносите сначала один canary gateway. Материал о BBR и fq для LLM-стриминга полезен после локализации sender и очереди; DNS failover для LLM API — когда проблема связана с выбором нового peer, а не HTTP/2 drain.

Пять ошибок, которые делают инцидент дороже

Ошибка 1 — считать любой GOAWAY потерей запроса. При корректном graceful drain часть активных streams завершится нормально, а новые уйдут на другое соединение. Если алерт не различает NO_ERROR и protocol failure, on-call начинает отменять штатные rollout и ухудшает доступность собственными действиями.

Ошибка 2 — увеличивать все таймауты одновременно. Больший idle timeout, drain grace и RPC deadline могут временно скрыть симптом, но оставят неизвестным работающий механизм. Меняйте один параметр, сохраняйте effective config и возвращайте baseline после canary. Иначе следующий инцидент начнётся с конфигурации, смысл которой уже никто не помнит.

Ошибка 3 — включать keepalive без договора с сервером. Клиент начинает чаще слать PING, server enforcement считает их нарушением и отвечает too_many_pings. Команда видит больше GOAWAY и ещё сильнее уменьшает интервал — получается положительная обратная связь. Сначала расширяйте допустимую server policy, потом раскатывайте клиентов; ужесточайте в обратном порядке.

Ошибка 4 — считать UNAVAILABLE разрешением на retry. Статус описывает результат попытки, но не доказывает, что application handler не начал работу. Для генерации, записи истории, биллинга и tool call нужен request ID и серверная дедупликация. После первого response token автоматический повтор особенно опасен: клиент может получить два расходящихся ответа.

Ошибка 5 — покупать capacity до локализации owner. Дополнительный gateway действительно полезен для canary и изоляции, но не исправляет неправильный client pool или policy. Сначала докажите дефицит control plane: невозможность управлять версией proxy, drain hook, kernel path или change window. Только после этого инфраструктурное расширение становится инженерным решением, а не дорогим способом отложить диагностику.

Runbook инцидента: от симптома до безопасного rollback

Шаг 1. Зафиксируйте symptom window, затронутые client versions и тип RPC. Не объединяйте unary и streaming ошибки в один график. Шаг 2. Получите GOAWAY code, debug data и Last-Stream-ID на каждом видимом hop. Если frame не записан, отметьте connection close как отдельную неопределённую категорию.

Шаг 3. Постройте карту connection owners и сопоставьте событие с rollout, drain, max age, idle timeout и server keepalive enforcement. Шаг 4. Проверьте application commitment: пришли ли headers или токены, могла ли операция изменить состояние, есть ли idempotency key. До этого не расширяйте retry.

Шаг 5. Выберите одно изменение и один canary. Для too_many_pings согласуйте client/server policy; для NO_ERROR во время rollout сопоставьте grace с stream duration; для protocol error снимите точные версии и минимальный воспроизводимый path. Шаг 6. Сравните transport и application metrics. Шаг 7. Верните canary к baseline тем же способом и подтвердите обратимость.

Типичная ловушка — увидеть меньше UNAVAILABLE после увеличения retry и закрыть инцидент. Если attempts и GPU-seconds выросли, вы лишь перенесли стоимость внутрь системы. Исправление считается доказанным, когда уменьшается исходный transport failure, сохраняется deadline/SLO и не растёт duplicate work.

Вывод: лечите конкретный connection lifecycle

GOAWAY — не диагноз, а указатель на смену состояния HTTP/2 connection. Надёжный разбор связывает frame и его отправителя, фактическую policy на каждом hop и результат конкретного LLM RPC. Keepalive нужен для обнаружения мёртвого transport, drain — для управляемого завершения, deadline — для ограничения работы, а retry допустим только там, где понятна commitment и idempotency boundary.

Начните с одного безопасного действия: выберите недавний инцидент, восстановите карту CLIENT → EDGE → GATEWAY → GPU и подпишите owner каждого connection. Затем повторите событие на canary с прежней policy и с одним изменением. Если для такого теста нужна отдельная управляемая площадка, используйте изолированный VPS или dedicated gateway-пул как воспроизводимый baseline, а не как обещание автоматического ускорения.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Когда TLS становится скрытой очередью перед GPU

График GPU utilization просел, TTFT вырос, а число запросов почти не изменилось. На gateway одновременно подскочили CPU и новые TCP-соединения. Это типичная картина, когда дорогим ресурсом внезапно становится не inference, а создание защищённых соединений: клиенты перестали переиспользовать transport, session resumption не срабатывает или балансировщик обнуляет его эффект.

Важно сразу провести границу с соседними проблемами. Если поток уже установлен, но токены идут рывками, полезнее начать с очереди BBR/fq или существующего материала про reverse proxy. Здесь другой intent: найти, почему gateway выполняет слишком много полных TLS handshakes, и доказать связь именно с application SLO.

Один handshake сам по себе не авария. Авария начинается, когда отношение новых соединений к полезным LLM-запросам резко меняется, CPU gateway уходит в насыщение, а TTFT ухудшается при стабильном времени генерации на backend. Проверяли ли вы эти три ряда на одной шкале времени? Без такой корреляции легко «лечить» сертификаты, хотя виноват client pool.

Материал рассчитан на NGINX-подобный TLS terminator, но метод переносится на Envoy, HAProxy и managed load balancer. Команды и директивы сверяйте с вашей версией: например, текущая документация NGINX отдельно описывает shared session cache, tickets и keepalive, а поведение upstream keepalive менялось между ветками.

Сначала снимите baseline, который переживёт спор команд

До изменения конфигурации соберите evidence bundle: точную версию gateway и TLS-библиотеки, effective config, topology termination points, частоту новых соединений, долю reused sessions, CPU по worker-процессам, ошибки handshake и application-метрики. Владелец шага — команда edge/platform; stop condition — вы не знаете, где именно завершается клиентский TLS.

Не ограничивайтесь средней загрузкой узла. Handshake storm часто выглядит как короткие пики по отдельным worker, которые растворяются в минутном average. Сопоставьте rate новых соединений с completed requests, а не только с RPS: один streaming-запрос может жить долго, тогда как неудачный клиент создаёт десятки соединений и почти не даёт полезной работы.

Хороший baseline включает спокойное окно и окно инцидента одинаковой длины. Зафиксируйте p50/p95 TTFT, CPU gateway, accepted connections, TLS handshakes, resumption hits, 4xx/5xx и время inference без сетевой части. Не придумывайте универсальные пороги: сравнивайте сервис с его собственным стабильным периодом и SLO.

• Identity: hostname, VIP, pod/VM, версия NGINX/OpenSSL.
• Transport: новые TCP-соединения, keepalive reuse, resets и timeouts.
• TLS: полные и resumed handshakes, протокол, certificate path.
• Application: TTFT, queue time backend, tokens/sec и error budget.

nginx -V 2>&1
nginx -T > /var/tmp/nginx-effective.conf 2>&1
ss -s
ss -Htan state established '( sport = :443 )' | wc -l
pidstat -p "$(pgrep -d, -x nginx)" 1 10

Три gate: TLS mechanism, transport reuse и LLM outcome

Разделите расследование на три независимых доказательства. TLS mechanism gate отвечает, умеет ли клиент возобновить сессию на том же termination point. Transport gate показывает, переиспользуются ли клиентские и upstream-соединения. Application gate проверяет, изменились ли TTFT и error budget. PASS в первом gate не гарантирует PASS в третьем.

Для TLS gate выполните повторные соединения одним и тем же тестовым клиентом и смотрите, сообщает ли инструмент о reuse. Для transport gate сравните число connect/accept с completed requests и длительностью соединений. Для application gate проведите одинаковый canary workload с фиксированными моделью, prompt и лимитом output tokens.

Отрицательный контроль обязателен. Запустите тот же canary с отключённым client pooling или через другой termination point, где cache/ticket заведомо не разделяется. Если метрика не расходится, вы не доказали механизм. Важно не направлять этот контроль на production-пользователей: достаточно малой изолированной выборки.

openssl s_client \
  -connect api.example.com:443 \
  -servername api.example.com \
  -tls1_3 \
  -reconnect &1 | \
  grep -E 'New,|Reused,|Protocol|Cipher|Verify return code'

Session resumption: cache, tickets и граница балансировщика

NGINX прямо указывает два способа сократить дорогие операции: keepalive и повторное использование параметров TLS-сессии. Shared cache доступен worker-процессам и настраивается через ssl_session_cache; время повторного использования задаёт ssl_session_timeout. В актуальной документации ngx_http_ssl_module также описаны session tickets и ротация ticket keys.

Ловушка появляется на нескольких gateway-репликах. Stateful cache на одном экземпляре не поможет клиенту, который при каждом reconnect попадает на другую реплику. Tickets могут пережить балансировку только при согласованной политике ключей; слишком долгая жизнь ключа расширяет окно риска, слишком быстрая несогласованная ротация обрушает reuse. Владельцу security нужно участвовать в решении, а не получать готовую настройку постфактум.

Для TLS 1.3 resumption основан на PSK и NewSessionTicket; это не повод включать 0-RTT автоматически. Early data имеет отдельные replay-риски и не требуется, чтобы получить пользу от обычного resumption. Сверяйтесь с RFC 8446 и политикой вашего клиента.

Проверяйте effective context. NGINX предупреждает, что параметры сессий могут зависеть от default server при выборе виртуального сервера. Мини-кейс: команда правит cache в одном SNI server block, а реальные сессии обслуживаются настройкой default server. Конфиг выглядит правильно, но resumption miss не меняется.

Keepalive важнее магии TLS, если соединения можно не закрывать

Session resumption делает новый handshake дешевле, но keepalive вообще убирает необходимость в новом соединении. Поэтому сначала спросите: почему соединение закрывается? Причиной могут быть client connection pool, max requests, idle timeout на LB, graceful reload, proxy policy, upstream close или ограничение SDK. Настраивать cache, не ответив на этот вопрос, — оптимизация второго порядка.

Разделяйте два плеча: client → gateway и gateway → LLM backend. Клиентский HTTP/2 может мультиплексировать запросы в одном соединении, а gateway при этом создавать новый upstream TCP/TLS на каждый вызов. И наоборот, upstream pool может быть здоров, но mobile-клиент или serverless worker постоянно пересоздаёт внешний transport.

В документации NGINX upstream подчёркнуто, что размер keepalive cache — это число idle connections на worker, а не лимит всех соединений. Слепо поставить огромное значение опасно: backend всё равно должен принимать новые соединения, а память и file descriptors конечны.

Негативный контроль здесь прост: небольшой canary без pooling должен показывать больше connect events на тот же объём полезных запросов. Если разницы нет, ищите termination между клиентом и gateway, принудительное закрытие или неверную телеметрию. Знакомо, когда команда считает HTTP requests, а настоящий TLS заканчивается на внешнем LB, чьи метрики никто не открыл?

Минимальная конфигурация и почему её нельзя копировать вслепую

Ниже — baseline, а не универсальный рецепт. Он включает shared session cache и keepalive, но размеры и время жизни нужно выбирать по реальному числу активных клиентов, памяти, security-политике и topology. Перед применением проверьте синтаксис вашей ветки NGINX: defaults и доступные директивы менялись.

Не добавляйте 0-RTT только ради красивого latency-графика. Для LLM API запрос может менять состояние, списывать квоту или создавать дорогостоящую генерацию; replay такого запроса требует отдельной модели идемпотентности. Обычный TLS 1.3 resumption и keepalive дают пользу без автоматического принятия early data.

После reload подтвердите именно effective state: nginx -T, новые worker PID, отсутствие ошибок загрузки ключей и поведение canary. Успешная команда reload доказывает лишь то, что master принял сигнал. Она не доказывает reuse, снижение CPU или улучшение TTFT.

worker_processes auto;

http {
    ssl_session_cache shared:TLS:20m;
    ssl_session_timeout 10m;
    ssl_session_tickets on;

    keepalive_timeout 75s;
    keepalive_requests 1000;

    upstream llm_backend {
        server 10.0.0.11:8000;
        server 10.0.0.12:8000;
        keepalive 32;
    }

    server {
        listen 443 ssl;
        server_name api.example.com;

        ssl_certificate     /etc/nginx/tls/fullchain.pem;
        ssl_certificate_key /etc/nginx/tls/privkey.pem;
        ssl_protocols TLSv1.2 TLSv1.3;

        location /v1/ {
            proxy_http_version 1.1;
            proxy_set_header Connection "";
            proxy_pass http://llm_backend;
        }
    }
}

Метрики, которые отделяют handshake storm от соседних аварий

Начните с причинной цепочки, а не с коллекции панелей: new connections → full handshakes → gateway CPU → request admission/queue → TTFT. К ней добавьте resumption reuse, connection lifetime, client cohort и termination replica. Если рост CPU не следует за full handshakes, ищите certificate loading, WAF, logging или другой workload на том же узле.

Сравните с conntrack и SNAT runbook. При исчерпании state table или портов новые соединения тоже ломаются, но signature другая: drops, allocation failures, retransmits и ошибки connect. TLS tuning не расширяет tuple space и не исправляет retry storm.

Отдельно проверьте DNS и peer identity. После failover клиент может держать старое соединение или старый IP; это разобрано в статье про DNS failover для LLM API. Здесь resumption miss будет следствием смены termination point, а не первопричиной инцидента.

• Qualifier: full handshake rate растёт быстрее полезных запросов, reuse падает, CPU gateway коррелирует.
• Disqualifier: CPU стабилен, но backend queue растёт; проблема вероятнее в inference capacity.
• Disqualifier: connect failures идут вместе с conntrack/SNAT pressure.
• Disqualifier: только один SDK churn-ит соединения; исправление принадлежит клиенту.

Canary rollout: меняйте один механизм и оставляйте путь назад

Canary должен отличаться одной гипотезой. Если одновременно увеличить session cache, поменять tickets, keepalive, worker count и LB policy, вы получите улучшение без attribution. Начните с самого дешёвого control: восстановите client pooling или устраните слишком короткий idle timeout. Затем отдельно проверяйте resumption.

Закрепите canary за отдельной gateway-репликой или hostname, но сохраните одинаковые certificate chain, модель, prompt distribution и backend pool. Сравнивайте не абсолютный latency двух разных потоков, а нормализованные показатели на полезный запрос: CPU/request, new connections/request, full handshakes/request и TTFT при сопоставимом output.

Stop condition задаётся заранее: рост handshake errors, 4xx/5xx, reset rate, ухудшение TTFT или нарушение security-policy. Rollback должен возвращать прежние cache/ticket/keepalive параметры и повторять те же три gate в обратном порядке. Только так возврат к baseline становится контрфактом, а не ритуалом.

Практический случай: после увеличения cache reuse растёт, но TTFT не меняется. Это частичный PASS. Механизм работает, однако bottleneck находится дальше — например, в admission queue backend. Не продавайте это как ускорение LLM; оставьте изменение только если снижение CPU gateway само по себе оправдывает сложность.

Когда нужен отдельный gateway, VPS или dedicated edge

Default простой: не покупайте новый сервер, пока не доказали дефицит ресурса и границу контроля. Если проблема в SDK, который закрывает соединение после каждого запроса, более мощный gateway лишь дороже переварит тот же churn. Если виноваты несогласованные ticket keys в managed LB, перенос без исправления ownership тоже не даст устойчивого результата.

Выделенный gateway оправдан, когда evidence показывает CPU saturation на TLS termination, соседние workloads создают непредсказуемый steal/noisy-neighbor эффект, а команде нужны управляемые версии OpenSSL/NGINX, воспроизводимый hardware profile и собственное change window. Для малого private API иногда достаточно VPS; высокий handshake rate, жёсткий SLO и большой blast radius чаще ведут к dedicated edge-пулу.

Коммерческий bridge к инфраструктуре KingServers здесь не про обещание «ускорить TLS одной кнопкой». Ценность — в контроле: закрепить gateway profile, отделить canary, наблюдать CPU и network path, проводить симметричный rollback. Архитектурный контекст private endpoint, квот и gateway можно связать со статьёй про Private AI API.

Decision helper должен учитывать owner. Client team отвечает за pooling и lifecycle SDK; edge team — за TLS policy, cache и termination; network team — за LB и path; LLM platform — за queue, batching и TTFT decomposition. Пока owner не назван, любой тюнинг рискует стать временной заплаткой.

Runbook инцидента: от алерта до доказанного восстановления

Шаг 1. Подтвердите симптом: TTFT или error rate вышли за SLO, а workload сопоставим с baseline. Шаг 2. Найдите TLS termination point и владельца. Шаг 3. Сохраните effective config, версии, worker CPU и connection counters. Шаг 4. Разделите full handshake, resumed handshake и already-open keepalive.

Шаг 5. Проведите безопасный отрицательный контроль: тестовый клиент без pool либо отдельный termination point без общего resumption state. Шаг 6. Выберите один fix — client pooling, idle timeout, shared cache или согласованная ticket policy. Шаг 7. Прокатите на canary с фиксированным workload и stop condition. Шаг 8. Повторите TLS, transport и application gates.

Шаг 9. Сделайте rollback-контрфакт: верните прежнее значение и проверьте, возвращается ли симптом. Если нет, причинность остаётся недоказанной. Шаг 10. Только после повторяемого результата расширяйте rollout. Обновите runbook реальными метриками вашего сервиса, но не превращайте наблюдавшийся порог в универсальный закон.

Важная производственная деталь: graceful reload сам может временно увеличить число соединений, если старые worker завершаются, а клиенты переподключаются. Не оценивайте canary только в первые секунды после reload; выделите warmup и стабильное измеряемое окно.

Главный вывод: сначала соединение, затем криптография, потом железо

TLS handshake storm — это не синоним «медленного шифрования». Сначала докажите, что сервис создаёт слишком много соединений на полезный запрос; затем проверьте session resumption на реальном termination point; после этого свяжите механизм с CPU gateway и TTFT. Такая последовательность защищает от красивого, но бесполезного тюнинга.

Рабочий change plan короткий: baseline, три evidence gate, один canary-fix, отрицательный контроль и симметричный rollback. Keepalive обычно сильнее оптимизации нового handshake, а новый сервер имеет смысл только после подтверждённого resource bottleneck и понятной границы ownership.

Следующий практический шаг — взять одно стабильное и одно проблемное окно, посчитать new connections/request и повторить OpenSSL probe через каждую gateway-реплику. Если причина подтверждена, перенесите минимальный fix на canary. Если нет — сохраните результат: честный disqualifier экономит больше времени, чем ещё одна директива в конфиге.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Быстрый вывод: DNS failover не равен переключению трафика

Если вы поменяли A- или AAAA-запись, а LLM-клиенты продолжают ходить на старую GPU-площадку, это еще не доказывает «сломанный DNS». Запись могла обновиться на authoritative-сервере, но остаться в рекурсивном или локальном кэше; приложение могло сохранить собственный результат; а уже открытый HTTP/2 или keep-alive канал вообще не обязан выполнять новый lookup. Поэтому рабочий default прост: не снижайте TTL и не чистите кэши вслепую. Сначала определите, какой слой владеет старым состоянием.

Для production LLM API цена ошибки выше, чем у короткого веб-запроса. Один streaming-сеанс может жить долго, GPU endpoint может быть DNS-доступен, но не готов к нужной модели, а повтор неидемпотентного запроса после первого токена создает дублирующую работу. DNS отвечает только на вопрос «какие адреса доступны для нового соединения». Он не выполняет health check модели, не дренирует соединения и не гарантирует завершение потока.

Runbook ниже строится вокруг трех независимых gates: DNS answer → transport peer → application outcome. Такой порядок быстро отделяет смену записи от сетевого пути и от готовности inference. Если второй и третий gates не пройдены, новая инфраструктура сама по себе проблему не исправит: больше GPU или выделенный сервер не лечат вечный connection pool, ошибочный timeout либо незакрытый retry storm.

Тема намеренно уже общего материала о принципах DNS и отдельного разбора active-active против active-passive для API. Здесь интересует операционная граница: как доказать фактическое переключение конкретного клиента и безопасно откатить изменение.

Составьте карту кэшей до изменения записи

На типичном Linux-хосте запрос проходит не одну «DNS-систему», а цепочку. Приложение обращается к runtime или библиотеке, та использует NSS/getaddrinfo либо собственный resolver, запрос попадает в systemd-resolved или другой локальный stub, затем в recursive DNS и лишь после этого — к authoritative-серверам зоны. В контейнерной платформе добавятся node-local cache, CoreDNS, sidecar или egress proxy. Каждый слой может иметь собственную политику refresh.

Нарисуйте цепочку именно для проблемного workload. Проверяли ли вы, куда указывает /etc/resolv.conf внутри контейнера, а не только на хосте? Если это 127.0.0.53, запрос обычно идет через systemd-resolved; если адрес кластера — через CoreDNS; если приложение собрано с библиотекой async DNS, NSS может быть обойден. Один dig к публичному resolver не описывает этот путь.

Положительный TTL ограничивает использование конкретного RRset обычным кэшем, но есть две важные оговорки. Во-первых, RFC 2308 определяет negative caching: NXDOMAIN и NODATA могут жить по TTL, вычисленному из SOA. Если имя создали после ошибочного lookup, клиенты могут еще видеть отсутствие записи. Во-вторых, RFC 8767 допускает serve-stale при недоступности upstream: resolver сначала пытается обновить данные, но при сбое может вернуть просроченный ответ ради доступности.

Это не повод назначать TTL в пять секунд. Слишком короткий TTL увеличивает зависимость от resolver path и может создать синхронный всплеск запросов. Сначала зафиксируйте желаемый recovery envelope: сколько времени допустимо направлять новые соединения на старый endpoint, сколько живет connection pool и кто отвечает за drain.

Снимите baseline: authoritative, recursive, host и приложение

Baseline нужен до аварийного изменения, иначе после переключения вы будете сравнивать четыре неполных снимка. Возьмите один QNAME, например api.example.net, отдельно запишите A и AAAA, TTL, CNAME-цепочку, ответ каждого authoritative nameserver и ответы рекурсивных resolver, которыми реально пользуется production. Рядом сохраните время в UTC и идентификатор узла.

На хосте сравните три поверхности: конфигурацию resolver, прямой запрос через systemd-resolved и результат NSS. Команды ниже только читают состояние; замените имя и адреса на свои. resolvectl status показывает per-link DNS и routing domains, а getent ahosts повторяет путь, близкий к обычному getaddrinfo. Это полезнее, чем считать dig универсальным доказательством.

date -u
readlink -f /etc/resolv.conf
resolvectl status
resolvectl query api.example.net
getent ahosts api.example.net
dig +noall +answer A api.example.net
dig +noall +answer AAAA api.example.net

Следующий шаг — получить фактический peer IP приложения. Для прокси это может быть upstream address в access log или connection metric; для клиента — адрес сокета, трассировка connect либо лог SDK. Если DNS уже показывает новый адрес, но peer остается старым, владелец проблемы расположен после resolver: connection reuse, неистекший application cache или статически собранный upstream.

Снимайте baseline с нескольких узлов и через каждый production resolver. Разница между двумя worker nodes — не шум, а подсказка. Например, один узел использует корпоративный recursive resolver со stale policy, а второй — node-local cache с иным negative TTL. Усредненный success rate скроет этот разрез.

Диагностика systemd-resolved без магии flush-caches

systemd-resolved — caching stub и менеджер маршрутизации DNS-запросов. Он выбирает серверы с учетом per-link domains и держится за выбранный сервер в scope до ошибки. Поэтому два интерфейса, VPN и default-route могут отправлять одинаковый QNAME по разным путям. Сначала докажите effective configuration, и только затем обсуждайте cache.

resolvectl statistics показывает общую статистику, monitor — локальные запросы и ответы, show-cache — содержимое cache на новых версиях systemd. По актуальной man page команды monitor, show-cache и show-server-state появились в разных версиях, поэтому их отсутствие на LTS-дистрибутиве не означает поломку. Используйте доступный набор и фиксируйте версию через resolvectl --version.

resolvectl --version
resolvectl status
resolvectl statistics
resolvectl query api.example.net
resolvectl monitor
# На systemd 254+:
resolvectl show-cache

resolvectl flush-caches допустим как диагностический контрфакт на одном canary-узле: до очистки старый ответ, после — новый. Не превращайте его в rollout-механизм для всего флота. Очистка не меняет app cache и не закрывает sockets; кроме того, вы стираете полезное состояние и можете создать одновременный поток запросов к upstream DNS.

Параметр StaleRetentionSec= доступен в новых systemd и позволяет хранить записи после TTL для ответа при недоступном upstream; значение по умолчанию — ноль. Это resilience-функция, а не ускоритель миграции. Она не применяется к валидному NXDOMAIN, а включать ее следует только вместе с мониторингом DNS failures и понятной политикой возврата к свежим данным. Отдельно учитывайте RFC 9520: временные resolution failures также могут кэшироваться, но не должны удерживаться дольше пяти минут.

Проверьте application DNS cache и connection reuse

Самая частая ловушка выглядит так: resolvectl query и dig уже возвращают новый IP, а метрики старой площадки не падают. Причина часто не в кэше RRset, а в том, что процесс не выполняет новый dial. HTTP keep-alive, HTTP/2 multiplexing и gRPC channel позволяют многим запросам идти по существующему TCP/TLS-соединению. DNS TTL не является сроком жизни этого сокета.

Разделите вопросы. Первый: когда runtime повторно резолвит имя? Второй: когда connection pool закрывает старый transport? Третий: может ли streaming client безопасно повторить запрос? До первого байта ограниченный retry иногда возможен; после начала потока прозрачный повтор рискует продублировать inference и расход GPU. Именно поэтому DNS failover нельзя оценивать только по HTTP status.

У Envoy DNS discovery работает асинхронно. Официальная документация описывает respect_dns_ttl, отдельную частоту refresh при ошибке и различие strict/logical DNS; для logical DNS живые соединения продолжают существовать, пока их не циклируют. В NGINX динамический resolve зависит от конкретного модуля и версии: например, документация stream upstream указывает появление открытой директивы resolver в контексте upstream в 1.27.3. Перед копированием примера проверяйте edition, module и release.

Надежный canary принудительно создает новый transport, но сохраняет SNI и Host. Для curl можно временно закрепить конкретный адрес через --resolve; это обходит DNS для одного теста и помогает отделить endpoint readiness от resolver path. Не используйте -k: сертификат должен проверяться так же, как в production.

TARGET_IP=203.0.113.20
curl --fail-with-body --silent --show-error \
  --resolve api.example.net:443:$TARGET_IP \
  https://api.example.net/health/ready

curl --fail-with-body --no-keepalive \
  --resolve api.example.net:443:$TARGET_IP \
  https://api.example.net/v1/models

Если прямой canary проходит, а обычный клиент остается на старом peer, работайте с lifecycle pool: max connection age, drain, reload или rolling restart выбранной cohort. Если прямой canary не проходит, DNS refresh лишь быстрее отправит пользователей на неготовый endpoint. Это disqualifier для переключения, а не повод еще сильнее уменьшать TTL.

Не смешивайте A и AAAA: dual-stack меняет картину отказа

Одинаковое имя может возвращать IPv4 и IPv6, а клиент выбирает семейство согласно своей реализации и состоянию сети. Вы удалили старую A-запись, но забыли AAAA; часть клиентов продолжит попадать на прежнюю площадку по IPv6. Или новый AAAA уже опубликован, но маршрутизация, firewall либо сертификат на новом пути не готовы. Общий график «DNS success» при этом будет зеленым.

Проверяйте A и AAAA независимо на каждом уровне, а затем фиксируйте выбранный peer. Важна не абстрактная доступность адреса, а полный путь: source network → routing → firewall/NAT → TLS SNI → endpoint readiness. Пример из практики: внешний мониторинг по IPv4 видит новую площадку, а worker nodes с рабочим IPv6 продолжают открывать старый endpoint. Команда считает failover завершенным, пока нагрузка на исходном GPU pool не исчезает.

Не выключайте IPv6 как универсальный fix. Это меняет сеть шире инцидента и маскирует несогласованную публикацию записей. Гораздо безопаснее на canary явно проверить обе семьи, затем синхронизировать health и routing policies. Если приложение поддерживает Happy Eyeballs или сходную гонку адресов, запишите, какой результат победил и почему; порядок массива getaddrinfo сам по себе не гарантирует выбранный маршрут.

Еще один отрицательный контроль: временно направьте тестовый клиент на старый IP через --resolve и убедитесь, что после drain он действительно перестал принимать новые запросы либо отвечает ожидаемым maintenance status. Если старый endpoint остается полностью рабочим, вы не доказали перенос, вы только добавили второй путь.

Runbook переключения: от записи к application SLO

Плановый failover начинается не с редактирования DNS, а с подготовки целевой площадки. Загрузите нужную версию модели, проверьте tokenizer и runtime, прогрейте только в пределах принятой политики, подтвердите health отдельно от mere process liveness. Новый endpoint должен пройти TLS, auth, quota и representative inference canary. Для streaming запроса измеряйте как минимум connect, время до первого байта, межтокенный прогресс и полное завершение.

За один или несколько TTL до окна убедитесь, что authoritative TTL действительно уменьшен и уже успел распространиться. Снижение TTL за минуту до изменения не влияет на ответы, ранее закэшированные с прежним значением. Отдельно проверьте SOA для negative answers: случайный предварительный запрос к еще несуществующему имени может оставить NXDOMAIN именно тогда, когда вы начнете rollout.

Во время изменения двигайтесь по gates. Gate 1: все authoritative отвечают новым RRset. Gate 2: выбранные recursive resolvers отдают новый ответ после ожидаемого срока. Gate 3: canary hosts получают его через свой effective resolver. Gate 4: новый connection устанавливается с целевым peer IP. Gate 5: LLM application canary проходит по качеству протокола и SLO. Между gates должен быть stop condition; не продолжайте rollout, если предыдущий слой не доказан.

После этого дренируйте старые connection pools контролируемо. Для прокси лучше иметь versioned policy max connection duration и graceful drain, чем массово убивать процессы. Для прямых SDK-клиентов раскатывайте настройки cohort-ами: один node pool, затем небольшой процент, затем весь fleet. Следите одновременно за old/new peer distribution, DNS failures, connect/TLS errors, first-byte latency и незавершенными streams.

Rollback должен быть симметричным: вернуть RRset недостаточно, если клиенты уже удерживают соединения с новой площадкой. Повторите те же gates в обратном направлении, восстановите baseline pool policy и убедитесь, что новая площадка перестала получать новые соединения. Так rollback становится проверяемой процедурой, а не надеждой на TTL.

Canary и отрицательный контроль: докажите механизм, а не корреляцию

Хороший canary отличается от обычного smoke test тем, что связывает DNS-ответ с конкретным transport и результатом приложения. В журнале одной попытки должны встретиться: timestamp, node/cohort, resolver, A/AAAA answer с TTL, resolved address, actual peer, reused или new connection, HTTP/gRPC outcome и streaming milestones. Тогда спор «это DNS или приложение» заканчивается данными.

Добавьте отрицательный контроль. Если гипотеза говорит, что старый application cache удерживает адрес, новый процесс с пустым cache должен выбрать новый peer, а долгоживущий процесс — старый. Если оба ведут себя одинаково, гипотеза ослабла. Если проблема якобы в recursive resolver, прямой запрос к authoritative и canary через другой recursive должны разойтись предсказуемо.

Canary должен быть production-sized по протоколу, но ограниченным по blast radius. Не обязательно генерировать большую нагрузку: достаточно реального TLS, auth и короткого запроса к той же модели. Не используйте только /health, если он обслуживается отдельным процессом без GPU/runtime dependency. Проверка списка моделей, короткий inference и корректное завершение stream дают более сильное доказательство.

Заранее назначьте владельцев: DNS zone, recursive resolver, host image, egress proxy, application SDK и inference endpoint. Иначе в инциденте все видят старый IP, но никто не владеет последним кэшем. Для выделенного gateway ценность как раз в этой границе контроля: единая versioned policy, наблюдаемый peer и предсказуемое окно drain. Но если причина — leak соединений или неверный retry, замена VPS на dedicated ее не устранит.

Когда DNS failover подходит, а когда нужен proxy или Anycast

DNS failover подходит, когда новые соединения могут терпеть eventual convergence, клиенты уважают refresh policy, а старую площадку можно держать до окончания drain. Это разумный базовый вариант для контролируемых server-to-server клиентов. Его сильная сторона — простота control plane; слабая — неодинаковое поведение resolver и application pools.

Центральный L4/L7 proxy полезен, когда нужно быстрее управлять health, connection lifecycle, auth, quotas и наблюдаемостью. Различие слоев важно: L4 сохраняет transport transparency, L7 понимает HTTP path и headers, но приносит buffering, timeout/retry policy и дополнительный on-call debt. Подробное сравнение для streaming API есть в статье о L4 и L7 перед LLM API.

Anycast решает другую задачу: routing приводит клиента к ближайшей или доступной точке объявления, но внутри каждой точки все равно нужны health, capacity и data/model consistency. Не считайте его «DNS без TTL». Архитектурные границы и operational trade-offs разобраны в материале о BGP Anycast.

Для private AI API часто полезна двухступенчатая схема: стабильное публичное или приватное имя ведет на контролируемый gateway, а gateway обнаруживает GPU backends и дренирует их по своей политике. Это добавляет компонент, зато концентрирует ownership. Общая архитектура gateway, квот и маршрутизации описана в гайде по Private AI API; текущий runbook дополняет ее именно DNS/transport evidence.

Выбирайте не по минимальному TTL, а по требуемому recovery envelope и возможностям команды. Если SLO стабилен и нет подтвержденной проблемы, не усложняйте. Если клиенты разнородны и вы не можете наблюдать их peer, proxy дает контроль. Если нужен глобальный вход с быстрым routing convergence, рассматривайте Anycast, сохраняя application health gates.

Метрики и алерты, которые действительно ловят DNS-инцидент

Один алерт на NXDOMAIN недостаточен. Соберите небольшой evidence set по слоям. На resolver: query volume, cache hit/miss, SERVFAIL/timeouts, stale answers и latency. На transport: новые connections, connect/TLS errors, peer IP distribution, connection age и drain state. На LLM API: admission, time to first token, idle-progress timeout, completed/cancelled streams и загрузка целевого GPU pool.

Коррелируйте по cohort и адресу, а не только по имени. Если 20% worker nodes продолжают использовать старый peer, общий success rate может выглядеть нормально, пока старую площадку не выключат. Полезен алерт на «старый peer получает новые connections после deadline», а не просто на наличие активных connections: длинные допустимые streams могут жить дольше окна переключения.

Логируйте DNS осторожно. Полный поток запросов может содержать внутренние имена и создавать большой объем. Для production достаточно агрегатов и выборочного canary trace; подробный resolvectl monitor включайте на ограниченное время. Храните timestamp и TTL рядом с результатом, иначе невозможно понять, был ли ответ действительно просроченным.

Наконец, проводите game day. Опубликуйте canary record с коротким контролируемым TTL, переключите между двумя тестовыми endpoints и измерьте фактическое время на каждом слое. Затем повторите с недоступным recursive upstream, чтобы увидеть serve-stale behavior. Не смешивайте этот тест с production model upgrade: одна переменная за раз делает rollback и выводы честными.

Определите бюджет ложных срабатываний заранее. Короткий всплеск cache miss после плановой смены записи ожидаем, а устойчивый рост SERVFAIL вместе с падением новых TLS-соединений — уже stop condition. Для старого peer задайте deadline, но исключите соединения, открытые до rollout и все еще передающие валидный stream. Такой разрез не наказывает корректные длинные ответы и одновременно замечает новые dial на устаревший адрес. После каждого game day обновляйте только те пороги, которые подтверждены наблюдением, а не удобной круглой цифрой.

Итог: управляйте состоянием, а не числом в TTL

DNS failover для LLM API надежен только тогда, когда команда видит всю цепочку состояния. Authoritative запись может быть свежей, recursive resolver — держать negative или stale data, приложение — собственный cache, а transport — старое живое соединение. TTL управляет RRset, но не заменяет drain, endpoint readiness и application canary.

Практический следующий шаг прост: выберите один production-подобный клиент и соберите для него evidence line «DNS answer → actual peer → LLM outcome». Затем выполните canary-переключение с отдельными A/AAAA, отрицательным контролем и симметричным rollback. Если результат нельзя объяснить по этим трем gates, массовый rollout еще рано начинать.

Когда вам нужна инфраструктура для такого теста, ищите не обещание «быстрее DNS», а контролируемую среду: выделенный gateway или node pool, наблюдаемый сетевой путь, право на drain/restart и воспроизводимый hardware profile для целевой модели. На VPS это удобно проверять в малом blast radius; на dedicated-серверах проще закрепить ресурсы и окно изменений. Главное — сначала доказать bottleneck. Тогда архитектура будет лечить конкретную проблему, а не просто добавлять еще один слой.

Зафиксируйте baseline сегодня, пока все работает: authoritative ответы, реальные resolver, peer IP и возраст соединений. В следующем инциденте эти пять минут подготовки сэкономят гораздо больше времени и позволят переключить LLM API без догадок.

Healthcheck зелёный, WireGuard-handshake есть, короткий запрос к private LLM API проходит — а длинный streaming-ответ внезапно замирает после первых данных или вообще не доходит до клиента. В такой ситуации легко обвинить GPU, reverse proxy или сам inference-сервер, хотя проблема может находиться ниже: пакет помещается в локальный интерфейс, но не помещается в реальный path MTU после инкапсуляции WireGuard. Если ICMP, необходимый для Path MTU Discovery, где-то отфильтрован, получается классический PMTUD black hole: соединение устанавливается, а крупные пакеты исчезают без полезной обратной связи. Ниже — production-runbook, который отделяет MTU-проблему от похожих симптомов, измеряет underlay и tunnel отдельно, а затем выбирает минимальный фикс вместо случайного уменьшения MTU. Все изменения проверяем canary-трафиком и симметричным rollback, чтобы не превратить сетевой тюнинг в новую причину простоя.

Быстрый verdict: когда подозревать MTU, а когда нет

MTU стоит проверять не потому, что «VPN иногда тормозит», а когда симптом зависит от размера данных. Типичный профиль: ICMP echo маленького размера проходит, TCP handshake завершается, TLS устанавливается, короткий JSON-ответ приходит, но передача заметно более крупного ответа или длинного SSE-потока останавливается. Ещё один сильный сигнал — один и тот же сервис стабилен напрямую, но воспроизводимо ломается через WireGuard или через конкретный site-to-site маршрут.

Для private LLM API это коварно: первый токен может прийти, а затем поток начинает висеть, потому что сетевой стек собрал более крупный сегмент или на пути появился пакет, который уже не помещается после внешней инкапсуляции. Но сам факт высокого TTFT ничего не доказывает. Если задержка одинаково воспроизводится вне VPN, GPU загружен, очередь запросов растёт или inference endpoint возвращает те же паузы по локальному интерфейсу, MTU — слабая гипотеза. Сначала отделите network-path symptom от application symptom.

То же относится к протоколу. MSS clamp влияет на TCP SYN и не исправляет произвольный UDP/QUIC path. Если проблема проявляется только в QUIC, исследуйте UDP PMTU и ICMP отдельно. Если же ломается TCP-трафик через VPN, у вас есть четыре независимых доказательства: underlay PMTU, effective MTU wg0, видимость ICMP «слишком большой пакет» и application canary. Пока хотя бы одно из них не измерено, не меняйте MTU по совету из чужой конфигурации.

Если вы только выбираете VPN-механизм, сначала полезно свериться с материалом «Какой VPN-протокол выбрать?». Здесь задача уже другая: WireGuard выбран и работает, но нужно доказать, почему конкретный production path теряет крупные пакеты.

Почему WireGuard меняет допустимый размер пакета

У интерфейса wg0 есть собственный MTU, но физически пакет едет не «внутри wg0». WireGuard берёт внутренний IP-пакет, шифрует его и отправляет через UDP поверх внешнего маршрута. Значит, внутренний пакет обязан оставить место для внешней оболочки. Если underlay действительно допускает 1500 байт, безопасный tunnel MTU будет ниже; если в underlay уже есть PPPoE, VXLAN, GRE, второй VPN или облачный overlay, реальный запас может оказаться ещё меньше.

Современный wg-quick умеет автоматически выбирать MTU, если параметр не задан. В текущем Linux-скрипте wg-quick выбор опирается на MTU маршрута до endpoint и затем оставляет консервативный запас; это хорошая отправная точка, но не доказательство end-to-end PMTU. Маршрут до endpoint на локальном хосте может выглядеть как 1500, а узкое место находиться дальше — у провайдера, в туннеле поверх туннеля или на асимметричном обратном пути.

Поэтому полезно держать в голове два числа. Interface MTU — что локальный интерфейс согласен принять для отправки. Path MTU — максимальный пакет, который реально пройдёт весь путь без фрагментации там, где она недопустима или нежелательна. PMTUD нужен именно для второго числа. Если обратная служебная информация не возвращается к отправителю, локальная настройка может выглядеть корректно, а приложение будет зависать на определённом размере трафика.

Практический disqualifier: если wg0 уже существенно меньше измеренного PMTU, но симптом не меняется при контролируемом уменьшении payload и одинаково виден на прямом маршруте, не продолжайте «резать MTU». Ищите L7 timeout, proxy buffering, перегрузку inference или иной bottleneck. Для архитектуры между площадками полезно держать рядом runbook по WireGuard site-to-site: там рассматривается топология и маршрутизация, а здесь — конкретная граница размера пакета.

Соберите baseline до изменения MTU

Сетевой тюнинг без baseline быстро превращается в гадание. До первого ip link set сохраните topology evidence: MTU интерфейсов, endpoint WireGuard, реальный маршрут до endpoint, маршрут до внутреннего peer и состояние TCP-соединения. Особенно важно записать, где находится фактический sender для проблемного потока. Если TLS завершается на reverse proxy, именно proxy может отправлять большие TCP-сегменты клиенту; если L4 passthrough сохраняет соединение до inference-сервера, граница другая.

Этот шаг защищает от типичной ошибки: MTU меняют на GPU-сервере, хотя узкий путь находится между VPN-gateway и клиентом. Для LLM streaming разделяйте pre-first-byte и post-first-byte. Если connection/TLS/TTFT проходят, а stall начинается уже после первого байта, сетевой hypothesis сильнее. Если первый байт не появляется вообще, сначала проверьте admission, upstream connect и timeout reverse proxy. Сравнение Nginx, Caddy и Traefik и их operational trade-offs есть в отдельном материале про reverse proxy.

Снимайте baseline на обеих сторонах туннеля. В production полезно прикрепить вывод команд к incident ticket: через час после временного фикса он будет ценнее памяти инженера о том, «кажется, там было 1500». Не публикуйте в тикете private keys: для диагностики достаточно peer endpoint, маршрутов, MTU и счётчиков.

ip -br link show
ip link show dev wg0
wg show wg0
ip route get 
ip route get 
ss -ti dst 

В выводе ss -ti смотрите не на одну «магическую» цифру, а на контекст: retransmissions, negotiated MSS и динамику соединения во время воспроизведения. Один snapshot не доказывает PMTU black hole, но помогает связать сетевой механизм с реальным application stall.

Gate 1: измерьте PMTU снаружи туннеля

Первый gate — underlay, то есть путь от WireGuard endpoint до WireGuard endpoint без внутреннего трафика. tracepath умеет оценивать PMTU по пути, а ping с режимом -M do позволяет отправлять IPv4 probe с DF и менять размер полезной нагрузки. Не превращайте 1472 в универсальную константу: это лишь удобный тест гипотезы о 1500-байтовом IPv4 path, потому что к payload добавляются заголовки IPv4 и ICMP.

Начните с ожидаемого верхнего значения, затем уменьшайте payload до устойчиво проходящего размера. Повторите тест с другой стороны: асимметричный маршрут способен дать разные результаты. Для IPv6 PMTUD является обязательной частью модели передачи: маршрутизатор не фрагментирует пакет за отправителя, а сообщает о слишком большом пакете через ICMPv6 Packet Too Big. Базовая логика описана в RFC 8201; для IPv4 классическое описание PMTUD — RFC 1191.

tracepath -4 
ping -4 -M do -c 3 -s 1472 
ping -4 -M do -c 3 -s 1400 

tracepath -6 
ping -6 -M do -c 3 -s 1452 

Если 1472 не проходит, а 1400 стабилен, это ещё не повод поставить MTU 1400 везде. Вы доказали только наличие границы между этими значениями. Найдите устойчивый PMTU, учтите внешнюю инкапсуляцию WireGuard и только потом выбирайте MTU wg0. Если tracepath показывает одно, а реальный TCP flow ведёт себя иначе, проверьте policy routing, ECMP и тот ли destination вы измеряете.

Gate 2: измерьте внутренний путь через wg0

Следующий gate проверяет уже внутренний пакет. Сначала прочитайте effective MTU интерфейса wg0, затем вычислите максимальный ICMP payload, который должен помещаться внутрь этого MTU. Для IPv4 из MTU вычитаются заголовки IP и ICMP; для IPv6 заголовок IP больше. Эти расчёты нужны не для «тюнинга по формуле», а чтобы probe совпал с фактическим интерфейсным лимитом.

WG_MTU=$(cat /sys/class/net/wg0/mtu)
V4_PAYLOAD=$((WG_MTU - 28))
V6_PAYLOAD=$((WG_MTU - 48))

ping -4 -I wg0 -M do -c 3 -s "$V4_PAYLOAD" 
ping -6 -I wg0 -M do -c 3 -s "$V6_PAYLOAD" 

Положительный результат означает только то, что этот probe проходит. Обязателен отрицательный контроль: увеличьте payload на несколько байт в отдельном тесте и убедитесь, что граница вообще наблюдаема, либо используйте меньший размер, чтобы увидеть, что symptom исчезает. Если любой размер внутри wg0 теряется, проблема может быть не MTU: проверьте AllowedIPs, routing, firewall и peer state.

На production-пути не стоит генерировать агрессивный flood. Нескольких повторяемых probe достаточно, а дальше нужен application canary. Цель — связать механизм с пользовательским симптомом: уменьшение внутреннего packet size должно менять сетевой результат, а корректный MTU — восстанавливать тот же LLM stream без изменения модели, proxy timeouts и GPU-параметров.

PMTUD black hole: проверьте ICMP, firewall и cloud ACL

PMTUD black hole возникает, когда отправитель посылает слишком большой пакет, промежуточный узел не может его передать как есть, но служебное сообщение о проблеме не доходит обратно. Именно поэтому соединение может казаться «почти рабочим»: handshake и маленькие сегменты проходят, а более крупная передача застывает. Этот класс проблем описан ещё в RFC 2923, и он по-прежнему встречается в современных overlay-сетях.

Проверяйте не правило «ICMP разрешён вообще», а конкретный путь и конкретный тип сообщения. На Linux capture на обеих сторонах часто быстрее любого чтения firewall-конфига: вы увидите, появляется ли ICMP/ICMPv6 на одном интерфейсе и исчезает ли на другом. Одновременно посмотрите counters wg0. Если ошибка возникает до шифрования, картина будет отличаться от ситуации, когда outer UDP дошёл до удалённого endpoint, но обратный control path пропал.

tcpdump -ni any 'icmp or icmp6'
nft list ruleset
ip -s link show dev wg0

В облачной или распределённой сети проверьте все policy layers: host firewall, security group/ACL, edge firewall, DDoS-политику и промежуточный VPN/router. Опасная практика — «для безопасности запретить весь ICMP». ICMP не является одним бесполезным ping-протоколом; часть сообщений нужна сетевому стеку для корректной работы path discovery. Если политика требует фильтрации, разрешайте необходимые типы осознанно и документируйте владельца правила.

Отрицательный контроль здесь очень полезен: временно воспроизведите тот же запрос по path, где PMTUD feedback заведомо доходит. Если проблема исчезает без изменения LLM stack, вы локализовали слой. Если не исчезает — не расширяйте firewall «на всякий случай».

Исправление 1: задайте MTU осознанно

Если underlay gate доказал меньший PMTU, а tunnel probe воспроизводит границу, самый прямой фикс — снизить MTU wg0 так, чтобы внутренний пакет гарантированно помещался во внешний path. Не копируйте 1420, 1380 или 1280 из форума: эти числа могут быть правильными для чужой топологии и неверными для вашей. Сначала получите собственный PMTU, затем оставьте консервативный запас под WireGuard outer transport и проверьте оба направления.

Текущий Linux wg-quick при автоматическом выборе MTU резервирует 80 байт относительно найденного underlay MTU. Эту логику удобно использовать как ориентир при диагностике, особенно когда endpoint может идти по IPv6. Но если вы вручную измерили реальный end-to-end PMTU, применяйте рассчитанное значение как canary, а не как мгновенный глобальный rollout.

# Пример: 1460 здесь — измеренный ВАМИ underlay PMTU, а не универсальное число
UNDERLAY_PMTU=1460
WG_MTU=$((UNDERLAY_PMTU - 80))

ip link set dev wg0 mtu "$WG_MTU"
ip link show dev wg0

После успешного canary закрепите проверенное целое значение через MTU = ... в конфигурации wg-quick и отдельно протестируйте restart. Не полагайтесь на временный runtime state: после reboot он исчезнет. Сохраните старое значение как rollback target и повторите те же probes после отката. Если application SLO не возвращается к baseline при возврате старого MTU, причинность не доказана.

Слишком маленький MTU тоже имеет цену: больше пакетов и выше packet-processing overhead. Цель — не «сделать поменьше, чтобы наверняка», а найти наибольшее устойчивое значение для вашего пути с достаточным запасом под реальную инкапсуляцию. В инфраструктуре с несколькими локациями полезно держать profile по каждому path вместо одного глобального числа.

Исправление 2: MSS clamp — страховка, а не замена PMTUD

MSS clamping уменьшает Maximum Segment Size, который TCP стороны объявляют в SYN. Это позволяет с самого начала формировать сегменты, лучше соответствующие path MTU. При VPN и старых сетях метод полезен, когда вы контролируете gateway, а корректный ICMP feedback невозможно гарантировать. Но важно понимать границу: MSS существует только в TCP. UDP, QUIC и уже установленные соединения не получают волшебного исправления.

В nftables route MTU можно использовать как источник для корректировки MSS. Пример ниже предполагает, что таблица и chain уже существуют; в вашей системе имя таблицы, family и hook могут отличаться. Проверьте правило через тестовую конфигурацию и убедитесь, что оно применяется к SYN в нужных направлениях.

nft add rule ip filter forward tcp flags syn tcp option maxseg size set rt mtu
nft add rule ip6 filter forward tcp flags syn tcp option maxseg size set rt mtu

Если используется iptables-совместимый стек, цель TCPMSS с --clamp-mss-to-pmtu решает похожую задачу; man page прямо описывает её как workaround для «браузер подключается, затем висит» при сломанном PMTUD. Но у route-based clamp есть caveat: асимметричный forward/reverse path способен иметь разные MTU. Поэтому после правила всё равно нужны captures и application tests, а не только отсутствие retransmission на одном соединении.

Правильная последовательность такая: сначала починить PMTUD там, где вы владеете сетью; затем применять MSS clamp как documented compatibility layer для TCP-path, который вы не можете полностью контролировать. Если clamp внезапно «лечит всё», это ещё один сигнал вернуться и найти потерянный ICMP feedback.

Linux tcp_mtu_probing: когда включать

Linux умеет включать TCP MTU probing при обнаружении ICMP black hole. Актуальная документация kernel для net.ipv4.tcp_mtu_probing описывает три режима: 0 — выключено, 1 — включать probing при обнаружении black hole, 2 — всегда использовать probing с начального базового MSS. Для production-разбора разумно начинать с текущего значения и, если механизм действительно нужен, тестировать режим 1 как ограниченную страховку, а не сразу включать 2 глобально.

sysctl net.ipv4.tcp_mtu_probing

# Временный canary: включать probing при обнаружении black hole
sysctl -w net.ipv4.tcp_mtu_probing=1

# Rollback
sysctl -w net.ipv4.tcp_mtu_probing=0

Документация ядра: IP sysctl — tcp_mtu_probing. Важно: этот sysctl не «чинит WireGuard». Он меняет поведение TCP stack, когда обнаруживается проблема с packet size. Если root cause — заблокированный ICMP, неправильный MTU интерфейса или дополнительный overlay, инфраструктурный дефект остаётся.

Проверяйте effective state на том же host/process path, который обслуживает трафик. В контейнеризированной среде отдельно убедитесь, какой network namespace формирует TCP connection и на каком узле применён sysctl. После canary повторите тот же запрос и тот же packet-size test. Если улучшения нет, откатите параметр и не оставляйте глобальный sysctl «на всякий случай».

Canary rollout для private LLM API

Сетевой фикс считается готовым не тогда, когда ping прошёл, а когда application outcome восстановлен. Для private LLM API соберите один воспроизводимый запрос с достаточно длинным streaming-ответом и прогоняйте его по одному и тому же маршруту до и после изменения. Одновременно наблюдайте TCP/ICMP и метрики proxy. Не меняйте модель, prompt, timeout и MTU в одном эксперименте: иначе вы не узнаете, что именно помогло.

Если API построен как внутренний аналог OpenAI-compatible endpoint, полезно заранее разделить access path, gateway и inference pool; архитектурный контекст есть в материале про Private AI API на своих серверах. Здесь нас интересует только один canary route. На первом шаге направьте через новый MTU профиль малую долю клиентов или отдельный peer, затем сравните completion success, stream stalls, retransmissions и жалобы на timeout с baseline.

curl -N --http1.1 https:///v1/chat/completions \
  -H 'Content-Type: application/json' \
  -H "Authorization: Bearer $LLM_TOKEN" \
  -d @request.json

--http1.1 здесь нужен не как рекомендация навсегда, а как способ зафиксировать protocol variant для эксперимента. Если production использует HTTP/2, повторите canary отдельно через HTTP/2 и сравните. Секрет не вставляйте прямо в shell history: используйте переменную окружения или безопасный secret injection.

Stop condition должна быть определена заранее: рост ошибок, потеря connectivity peer, ухудшение latency или новый класс stall — немедленный rollback к прежнему MTU/sysctl/rule. После успешного canary перезапустите туннель или узел в контролируемом окне и повторите те же gates. Это проверяет не только runtime tweak, но и то, что конфигурация переживает lifecycle.

Production-чеклист: как не вернуть black hole через месяц

MTU-инциденты часто возвращаются после изменения внешнего маршрута, миграции в другой ЦОД или добавления ещё одного overlay. Поэтому фикс должен стать частью network profile, а не знанием одного инженера. Зафиксируйте, какой underlay PMTU измерен для каждой пары локаций, какой MTU выставлен на WireGuard и почему, где допускается MSS clamp и какой мониторинг должен сработать при повторном symptom.

• Ownership: кто владеет wg0, firewall и provider ticket, если PMTU меняется вне вашей зоны.
• Evidence: сохранённые tracepath/ping results и дата измерения.
• Config: MTU закреплён в deployment/config management, а не только runtime-командой.
• Negative control: direct path без VPN и заведомо небольшой payload остаются частью incident playbook.
• Application probe: длинный LLM streaming-request запускается после сетевых изменений.
• Rollback: старое значение MTU и правила firewall можно вернуть одним контролируемым change.

Если инфраструктура распределена между офисом, облаком и dedicated-серверами, MTU следует рассматривать как свойство конкретного path class. Один peer может идти напрямую по 1500-byte Ethernet, другой — через provider overlay, третий — через дополнительный IPsec. Одна глобальная константа для всех туннелей удобна только на бумаге.

Коммерческий смысл выделенного узла здесь не в обещании «меньшего ping», а в границе контроля. На dedicated/VPS, где вы управляете WireGuard endpoint, firewall, routing и change window, проще воспроизвести baseline, выполнить canary и откатить изменение. Если endpoint или middlebox находится у внешнего владельца, заранее включите его в runbook — иначе network ownership будет выясняться уже во время инцидента.

Вывод: лечите путь, а не симптом

WireGuard MTU problem становится управляемой, когда вы перестаёте начинать с числа «1420» и строите цепочку доказательств. Сначала подтвердите, что symptom зависит от размера трафика и действительно появляется на VPN-path. Затем измерьте PMTU внешнего маршрута, отдельно проверьте внутренний путь через wg0, убедитесь, что ICMP/Packet Too Big не теряется, и только после этого выбирайте MTU, MSS clamp или TCP probing.

Для private LLM API финальный gate всегда application-level: тот же streaming-request должен стабильно завершаться после изменения и снова воспроизводить старое поведение при контролируемом rollback, если вы хотите доказать причинность. Ping и tracepath объясняют механизм, но пользовательский поток доказывает результат.

Если ваш WireGuard path проходит через несколько провайдеров, overlay или площадок, сохраните этот runbook как повторяемый checklist и прогоняйте его после сетевых миграций. А если нужен отдельный VPS, dedicated gateway или GPU-инфраструктура, где можно зафиксировать network profile и провести canary без воздействия на весь production, начинайте с небольшого воспроизводимого контура — он даст больше информации, чем очередной глобальный sysctl.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Быстрый вердикт: DRA нужен не каждому GPU-кластеру

Если текущий inference стабильно получает целый GPU через nvidia.com/gpu, а команде не нужны фильтры по свойствам устройства, совместное использование claim или конфигурация на уровне workload, срочной миграции нет. Dynamic Resource Allocation меняет не скорость матричного умножения, а договор между планировщиком, драйвером и приложением. Польза появляется там, где «один GPU» уже слишком грубая единица описания.

Практический кандидат на DRA — платформа с несколькими типами ускорителей, отдельными SLA для команд и потребностью доказать, какой именно device получил Pod. Kubernetes описывает DRA как стабильный механизм начиная с v1.35; он использует DeviceClass, ResourceSlice и ResourceClaim, а драйвер готовит устройство для контейнера через CDI. При этом preemption для DRA-ресурсов пока не поддерживается: высокоприоритетный Pod может остаться Pending, пока занятый device не освободится. Это важный disqualifier для очередей, где приоритет должен немедленно вытеснять низкий класс нагрузки.

В этой инструкции мы не обещаем «бесшовную миграцию». Для актуального GPU Operator 26.7 и NVIDIA DRA Driver v0.5.0 официальный путь с объектом GPUCluster рассчитан на новую установку; переход in-place с ClusterPolicy не поддерживается. Поэтому рабочая стратегия — отдельный canary-кластер или новый GPU-pool с независимым control plane, воспроизводимым baseline и маршрутом отката. Общую картину Kubernetes-инференса полезно сверить с материалом про KServe, GPU Operator и autoscaling, но здесь фокус уже: только выделение GPU и evidence chain.

Как работает DRA: четыре объекта вместо одного счётчика

Device Plugin публикует extended resource, после чего Pod просит, например, один nvidia.com/gpu. Эта модель проста, но планировщик видит главным образом количество. DRA переносит описание устройства в API. Драйвер создаёт ResourceSlice с доступными devices и их атрибутами; администратор или vendor предоставляет DeviceClass; workload создаёт ResourceClaim либо ResourceClaimTemplate; scheduler выбирает подходящий device и записывает allocation в статус claim.

Такую цепочку удобно сравнить с динамическими томами. StorageClass описывает класс хранилища, PVC формулирует запрос, а control plane подбирает ресурс. В DRA роль PVC выполняет ResourceClaim, только объектом становится GPU, NIC, FPGA или другой device. Аналогия не полная: подготовку устройства на узле выполняет DRA driver через gRPC-вызовы kubelet, а доступ в контейнер обычно материализуется через CDI.

Главная operational-прибавка — наблюдаемость решения. При Pending можно отдельно спросить: рекламирует ли драйвер ResourceSlice, существует ли DeviceClass, создан ли claim, получил ли он allocation, зарезервирован ли за Pod и завершился ли NodePrepareResources. Это лучше, чем один симптом «Insufficient nvidia.com/gpu». Но объектов становится больше, а значит нужны RBAC, события, алерты и владелец каждого слоя.

Версии, feature state и стоп-условия до установки

На 15 сентября 2026 года upstream Kubernetes помечает core DRA как Stable с v1.35. Документация NVIDIA GPU Operator 26.7 для управляемого DRA-пути требует Kubernetes v1.34.2 или новее, API resource.k8s.io с DeviceClass, драйвер NVIDIA 580+ и runtime с CDI. Для нового проекта разумнее брать Kubernetes 1.36+ не из-за моды, а потому что DRAExtendedResource там включён по умолчанию и путь совместимости проще контролировать.

Не смешивайте стабильность core API со зрелостью каждой vendor-функции. NVIDIA прямо предупреждает, что часть возможностей DRA driver остаётся alpha. Например, VFIO passthrough требует отдельного alpha feature gate, а ComputeDomain предназначен для систем с Multi-Node NVLink вроде HGX GB200/GB300 и несёт собственные требования к IMEX. Если ваш inference живёт на обычных PCIe GPU в одном узле, отключение ComputeDomain уменьшит поверхность отказа.

Стоп-условия просты: существующий ClusterPolicy в целевом кластере, неподтверждённый CDI, version skew между control plane и kubelet, отсутствие тестового маршрута или невозможность вернуть трафик на старый pool. Не обходите их широкими правами и ручными правками сокетов. Отдельная статья про MIG и MPS помогает выбрать способ деления GPU, но DRA не превращает неподдерживаемый режим sharing в безопасный автоматически.

Baseline и inventory: что снять до первого Helm upgrade

До изменений сохраните evidence bundle. Нужны версии API server и kubelet, фактический драйвер на каждом GPU-узле, runtime config, наличие CDI spec, список GPU UUID, topology, текущие DaemonSet и ClusterPolicy. Отдельно снимите application baseline: время готовности реплики, успешность тестового запроса, используемая модель, GPU UUID внутри контейнера и ключевые DCGM-метрики. Это не benchmark для статьи, а ваша контрольная точка.

Записывайте не только «команда прошла», но и ожидаемую границу. Положительный тест: существующий Pod видит ровно тот GPU, который ему выделен. Отрицательный: соседний GPU недоступен, а workload с несовместимым селектором остаётся Pending с объяснимым событием. Именно отрицательный контроль ловит конфигурации, где контейнер случайно получил весь /dev/nvidia*.

Для canary выделите отдельный namespace, route и набор запросов. Не используйте первый production Pod как тестовый стенд. Если кластер уже занят jobs с checkpointing или online inference, заранее определите окно, владельца остановки и максимальную длительность Pending. Сравнивать нужно одинаковую модель и одинаковый профиль запроса; иначе изменение latency нельзя будет связать с DRA.

kubectl version
kubectl api-resources --api-group=resource.k8s.io
kubectl get nodes -o wide
kubectl get clusterpolicy
kubectl get pods -A -o wide | grep -E 'nvidia|gpu'
kubectl get deviceclass,resourceslice,resourceclaim -A
nvidia-smi --query-gpu=uuid,name,driver_version,pci.bus_id --format=csv

Разворачиваем новый GPUCluster, не ломая рабочий pool

Для GPU Operator 26.7 управляемый DRA-путь создаёт singleton GPUCluster с именем gpu-cluster. Он заменяет ClusterPolicy как корневой объект именно в этом workflow. NVIDIA не поддерживает их совместное существование в одном кластере и не поддерживает in-place migration. Поэтому ниже команда предназначена для нового canary-кластера, где kubectl get clusterpolicy не возвращает объект.

Зафиксируйте chart version в values или команде, а не устанавливайте «latest». Если драйвер уже управляется на хосте, используйте вариант с driver.enabled=false; если Operator должен ставить драйвер через NVIDIADriver, включите соответствующий CRD. Для обычных PCIe GPU без Multi-Node NVLink отключите ComputeDomain, чтобы не развертывать ненужные компоненты.

После Helm не переходите сразу к workload. Сначала ждите Ready у GPUCluster, затем проверьте Pods оператора, DeviceClass и ResourceSlice. gpu.nvidia.com должен существовать, а ResourceSlice — рекламировать устройства на ожидаемых узлах. Если GPUCluster сообщает PrerequisiteNotMet, ищите ClusterPolicy; OperandNotReady означает, что один из управляемых компонентов ещё не готов.

helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update

helm upgrade --install gpu-operator nvidia/gpu-operator \
  --version=v26.7.0 \
  --namespace gpu-operator \
  --create-namespace \
  --set clusterPolicy.deployCR=false \
  --set gpuCluster.deployCR=true \
  --set driver.enabled=false \
  --set draDriver.computeDomains.enabled=false

kubectl get gpucluster gpu-cluster
kubectl get pods -n gpu-operator
kubectl get deviceclass
kubectl get resourceslice

ResourceClaimTemplate для inference-реплик

Для stateless inference Deployment обычно удобен ResourceClaimTemplate: каждая реплика получает отдельный claim с тем же классом требований, а Kubernetes управляет его жизненным циклом вместе с Pod. Заранее созданный ResourceClaim нужен, когда несколько контейнеров или Pods действительно должны ссылаться на один device и драйвер поддерживает такой режим. Не выбирайте shared claim только ради экономии GPU: isolation и scheduling semantics должны быть доказаны отдельно.

Минимальный запрос к NVIDIA-классу использует resource.k8s.io/v1 и deviceClassName: gpu.nvidia.com. В Pod template имя из spec.resourceClaims повторяется в resources.claims контейнера. Ниже образец показывает структуру, а image и probes оставляет вашей платформе: копировать случайный LLM container в production было бы хуже, чем честно обозначить точку интеграции.

Селекторы CEL добавляйте только после просмотра реальных attributes и capacity в ResourceSlice вашей версии драйвера. Не выдумывайте имя поля памяти или product name по примеру другого vendor. Сначала kubectl get resourceslice -o yaml, затем выражение, затем отрицательный claim с заведомо недоступным условием. Если отрицательный Pod внезапно стартовал, selector не обеспечивает ожидаемую границу.

apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: llm-gpu
spec:
  spec:
    devices:
      requests:
      - name: inference-gpu
        exactly:
          deviceClassName: gpu.nvidia.com
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: llm-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: llm-canary
  template:
    metadata:
      labels:
        app: llm-canary
    spec:
      containers:
      - name: server
        image: YOUR_PINNED_LLM_IMAGE
        resources:
          claims:
          - name: gpu
      resourceClaims:
      - name: gpu
        resourceClaimTemplateName: llm-gpu

Три evidence gate: API, node runtime, LLM

Первый gate принадлежит platform team и доказывает desired state. ResourceClaim создан, в status есть allocation, reservedFor ссылается на нужный Pod, scheduler выбрал ожидаемый узел. События не содержат повторяющегося allocation failure. На этом этапе GPU ещё не считается пригодным для модели: control plane мог принять решение, а node preparation — провалиться.

Второй gate принадлежит node/runtime owner. Kubelet вызвал NodePrepareResources, DRA plugin здоров, CDI spec применён, внутри контейнера виден выделенный GPU UUID и не виден соседний. Сопоставьте UUID с ResourceSlice и host inventory. Если контейнер видит device, но UUID не тот, это failure, даже когда nvidia-smi возвращает ноль.

Третий gate принадлежит владельцу inference. Startup/readiness проходят, модель загружена, тестовый запрос даёт ожидаемый контракт ответа, а GPU-метрики меняются именно на выделенном device. Сравните с baseline в одинаковом режиме. DRA не исправляет медленное чтение весов, NUMA-удалённую память или app-limited networking; при деградации полезны отдельные runbook, например про NUMA-locality GPU inference.

Повышайте трафик только после трёх PASS подряд и отрицательного контроля. Эта последовательность не бюрократия: она локализует владельца сбоя. Если allocation пуст, бессмысленно тюнить vLLM. Если claim корректен, но CDI не подготовил устройство, autoscaling только размножит Pending.

kubectl get pods -n llm-canary -o wide
kubectl get resourceclaim -n llm-canary
kubectl describe resourceclaim -n llm-canary
kubectl describe pod -n llm-canary -l app=llm-canary
kubectl logs -n gpu-operator -l app.kubernetes.io/name=nvidia-dra-driver-gpu --all-containers --tail=200

POD=$(kubectl get pod -n llm-canary -l app=llm-canary -o jsonpath='{.items[0].metadata.name}')
kubectl exec -n llm-canary "$POD" -- nvidia-smi -L
kubectl get --raw /readyz

Диагностика Pending без хаотичных рестартов

Идите сверху вниз по одной и той же цепочке. Если ResourceClaimTemplate не породил claim, проверьте ссылку в Pod spec, controller-manager и старые mutating webhooks. Upstream отдельно отмечает ошибку, когда webhook, собранный против старого API, оставляет несовместимые поля. Перезапуск kubelet здесь не поможет: сбой ещё в control plane.

Если claim есть, но allocation пуст, смотрите DeviceClass, ResourceSlice, CEL и события scheduler. Подходящее устройство должно быть доступно на узле, который одновременно удовлетворяет обычным requests, affinity и taints Pod. DRA использует first-fit и рассматривает pools/ResourceSlices в лексикографическом порядке, поэтому имя и состав pool могут влиять на повторяемость выбора. Не подменяйте диагностику ручным spec.nodeName: такой Pod обходит scheduler и способен зарезервировать CPU/RAM на узле, оставаясь неработоспособным.

Если Pod уже назначен, но sandbox или контейнер не стартует, переходите к kubelet, DRA plugin gRPC, CDI и runtime logs. При обновлении драйвера running Pods обычно продолжают работать, но новые Pods могут не стартовать, а cleanup claim задержится. Поэтому DRA DaemonSet надо drain-ить последним, когда пользовательские Pods и их claims уже освобождены.

Наконец, если inference медленный при здоровых первых двух gate, остановитесь. Это application или hardware-path проблема. Проверьте загрузку модели, storage, NUMA, power cap и сеть. Материал про power cap GPU показывает тот же принцип: сначала механизм, затем метрика приложения, затем rollback-контрфакт.

Rollout и rollback: отдельные lanes, одинаковые проверки

Безопасный rollout состоит из четырёх ступеней. Baseline фиксирует старый Device Plugin lane. Canary запускает одну реплику в новом DRA-кластере и только синтетические запросы. Shadow получает копию production traffic без влияния на ответ пользователю. Cutover переносит малую долю реального трафика и растёт только при стабильных gate. Проценты и окна выбирайте по своему SLO; универсальных чисел здесь нет.

Старый и новый механизм не должны бороться за один физический GPU. Разведите узлы или кластеры, маршруты и capacity accounting. Сохраните один и тот же model artifact, tokenizer, runtime image и профиль запроса. Иначе команда увидит разницу, но не узнает, породил её DRA, новый драйвер или обновлённая модель.

Rollback повторяет доказательства в обратном направлении: вернуть route на baseline, дождаться завершения canary requests, удалить user workloads и claims, подтвердить NodeUnprepareResources, затем разбирать DRA. NVIDIA предупреждает не использовать helm uninstall --no-hooks при существующем GPUCluster: pre-delete hook и finalizer обеспечивают упорядоченное удаление managed DaemonSets до kubelet plugin. Обход hook может оставить GPUCluster и claims без контроллера.

Stop condition формулируйте заранее: необъяснимый Pending, неправильный GPU UUID, рост error rate, failure readiness, невозможность освободить claim или расхождение telemetry attribution. Остановка означает возврат трафика, а не двадцать рестартов. Именно здесь отдельный canary-кластер окупает кажущуюся сложность.

RBAC, квоты и наблюдаемость DRA

DeviceClass и ResourceSlice относятся к административной поверхности: их должны изменять драйвер и cluster admins. Командам приложений обычно достаточно namespace-scoped ResourceClaim и ResourceClaimTemplate. Начиная с Kubernetes 1.36 hardening guide описывает отдельные synthetic subresources для обновления статуса: binding для scheduler/allocation controller и driver для node-local или multi-node компонента. Не выдавайте приложению право менять ResourceSlice только потому, что claim остаётся Pending.

Квоты теперь можно строить по DeviceClass. Это помогает ограничить число claims в namespace, но quota не заменяет поддержку sharing самим драйвером. Сумма «запрошено» и реальное потребление GPU могут отличаться, особенно с экспериментальными capacity-механизмами. Для production сначала квотируйте простые whole-device claims и расширяйте модель после canary.

Наблюдайте workqueue ResourceClaim controller, scheduler latency, health DRA plugin, длительность claim allocation и unprepare, Pending reasons и GPU telemetry с привязкой к Pod. GPUCluster включает DCGM Exporter по умолчанию; актуальный Operator умеет обогащать метрики данными ResourceSlice при включённых pod labels/UID. При высокой churn-нагрузке DRA добавляет API-вызовы и работу controller-manager, поэтому алерт только по GPU utilization недостаточен.

Проверяли ли вы освобождение claim после crash-loop и удаления Pod? Утечка reservation незаметна при низкой загрузке, а в пик превращается в «свободный GPU есть, новый Pod не стартует». В тесте обязательно создайте и удалите workload несколько раз, сохранив события и время cleanup, но не выдавайте результаты стенда за универсальный benchmark.

Для дежурной смены полезен короткий decision tree: claim не создан — controller или admission; allocation пуст — scheduler, class, slice и selector; Pod bound — kubelet, driver и CDI; модель не ready — application. В алерте передавайте namespace, Pod UID, claim name, selected node и device identity. Без этих полей инженер снова начнёт с общего списка Pods и потеряет время на переход между владельцами.

Когда выделенная GPU-инфраструктура упрощает DRA

DRA полезнее всего там, где inventory стабилен и известен платформе: конкретные модели GPU, одинаковый driver branch, предсказуемая PCIe/NUMA-топология и контролируемый container runtime. На выделенных GPU-серверах проще зафиксировать этот baseline, изолировать canary-pool и повторить hardware profile при расширении. Это не обещание ускорения; это уменьшение числа неизвестных в rollout.

Qualifying condition для нового пула — существующая боль от грубого extended resource: разные GPU под одним именем, ручные node labels, сложный sharing или слабая трассировка allocation. Disqualifier — единичный сервер с одним типом GPU и стабильным Deployment, где Device Plugin полностью закрывает задачу. В последнем случае новый control plane добавит больше сопровождения, чем ценности.

При выборе хостинга спрашивайте не «поддерживает ли он Kubernetes», а кто владеет драйвером, можно ли закрепить версию, включён ли CDI, доступна ли нужная topology и есть ли отдельные узлы для canary. Для multi-node NVLink уточняйте ComputeDomain и IMEX отдельно; обычная сеть между PCIe-серверами не становится MNNVL от установки DRA driver.

King Servers здесь уместен как инфраструктурная основа для воспроизводимого пилота: выделенные GPU-узлы, отдельная сеть и возможность сохранить старый pool на время проверки. Решение всё равно принимает команда по evidence gate. Сначала докажите allocation, runtime и LLM outcome, затем переносите трафик.

Перед заказом capacity составьте минимальную матрицу: модель GPU и объём памяти, число независимых failure domains, требования к локальному NVMe, скорость сети, версия Kubernetes, способ управления NVIDIA driver и окно обслуживания. Она не заменяет sizing LLM, зато не даёт купить ускорители, которые затем нельзя одинаково описать через DeviceClass или безопасно вывести в canary. Стабильный hardware profile ценнее красивой спецификации, если цель — воспроизводимый rollout.

Итог: мигрируйте договор выделения GPU, а не YAML

NVIDIA DRA Driver переводит GPU из безымянного счётчика в ресурс с классом, атрибутами, claim и наблюдаемым жизненным циклом. Это сильный инструмент для неоднородных GPU-парков и platform teams, но он не ускоряет модель сам по себе и не заменяет MIG, MPS, очередь или application profiling.

Рабочий маршрут на Kubernetes 1.36+ и GPU Operator 26.7 выглядит так: новый canary-кластер без ClusterPolicy, driver 580+, CDI, GPUCluster Ready, DeviceClass и ResourceSlice, один ResourceClaimTemplate, затем три независимых gate. После каждого шага оставляйте отрицательный контроль и готовый rollback. При любом необъяснимом расхождении возвращайте route на baseline, а не расширяйте права и не обходите finalizer.

Начните с evidence bundle и одного canary Pod. Если claim выделяется, контейнер видит ровно нужный GPU, а LLM проходит тот же probe, у вас есть основание для shadow traffic. Если нет, цепочка объектов уже подсказывает, какой владелец и какой слой должны чинить проблему. Это и есть главная практическая ценность DRA: не магия, а проверяемый контракт между железом, Kubernetes и приложением.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Где на самом деле живёт задержка LLM-стрима

У LLM API слово latency слишком легко превращается в один общий график. Для диагностики этого недостаточно. Минимум разделите путь на три наблюдаемых интервала: время до первого байта/токена, паузы между последующими чанками и полную длительность ответа. Первый интервал часто определяется очередью запросов, prefill, доступностью GPU, cold start модели или работой gateway. Второй уже сильнее зависит от decode cadence, buffering и сетевой доставки. Третий смешивает всё сразу.

Практический пример: TTFT вырос с обычного уровня, а после первого токена поток идёт ровно. Это плохой кандидат для BBR: congestion control не сокращает очередь на GPU. Обратная картина — первый токен появляется вовремя, но далее клиент видит нерегулярные паузы, RTT под нагрузкой растёт, на sender-сокете видны retransmissions или очередь qdisc. Вот здесь сетевой слой уже заслуживает отдельного canary-теста.

Ещё одна типичная ловушка — настроить не тот хост. Если внешний TCP завершается на reverse proxy, ingress-controller или L7 gateway, именно он является sender для клиентского соединения. Изменение TCP congestion control на backend с vLLM не обязано повлиять на WAN-сегмент до пользователя. Для архитектуры gateway полезно сначала свериться с материалом про Private AI API, а для проблем на GPU — с разбором GPU throttling через DCGM и Prometheus.

Поэтому первый gate простой: вы должны назвать конкретный TCP sender, интерфейс, клиентский сегмент и пользовательскую метрику, которую собираетесь улучшить. Если этого нет, смена алгоритма — тюнинг вслепую.

Что BBR и fq действительно меняют в Linux

BBR — congestion control для TCP, который опирается на модель пропускной способности пути и RTT и управляет тем, сколько данных и с какой скоростью отправлять. В Linux алгоритм для новых соединений выбирается через net.ipv4.tcp_congestion_control; список уже зарегистрированных вариантов виден в net.ipv4.tcp_available_congestion_control. Документация ядра подчёркивает важную деталь: изменение sysctl задаёт алгоритм именно для новых TCP-соединений, поэтому проверять результат на старом keep-alive сокете бессмысленно.

fq — classless qdisc, рассчитанный прежде всего на локально генерируемый трафик. Он разделяет потоки и умеет уважать pacing, заданный TCP stack. Это не «ускоритель BBR», а scheduler на egress, который помогает выпускать пакеты во времени более управляемо. После перехода Linux на EDT TCP-level pacing больше не делает fq формально обязательным для работы BBR; Google отдельно отмечает, что на современных ядрах BBR может работать и с другими qdisc, хотя fq остаётся полезным на нагруженных серверах.

Отсюда главный operational вывод: тестировать нужно пару механизмов, а не магическую строку из старого блога. Сначала убедитесь, какой congestion control реально назначен сокету; затем — какой root qdisc реально висит на нужном интерфейсе. net.core.default_qdisc показывает дефолт для создаваемых qdisc, но фактическое состояние интерфейса смотрите через tc qdisc show.

Не путайте и версии BBR. Ветка Google BBRv3 существует отдельно от стандартного bbr, поставляемого конкретным дистрибутивным ядром. Нельзя по одному имени sysctl заключить, что у вас именно v3: это проверяется по происхождению и сборке ядра. Для production-runbook разумнее начинать с того BBR, который поддерживается вашим kernel/vendor profile, а экспериментальную ветку выносить в отдельный change.

Baseline начинается с identity: какой сокет, интерфейс и qdisc вы меняете

До любых изменений соберите evidence bundle. Нужны версия ядра, доступные congestion control, текущий алгоритм, реальный qdisc интерфейса, состояние NIC и несколько живых TCP-сокетов. Это защищает от самой неприятной ошибки: вы включили BBR на backend, а клиентский TCP на самом деле живёт в другом network namespace, на proxy или вообще в отдельном узле.

Сначала определите интерфейс по маршруту до тестового клиента: ip route get CLIENT_IP. Если сервис в контейнере, проверьте, где заканчивается TCP — в pod, host network, ingress или внешнем балансировщике. На bare metal и обычном VPS sender чаще очевиден, но и там source policy routing или bonding могут отправлять трафик не через тот интерфейс, который вы выбрали по имени.

IFACE=ens5

uname -r
ip route get 203.0.113.10
sysctl net.ipv4.tcp_congestion_control
sysctl net.ipv4.tcp_available_congestion_control
sysctl net.core.default_qdisc

tc qdisc show dev "$IFACE"
ip -s link show dev "$IFACE"
ss -tin state established | head -n 80

Адрес 203.0.113.10 здесь — документационный пример: замените его IP своего canary-клиента. Не копируйте имя ens5 вслепую. Сохраните вывод рядом с change ticket: после rollout и rollback вы будете сравнивать не память инженера, а одно и то же состояние.

Отдельно запишите topology class: физический dedicated, KVM/VPS, bonding, VLAN, NAT, внешний LB. BBR работает на TCP sender, но гипервизор, vSwitch, NIC ring, ToR и провайдерский uplink остаются другими очередями. Если проблема живёт там, красивый ss на гостевой ОС не доказывает, что вы контролируете bottleneck.

Сначала докажите сетевую причину, а уже потом меняйте congestion control

Хороший canary начинается с гипотезы, которую можно опровергнуть. Например: «при одинаковом запросе TTFT остаётся стабильным, но p95 паузы между SSE-чанками растут вместе с RTT/retransmissions на клиентском TCP». Это гораздо сильнее, чем «пользователь говорит, что ответ идёт рывками».

На application layer зафиксируйте TTFT, интервал между чанками и полную длительность ответа. На network layer — RTT, retransmissions, delivery/pacing rate конкретного сокета и статистику qdisc. На host layer — CPU softirq, NIC drops и saturation, если они есть в вашей телеметрии. Важен один и тот же запрос или фиксированный набор canary-запросов, одинаковая модель, одинаковый лимит токенов и один и тот же клиентский регион. Иначе вы сравните разные workloads.

Если ss -tin показывает app_limited, это сильный disqualifier для идеи «нам мешает congestion control»: sender не заполняет доступный путь постоянно. Для LLM это нормально — decode выдаёт токены дискретно. В такой ситуации BBR может быть технически активен, но пользовательский ритм определяет приложение. Аналогично, если retransmissions не меняются, qdisc backlog почти пуст, а паузы коррелируют с GPU decode, сетевой эксперимент лучше остановить.

Не забывайте прокси. Если Nginx/Envoy/HAProxy завершает клиентский TCP, снимайте socket evidence там. Backend-соединение между proxy и inference node может выглядеть идеально и никак не описывать WAN-очередь. Разницу между L4 и L7 особенно важно учитывать в streaming API: семантика buffering и timeout может дать те же симптомы, что и плохая сеть.

Снимите контрольный профиль CUBIC и не меняйте workload одновременно

Перед BBR нужен контрольный профиль текущего congestion control. На большинстве систем это будет CUBIC, но не предполагайте — прочитайте sysctl и фактический сокет. Ключевая дисциплина эксперимента: не менять одновременно модель, batching, max tokens, proxy buffering, kernel, MTU и congestion control. Один change — одна причинная гипотеза.

Для LLM streaming полезнее всего воспроизводить не гигантский download, а настоящий API-путь. Генератор трафика должен проходить через тот же TLS terminator и тот же network segment, что и пользователь. Сохраняйте timestamp первого байта и времена каждого чанка. Если ваш клиент умеет только «полное время запроса», вы не увидите разницу между TTFT и последующими паузами.

Сетевые counters снимайте в том же окне. ss -tin показывает RTT, congestion window, pacing rate и другие параметры TCP; для BBR там же могут появляться bandwidth/min_rtt state и признак app_limited. tc -s qdisc show нужен, чтобы видеть фактическую egress-очередь, а не только выбранный алгоритм TCP.

IFACE=ens5

ss -tin state established | head -n 120
tc -s qdisc show dev "$IFACE"
nstat -az | grep -E 'TcpRetransSegs|IpOutDiscards'
ip -s link show dev "$IFACE"

Не задавайте заранее «нормальный процент улучшения». Такой порог без вашего traffic mix будет выдуманным benchmark. Сначала соберите распределение метрик на baseline, затем сравните canary в одинаковых условиях. Если разница меньше естественного разброса или исчезает после повторного прогона, честный вывод — причинность не доказана.

Для контекста по другим слоям полезно сопоставить этот эксперимент с NUMA-locality для GPU-инференса: там действует тот же принцип — низкоуровневый счётчик сам по себе не равен улучшению application SLO.

Включайте BBR и fq только на canary-узле

Когда baseline сохранён, переключайте один canary-host или небольшой canary-pool. Не начинайте с fleet-wide sysctl. Изменение congestion control затронет новые TCP-соединения, поэтому после переключения создайте новые клиентские сессии. Если приложение держит очень длинные keep-alive connections, старые сокеты могут продолжать жить с прежним профилем и смешивать результаты.

Сначала убедитесь, что модуль BBR доступен на вашем ядре. Затем переключите congestion control и qdisc. Команда tc qdisc replace ... root fq меняет root qdisc интерфейса прямо сейчас — это production change, а не безобидное чтение. Выполняйте его только на изолированном canary, где вы заранее знаете исходную конфигурацию и путь rollback.

IFACE=ens5

sudo modprobe tcp_bbr
sysctl net.ipv4.tcp_available_congestion_control

sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
sudo tc qdisc replace dev "$IFACE" root fq

sysctl net.ipv4.tcp_congestion_control
tc -s qdisc show dev "$IFACE"
ss -tin state established | head -n 120

Не записывайте настройки в /etc/sysctl.d до окончания canary. Сначала докажите эффект и rollback. Persistence — отдельный change. Так проще избежать ситуации, когда временный эксперимент пережил reboot и внезапно стал новым baseline.

На виртуальной машине отдельно проверьте, что вы действительно контролируете нужный egress. Гостевой fq не заменяет очереди vSwitch или физического uplink. На выделенном сервере граница контроля шире: вы управляете kernel, qdisc, NIC и часто topology целиком, но провайдерская сеть и клиентский last mile всё равно остаются вне хоста.

Как читать ss и qdisc без ложной победы по одной метрике

После переключения легко попасть в ловушку «в ss появился bbr — значит всё работает». Это доказывает только выбор congestion control для данного сокета. Для production-вывода нужны как минимум mechanism gate и application gate.

В mechanism gate смотрите, что новый сокет действительно использует BBR, что qdisc — fq, а pacing/delivery state выглядит правдоподобно. Сравните RTT, retransmissions и qdisc backlog с baseline. Если у BBR-сокета app_limited, не трактуйте низкий delivery rate как проблему сети: приложение само не подаёт достаточно данных. Для токенного стрима это частый режим.

В application gate проверяйте то, ради чего вообще делался change: распределение межтокенных пауз, tail latency стрима, число разрывов/повторных подключений и пользовательский SLO. TTFT держите рядом как контроль: если он внезапно изменился, вероятно, в эксперимент вмешалась очередь inference, autoscaling или другая нагрузка.

Сравнивать нужно идентичные traffic cohorts. Один быстрый клиент в соседнем дата-центре не доказывает эффект для мобильных пользователей через длинный WAN. И наоборот, один проблемный оператор связи не должен определять fleet-wide kernel policy. Разделите хотя бы внутренний/региональный и дальний внешний path.

Ещё один важный counterfactual — нагрузка. Повторите тест в спокойном окне. Если отличие BBR/fq проявляется только при заполненном egress и исчезает при низкой загрузке, это логично и полезно: вы локализовали queueing problem. Если «эффект» одинаков даже когда очередь пуста, ищите confounder.

Rollback — это часть эксперимента, а не аварийная кнопка

Если canary выглядит лучше, следующий шаг — не rollout, а возврат к baseline. Это отрицательный контроль. Сначала верните исходный congestion control и qdisc, откройте новые TCP-соединения и повторите тот же canary-набор. Если streaming metric возвращается к прежнему распределению, причинная связь становится сильнее. Если улучшение остаётся, BBR мог просто совпасть по времени с другой переменной.

Исходный qdisc нельзя угадывать. Сохраните его до эксперимента и восстанавливайте из вашего IaC/change record. Ниже показан только пример с переменными; подставлять fq_codel или cubic автоматически нельзя, если это не ваш реальный baseline.

IFACE=ens5
BASE_CC=cubic
BASE_QDISC=fq_codel

sudo sysctl -w net.ipv4.tcp_congestion_control="$BASE_CC"
sudo tc qdisc replace dev "$IFACE" root "$BASE_QDISC"

sysctl net.ipv4.tcp_congestion_control
tc -s qdisc show dev "$IFACE"

После rollback повторите mechanism gate и application gate в том же порядке. Если низкоуровневые TCP counters вернулись, а пользовательская метрика нет, значит bottleneck мигрировал или вы измеряете не тот слой. Например, сеть перестала быть ограничением, и теперь tail latency определяется gateway CPU, TLS, storage или decode cadence.

Именно поэтому rollback должен быть симметричным rollout. Не «вернули sysctl и разошлись», а заново проверили identity, сокет, qdisc и клиентский результат. Такой процесс длиннее, зато он предотвращает накопление мифических kernel tweaks, эффект которых никто не может воспроизвести.

Когда BBR/fq не поможет — и может отвлечь от настоящей причины

Первый disqualifier — HTTP/3. Клиентский HTTP/3 работает поверх QUIC, а не TCP; Linux sysctl net.ipv4.tcp_congestion_control не управляет QUIC congestion control. У Google для QUIC BBR есть отдельная реализация в quiche. Если внешний API уже на HTTP/3, тюнинг TCP BBR на этом сегменте — просто не тот механизм. Сначала разберите транспорт; для этого пригодится статья про HTTP/3 для AI API.

Второй disqualifier — app_limited и низкая интенсивность данных. LLM token streaming часто не похож на bulk transfer: приложение выдаёт небольшие чанки с паузами между decode steps. Если bottleneck bandwidth не заполняется, congestion control имеет мало пространства для улучшения пользовательского ритма.

Третий — buffering выше TCP. L7 proxy может копить данные до размера/таймера, библиотека — не flush-ить каждый chunk, а клиент — сам буферизовать UI. Тогда сеть доставляет всё корректно, но пользователь видит «пачки». Смотрите место фактической задержки, а не только wire metrics.

Четвёртый — saturation на GPU или admission control. Если очередь запросов растёт, TTFT уезжает, а inter-token gap ухудшается из-за конкуренции за compute, BBR здесь не лекарство. Иногда именно ограничение дорогих запросов через quota/rate policy стабилизирует сервис лучше сетевого тюнинга; см. разбор rate limits и quotas для дорогих API.

Пятый — bottleneck за пределами вашего host. Wi‑Fi пользователя, мобильная сеть, межоператорский peering и provider uplink могут доминировать. BBR на sender способен изменить своё поведение, но не даёт вам контроль над чужой очередью. Поэтому коммерчески ценен не сам алгоритм, а возможность воспроизводимо управлять своей частью пути и честно отделять её от внешней.

Production rollout: ценность не в sysctl, а в контроле сетевого пути

Если canary прошёл mechanism gate, application gate и rollback-контрфакт, можно обсуждать rollout. Делайте его по topology class: одинаковые kernel build, NIC/driver, qdisc baseline, MTU и роль в трафике. Не смешивайте в один wave разные типы виртуализации и физические серверы — одинаковый sysctl поверх разных egress paths не создаёт одинаковую систему.

Persistence включайте отдельным шагом. Зафиксируйте sysctl в управляемой конфигурации, qdisc — в network bootstrap/systemd unit или другом IaC-механизме, который ваша команда умеет проверять и откатывать. После reboot должен существовать тот же evidence gate: congestion control доступен, новые сокеты его используют, qdisc соответствует профилю, application canary проходит.

Для выделенной инфраструктуры это и есть естественный offer bridge. Dedicated host даёт ownership над kernel profile, qdisc, NIC, IRQ/CPU placement, reboot window и rollback. Это не обещание, что «dedicated + BBR всегда быстрее». Наоборот: ценность в том, что один и тот же baseline можно воспроизвести, а изменение — изолировать. Если команда не контролирует host networking или провайдер запрещает нужные kernel/qdisc changes, эксперимент может быть организационно невозможен.

При этом сеть не существует отдельно от inference topology. Если после устранения egress queue bottleneck переезжает в CPU/memory locality, вернитесь к системной диагностике. В multi-GPU сценариях полезно сопоставить сетевой rollout с NUMA-locality и другими host-level gates, а не пытаться одним TCP tweak закрыть всю цепочку.

Чек-лист перед rollout и главный вывод

BBR + fq имеет смысл не тогда, когда «так советуют для VPS», а когда вы доказали sender-side queueing problem на реальном LLM streaming path. Перед production change проверьте: известен фактический TCP sender; TTFT отделён от межтокенных пауз; baseline CUBIC/текущего CC сохранён; root qdisc известен; на canary открываются новые соединения; mechanism и application metrics улучшаются согласованно; rollback возвращает картину к baseline; после изменения bottleneck не переехал в GPU, gateway или другой сетевой слой.

Если хотя бы один из этих пунктов не выполняется, результат лучше назвать «интересным наблюдением», а не оптимизацией. Такой консерватизм экономит время: kernel tuning, который нельзя причинно связать с SLO, быстро превращается в технический долг.

Источники для перепроверки механики — актуальная документация Linux IP sysctl, описание tc-fq и материалы Google BBR. Они важнее старых рецептов с одной строкой sysctl.conf, потому что поведение pacing и kernel networking менялось.

Начните с одного canary-host и одного фиксированного набора streaming-запросов. Если эффект выдерживает повтор, rollback и reboot — тогда у вас есть инженерное основание для rollout. Если нет, это тоже хороший результат: вы исключили один слой и можете идти дальше по цепочке без гадания.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Сначала отделите HNSW maintenance от обычного pgvector tuning

У KingServers уже есть общий материал про pgvector в PostgreSQL для RAG: там важны выбор HNSW/IVFFlat, фильтрация, миграции и базовая эксплуатация. Здесь граница намеренно уже. Мы не выбираем индекс заново и не сравниваем PostgreSQL с отдельной vector DB. Нас интересует конкретный класс инцидентов: таблица с embeddings переживает заметный поток UPDATE/DELETE, после чего меняются maintenance time, количество dead tuples или проверяемый recall.

Это разграничение важно, потому что три независимые проблемы выглядят похоже. Первая — maintenance: PostgreSQL накопил obsolete tuple versions, а HNSW vacuum стал дорогим. Вторая — query budget: approximate scan просмотрел недостаточно кандидатов, особенно при фильтрах. Третья — semantic drift: изменилась embedding-модель или схема chunking, и старый индекс физически исправен, но вектора уже не соответствуют новому retrieval pipeline.

Не начинайте с команды REINDEX. Начните с трёх доказательств: версия pgvector, состояние таблицы/индекса и одинаковый canary-набор запросов для approximate-vs-exact сравнения. Только если эти слои указывают на maintenance path, имеет смысл расходовать I/O на rebuild.

Отдельный случай — смена embedding-модели. Для него у нас есть материал про embedding lifecycle и переиндексацию после смены модели. Обычный HNSW REINDEX не пересчитывает embeddings и не исправляет несовместимое vector space.

Version gate: проверьте pgvector до любого HNSW vacuum runbook

Версия здесь не формальность. В changelog pgvector есть несколько свежих исправлений именно вокруг HNSW vacuum: версия 0.8.3 от 17 июня 2026 года исправляла возможную corruption при vacuum, а 0.8.4 от 30 июня — ошибку hnsw graph not repaired и возможную ошибку при inserts во время HNSW vacuum. В актуальном changelog последняя версия — 0.8.6 от 29 июля 2026 года.

Это не означает, что любой production обязан немедленно прыгнуть на последнюю minor-версию без canary. Но если ваш maintenance-процесс построен на HNSW vacuum и вы всё ещё ниже ветки с этими исправлениями, сначала разберите upgrade path и release notes, а уже затем интерпретируйте странное поведение как «нормальный bloat».

PostgreSQL тоже фиксируйте в evidence bundle. На дату этой статьи current stable branch — PostgreSQL 18.6; при этом runbook ниже применим и к поддерживаемым 17/16/15/14, если соответствующие команды доступны. Не переносите значения memory/autovacuum между major-версиями вслепую.

SELECT version();

SELECT extname, extversion
FROM pg_extension
WHERE extname = 'vector';

SELECT current_setting('server_version_num') AS server_version_num;

Что UPDATE и DELETE оставляют в PostgreSQL — и при чём здесь HNSW

PostgreSQL использует MVCC: удалённая строка или старая версия строки после UPDATE не исчезает физически мгновенно. Она остаётся как dead tuple, пока VACUUM не сможет её обработать. Поэтому write-heavy RAG corpus после массовой замены документов может иметь гораздо больше физической работы, чем подсказывает простое COUNT(*).

Для HNSW есть дополнительная практическая деталь: официальный pgvector README прямо предупреждает, что vacuum HNSW-индексов может занимать заметное время и рекомендует перед ним reindex. Это важнее, чем пытаться вывести универсальное правило вроде «при N% dead tuples всегда REINDEX»: такого порога документация не задаёт, а допустимый churn зависит от размера таблицы, storage I/O, окна обслуживания и запроса.

Нужно различать table dead tuples, index physical size и retrieval behavior. Большой n_dead_tup — сигнал к расследованию, но сам по себе не доказывает semantic recall regression. И наоборот, мало результатов в HNSW-запросе не обязательно означает bloat: при фильтрах pgvector применяет filter после approximate scan, поэтому search budget может закончиться раньше, чем будет найден нужный top-k.

Baseline до REINDEX: dead tuples, index size, plan и recall

Evidence bundle собирайте до первого maintenance action. В нём должны быть stable table/index identity, версия extension, пример реального retrieval query, статистика таблицы и размер HNSW. Для application layer сохраните небольшой набор canary queries: не случайные synthetic vectors, а те типы запросов, на которых команда замечает проблему.

pg_stat_user_tables даёт оценочные n_live_tup/n_dead_tup и время последнего vacuum/autovacuum. Размер индекса удобно фиксировать через pg_relation_size. План нужно смотреть на реальном WHERE и том же операторе distance, который использует приложение.

SELECT
  schemaname,
  relname,
  n_live_tup,
  n_dead_tup,
  last_vacuum,
  last_autovacuum,
  n_mod_since_analyze
FROM pg_stat_user_tables
WHERE schemaname = 'public'
  AND relname = 'rag_documents';

SELECT
  pg_size_pretty(pg_relation_size('public.rag_documents')) AS table_size,
  pg_size_pretty(pg_relation_size('public.rag_documents_embedding_hnsw_idx')) AS hnsw_size;

EXPLAIN (ANALYZE, BUFFERS)
SELECT id
FROM public.rag_documents
WHERE tenant_id = :tenant_id
ORDER BY embedding <=> :query_embedding
LIMIT 20;

Почему pgvector рекомендует REINDEX CONCURRENTLY перед VACUUM

Для HNSW официальный pgvector README даёт необычно конкретную рекомендацию: если vacuum идёт долго, сначала выполните REINDEX INDEX CONCURRENTLY, затем VACUUM таблицы. Это не общий закон PostgreSQL для любого index type, а pgvector-specific operational hint.

REINDEX строит новую копию индекса из данных таблицы. В production вариант CONCURRENTLY позволяет продолжать обычные INSERT/UPDATE/DELETE, тогда как обычный REINDEX блокирует writes на время rebuild. Цена concurrency — больше общей работы, дополнительные scans и ожидание транзакций.

Команды не объединяйте в одну большую transaction. PostgreSQL не разрешает REINDEX CONCURRENTLY внутри transaction block; VACUUM тоже запускается отдельно. И не превращайте последовательность ниже в cron «после каждого batch»: сначала symptom и evidence, затем maintenance.

REINDEX INDEX CONCURRENTLY public.rag_documents_embedding_hnsw_idx;

VACUUM public.rag_documents;

-- Если после большого churn нужна свежая planner statistics:
ANALYZE public.rag_documents;

CONCURRENTLY не блокирует writes, но требует отдельного resource budget

Слово CONCURRENTLY иногда ошибочно читают как «дёшево и незаметно». PostgreSQL описывает обратный trade-off: concurrent rebuild делает больше работы, выполняет два scans таблицы и ждёт завершения транзакций, которые могут мешать переключению индекса. Кроме времени, вы платите CPU, memory и storage I/O; именно поэтому rebuild способен ухудшить application latency даже без lock, который блокирует writers.

Для крупной RAG-таблицы maintenance budget должен жить рядом с пользовательским SLO. До запуска определите stop condition: например, рост database queue/latency выше внутреннего canary threshold, replication lag выше вашего допустимого окна или saturation storage. Числа здесь нельзя копировать из статьи — они зависят от дисков, размера HNSW и текущего трафика.

PostgreSQL также ограничивает concurrent index work: на одной таблице одновременно может идти только один concurrent index build. Длинные транзакции способны затянуть фазы ожидания. Поэтому перед окном rebuild полезно посмотреть не только CPU, но и transaction age.

SELECT
  pid,
  datname,
  relid::regclass AS table_name,
  index_relid::regclass AS index_name,
  command,
  phase,
  lockers_total,
  lockers_done,
  blocks_total,
  blocks_done,
  tuples_total,
  tuples_done
FROM pg_stat_progress_create_index
WHERE relid = 'public.rag_documents'::regclass;

Если вы хотите оценить resource envelope заранее, делайте rebuild на свежем production-sized clone, а не на маленькой demo-базе. Это не докажет точную длительность в production, зато покажет порядок I/O и memory pressure без риска для live traffic. Ценность выделенной инфраструктуры в этом сценарии — не обещание «pgvector станет быстрее», а управляемый запас IOPS/CPU и возможность запланировать maintenance без соседнего noisy workload.

VACUUM после rebuild: что он освобождает и чего не делает

Обычный VACUUM обрабатывает dead tuples и делает освободившееся место доступным для повторного использования. В normal PostgreSQL operation это routine maintenance, который обычно может идти параллельно с чтениями и записями. При этом freed space чаще остаётся внутри relation для будущих tuples — ожидать, что файл на диске сразу резко уменьшится, неправильно.

VACUUM FULL — другая операция: она переписывает таблицу, может вернуть больше места операционной системе, но требует ACCESS EXCLUSIVE и значительно тяжелее. Не используйте FULL как автоматическое продолжение HNSW runbook только потому, что pg_relation_size выглядит большим.

В PostgreSQL 18 параметр INDEX_CLEANUP у VACUUM по умолчанию AUTO: движок может пропустить index vacuuming, если dead tuples очень мало и стоимость обхода индексов выше пользы. Это ещё одна причина не сводить политику к одному percentage threshold.

После завершения сравните тот же evidence bundle: dead tuples, длительность следующего vacuum, plan и application canary. Если изменился только storage counter, а retrieval SLO/recall остались прежними, называйте это доказательством maintenance mechanism — не «ускорением RAG».

Recall gate: approximate HNSW сравнивайте с exact search на том же snapshot

pgvector предлагает простой способ мониторить recall: сравнивать результаты approximate search с exact search, временно отключая index scan. Для production-проверки этого мало сделать один раз случайным vector. Нужен фиксированный набор запросов, одинаковые filters, одинаковый top-k и по возможности один database snapshot, чтобы concurrent writes не подменили причину различий.

Exact control отвечает на узкий вопрос: насколько approximate index path воспроизводит ближайших соседей, которые получил бы exact search. Он не измеряет качество RAG целиком: если embedding-модель плохо кодирует предметную область, exact top-k тоже может быть семантически плохим. Поэтому index recall и answer quality держите раздельно.

BEGIN ISOLATION LEVEL REPEATABLE READ READ ONLY;

-- 1) approximate HNSW path
SELECT id
FROM public.rag_documents
WHERE tenant_id = :tenant_id
ORDER BY embedding <=> :query_embedding
LIMIT 20;

-- 2) exact control, как рекомендует pgvector для recall monitoring
SET LOCAL enable_indexscan = off;

SELECT id
FROM public.rag_documents
WHERE tenant_id = :tenant_id
ORDER BY embedding <=> :query_embedding
LIMIT 20;

ROLLBACK;

Сравнивайте IDs в тестовом harness: top-k overlap, попадание в заранее размеченный relevant set и стабильность на нескольких категориях запросов. Если exact и approximate расходятся только при фильтре, переходите к query-budget диагностике. Если расхождение коррелирует с churn и меняется после controlled maintenance, это уже гораздо сильнее как attribution.

Iterative scans лечат filter starvation, а не заменяют maintenance

У HNSW есть другой источник «пропавших» результатов. В approximate search pgvector применяет обычный WHERE-filter после index scan. Если условие пропускает небольшую долю rows, из первоначального candidate set может остаться меньше строк, чем запрошено через LIMIT. Это не обязательно повреждение индекса.

Начиная с pgvector 0.8.0 доступны iterative index scans. Режим strict_order продолжает обход, сохраняя строгий порядок distance; relaxed_order может дать лучшую recall ценой слегка relaxed ordering. Обход ограничивается, в частности, hnsw.max_scan_tuples; default в текущем source — 20 000, а hnsw.scan_mem_multiplier — 1. Эти default не надо автоматически увеличивать: больший search budget покупает recall дополнительной работой.

BEGIN;

SHOW hnsw.ef_search;
SHOW hnsw.max_scan_tuples;
SHOW hnsw.scan_mem_multiplier;

SET LOCAL hnsw.iterative_scan = strict_order;

SELECT id
FROM public.rag_documents
WHERE tenant_id = :tenant_id
ORDER BY embedding <=> :query_embedding
LIMIT 20;

ROLLBACK;

Autovacuum: настраивайте trigger под churn, но не превращайте его в магию

Routine vacuum должен оставаться автоматизированным. PostgreSQL запускает autovacuum, когда число obsolete tuples превышает threshold, который зависит от базового значения, scale factor и размера таблицы. Для очень большой RAG table даже стандартный scale factor может означать большой абсолютный объём изменений до следующего vacuum; для маленькой таблицы слишком агрессивный trigger создаст лишнюю фоновую работу.

Поэтому сначала смотрите фактический churn и table-specific settings. Не копируйте из чужого runbook autovacuum_vacuum_scale_factor=0.01 или другое красивое число без бюджета: частота vacuum должна соответствовать write rate, storage bandwidth и допустимому background load.

SHOW autovacuum;
SHOW autovacuum_vacuum_threshold;
SHOW autovacuum_vacuum_scale_factor;

SELECT
  n_live_tup,
  n_dead_tup,
  last_autovacuum,
  autovacuum_count
FROM pg_stat_user_tables
WHERE relid = 'public.rag_documents'::regclass;

SELECT reloptions
FROM pg_class
WHERE oid = 'public.rag_documents'::regclass;

Если autovacuum явно не успевает за predictable churn, меняйте одну table-level policy за раз и наблюдайте несколько циклов. Но не путайте более частый routine VACUUM с pgvector-specific рекомендацией reindex-before-vacuum для тяжёлого HNSW: это разные уровни maintenance.

Rollout: canary, stop condition и восстановление без легенды про «нулевой риск»

На production не начинайте с самого большого HNSW. Сначала проверьте процедуру на production-sized clone или на менее критичной таблице с той же схемой. На live primary используйте REINDEX CONCURRENTLY только когда нужен write availability и у вас есть запас ресурсов; если сервис можно полностью остановить в maintenance window, обычный REINDEX дешевле по общей работе.

У rollout должны быть три gate. Infrastructure gate: rebuild завершён, index valid, VACUUM не завис, storage и replication вернулись к baseline. Retrieval gate: canary approximate-vs-exact не ухудшился и production filters возвращают ожидаемый top-k. Application gate: RAG endpoint отвечает в вашем SLO и не переносит bottleneck, например, с database I/O на CPU или embedding service.

Rollback здесь не означает, что после каждого REINDEX вы обязаны восстанавливать базу из backup. REINDEX перестраивает индекс из данных таблицы; если data layer не менялся, при неудачном application canary чаще нужно остановить дальнейший rollout, вернуть query settings и расследовать planner/filter path. А PITR остаётся независимым data-protection control на случай ошибочных data changes, а не штатной кнопкой отмены index maintenance.

Decision tree: когда ничего не делать, когда tuning, а когда REINDEX + VACUUM

Главный вывод — HNSW maintenance должен начинаться не с команды, а с классификации причины. Если таблица почти append-only, autovacuum справляется, а canary recall стабилен, периодический REINDEX «для профилактики» только создаст ненужный I/O. Если меньше результатов возникает при selective filters, проверяйте ef_search, iterative scans и filter indexes. Если изменилась embedding-модель, запускайте полноценный re-embed/migration lifecycle. И только когда churn, dead tuples, HNSW maintenance symptom и canary указывают в одну сторону, применяйте pgvector-specific последовательность REINDEX INDEX CONCURRENTLY → VACUUM.

Для инфраструктуры решение тоже практическое. Dedicated database node полезен здесь не потому, что сам по себе повышает recall, а потому что даёт контролируемый storage/CPU envelope, понятный maintenance window и возможность воспроизвести один hardware profile. Если у вас embeddings занимают значимую долю PostgreSQL и вы ещё выбираете границу системы, сначала сверитесь со сравнением отдельной vector DB и PostgreSQL. А если retrieval cost начинает доминировать, отдельно проверьте semantic cache — это другой слой и он не должен маскировать больную database maintenance.

Практический следующий шаг: сохраните один baseline SQL bundle и 20–50 canary queries, прогоните их до и после следующего реального churn-window и только затем решайте, нужен ли recurring maintenance policy. Так у команды появится причинная связь между изменением базы, состоянием HNSW и пользовательским retrieval, а не набор периодических команд «потому что так принято».

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Симптом: RDMA есть, а прямой GPU↔NIC путь не доказан

Начните не с модулей, а с наблюдаемого расхождения. Например, два одинаковых GPU-узла работают на одной версии приложения и используют один fabric, но на одном растёт загрузка CPU и память хоста становится заметной частью data path, а на другом обмен остаётся ближе к ожидаемому GPU-centric профилю. Это повод проверить registration path. Сам по себе низкий throughput ничего не доказывает: причина может быть в MTU, routing, PFC/ECN, PCIe topology, NUMA, CPU pinning или вообще в TCP fallback.

Disqualifier важен сразу. Если rdma link уже показывает проблему, NIC не поднимается, ib_write_bw на обычной host memory нестабилен или два узла не видят друг друга по RDMA, сначала чините сеть. DMA-BUF не исправляет fabric. Точно так же миграция registration path не должна становиться способом «вылечить» плохой PCIe: для низкоуровневых P2P-проблем полезен отдельный runbook по PCIe ACS и P2P DMA.

Цель этой статьи уже: доказать, какой kernel path регистрирует GPU memory для RDMA, подтвердить реальную передачу из GPU memory, затем проверить NCCL и только после этого смотреть на LLM SLO. Если application metric не меняется, улучшение низкоуровневого счётчика остаётся доказательством механизма, а не бизнес-эффекта.

DMA-BUF и nvidia-peermem: что на самом деле меняется

GPUDirect RDMA позволяет peer-устройству — обычно RDMA NIC — работать с GPU memory без обязательной промежуточной копии через host memory. В Linux для этого нужен механизм регистрации и обмена memory handles. В современном стеке NVIDIA таким механизмом может быть стандартный DMA-BUF; legacy-вариант использует модуль nvidia-peermem и peer-memory API.

В документации NVIDIA GPU Operator 26.3 DMA-BUF обозначен как рекомендуемый вариант. Для него используется Open GPU Kernel Module, а поддержка RDMA может опираться на inbox-драйверы Linux. Legacy nvidia-peermem по-прежнему описан как отдельный путь и требует соответствующего OFED/DOCA-OFED стека. Это не означает, что каждый существующий peermem-кластер нужно срочно переделать: production-миграция оправдана, когда вы можете воспроизвести baseline и откатить canary без смешения гипотез.

Практическая разница для оператора в ownership. С DMA-BUF вы проверяете open kernel module, kernel/RDMA stack и GPU-memory transfer; с peermem появляется отдельный модуль и его совместимость с RDMA drivers. Поэтому после обновления kernel, NVIDIA driver или NIC stack разные узлы могут формально быть «зелёными», но фактически использовать разные пути.

До миграции зафиксируйте identity узла, GPU и RDMA NIC

Первое обязательное правило — не менять kernel path до evidence bundle. Запишите kernel release, версию и тип NVIDIA kernel module, PCI identity GPU, RDMA devices и физическую близость GPU↔NIC. Иначе после перезагрузки вы увидите «стало работать» и не сможете ответить, что именно изменилось.

Identity должна быть стабильной и машинно проверяемой. Для GPU полезен BDF из nvidia-smi и topology map; для NIC — RDMA device и связанный netdev. Если у вас несколько HCA, не используйте «mlx5_0» как вечную бизнес-идентичность: после firmware или PCI enumeration имя может поменяться. Сопоставляйте его с PCI BDF и физическим портом.

uname -r
modinfo nvidia | grep -E '^(version|license):'
nvidia-smi -L
nvidia-smi topo -m
rdma link
rdma dev show
ibdev2netdev
lsmod | grep -E 'nvidia_peermem|nvidia|ib_core|mlx5'

Сохраните этот вывод вместе с версией CUDA/NCCL и образом приложения. При canary сравнении нужен не просто «другой сервер», а узел того же topology class. Если одна машина имеет другой root complex, другой NIC firmware или другой kernel, она плохой контроль.

Для LLM-нагрузки отдельно зафиксируйте application baseline: время инициализации distributed job, steady-state throughput, p95/p99 интересующей операции и CPU utilization. Не выбирайте только одну метрику. Например, NCCL transport может стать чище, но end-to-end latency не изменится из-за другого bottleneck. Это нормальный результат, а не повод придумывать эффект.

Gate 1: докажите prerequisites DMA-BUF, а не просто наличие NVIDIA driver

По актуальной документации NVIDIA для GPUDirect RDMA через DMA-BUF требуется Open GPU Kernel Module; GPU Operator также указывает CUDA 11.7+ и Linux kernel 5.12+ как базовые требования этого пути. Проверяйте именно вашу поддерживаемую комбинацию OS/kernel/driver, а не переносите минимумы из документации на неподдерживаемый дистрибутив.

На практике gate должен отвечать на три вопроса. Во-первых, загружен ли open kernel variant, а не только «NVIDIA driver работает». Во-вторых, виден ли RDMA device и его netdev. В-третьих, соответствует ли GPU/NIC topology вашему canary-плану. На этом шаге не нужно запускать LLM: сначала докажите инфраструктурный механизм.

uname -r
modinfo nvidia | grep -E '^(version|license):'
rdma dev show
rdma link
nvidia-smi topo -m
ls -l /dev/infiniband

Не используйте отсутствие nvidia_peermem как единственный PASS. Модуль может быть не загружен, но DMA-BUF transfer всё равно не работать из-за несовместимой комбинации kernel/NIC driver. И наоборот, наличие старого модуля в filesystem ещё не доказывает, что runtime использует legacy path.

Gate 2: отдельно докажите RDMA из GPU memory

Следующий gate отделяет fabric от GPU-memory registration. Сначала полезно подтвердить обычный host-memory RDMA test на той же паре узлов и порту. Если он не проходит стабильно, не переходите к DMA-BUF — иначе две гипотезы смешаются. После PASS запускайте тот же класс perftest с GPU buffer и флагом DMA-BUF.

NVIDIA в troubleshooting для NCCL прямо предлагает сравнивать host-memory transfer и GPU-memory transfer через ib_write_bw; для DMA-BUF используется --use_cuda_dmabuf. Название HCA, GPU id и server address подставляйте из своего inventory, а не копируйте из примера как константы.

# На серверной стороне
ib_write_bw -d mlx5_0 -a

# На клиенте: сначала host-memory baseline
ib_write_bw -d mlx5_0 -a 

# Затем GPU-memory DMA-BUF test
ib_write_bw --use_cuda=0 --use_cuda_dmabuf -d mlx5_0 -a -F --report_gbits -q 1 

Смысл не в том, чтобы получить универсальное число Gbit/s. PASS — GPU-memory test стабильно работает на ожидаемой паре GPU/NIC, не разваливается при повторении и воспроизводится после controlled restart. Сравнение bandwidth полезно только между одинаковыми topology, message sizes и software versions.

Отрицательный контроль: намеренно запустите host-memory вариант отдельно. Если оба режима дают одинаково плохое поведение, не объявляйте DMA-BUF причиной. Если host memory стабилен, а GPU DMA-BUF падает, область поиска сужается к GPU registration/peer path и его совместимости.

Gate 3: проверьте, что NCCL не маскирует path своим fallback

Даже успешный perftest ещё не равен успешному distributed workload. NCCL выбирает transport с учётом topology и доступных plugins. В актуальной документации NCCL_DMABUF_ENABLE существует с NCCL 2.13, имеет значение по умолчанию 1 и автоматически отключается, если platform не поддерживает DMA-BUF. Поэтому отсутствие ручного export не доказывает, что path активен, а сам export не заставит неподдерживаемую систему чудесным образом заработать.

Для canary включите диагностический лог и запустите контролируемый nccl-tests на той же паре узлов. Смотрите не только на итоговую полосу, но и на transport selection, ошибки registration и неожиданный socket fallback. Команда ниже — шаблон локального теста; способ multi-node launch зависит от вашей MPI/Slurm/Kubernetes обвязки.

export NCCL_DEBUG=INFO
export NCCL_DMABUF_ENABLE=1

# Запускайте тем же orchestrator, который используете для canary
./build/all_reduce_perf -b 8M -e 1G -f 2 -g 1

Если тест не использует ожидаемый RDMA transport, не лечите его отключением safety checks вслепую. Вернитесь к identity и network baseline. Полезный принцип: каждый новый environment override должен отвечать на конкретное наблюдение в логе и иметь обратную команду.

Отдельно не путайте DMA-BUF с настройкой RoCE fabric. ECN/PFC, QoS и congestion control остаются самостоятельным слоем. Если NCCL видит RDMA, но сеть теряет пакеты или уходит в congestion, registration path уже не главный подозреваемый.

Gate 4: LLM canary должен подтвердить полезный эффект, а не красивый low-level test

Теперь повторите реальный workload на canary-узлах. Для training это может быть короткий репрезентативный distributed step; для multi-node inference — фиксированный replay запросов с теми же model revision, tensor/pipeline parallel settings и concurrency. Главное — не менять одновременно registration path, batch policy и модель: иначе attribution потеряна.

Держите рядом минимум три группы метрик: application SLO, NCCL/RDMA evidence и host pressure. Например, если после DMA-BUF direct path CPU utilization упал, но tokens/s и p95 остались прежними, вы доказали разгрузку host path, но не ускорение сервиса. Такой результат может быть полезен для capacity, но его нельзя продавать как рост производительности без дополнительного evidence.

Если наоборот p95 улучшается только на одном canary, сначала проверьте topology class и workload equality. Одна «быстрая» машина на другом PCIe root complex — плохое доказательство. Для смежных вопросов CPU/memory locality полезен runbook по pinned memory и memlock, а throttling GPU лучше исключать отдельным DCGM/Prometheus runbook.

Canary migration: не смешивайте DMA-BUF и legacy path в одном эксперименте

Самая опасная миграция — «обновим половину пакетов и посмотрим». Для canary заранее определите immutable software set: kernel, NVIDIA driver/kernel module type, CUDA/NCCL, RDMA stack, firmware и container image. Меняйте только registration path и связанные обязательные prerequisites.

Если вы используете GPU Operator, текущая документация показывает DMA-BUF как default path для GPUDirect RDMA и отдельный driver.rdma.enabled=true для legacy peer-memory сценария. Для bare metal применяйте ту же идею: два явных профиля конфигурации, а не ручные modprobe на десятках узлов. Infrastructure-as-code должен позволять вернуть прежний профиль целиком.

Порядок rollout: один canary pair → повторение после reboot → небольшой pool → только потом остальной cluster. На каждом этапе повторяйте четыре gates в одном порядке. Если после reboot GPU-memory perftest перестал работать, не переходите к NCCL; если NCCL упал, не объясняйте это application metrics.

Типовые failure modes: где DMA-BUF чаще всего обвиняют зря

Сеть не готова. Host-memory perftest уже нестабилен, но команда сразу запускает GPU test. В результате DMA-BUF получает чужую вину. Negative control здесь простой: сначала стабильный host buffer на том же HCA/port/path.

Смешаны kernel module types. Один узел использует open module, другой — другой driver profile, а orchestration считает их одинаковыми. Distributed job становится экспериментом сразу с несколькими переменными. Лечится inventory gate и node labels/taints, а не дополнительным environment variable.

NCCL auto-disable принимают за успех. Поскольку NCCL_DMABUF_ENABLE по умолчанию включён, можно ошибочно решить, что DMA-BUF точно используется. Документация прямо говорит об auto-disable на неподдерживаемой platform; поэтому нужен log/evidence, а не только значение переменной.

Peermem удаляют до rollback window. Если legacy path был рабочим baseline, не уничтожайте его в том же change, где впервые проверяете DMA-BUF. Сначала докажите новый path, затем сокращайте legacy dependencies отдельным change.

Механизм путают с SLO. GPU-memory RDMA может работать идеально, а LLM не ускориться, если bottleneck — compute, storage или scheduler. Для I/O storm на общем NVMe, например, полезнее отдельная изоляция I/O через cgroup v2/systemd.

Rollback и мониторинг: возвращайте профиль, а не отдельный модуль

Rollback должен быть симметричным rollout. Если baseline использовал legacy nvidia-peermem, верните прежний driver/RDMA profile целиком, перезагрузите узел при необходимости и повторите те же gates: identity → host/GPU perftest → NCCL → application. Это важнее, чем просто увидеть модуль в lsmod.

Для legacy path NVIDIA GPU Operator документирует отдельное включение RDMA driver integration. На bare metal эквивалентом должен быть versioned package/profile, а не «дежурный знает, какой modprobe сделать». После rollback сохраните оба evidence bundles — именно они позволяют понять, воспроизводится ли причинность.

# Пример проверки legacy baseline после возврата профиля
sudo modprobe nvidia-peermem
lsmod | grep nvidia_peermem
rdma dev show
nvidia-smi topo -m

# Затем повторите host-memory и GPU-memory tests,
# соответствующие вашему legacy baseline.

В постоянный мониторинг имеет смысл вынести не «DMA-BUF=1», а симптомы расхождения: node software fingerprint, RDMA link state, NCCL transport errors, неожиданный рост host CPU/memory при одинаковом workload и application SLO. Если инфраструктурный сигнал меняется без user-facing эффекта, храните его как ранний индикатор, но не эскалируйте как outage без порогов.

Когда выделенный GPU-узел даёт практическое преимущество

Здесь коммерческая граница довольно конкретна. Переход между kernel registration paths требует контроля над kernel, типом NVIDIA kernel module, NIC/RDMA stack, firmware, reboot/drain и составом canary pool. В среде, где эти слои скрыты или разделены между несколькими владельцами, вы можете увидеть symptom, но не собрать воспроизводимый evidence bundle.

Ценность dedicated GPU infrastructure в таком кейсе — не «DMA-BUF ускорит всё». Она в ownership: можно закрепить software/hardware profile, вывести узел из нагрузки, выполнить perftest на конкретной GPU↔NIC паре, вернуть baseline и заменить физический компонент, если проблема переживает software rollback. Это особенно важно для multi-node LLM, где один неоднородный узел способен испортить весь distributed job.

Если вы проектируете более широкий AI platform, полезно отделять этот низкоуровневый runbook от orchestration. Например, Kubernetes/KServe/GPU Operator решают scheduling и lifecycle задачи выше, но не отменяют необходимость доказать data path на хосте.

Источники и версия контекста

Проверено на дату подготовки статьи по официальной документации NVIDIA: GPU Operator 26.3 — GPUDirect RDMA, NCCL Environment Variables, NCCL Networking Troubleshooting и CUDA GPUDirect RDMA.

Особенно внимательно сверяйте minimum kernel/driver/CUDA requirements при обновлениях: эта часть стека меняется быстрее, чем общая логика runbook. Команды в статье — диагностические шаблоны; имена HCA, GPU id, IP, orchestrator и package profile должны соответствовать вашему inventory.

Вывод: мигрируйте не модуль, а доказанную цепочку data path

Переход с legacy nvidia-peermem на DMA-BUF имеет смысл делать как controlled infrastructure change. Сначала сохраните identity и baseline, затем докажите prerequisites open kernel, отдельно подтвердите RDMA из GPU memory, после этого — NCCL transport и только в конце — LLM application SLO. Если любой слой FAIL, не перепрыгивайте к следующему и не маскируйте проблему дополнительными overrides.

Главный operational результат — воспроизводимость. После reboot тот же canary должен проходить те же gates; rollback должен возвращать тот же baseline; улучшение low-level counters без application effect нужно называть именно так. Начните с одной пары однородных GPU-узлов и одного фиксированного workload replay — этого достаточно, чтобы миграция перестала быть догадкой и стала проверяемым change.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Когда подозревать PCIe, а когда не стоит

PCIe редко становится первым подозреваемым при деградации LLM inference. Обычно команда сначала смотрит utilization GPU, VRAM, clocks, throttling, CPU steal, NUMA и очередь запросов. Это правильный порядок: большинство проблем действительно находится выше. Но есть характерная комбинация признаков, при которой стоит спуститься на link layer: приложение теряет throughput или растёт latency, GPU не загружен так, как ожидалось, host-to-device transfer занимает заметно больше времени, а модель и workload не менялись.

Disqualifier здесь важнее красивой гипотезы. Если сервис целиком держит weights и KV cache на GPU, почти не гоняет данные через host после warmup, а p95 растёт одновременно на всех узлах независимо от конкретного BDF, PCIe — слабый кандидат. Точно так же не надо объяснять PCIe любой низкий GPU utilization: причиной может быть CPU preprocessing, storage, tokenizer, scheduler или network backpressure.

И наоборот, настораживает узел, который отличается от соседей того же hardware class. Например, две одинаковые машины работают на одной версии драйвера и одном образе, но одна после обслуживания показывает меньший negotiated link width или generation. Такая асимметрия — уже полезный след: сравнивать нужно не «нормально ли вообще», а «совпадает ли текущий effective state с известным baseline этого конкретного слота и GPU».

Если проблема выглядит как throttling, сначала исключите его по отдельному runbook: мониторинг GPU throttling через DCGM и Prometheus. Для multi-GPU topology полезен и материал про PCIe ACS и P2P DMA. Эта статья намеренно уже: здесь нас интересуют ошибки линии, retrain и downtraining.

Сначала зафиксируйте identity и baseline

До любых reset, retrain, перестановки карты или перезагрузки снимите evidence bundle. Главная ошибка диагностики — потерять исходное состояние, а затем пытаться доказать, что стало лучше. Для GPU используйте стабильный идентификатор: UUID и PCI Bus ID. NVIDIA прямо рекомендует для автоматизации UUID или PCI bus ID, потому что индекс GPU может меняться между перезагрузками.

Минимальный baseline должен отвечать на пять вопросов: какой это GPU; какой BDF видит ОС; какой upstream path ведёт к Root Port; каковы максимальные и текущие speed/width; были ли AER-события до инцидента. Если у вас несколько одинаковых узлов, сохраните те же данные с одной здоровой машины. Это превращает расследование из гадания в diff.

GPU=0
nvidia-smi -i "$GPU" --query-gpu=uuid,pci.bus_id,name --format=csv
nvidia-smi -i "$GPU" -q | sed -n '/PCI/,/Clocks/p'
BDF=$(nvidia-smi -i "$GPU" --query-gpu=pci.bus_id --format=csv,noheader | tr '[:upper:]' '[:lower:]')
echo "GPU BDF: $BDF"
lspci -s "$BDF" -vv
lspci -t
journalctl -k -b | grep -Ei 'AER|PCIe Bus Error|pcieport|NVRM|Xid' | tail -n 200

Привяжите GPU к реальному PCIe-пути

Сообщение AER часто приходит не от самого GPU, а от Root Port или другого элемента иерархии. Поэтому BDF endpoint — только начало. Нужно понять, через какой upstream bridge, riser или PCIe switch проходит карта. Это особенно важно в 2U/4U GPU-серверах: физический слот на задней панели не всегда очевидно соответствует тому Root Port, который вы увидите в журнале.

Начните с lspci -t, затем раскройте подробности endpoint и upstream-портов через lspci -vv. В Capability PCI Express ищите LnkCap и LnkSta: первое описывает возможности конкретного звена, второе — согласованное состояние. Сравнивать надо speed и width вместе. Gen5 x8 и Gen4 x16 — разные состояния, и один только номер поколения не говорит, что линия деградировала.

Не делайте ещё одну распространённую ошибку: не сравнивайте текущий link с маркетинговым максимумом GPU. Ограничение может находиться в слоте, riser, switch или платформе. Правильный baseline — то, что поддерживает минимальное звено по пути и что стабильно показывает здоровый узел той же конфигурации.

GPU_BDF=0000:65:00.0
lspci -s "$GPU_BDF" -vv | grep -E 'LnkCap:|LnkSta:'
lspci -t
# Затем повторите -vv для upstream bridge/root port из дерева:
lspci -s 0000:64:00.0 -vv | grep -E 'LnkCap:|LnkSta:|AER|DevSta:'

Как читать AER и replay без ложных выводов

Linux AER driver собирает расширенную информацию об ошибках PCIe, сообщает её пользователю и участвует в recovery. В документации ядра ошибки делятся на correctable и uncorrectable. Correctable исправляются протоколом без потери функциональности; uncorrectable уже могут затрагивать транзакцию или надёжность самой линии. Это ключевая граница: наличие correctable warning не равно «GPU сломан», но серия событий — хороший триггер для корреляции.

AER в Linux работает через Root Port service driver и зависит от того, передала ли прошивка управление AER операционной системе через ACPI _OSC. Поэтому отсутствие сообщений в dmesg не всегда означает отсутствие ошибок на физическом уровне. На одних платформах телеметрия будет полной в Linux, на других часть обработки остаётся в firmware/BMC. Зафиксируйте эту особенность платформы до того, как строить алерт «AER=0 — всё хорошо».

Отдельный сигнал — replay. PCIe использует механизм повторной передачи, и рост соответствующего счётчика может указывать, что протоколу приходится восстанавливать транзакции. Но опять же: абсолютное число без окна наблюдения и без baseline мало полезно. Снимайте delta за одинаковый интервал под одинаковой нагрузкой и сравнивайте с p95/throughput приложения.

В NVIDIA-стеке часть PCIe-показателей можно получать через NVML/DCGM; для долгоживущей автоматизации предпочтительнее NVML/DCGM, чем парсинг человекочитаемого вывода nvidia-smi, поскольку NVIDIA отдельно предупреждает, что формат NVSMI не гарантирует обратную совместимость.

START=$(date -Is)
echo "start=$START"
# запустите один и тот же canary workload
sleep 60
journalctl -k --since "$START" | grep -Ei 'AER|PCIe Bus Error|pcieport|NVRM|Xid'
# На поддерживаемых системах проверьте sysfs AER counters для endpoint/upstream port:
find /sys/bus/pci/devices/0000:65:00.0 -maxdepth 1 -type f -name 'aer_*' -print -exec cat {} \;

Докажите влияние на LLM, а не только на PCIe-счётчик

Даже если вы нашли AER и current link ниже baseline, этого недостаточно для коммерчески значимого вывода. Production-вопрос звучит не «есть ли ошибка PCIe», а «мешает ли она полезной работе». Поэтому разделите infrastructure gate и application gate.

Infrastructure gate считается пройденным, когда identity однозначна, topology известна, current link сопоставлен с capability и peer baseline, а AER/replay измеряются в фиксированном окне. Application gate — отдельный эксперимент: один и тот же prompt set, те же model revision, batch/concurrency, CPU affinity, tokenizer path и network path. Сравнивайте request throughput и latency, а не только GPU utilization.

Особенно аккуратно с prefilling и streaming. Workload, который часто передаёт большие host buffers, может сильнее проявлять деградацию PCIe, чем steady-state decode с данными уже в VRAM. Поэтому canary должен представлять реальный traffic mix. Если проблема видна только в synthetic host-to-device copy benchmark, а production SLO не меняется, вы доказали механизм, но не доказали влияние на сервис.

Для NUMA-проверок используйте отдельный runbook NUMA-locality для GPU-инференса: remote memory может имитировать часть симптомов, но это другой слой.

Triage: software, retrain или физический путь

Когда evidence собран, можно выбирать действие. Если link state соответствует baseline, AER не растёт, а application gate деградирован, оставайтесь на software path: драйвер, runtime, NUMA, CPU, storage, network или сама модель. Не надо «на всякий случай» трогать PCIe reset.

Если current speed/width ниже ожидаемого и состояние появилось после boot или maintenance, сначала ищите наименее разрушительный способ подтвердить гипотезу. Для production-узла это обычно drain workload, фиксация evidence, затем контролируемый reboot в maintenance window. Ручной reset bridge или endpoint может затронуть другие устройства в той же иерархии; Linux AER recovery для серьёзных ошибок тоже способен выполнять reset выше originator. Поэтому topology должна быть известна до любого воздействия.

Если после reboot/retrain линия возвращается к baseline и application metric восстанавливается, это сильная корреляция, но ещё не повод закрывать инцидент. Нужен контрфакт: повторите тот же canary и проверьте, не растут ли AER/replay снова. Возвращающаяся деградация указывает на физический путь, signal integrity, riser, слот, питание, board или firmware/BIOS interaction.

Если же link стабилен после холодного старта, но деградирует только под определённой нагрузкой, расследование становится интереснее: коррелируйте температуру платы, питание, BMC SEL, AER delta и workload. Не заменяйте этот анализ снижением PCIe generation «для стабильности» без фиксации причины: такой workaround может скрыть дефект и одновременно урезать capacity.

Когда переходить к riser, слоту и плате

Физическую диагностику начинайте только после software evidence, иначе очень быстро появляется «ремонт методом перестановки». На выключенном и снятом с нагрузки сервере проверьте посадку GPU и riser, крепёж, разъёмы питания, следы перегрева и соответствие riser/slot спецификации платформы. На системах с PCIe switch добавьте его firmware и health в evidence bundle.

Лучший hardware experiment — один контролируемый swap за раз. Перенесли GPU в другой заведомо исправный slot: если проблема следует за картой, подозрение смещается к endpoint. Оставили GPU, заменили riser: если проблема исчезла, у вас локализован элемент пути. Нельзя одновременно переставить карту, заменить riser, обновить BIOS и драйвер, а потом объявить RCA — вы потеряете причинность.

Для каждого swap сохраняйте stable identity новой комбинации: serial/UUID GPU, BDF, slot label из документации сервера, upstream Root Port, BIOS version. После каждого изменения повторяйте те же два gate: infrastructure и application. Симметрия важна — одни и те же проверки до и после изменения позволяют отличить реальное исправление от случайного изменения нагрузки.

Если сервер арендованный или размещён у провайдера, именно здесь ценность ownership становится практической: нужна возможность drain узла, получить BMC/firmware evidence, выполнить замену riser/slot и вернуть прежнюю конфигурацию. Это не обещание «dedicated быстрее»; это граница управляемости, без которой такой RCA часто останавливается на гипотезе.

Что вынести в постоянный мониторинг

После инцидента не стоит превращать все найденные счётчики в paging alerts. Хороший мониторинг PCIe строится слоями. Первый слой — inventory: GPU UUID/BDF, ожидаемый speed/width и upstream path. Второй — error telemetry: AER и поддерживаемые PCIe counters. Третий — application SLO. Срабатывать должна комбинация, а не любой одиночный correctable event.

Практический pattern: alert высокого приоритета, если current link отличается от expected baseline и одновременно деградирует application metric. Средний приоритет — sustained рост error/replay delta на конкретном BDF без SLO impact; это повод для плановой проверки. Единичный correctable warning можно оставить как event для расследования, а не будить команду ночью.

Для скриптов и exporter-логики лучше опираться на NVML/DCGM или стабильный structured interface, а не на свободный текст nvidia-smi -q. NVSMI удобен для ручной диагностики, но NVIDIA не гарантирует обратную совместимость его текстового вывода. Для AER Linux предоставляет статистику в sysfs на поддерживаемых системах; учитывайте, что firmware ownership через ACPI _OSC влияет на то, что именно увидит ОС.

GPU=0
STAMP=$(date -Is)
echo "timestamp=$STAMP"
nvidia-smi -i "$GPU" --query-gpu=uuid,pci.bus_id,utilization.gpu,power.draw,temperature.gpu --format=csv,noheader
BDF=$(nvidia-smi -i "$GPU" --query-gpu=pci.bus_id --format=csv,noheader | tr '[:upper:]' '[:lower:]')
lspci -s "$BDF" -vv | grep -E 'LnkCap:|LnkSta:'
for f in /sys/bus/pci/devices/${BDF}/aer_*; do [ -r "$f" ] && printf '%s=' "$f" && cat "$f"; done

Recovery и rollback: доказательство важнее перезагрузки

Recovery считается успешным не тогда, когда GPU снова появился в nvidia-smi. Нужно восстановить всю цепочку доказательств. Сначала identity: тот ли endpoint и тот ли slot. Затем effective link state: speed/width вернулись к expected baseline. Потом error window: AER/replay не демонстрируют прежний паттерн. И только после этого application canary подтверждает SLO.

Rollback должен быть заранее определён. Если изменение включало BIOS option, firmware, перестановку riser или новый driver, вы должны знать, как вернуться к предыдущей комбинации. Особенно опасны инциденты, где несколько действий дают временное улучшение: без rollback вы не поймёте, что действительно повлияло на линию.

Полезный контрфакт — вернуть прежнюю конфигурацию на canary, если это безопасно, и проверить, возвращается ли симптом. Для аппаратного дефекта такой эксперимент не всегда разумен: не нужно повторно создавать потенциально fatal состояние ради красивого RCA. В этом случае достаточно устойчивой связи «дефектный элемент → ошибка» и «замена элемента → стабильный baseline» при одинаковом workload.

Отдельно документируйте ownership. Кто имеет право drain узел, кто меняет BIOS, кто работает с железом, кто принимает SLO после возврата. Hardware runbook без owner часто зависает именно в момент, когда диагностика уже доказала проблему, но никто не хочет брать риск физического действия.

Решение по узлу: вернуть в пул, наблюдать или вывести

Не каждый PCIe incident требует немедленной замены сервера. Решение удобно формализовать. Вернуть узел в production можно, если negotiated link устойчиво соответствует baseline, error delta не возвращается в canary-окне, application SLO восстановлен и причина изменения понятна. Если причина не доказана, но симптомы исчезли после reboot, разумнее оставить узел под наблюдением или в пониженном blast radius, а не сразу считать его исправным.

Выводите узел из пула, если деградация воспроизводится, link снова downtrain после нагрузки, появляются uncorrectable/fatal события, устройство теряется или recovery затрагивает соседние endpoints. То же относится к повторяющемуся дефекту riser/slot: workaround вроде принудительного более низкого поколения может быть допустим временно только как явно зафиксированное operational решение с capacity impact и сроком устранения.

Для LLM-платформы полезно хранить topology class как часть inventory: модель сервера, BIOS, CPU, slot, riser, GPU SKU, ожидаемые link parameters. Тогда новый узел не просто «GPU A100/H100/другой», а член конкретного класса с проверяемым baseline. Это облегчает и capacity planning, и замену железа.

Если вам нужна среда, где команда может контролировать BIOS, PCIe topology, reboot window и аппаратную замену, выделенный GPU-сервер даёт такую границу ownership. Но покупать «больше PCIe» без измерения бессмысленно: сначала докажите, что именно link state влияет на ваш workload, и только потом принимайте инфраструктурное решение.

Источники и ограничения runbook

Основные внешние опоры этого runbook — официальная документация Linux Kernel по PCI Express Advanced Error Reporting и документация NVIDIA по nvidia-smi/NVML/DCGM. Linux описывает AER как механизм сбора расширенной информации об ошибках, их вывода и recovery; отдельно подчёркивает классификацию correctable/uncorrectable и зависимость OS AER от ACPI _OSC. NVIDIA документирует PCI bus ID как стабильный способ адресации GPU и рекомендует NVML для поддерживаемой автоматизации, поскольку текстовый вывод NVSMI может меняться между версиями.

Ссылки: Linux Kernel: PCIe AER Driver Guide HOWTO, NVIDIA System Management Interface documentation, NVIDIA DCGM Feature Overview.

Команды в статье — диагностический baseline, а не универсальная автоматизация для всех платформ. Названия sysfs-файлов, доступность отдельных counters и поведение firmware зависят от kernel, platform firmware и устройства. Перед изменениями на production-сервере сверяйтесь с документацией конкретной модели сервера и maintenance policy.

Вывод: ищите причинность по слоям

PCIe-проблема в GPU-инференсе опасна тем, что может выглядеть как «модель почему-то стала медленнее», а сам ускоритель при этом продолжит отвечать на health-check. Надёжный путь — не начинать с reset и не верить одному счётчику. Зафиксируйте identity, восстановите topology, сравните capability с effective link state, измерьте AER/replay в окне и только затем подтвердите влияние одинаковым application canary.

Если после recovery link вернулся к baseline, повторите те же gate в том же порядке. Если деградация возвращается, переходите к физическому пути — riser, slot, switch, board, power и firmware — меняя только один фактор за раз. Так вы получите RCA, который можно повторить, а не историю «перезагрузили — вроде прошло».

Практический следующий шаг простой: выберите один здоровый и один подозрительный GPU-узел, снимите одинаковый evidence bundle и сохраните expected topology class. Даже если текущего инцидента нет, этот baseline резко сокращает время диагностики, когда p95 однажды начнёт расти без очевидного GPU error.