Что там пишут?

Тестирование Citrix SD-WAN WANOP

Введение

Citrix SD-WAN WANOP (WAN Optimization) – это редакция устройств и виртуальных машин линейки SD-WAN, которые предназначены для оптимизации проходящего через них трафика, и надо сказать – справляются с этим достаточно хорошо. Данный функционал также присутствует в устройствах Citrix редакции Enterprise, совмещающей в себе агрегацию и оптимизацию трафика. Хотя нужно понимать, что Enterprise устройства предназначены больше для размещения в удаленных филиалах, где важна консолидация оборудования при использовании всех функций, а для ЦОДа рекомендуется использовать связку отдельных устройств SE и WO, реализующих виртуализацию и оптимизацию каналов по отдельности. Ранее SD-WAN WANOP устройства были известны под такими именами как Citrix Cloudbridge и Branch repeater.

А зачем вообще оптимизировать трафик? Во-первых, можно уменьшить потребляемую полосу пропускания за счет сжатия данных на лету, за счет кэширования и адресации повторяющихся блоков информации, когда вместо повторной передачи ранее отправленной информации, устройства просто указывают друг другу на области памяти, откуда эти данные можно считать (дедупликация). А во-вторых, оптимизация предполагает улучшение работы протокола TCP на транспортном уровне, снижая воздействие на сеть «болтливых» приложений, выравнивания и ускоряя передачу данных, что в конечном итоге выливается в улучшение User experience, производительность виртуальных рабочих мест и снижение затрат на каналы связи.

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

Рис. 1 Зависимость реальной полосы пропускания от задержки на канале

Как видно из таблицы, возможны ситуации, когда не спасает даже гигабит. От Москвы до Хабаровска задержка может быть больше 100 мс, а до городов в районе Урала 40-50мс – обычное дело. На спутниковых каналах связи задержка может быть 500-800мс. Поэтому начиная с задержки в 20-30 мс можно увидеть существенное проседание реальной пропускной способности, что обусловлено просто физикой процессов передачи данных. Но в сети не исключены также и потери данных, и значения около 1% процента можно считать обычными. Есть каналы с более плохими и более хорошими показателями, но даже небольшое количество «дропов» приводит к тому, что производительность TCP потока принимает форму пилы с медленным ростом и регулярными провалами (см. Рис. 2). TCP по своей природе старается постепенно занять всю предоставленную ему полосу пропускания, постоянно наращивая скорость передачи данных, но в случае потери пакета происходит резкий спад и процесс начинается заново.

Рис. 2 Передача данных без оптимизации, обычное поведение TCP

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

Рис. 3 Передача данных без оптимизации, обычное поведение TCP

В случае, когда по сети передаются данные, уже отправленные ранее, они будут скачаны на скорости локальной сети с ближайшего оптимизатора. И здесь речь идет не о простом кэшировании на уровне файлов – в Citrix WANOP реализован механизм сохранения и повторного чтения (дедупликация) данных на уровне блоков данных разной длины, которые кэшируются как в памяти, так и на диске. В отличие от традиционного кэширования, если по сети будет передан, например, текстовый файл, в который были внесены некоторые правки или даже изменено хотя бы его имя, WANOP укажет партнеру лишь на области памяти в которых хранятся части этого файла, а сами измененные блоки данных передаст по сети. При традиционном кэшировании весь файл будет передан заново, как несовпадающий с кэшем. В случае использования приложений, опубликованных в Citrix XenApp/Desktop, будут кэшированы даже графические области экрана и интерфейса программ. Так, в случае, когда одно и то же приложение используют несколько пользователей, каждому из них будут отсылаться лишь те области экрана, которые отличаются от других, а общие – будут скачиваться из кэша ближайших оптимизаторов на скорости локальной сети. Для этих целей используется низколатентный кэш в оперативной памяти, который хранит блоки размером до нескольких байт и обладает наивысшей скоростью обмена. Файловые ресурсы в основном будут кэшированы на встроенных высокопроизводительных SSD дисках.

Настройка тестового стенда

У нас на тестировании оказались два устройства Citrix SD-WAN WANOP 2000-050 (далее оптимизатор), с SSD диском на 600 ГБ под кэширование и лицензированной пропускной способностью 50Mb/s. Под этой лицензией понимается полоса оптимизированных данных, хотя общий поток, в случае нашего устройства, может быть 200 Mbit/s, из которых оптимизироваться будут 50. Но даже при этом нужно понимать, что это не мало, т.к. это скорость в WAN сегменте, а до распаковки и после рапаковки в LAN сегментах объем, и соответственно скорость, будут больше.

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

Рис. 4 Логическая схема подключения

В качестве Клиента и Сервера выступают две рабочие станции. Для удобства, разделение подсетей организовали VLAN’ами, используя всего один маршрутизатор, в который были подключены все устройства. Для организации связи в обход оптимизаторов было достаточно переключить VLAN на порту, в который подключен клиентский компьютер, так чтобы этот VLAN совпал с VLAN’ом выхода В на Linktropy. А также переключить VLAN на порту, в который подключен выход А от Linktropy, так чтобы он совпал с VLAN’ом, в который подключен Сервер. На рис. 5 представлена физическая схема подключения, на которой можно видеть используемые порты и VLAN’ы.

Рис. 5 Физическая схема подключения

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

Мониторинг трафика и снятие тестовых значений решили проводить в Wireshark, как простой и надежный метод. Для этого на маршрутизаторе была организована span сессия с порта 16 (выход В от Linktropy) на порт 29, к которому подключили ноутбук с установленным Wireshark. Этот выход дублирует поток данных на WAN участке. Для мониторинга данных на LAN участке, Wireshark был установлен на Клиентский компьютер.

Предметом испытаний в данном тестировании выступали 4 основные задачи:

– оптимизация CIFS (файлообменник)

– оптимизация почты (MAPI, RPC over HTTPS)

– оптимизация ICA/HDX (Citrix VDI)

– оптимизация HTTPS (web)

В этих задачах измерялись время, за которое проходили тестовые операции, а также объем данных передаваемых в WAN и LAN сегментах. Все тесты проводились в начале на маршруте без оптимизаторов, чтобы получить референсные значения, с которыми в последствии можно было бы сравнить результаты тестов с оптимизаторами, оценив тем самым эффект от их использования. Разница в объеме данных, переданных по WAN и LAN участкам, дает нам информацию о сжатии и использовании кэширования. Время передачи фиксировалось по графику I/O Graph в Wireshark, выделяя момент начала отправки и окончания передачи данных.

В итоге было решено провести тестирование на сетях со следующим параметрами:

  • задержка 10 мс + потери 1%
  • задержка 40 мс + потери 1%
  • задержка 100 мс + потери 1%
  • задержка 800 мс + потери 1%

Первичную отправку данных обозначили как Cold, а повторную – Warm. Замеры без оптимизаторов – всегда Cold, т.к. при повторной отправке ничего не меняется, за исключением погрешности и разброса показателей из-за некоторой доли нестабильности в сети. После каждого проведения Warm теста решили очищать кэш оптимизаторов, для получения чистых результатов, исключая влияние ранее сохраненных данных.

Также стоит отметить, что в соответствии с лицензированной полосой пропускания оптимизаторов в 50 Мб/с было решено задать скорость WAN канала – 50 Мб/с. Если оптимизатор работает в сети, скорость которой превышает лицензированный порог, но не превышает максимальную скорость пропускания, то устройство будет оптимизировать данные только на скорости лицензированной полосы. Остальные данные, которые превышают этот порог, будут проходить без оптимизации. Чтобы исключить неоптимизированный трафик из измерений, ширину канала взяли в соответствии с лицензией.

Тестирование CIFS

В Citrix WANOP есть три режима оптимизации, которые можно настроить для интересующего вас протокола: Flow Control Only, Memory и Disk. В режиме Flow Control Only устройство не сжимает и не кэширует данные, а лишь управляет передачей TCP Flow. В режиме Memory к оптимизации TCP добавляется возможность гранулярно сжимать и кэшировать блоки длинной в несколько байт, хранимые в оперативной памяти оптимизатора для тех задач, которые требуют минимальное время отклика. В режиме Disk работают все возможные алгоритмы оптимизации, включая блочное кэширование и сжатие за чем использования SSD диска.

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

  1. Копирование одного большого несжимаего файла в режиме Flow Control Only – выявляет работу TCP Flow Control
  2. Копирование 150 сгенерированных маленьких файлов со случайными данными (в режиме Flow Control Only) – выявляет оптимизацию болтливости
  3. Копирование сжимаемых данных (в режиме Disk) – выявляет способность сжимать данные на лету
  4. Копирование версионных файлов (в режиме Disk) – выявляет способность к блочному кэшированию

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

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

Результаты

Тест 1.1 – Один несжимаемый файл (.rar 20MB)
Тест 1.2 – Много маленьких файлов (150 сгенерированных файлов по 10kB)
Тест 1.3 – Сжимаемые данные (.rtf файл – 23MB). В данном тесте измерялся объем информации, передаваемый в LAN и WAN сегментах, чтобы оценить степень сжатия и дедупликации.
Тест 1.4 – Версионные файлы (версии .docx файлов). Данный тест похож на предыдущий за исключением того, что здесь использовались мало сжимаемые файлы .docx (которые представляют из себя .zip архив), незначительно отличающиеся друг от друга от внесенных правок. Таким образом мы видим в большей степени работу дедупликации.

Тестирование почты MAPI

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

В качестве тестового задания было решено пересылать письмо с несколькими офисными вложениями (документы Word и Excel, презентации Powerpoint). В результате оценивали время доставки и объем сэкономленного трафика, измеряемые как обычно через Wireshark. Далее представлены результаты измерений.

Тест 2.1 – Одно письмо (несколько вложений – 28MB) – MAPI

Тестирование почты RPC over HTTPS

Для оптимизации почты, использующей протокол RPC over HTTPS, вводить серверный оптимизатор в домен не требуется, достаточно установить все необходимые сертификаты. В данном тесте мы использовали Exchange 2016.

В качестве тестового задания было выбрано письмо с несколькими офисными вложениями из первого теста (документы Word и Excel, презентации Powerpoint). В результате оценивали время доставки и объем сэкономленного трафика.

Тест 3.1 – Одно письмо (несколько вложений – 28MB) – RPC over HTTPS

Тестирование HTTPS

В рамках тестирования оптимизации передачи данных по сети нельзя было обойти стороной web-трафик и производительность web-страниц. При этом рассматривался именно шифрованный SSL трафик, для обработки которого на оптимизаторы нужно устанавливать соответствующие сертификаты. Обычно – это сертификат CA и сертификат того сервера, для связи с которым настраивается оптимизация. Если сертификаты не установлены, или что-то настроено не так, HTTPS трафик оптимизироваться не будет.

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


Тест 4.1 – Время загрузки WEB-страниц и объем передаваемых данных

Значимый прирост в скорости наблюдается только, начиная с серьезных задержек в 100мс, при этом картина с кешированием и сжатием трафика напоминает все остальные тесты.

Также для оценки оптимизации HTTPS трафика решили провести одну из наиболее распространенных операций – скачивание файла (.rar архив). Результаты на слайде.

Тест 4.2 – Время скачивания архива с WEB-страницы

Тестирование ICA/HDX

С тестированием Citrix оказалось несколько сложнее. Трудность заключается в том, что использование SD-WAN WANOP в сценарии VDI позволяет добиться лучшей производительности в использовании приложений, более быстрого отклика на действия пользователя и лучшего качества изображения. Все эти показатели хоть и воспринимаются каждым отдельным пользователем, и каждый в состоянии сказать, что стало «лучше» или «хуже», но померить это, зафиксировать и получить какие-то численные результаты довольно сложно. При том, что эффект на практике будет заметным тем сильнее, чем больше пользователей работают в похожих приложениях (например, бухгалтера в 1С), что невозможно воспроизвести в малой тестовой среде. Поэтому было решено провести 2 простых теста, чтобы выявить хоть какие-то закономерности: это копирование файлов и печать в HDX/ICA сессии.

Тест 5.1 – Печать в ICA/HDX сессии (Powerpoint документ 8MB).
Тест 5.2 – Копирование файлов в ICA/HDX сессии (.msu файл обновлений 11MB)

Трудности во время тестирования

– NetScaler SD-WAN WANOP имеет типичный интерфейс веб-консоли, который схож с любым другим NetScaler’ом, но со своими уникальными особенностями. В целом навигация по меню не составляет труда, но иногда некоторые страницы начинают открываться значительно долго для такой простой операции. С чем это было связано – выявить не удалось.

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

– Не сразу удалось найти, каким образом можно очистить кэш. Сделать это можно, зайдя в консоль по ссылке: http://<NetSacler_IP_address>/console.php. И затем в командной строке поочередно ввести следующие команды (без кавычек):

“compressionhistory content_reset”

“ResetDiskHistory”

Первая команда очищает кэш в памяти, вторая – на диске.

– Во время тестирования почты оказалось невозможным получить достоверные данные по сценарию, когда с почтового сервера приходит не одно письмо, а несколько. Для этого сформированную цепочку из 20 писем на сервер сначала нужно доставить, а затем инициировать их передачу. Но выходило так, что во время замеров времени на скачивание писем в Outlook клиента сначала скачивались 3-5 писем, затем было затишье, и спустя какое-то время докачивались все остальные. Это связано с тем, что в NetScaler’е есть функция авто-опроса почтового сервера, не пришло появились ли новые письма, которые в случае обнаружения скачиваются в локальный кэш. Таким образом сотрудник, открыв свою почту, быстро получает новые письма, закэшированные на WANOP. И видимо этот функционал препятствовал проведению тестирования, скачивая первые нексоклько писем и сразу их отсылая, а последующие – уже после полной их загрузки на почтовый сервер. Тем не менее сама по себе функция эта – полезная.


В целом NetScaler SD-WAN WANOP оставил очень приятные впечатления, т.к. удалось зафиксировать основной заявленный результат по значительному снижению повторно передаваемого трафика, и по увеличению производительности передачи данных относительно обычного поведения TCP. В свою очередь было экспериментально зафиксировано, что с увеличением задержки реальная производительность канала снижается значительно, в чем не все специалисты бывают уверены. Жаль только, что не удалось провести достойное тестирование оптимизации HDX/ICA и кэширования видео, но данные технологии заведомо должны работать лучше с Citrix WANOP’ом, чем с чем бы то еще, в силу нативной совместимости и полной прозрачности протоколов в рамках единой экосистемы Citrix.

Оставьте комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

один + четыре =

Scroll Up