Видеоконференция без обрывов: почему одного Hot Failover недостаточно

Тот, кто хочет застраховать видеоконференцию, думает сначала о полном отказе: экскаватор, отключение электричества, авария у провайдера. На практике это более редкий случай. Идущую передачу на самом деле портят потери пакетов и колебания задержки на линии, которая формально по-прежнему «up».

Понять суть помогает порядок величин. Для отправки потока 1080p Zoom указывает около 3,8 Mbit/s на отдачу; параллельная демонстрация презентации добавляет примерно от 50 до 150 kbit/s, аудиоканал — от 60 до 80 kbit/s. Значит, профессиональному студийному рабочему месту нужно примерно 4 Mbit/s на отдачу — на подключении с 40 или 300 Mbit/s отдачи это погрешность округления.

Именно здесь и лежит ошибка многих концепций резервирования: пропускная способность не является проблемой. Проблема в равномерности доставки. Кодек реального времени не может запросить потерянный пакет повторно и дождаться его — воспроизведение идёт дальше. Пропал пакет — возникает артефакт; пропало несколько подряд — картинка замирает или обрывается звук. Два процента потерь пакетов на линии 300 Mbit/s незаметны при скачивании файла и отчётливо слышны в прямой передаче.

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

Hot Failover — это режим работы туннеля SpeedFusion. Туннель поднимается по всем задействованным соединениям WAN и поддерживается активным на всех, но полезный трафик в каждый момент времени несёт только путь с наивысшим приоритетом. Если он отказывает, эстафету принимает следующий.

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

И вот та брешь, о которой в предложениях говорят редко: переключение начинается только тогда, когда сбой обнаружен. Обнаруживается он через мониторинг линии и keepalive-пакеты туннеля. Насколько быстро это происходит, вытекает из произведения интервала проверки и числа повторов, после которых линия считается мёртвой, — плюс время, которое требуется самому переключению.

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

Ещё важнее: более частый вид отказа Hot Failover вообще не закрывает. Линия с двумя процентами потерь пакетов не отказала. Она проходит любую проверку, остаётся активной и всё это время даёт плохую картинку.

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

Из этого следуют три вещи, которые точно подходят прямой передаче:

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

Цена — пропускная способность, причём с планируемой градацией. Ступень Normal удваивает объём трафика, Medium утраивает его, High увеличивает его вчетверо; Maximum зависит от числа активных пар соединений. Значит, для нашего студийного рабочего места с полезной нагрузкой 4 Mbit/s ступень Normal означает 8 Mbit/s на подключении — для бизнес-линии это мелочь.

Важна точка отсчёта: накладные расходы возникают только для того трафика, который идёт в сглаженном туннеле. Кто включает Smoothing огулом для всего дома, удваивает и каждую загрузку, и каждое резервное копирование. Именно поэтому ему место в отдельном субтуннеле.

Между «ничего не делать» и «отправлять всё дважды» находится Forward Error Correction. Вместо передачи полных копий FEC дополняет поток данных корректирующей информацией, из которой удалённая сторона может восстановить потерянные пакеты, не запрашивая их повторно.

За счёт этого накладные расходы заметно меньше. Статические ступени лежат около 13 процентов и около 27 процентов; адаптивный вариант регулируется динамически примерно между 7 и 20 процентами в зависимости от измеренных потерь. Значит, вместо удвоения платят надбавку в низком двузначном процентном диапазоне.

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

В списках требований часто встречается формулировка вроде: резервирование через Hot Failover, при необходимости дополнительно WAN Smoothing. Звучит разумно и технически неосуществимо — по крайней мере не так, как это задумано.

WAN Smoothing — это фиксированная настройка в профиле туннеля, а не контур регулирования. Автоматики, которая при росте задержки или увеличении потерь пакетов подключалась бы сама, не существует. Значит, кто планирует «при необходимости», должен сам определить эту необходимость — и есть ровно три состоятельных ответа:

1. Постоянно активен для критического субтуннеля. Накладные расходы известны и невелики, польза есть всегда. Почти во всех случаях это правильный ответ.
2. По расписанию: правило, которое направляет трафик в сглаженный туннель, привязывается к временному профилю. Разумно, когда объём ограничен, а время выхода в эфир известно заранее.
3. Постоянный FEC, а Smoothing только для определённых событий. Компромисс для линий в дефиците.

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

Чистое решение отделяет критический трафик от остального вместо того, чтобы удваивать всю сеть. Для этого Peplink в прошивке 8.0.1 ввёл субтуннели: один канал SpeedFusion может нести несколько субтуннелей — задокументировано до пяти — и каждый со своим профилем. Один туннель, несколько вариантов поведения.

Конфигурация на практике:

1. Студийное рабочее место получает фиксированный адрес через резервирование DHCP и находится в отдельном VLAN. Без стабильного адреса ни одно правило не надёжно.
2. Создать субтуннель с WAN Smoothing, ступень Normal как отправная точка.
3. Правило трафика направляет трафик этого одного компьютера в этот субтуннель — привязка по адресу источника надёжнее правила по портам, потому что работает независимо от того, какие порты конференц-программа задействует в следующем обновлении.
4. Всё остальное идёт напрямую через линии или через второй субтуннель в режиме Hot Failover. Для резервного копирования и больших выгрузок дополнительно устанавливается ограничение полосы, чтобы они не вытесняли студийное рабочее место.

Два места, на которых это срывается на практике. Во-первых, туннелю SpeedFusion всегда нужна встречная точка — второе устройство Peplink, FusionHub или хостируемый сервис SpeedFusion Connect. Без удалённой стороны нет Smoothing, а есть только распределение нагрузки. Во-вторых, с объёмом данных всё не само собой: то, что сглаженный туннель передаёт дважды, во встречной точке тоже считается дважды. Как это считается, мы разобрали в отдельной статье.

И самое важное предложение в конце, потому что на сетевой схеме его не видно: резервирование линий защищает от сбоев линий. Оно не защищает от зависшего студийного рабочего места, от повисшего адаптера захвата или от аварии у провайдера конференций. Кто действительно хочет застраховать передачу, подключает компьютер и монитор к ИБП и держит наготове второй компьютер как со-модератора.

Эта статья исследована и написана с помощью ИИ и перед публикацией проверена сертифицированными по Peplink техниками Ascend.