Сосед по гипервизору положил канал: как это выглядит изнутри

MAATRIX

Раз в несколько дней сеть на вашем VPS начинает вести себя странно: пинг скачет, скачивание файла зависает на середине, SSH-сессия секунду думает перед каждой командой — а потом всё само проходит. На сервере при этом тихо: нагрузка своя невысокая, процессы не штормят, диск не забит. Знакомая ситуация — и в девяти случаях из десяти дело не в вашем сервере, а в соседе по тому же физическому узлу, который в этот момент генерирует аномальный трафик и забивает общий аплинк.

Первая версия: грешим на себя

Первая реакция разумна — проверить, не сами ли вы себе создали проблему. Смотрим нагрузку:

top
htop
uptime

Если load average в пределах нормы для числа ядер, а процессы вроде nginx, приложения или базы не разрослись — переходим к сети своими средствами:

ss -s
ss -tunap | wc -l
cat /proc/net/dev
vnstat -l

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

iftop -i eth0
nethogs

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

Реальная причина: чужой трафик на общем узле

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

Типичные сценарии на стороне соседа:

• Флуд или атака, которую сосед устроил не специально — заражённый бот на его VPS начал DDoS-атаку на третью сторону или сканирование диапазонов IP.
• Входящая атака на самого соседа — кто-то положил именно его сервис флудом, и входящий трафик забивает канал узла ещё до того, как хостер успевает отфильтровать паразитную нагрузку.
• Резкий легитимный всплеск — у соседа вышел вирусный контент, начался массовый скрейпинг или разовый бэкап на несколько терабайт, который никто не ограничил по скорости.

Ключевая деталь: физический аплинк узла — общий ресурс. Хостер обычно продаёт VPS с гарантированной полосой (например, 100–200 Мбит/с на тариф), но суммарная пропускная способность порта узла конечна, и не всегда рассчитана на то, что все клиенты одновременно упрутся в свой максимум. Обычно это работает, потому что трафик соседей статистически не совпадает по пикам. Но когда один клиент генерирует аномалию — флуд легко в разы превышает нормальный трафик всех остальных соседей вместе — общий канал забивается, и деградация ощущается у всех, кто сидит на этом узле, независимо от того, сколько трафика гоняете лично вы.

Это не всегда выглядит как «сеть отвалилась». Чаще это частичная деградация: растёт джиттер, появляются точечные потери пакетов, TCP-сессии периодически подвисают на ретрансмитах, а не рвутся полностью. Именно поэтому проблему легко спутать с чем-то у себя — она не бинарная «есть/нет», а плавающая.

Как отличить чужую проблему от своей

Для CPU эта задача решается просто — есть steal time, метрика, которая прямо показывает, сколько времени гипервизор не давал вашей виртуалке процессорное время, отдавая его другим (подробно об этом — в статье про steal time и соседа, который ест ваш CPU). У сети такой готовой метрики внутри гостевой ОС, как правило, нет: виртуальный сетевой интерфейс не сообщает, сколько времени пакет провёл в очереди на физическом порту узла из-за чужого трафика. Поэтому диагностика идёт по косвенным признакам.

Первый и главный признак — несоответствие своего трафика и деградации. Смотрите одновременно на графике: сколько трафика гоняет ваш сервер (vnstat, iftop, счётчики в панели хостера) и как ведёт себя качество соединения (потери, задержка). Если ваш трафик — 5–10% от заявленной полосы тарифа, а пинг и потери пакетов растут так, будто канал забит под завязку — это явный сигнал, что забивает кто-то другой, не вы.

Второй признак — потери и задержка растут «снаружи», а не «внутри». Запустите mtr до внешнего хоста (не только до шлюза) и посмотрите, на каком хопе появляются потери:

mtr -rw -c 100 8.8.8.8
mtr -rw -c 100 ya.ru

Если потери и рост RTT появляются уже на первом-втором хопе (это, как правило, сам узел хостера или ближайший аплинк-роутер дата-центра), а дальше по маршруту всё чисто — проблема локализуется именно в инфраструктуре хостера, а не где-то в интернете по пути.

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

Четвёртый признак, который стоит проверить обязательно — потеря пакетов, которую не видно в обычном ping. Одиночные ICMP-пакеты раз в секунду могут проходить чисто, пока реальные TCP-потоки с их пачками пакетов и разным размером страдают. Как правильно это ловить — отдельная тема, разобрана в статье про потерю пакетов, которой не видно в ping. Короткая версия: гоняйте не ping, а mtr с достаточным числом пакетов и, если возможно, iperf3 до контролируемой точки, чтобы увидеть реальный TCP-throughput, а не только задержку одиночных пакетов.

Полезно держать под рукой простую табличку для себя, чтобы не гадать заново каждый раз:

Что можно сделать самому

Возможностей у вас немного, потому что корень проблемы — вне вашей виртуалки, но кое-что сделать стоит:

• Собрать доказательную базу перед обращением в поддержку. Логи mtr с таймстампами, графики vnstat/iftop за период проблемы, время начала и конца эпизодов. Без этого тикет превращается в «у меня медленно» — а с конкретными данными хостер обычно реагирует быстрее и предметнее.
• Исключить локальные факторы, чтобы не тратить время поддержки и своё на очевидное: свежие обновления ядра/сетевого стека, драйвер virtio-net, настройки MTU, лимиты tc, странности в конфиге firewall (правила iptables/nftables, которые могли появиться после автообновлений).
• Настроить постоянный мониторинг сети, а не проверять руками только когда уже плохо — так проще поймать паттерн (время суток, периодичность) и показать его хостеру.
• Проверить, не идёт ли атака конкретно на вас — если трафик всё же входящий и большой именно на ваш IP, это уже не соседская проблема, а атака на вас лично. Что делать в этом случае — в статье DDoS-атака: первые действия.

Чего сделать самому нельзя — повлиять на трафик соседей или на пропускную способность физического порта узла. Это инфраструктурный уровень, который целиком на стороне хостера.

Что запросить у хостера

Обращаясь в поддержку, стоит просить конкретные вещи, а не общее «у меня медленно»:

1. Проверить загрузку физического сетевого порта узла в момент проблемы (с вашими таймстампами) — большинство хостеров видит нагрузку на аплинк узла в своём мониторинге и может подтвердить или опровергнуть версию с соседом.
2. Проверить, не было ли на узле инцидентов — абузы, жалоб на флуд/сканирование от других клиентов узла, срабатываний DDoS-защиты именно на этом сервере.
3. При повторяемости проблемы — запросить миграцию вашей виртуалки на другой физический узел. Это стандартная и обычно бесплатная операция для VPS, и если дело действительно в конкретном соседе на конкретной машине, миграция снимает проблему сразу.
4. Уточнить политику хостера по шейпингу трафика на узле — у части провайдеров есть механизмы fair-use или автоматического троттлинга клиента, который резко превышает норму; если такого механизма нет или он работает медленно, это стоит знать заранее, планируя, оставаться ли на этом тарифе.

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

Почему выделенный сервер снимает эту проблему полностью

На выделенном сервере (dedicated) у физического сетевого порта нет других арендаторов — вся полоса канала, которую даёт хостер, принадлежит только вам. Соседа, который может забить аплинк своим трафиком, физически не существует, потому что нет совместно используемого узла.

Это не значит, что на выделенном сервере невозможны проблемы с сетью вообще — атака на сам дата-центр, проблемы на магистральных каналах провайдера или на вашем собственном сервисе никуда не деваются. Но целый класс проблем — «мой сосед по гипервизору устроил что-то, и от этого страдаю я» — исчезает архитектурно, а не потому что хостер стал внимательнее.

Разница по сути такая:

Если эпизоды с сетью повторяются регулярно, а сервис уже чувствителен к задержкам и потерям (стриминг, трейдинг, игровые сервера, VoIP, вебсокеты в реальном времени) — экономия на VPS может обходиться дороже в виде потерянных клиентов и разбирательств с поддержкой, чем переход на выделенный сервер. Сравнение сценариев, когда стоит переезжать, а когда VPS остаётся разумным выбором, разобрано в статье VPS против выделенного сервера: когда пора переезжать.

Частые вопросы