Соседи по гипервизору и ваш канал: как измерить, сколько сети реально досталось вам

MAATRIX

Сайт или API на VPS то работает штатно, то без видимой причины «подвисает» на секунды именно в сети — при этом собственный трафик копеечный, а CPU и диск скучают в простое. Одно из вероятных объяснений: вы не одни на этом физическом канале, и когда сосед по гипервизору начинает гонять трафик, вашей VM достаётся меньше полосы, чем указано в тарифе. Разово это не измерить — нужен систематический замер, чтобы отличить реальную нехватку общего канала от внешних сетевых шумов или собственной нагрузки.

Почему на общем канале ваша скорость не гарантирована

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

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

Разница между «шумным соседом по CPU» и «шумным соседом по сети» в том, что первое видно изнутри VM напрямую — метрика steal time в top показывает, сколько процессорного времени забрал гипервизор в пользу другого гостя (методика в статье про steal time). У сети такой прямой метрики нет: гостевая ОС видит только свой трафик и не знает, сколько трафика в этот момент гоняют по тому же физическому порту другие гости. Отсюда и сложность диагностики — приходится измерять внешнее поведение канала и делать выводы косвенно.

«Гарантированная» и «до» полоса: что на самом деле обещает тариф

В карточках тарифов VPS-провайдеров формулировки про сеть звучат похоже, но означают разное, и путаница между ними — источник половины недопониманий с поддержкой:

Модель burst-полосы честна с инженерной точки зрения: провайдер даёт прокачать больше номинала на короткое время, пока канал свободен, но не обязуется держать эту скорость постоянно при активных соседях. Проблема в том, что формулировка часто не уточняет, burst перед вами или устойчивая гарантия — оба варианта могут называться просто «1 Гбит/с». Подробный разбор того, что стоит за словом «гарантированный» и как работает оверсабскрипшн, — в статье про общий канал и выделенный.

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

Почему нельзя мерить канал через сам хостинг

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

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

Во-вторых, контрольная точка того же провайдера сама может стать вашим «шумным соседом наоборот»: если на ней в момент теста запущена посторонняя нагрузка, результат смешивается с ещё одной неизвестной переменной.

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

• недорогая VPS у другого провайдера, поднятая специально под роль измерительного сервера;
• сервер, который у вас уже есть по другим задачам в другой инфраструктуре;
• в крайнем случае — публичный iperf3-сервер (их список меняется, стоит поискать актуальный, а не брать адрес из старого руководства; публичные точки сами часто перегружены и годятся скорее для грубой оценки).

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

Методика регулярных замеров iperf3

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

Поднимите iperf3-сервер на контрольной точке (вне вашего основного хостинга):

# На контрольном сервере — держим iperf3 в режиме сервера постоянно
iperf3 -s -D

Флаг -D переводит процесс в фоновый режим (демон); для постоянной работы имеет смысл обернуть его в systemd-юнит, чтобы сервис поднимался сам после перезагрузки контрольного сервера.

На основной VPS запускайте тест по расписанию через cron, сохраняя каждый результат вместе с меткой времени:

#!/usr/bin/env bash
# /usr/local/bin/net-probe.sh
LOG=/var/log/net-probe.log
TS=$(date '+%Y-%m-%d %H:%M:%S')
RESULT=$(iperf3 -c control.example.net -t 15 -J 2>&1)
BW=$(echo "$RESULT" | grep -o '"bits_per_second":[0-9.]*' | tail -1 | cut -d: -f2)
RETR=$(echo "$RESULT" | grep -o '"retransmits":[0-9]*' | tail -1 | cut -d: -f2)
echo "$TS bps=$BW retransmits=$RETR" >> "$LOG"

# crontab -e — четыре замера в сутки плюс один ночной, чтобы поймать разброс между пиком и затишьем
0 9,13,18,22 * * * /usr/local/bin/net-probe.sh
0 3 * * * /usr/local/bin/net-probe.sh

Ключевые параметры теста:

• -t 15 — длительность в секундах. Слишком короткий тест (2-3 с) не успевает выйти на устойчивую скорость; 10-20 секунд — разумный баланс.
• -J — вывод в JSON, чтобы результат было удобно парсить скриптом, а не выцарапывать из текста регулярками.
• -P 4 (опционально) — несколько потоков. Один поток на канале с большой задержкой может не выбрать даже свободную полосу из-за размера TCP-окна — тогда низкий результат говорит не о соседях, а об окне. На длинных маршрутах стоит сравнивать -P 1 и -P 4 отдельно.
• UDP-режим (-u -b <полоса>) показывает потери пакетов и джиттер при заданной скорости отправки — ближе к поведению критичных к реальному времени сервисов, чем TCP-throughput тест.

Держите отдельный лог потерь пакетов и retransmits, а не только пропускной способности — иногда канал деградирует не по скорости, а по стабильности: полоса та же, но растут ретрансмиты TCP, из-за чего эффективная скорость приложения проседает сильнее, чем видно по сырому bits_per_second.

Как читать накопленную статистику и искать паттерн

Смысл регулярных замеров не в отдельной цифре, а в разбросе между замерами и в его привязке ко времени. После недели-двух сбора данных стоит смотреть на несколько вещей.

Привязка ко времени суток. Если результаты стабильно хуже в определённые часы (типично — вечерний пик, когда активны и пользователи соседних проектов, и автоматические бэкапы) и стабильно лучше в другие — это не случайный шум, а системный паттерн общего канала. Разброс без временной привязки скорее говорит о нестабильности транзитной сети до контрольной точки.

Сравнение дня недели. У разных проектов разная типовая нагрузка — у кого-то трафик коррелирует с рабочим днём, у кого-то со свободным вечером. Разница между буднями и выходными в логах — ещё один сигнал в пользу гипотезы про общий узел.

Устойчивость просадки, а не единичный выброс. Один плохой замер раз в месяц может быть чем угодно — сбоем на магистрали, случайным всплеском на маршруте. Признак именно проблемы общего канала — воспроизводимая просадка примерно в одно и то же время несколько дней подряд.

Простой способ увидеть паттерн без отдельных инструментов — вывести среднее по часам прямо в терминале:

awk '{split($2,t,":"); h=t[1]; split($3,b,"="); bw[h]+=b[2]; cnt[h]++}
     END {for (h in bw) printf "%s:00  avg=%.1f Mbit/s (n=%d)\n", h, bw[h]/cnt[h]/1e6, cnt[h]}' \
     /var/log/net-probe.log | sort

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

Как отличить сетевую проблему хоста от собственной нагрузки

Прямо увидеть, что делают соседние виртуальные машины на том же физическом узле, вы не можете — гипервизор намеренно не даёт гостевой ОС такой видимости. Но косвенно отличить «нагружен общий канал хоста» от «нагружены вы сами» реально, если снимать метрики своей VM синхронно с сетевым тестом: если в момент просадки iperf3 нагрузка на CPU, диск и сеть внутри VM низкая, а внешний тест всё равно показывает деградацию — узкое место снаружи виртуальной машины. Собирайте метрики одновременно с сетевым тестом, в одном скрипте:

#!/usr/bin/env bash
# Расширенный net-probe: сеть + собственные ресурсы одним замером
TS=$(date '+%Y-%m-%d %H:%M:%S')
CPU_IDLE=$(vmstat 1 2 | tail -1 | awk '{print $15}')
STEAL=$(vmstat 1 2 | tail -1 | awk '{print $17}')
DISK_UTIL=$(iostat -x 1 2 | tail -n +$(($(iostat -x 1 2 | grep -n Device | tail -1 | cut -d: -f1)+1)) | awk '{print $NF; exit}')
BW=$(iperf3 -c control.example.net -t 10 -J | grep -o '"bits_per_second":[0-9.]*' | tail -1 | cut -d: -f2)
echo "$TS bw=$BW cpu_idle=$CPU_IDLE steal=$STEAL disk_util=$DISK_UTIL" >> /var/log/net-probe-full.log

Столбец steal из vmstat здесь особенно показателен: если он растёт одновременно с падением сетевой скорости, гипервизор в этот момент жмёт VM по нескольким ресурсам сразу, что ещё сильнее указывает на перегруженный узел. Методика чтения этой колонки разобрана в статье про steal time, а более широкий чек-лист диагностики шумного соседа по CPU, диску и сети — в статье про шумного соседа на гипервизоре.

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

Что делать, если паттерн подтвердился

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

Соберите данные перед обращением в поддержку. Голословное «у меня медленный интернет» разбирают долго и часто безрезультатно. Быстрее работает конкретика: график с метками времени, показывающий просадку в конкретные часы на протяжении нескольких дней, плюс подтверждение, что собственная нагрузка VM в эти моменты низкая. Хорошая поддержка либо подтвердит перегрузку узла и предложит миграцию, либо укажет на встречный факт, который вы не учли.

Уточните у провайдера модель канала явно — burst или устойчивая гарантия, и до какой точки сети она действует. Прямой вопрос в духе «канал оверсабскрайбленный или с резервированием» обычно даёт более полезный ответ, чем попытка додумать это по формулировке в тарифе.

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

Для по-настоящему критичных к сети задач — торговые системы, потоковое видео, VoIP, синхронная репликация между дата-центрами, игровые серверы — постоянная работа на общем канале может быть неподходящей моделью в принципе. Тогда разумно сравнить стоимость перехода на тариф с честно выделенным каналом против цены простоев и разбирательств с общим каналом. Разбор того, что технически отличает выделенный канал от общего, — в статье про общий канал против выделенного.

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

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