Тестирование механизмов балансировки на Kaspersky SD-Wan

Описание тестового стенда и ограничения

Для целей тестирования в нашей лаборатории была развернута сеть, состоящая из двух SD-WAN CPE:

• —Kaspersky SD-WAN ESR (R) Model 1 (железка с LTE модемом и 5ю Ethernet портами) на стороне клиента IPERF;

• —Kaspersky SD-WAN Virtual M1 развернутый в «облаке» на гипервизоре, на стороне сервера IPERF.

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

Между двумя CPE установлены 2 линка (Link в терминах SD-WAN) в каждую сторону (всего 4), которые формируют отказоустойчивый сегмент (Segment) для прохождения трафика.

 Для генерации трафика и измерения скорости передачи использовалась утилита Iperf3. В данной статье рассматривается только TCP трафик, как наиболее распространённые в интернет (для UDP картина будет другой).

С тестового компьютера по очереди запускается два теста в 8 параллельных потоков. Тестирование в один поток не показательно, так как скорее всего может исказить результаты балансировки – из-за того, что весь трафик может попасть в один канал провайдера. Примечание: одновременные прием и передача не исследовались в данной статье, так как тесты запускали один за одним. Графики отражают трафик от сервера к клиенту.

Система мониторинга на основе Zabbix снимает метрики потребления сетевого трафика каждые 10 секунд c виртуальной и физической CPE. На стороне клиента метрики снимаются с портов sdwan0 и sdwan1. На стороне сервера суммированный трафик измеряется на интерфейсе ближе к серверу, чтобы визуализировать итоговый результат.

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

На стороне IPERF сервера трафик TCP исследуется с помощью встроенных средств программы Wireshark.

Балансировка по пакетам (Per-packet)

Adaptive balancing: выключена

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

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

Cost = 10 000 000 / Speed, где Speed берется с физического порта интерфейса или может быть задана в параметре «max rate».

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

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

После запуска Iperf анализируем загрузку портов SD-WAN:

Скорость низкая, пропускная способность второго провайдера «подравнивается» под первого. Итоговый трафик суммируется, но не поднимается выше х2 «деградировавшего» канала.

График TCP-сессий на сервере показывает огромное количество ошибок TCP-соединения и объясняет медленную скорость:

Замеры IPERF показывают и подтверждают грустные результаты:

Трафик от сервера к клиенту (на его основе построены графики выше):

[ ID] Interval           Transfer     Bitrate

[  5]   0.00-840.00 sec  7.62 MBytes  76.1 Kbits/sec                  sender

[  8]   0.00-840.00 sec  23.9 MBytes   238 Kbits/sec                  sender

[ 10]   0.00-840.00 sec  19.4 MBytes   193 Kbits/sec                  sender

[ 12]   0.00-840.00 sec  16.9 MBytes   169 Kbits/sec                  sender

[ 14]   0.00-840.00 sec   896 KBytes  8.74 Kbits/sec                  sender

[ 16]   0.00-840.00 sec  21.1 MBytes   211 Kbits/sec                  sender

[ 18]   0.00-840.00 sec  14.9 MBytes   149 Kbits/sec                  sender

[ 20]   0.00-840.00 sec  22.0 MBytes   220 Kbits/sec                  sender

[SUM]   0.00-840.00 sec   127 MBytes  1.26 Mbits/sec                  sender

Трафик от клиента к серверу:

[ ID] Interval           Transfer     Bitrate

[  5]   0.00-240.12 sec  4.75 MBytes   166 Kbits/sec                  receiver

[  8]   0.00-240.12 sec  1.62 MBytes  56.8 Kbits/sec                  receiver

[ 10]   0.00-240.12 sec  2.12 MBytes  74.2 Kbits/sec                  receiver

[ 12]   0.00-240.12 sec  4.00 MBytes   140 Kbits/sec                  receiver

[ 14]   0.00-240.12 sec  4.38 MBytes   153 Kbits/sec                  receiver

[ 16]   0.00-240.12 sec  4.62 MBytes   162 Kbits/sec                  receiver

[ 18]   0.00-240.12 sec  4.25 MBytes   148 Kbits/sec                  receiver

[ 20]   0.00-240.12 sec  4.38 MBytes   153 Kbits/sec                  receiver

[SUM]   0.00-240.12 sec  30.1 MBytes  1.05 Mbits/sec                  receiver

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