Резервное копирование

Латентность российских облаков: как диагностировать задержки до Selectel и Yandex Cloud

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

1. Что измерять до изменения маршрутизации

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

Метрика	Что показывает	Почему важна
RTT	Время прохождения пакета до узла и обратно	Влияет на интерактивные приложения, базы данных и протоколы с частыми подтверждениями
Jitter	Разброс времени отклика	Выявляет нестабильность канала, которую скрывает среднее значение RTT
Packet loss	Долю потерянных пакетов	Вызывает повторные передачи TCP и резкое падение полезной скорости
Пропускная способность	Фактическую скорость передачи TCP и UDP	Показывает, способен ли канал передать резервную копию в предусмотренное окно
Retransmits	Число повторных передач TCP	Помогает отличить сетевую проблему от ограничения диска или приложения
MTU и фрагментация	Проходит ли пакет выбранного размера по всему пути	Особенно важно для IPsec, GRE и других туннелей с дополнительными заголовками

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

Не назначайте универсальный «нормальный пинг». Критерий должен исходить из профиля приложения, исходного замера, требований к окну резервного копирования и согласованных параметров канала.

2. Пошаговая диагностика задержек и пропускной способности

Шаг 1. Исключите локальную сеть

Сначала измерьте задержку до шлюза филиала и до первого доступного узла оператора. Проверьте загрузку WAN-интерфейса, ошибки, отброшенные пакеты, состояние дуплекса и очередей QoS. Если потери появляются до выхода к оператору, изменение облачного маршрута проблему не устранит.

# Linux: серия запросов к локальному шлюзу
ping -c <число_запросов> <адрес_шлюза>

# Состояние интерфейса и счётчики
ip -s link show dev <интерфейс>
ethtool <интерфейс>

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

Шаг 2. Снимите маршрут до реального облачного ресурса

Выполните трассировку до тестовой виртуальной машины или другого адреса, который участвует в рабочем обмене. Замеры делайте с той же площадки и через тот же шлюз, которыми пользуется приложение резервного копирования.

# Linux
traceroute <облачный_IP>
mtr -rwzbc <число_циклов> <облачный_IP>

# Windows
tracert <облачный_IP>
pathping <облачный_IP>

Сохраните отчёты для Selectel и Yandex Cloud отдельно. Смотрите, где устойчиво меняются задержка или потери. Отсутствие ответа от промежуточного маршрутизатора само по себе не доказывает потерю пользовательского трафика: сетевое оборудование может ограничивать ICMP. Значима потеря, которая сохраняется на последующих узлах и на конечном адресе.

Шаг 3. Проверьте маршрут в обоих направлениях

Запустите трассировку из локальной сети в облако и с облачной виртуальной машины обратно к публичному адресу площадки. Прямой и обратный трафик могут идти через разных операторов. Такая асимметрия не всегда является ошибкой, но её нужно учитывать при диагностике stateful firewall, NAT и нестабильных VPN-туннелей.

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

Шаг 4. Измерьте полезную скорость через iperf3

Разверните временный сервер iperf3 на собственной тестовой виртуальной машине в нужном облачном сегменте. Не используйте случайный публичный сервер: его загрузка и сетевые ограничения неизвестны. Разрешите тестовый порт только для адреса вашей площадки и закройте доступ после проверки.

# На тестовой виртуальной машине
iperf3 -s

# С локальной площадки: передача в облако
iperf3 -c <облачный_IP> -t <длительность>

# Обратное направление
iperf3 -c <облачный_IP> -R -t <длительность>

# Несколько параллельных TCP-потоков
iperf3 -c <облачный_IP> -P <число_потоков> -t <длительность>

Сопоставьте одиночный и многопоточный тесты. Если один поток заметно медленнее нескольких, проверьте RTT, потери, TCP window, shaping и особенности приложения. Если одинаково ограничены все варианты, ищите лимит интерфейса, VPN-шлюза, тарифа связи, виртуальной машины или политики QoS.

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

Шаг 5. Проверьте MTU внутри рабочего туннеля

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

# Linux: запрет фрагментации
ping -M do -s <размер_полезной_нагрузки> <удалённый_IP>

# Windows: запрет фрагментации
ping -f -l <размер_полезной_нагрузки> <удалённый_IP>

Если крупные пакеты не проходят, согласуйте MTU на интерфейсах и туннелях либо настройте TCP MSS clamping на границе. Обязательно проверьте, что ICMP-сообщения, необходимые для Path MTU Discovery, не блокируются без необходимости.

3. Как оптимизировать гибридный маршрут

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

Разместите тестовую виртуальную машину в том же облачном регионе и сетевом сегменте, где работает целевая система. Не выбирайте площадку только по названию города — сравните фактические маршруты от ваших офисов и ЦОД.
Разделите маршруты к Selectel, Yandex Cloud и обычному интернету. Направляйте облачные префиксы через соответствующий VPN или выделенный канал, не меняя маршрут всего пользовательского трафика без необходимости.
Исключите пересекающиеся адресные пространства локальных и облачных подсетей. Иначе придётся применять дополнительный NAT, который усложняет диагностику и правила доступа.
Для двух каналов задайте понятную политику выбора и возврата маршрута. При BGP контролируйте принимаемые и анонсируемые префиксы фильтрами, а также проверяйте поведение при отказе каждого соединения.
Согласуйте маршрутизацию с DNS. В гибридной схеме внутреннее имя должно возвращать адрес, достижимый через приватный маршрут, если именно он предусмотрен архитектурой.
Ограничьте фоновые копии политиками QoS так, чтобы резервное копирование не вытесняло критичный бизнес-трафик. Одновременно убедитесь, что QoS не стал причиной искусственного ограничения самого задания копирования.

Для прямой связности с инфраструктурой Yandex Cloud используется Yandex Cloud Interconnect. Обмен маршрутами в приватных соединениях строится с использованием BGP и Routing Instance; точную схему следует проектировать по документации сервиса и параметрам оператора связи.

В Selectel варианты связности зависят от используемого продукта. Для объединения приватных подсетей применяется Глобальный роутер Selectel, а подключение стороннего оператора и варианты Direct Connect описаны в документации по сетям выделенных серверов. Перед изменением маршрутов уточните доступность требуемой схемы для конкретного облачного проекта.

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

4. Критерии проверки и типовые ошибки

Критерии приёмки

Изменение можно считать подтверждённым только после повторного замера по той же методике. В отчёте должны присутствовать:

схема пути от локальной сети до каждого облачного ресурса;
результаты RTT, jitter и потерь в разные периоды нагрузки;
трассировки в прямом и обратном направлениях;
скорость iperf3 в облако и из облака;
число повторных передач TCP и загрузка интерфейсов во время теста;
подтверждённый MTU рабочего туннеля;
время фактического тестового резервного копирования и восстановления;
проверка переключения на резервный канал и возврата на основной;
сравнение с исходным замером и требованиями приложения.

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

Типовые ошибки

Оценивать канал только по ping. Низкий RTT не гарантирует достаточную пропускную способность и отсутствие повторных передач.
Тестировать сайт провайдера вместо рабочего ресурса. Маршруты до публичного сайта и облачной виртуальной машины могут различаться.
Считать каждый пропуск в traceroute аварией. Промежуточный узел может ограничивать ответы ICMP, продолжая нормально передавать трафик.
Запускать тест во время неизвестной фоновой нагрузки. Без данных с WAN-интерфейса результат невозможно правильно интерпретировать.
Использовать публичный iperf-сервер. Его производительность и ограничения не находятся под вашим контролем.
Смешивать сетевой тест с копированием файлов. Диск, шифрование и дедупликация могут стать узким местом раньше сети.
Менять основной маршрут без плана возврата. Ошибка в статическом маршруте или BGP-фильтре способна нарушить доступ сразу к нескольким системам.
Игнорировать обратный путь. Асимметричная маршрутизация может конфликтовать с межсетевым экраном и NAT.
Забывать про MTU после включения VPN. Туннельные заголовки уменьшают доступный размер полезной нагрузки.
Не проверять восстановление. Быстрая отправка копии не подтверждает, что данные можно получить обратно в требуемое время.

5. Краткий вывод

Оптимизация связи с Selectel и Yandex Cloud начинается не с замены провайдера, а с воспроизводимого замера. Проверьте локальный сегмент, оба направления маршрута, потери, TCP-пропускную способность, MTU и ограничения конечных систем. Затем сравните интернет-VPN и выделенную схему на одинаковых тестах, зафиксируйте маршруты и подтвердите результат реальным заданием резервного копирования и восстановления.

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