Ранее в нашем блоге на Хабре мы уже разбирали, из чего состоит и как работает VMware SD-WAN. Пришло время проверить его в деле!
Сегодня мы посмотрим, насколько эффективно SD-WAN помогает сохранить требуемую производительность приложений при деградации каналов связи и даже полном отказе основного канала. Дополнительно познакомимся с возможностями встроенного мониторинга WAN-каналов и пользовательских приложений.
Зачем все это нужно? С помощью практических сценариев я хочу показать, как работает решение VMware SD-WAN и каким образом инфраструктура провайдера раскрывает его возможности. Иными словами, мы будем тестировать не абстрактную технологию, а готовый сервис от #CloudMTS. Будет много замеров, сравнений и графиков.
Чтобы освежить принципы работы технологии, рекомендую обратиться к предыдущей статье. Там мы уже использовали многие термины из парадигмы SD-WAN, но на всякий случай я приведу их здесь еще раз. Все это понадобится нам для понимания методов и результатов тестирования.
DMPO (Dynamic Multipath Optimization) — набор технологий, обеспечивающий построение надежной и устойчивой оверлейной сети, которая учитывает производительность каналов WAN в реальном времени.
VCG (Velocloud Gateway / VMware SD-WAN Gateway) — облачный шлюз, выполняющий функцию Control Plane и опционально Data Plane. Размещается в точках обмена трафиком, ЦОД, пиринговых площадках, стыках с IaaS-провайдерами.
SD-WAN фабрика — совокупность всех SD-WAN устройств организации, объединенных в защищенную сеть.
VCO (Velocloud Orchestrator / VMware SD-WAN Orchestrator) — система управления SD-WAN фабрикой.
VCMP — тоннельный протокол в SD-WAN от VMware, также участвует в измерении характеристика каналов.
VCE (Velocloud Edge / VMware SD-WAN Edge) — маршрутизатор, каналообразующее оборудование на удаленной площадке или в ЦОД, реализует Data Plane компонент.
Примечание. Как вы помните из предыдущей статьи, ключевым шагом VMware на рынке SD-WAN стала покупка стартапа Velocloud Networks. На момент сделки терминология решения (VCE — Velocloud Edge, VCO — Velocloud Orchestrator и другие) уже закрепились за ним в индустрии. Эти же обозначения использовались и на момент интеграции SD-WAN by Velocloud в продуктовую линейку VMware. Сейчас компания внедряет новые обозначения (например, VMware SD-WAN Edge вместо Velocloud Edge), но делает это разумно. За годы, прошедшие с момента покупки Velocloud, их оригинальная терминология для многих стала узнаваемой и устоявшейся. А некоторые обозначения — например, название протокола Velocloud Multipath Protocol (VCMP) — не изменились до сих пор.
Любой стек (набор технологий) подразумевает совокупность компонентов, согласованно работающих для достижения общей цели. Чтобы используемые технологии приносили ожидаемый (а главное — желаемый) результат, необходимо знать принцип их работы. Понимание того, как работает приоритизация трафика, позволит принимать правильные решения при настройке и минимизировать временные затраты. Из предыдущей статьи мы выяснили, что DMPO помогает передаче данных на всех «фронтах»:
Многим известно, что SD-WAN — это не только про сети, но и про приложения. Любой успешный игрок на этом рынке уделяет внимание классификации и обработке трафика различных приложений, используя такие системы как DPI (Deep Packet Inspection).
Необходимость классифицировать трафик и использовать результаты классификации была всегда. Механизмы QoS еще до появления SD-WAN решали задачи приоритизации трафика при недостаточной полосе пропускания. Однако при классическом DiffServ подходе с Per-hop Behavior приходится вручную вносить изменения на каждом устройстве в цепочке, создавая множество списков доступа и классификаторов, связывать различные компоненты подсистемы QoS соответствующими настройками. Такой подход требует затрат времени и сил, а ведь надо еще и контролировать единообразие настроек, выполненных зачастую разными специалистами. С ростом сети задача усложняется, а риск возникновения ошибок лишь повышается. При этом QoS нужен всем, но при текущем темпе роста количества приложений с различными требованиями к качеству каналов связи, он должен быть централизованным и легко адаптироваться к изменениям.
Идея управления сетью в режиме «единого окна» не нова. Однако именно с развитием SD-WAN в корпоративном сегменте появилась возможность управлять качеством обслуживания на уровне приложений, создавать единые политики управления трафиком и распространять их на множество устройств.
Конечно, на начальной стадии своего развития такие решения не могли похвастаться возможностями, речь о которых пойдет ниже. Но все течет, все развивается — и сегодня они уже стали полноценными продуктами в формате Network-as-a-Service.
В первую очередь, это классификация трафика на уровне приложений. В VMware SD-WAN она выполняется автоматически. Администратору больше не нужно самостоятельно определять классы сервиса и вручную маркировать трафик. В SD-WAN он автоматически делится на классы, которые складываются из его типа и приоритета. Получается наглядная и удобная матрица, отражающая философию разделения приложений на классы.
Матрица QoS в VMware SD-WAN
Вместе с тем, в распоряжении администратора интуитивные инструменты для классификации и описания приложений, которые не содержатся в базе DPI.
Во-вторых, интерпретация результатов, полученных на первом шаге. Уже «из коробки» технология DMPO, в зависимости от типа трафика и его направления (SD-WAN тоннель или Direct to Internet), применяет техники, оптимизирующие передачу трафика с учетом наличия нескольких каналов связи на объекте.
Для создания или изменения политик управления трафиком используется Business Policy Framework. Эта подсистема позволяет не только настроить, но и распространить единый набор правил управления трафиком по всей сети.
Давайте разберем, как это работает, на примере. Предположим, что в филиале есть Broadband Internet 90 Мбит/с и MPLS 10 Мбит/с, то есть совокупная пропускная способность (помним про возможность агрегировать каналы) составит до 100 Мбит/с. На основании матрицы со значениями «по умолчанию» приложения из категории Business Collaboration будут иметь гарантированную полосу 35 Мбит/с, а на все активности, связанные с email, будет отведено гарантировано 15 Мбит/с. Политики могут быть установлены как для целых категорий, так и отдельно для каждого приложения, например, Skype for Business.
Но DMPO не работал бы так, как это было задумано, если бы не опирался на надежный оверлейный протокол VCMP. Он позволяет строить защищенные соединения между VCE и VCG, а также между VCE напрямую. Протокол использует в своем заголовке механизм гарантированной доставки, и каждому пакету присваивается номер в последовательности. По нему можно заново отправить потерявшийся пакет.
Взаимодействие между компонентами VMware SD-WAN
В SD-WAN существует четкое разделение понятий Overlay и Underlay:
Underlay нужен для работы Overlay (служебный трафик SD-WAN), а также передачи данных, которые по определённым причинам не должны инкапсулироваться в VCMP. Но какими путями передаются те или иные данные? Глобально я выделяю для себя два пути передачи трафика:
Для взаимодействия между собой VCE в филиалах должны прийти туда, где хранится информация для подключения — например, адресация. Этим местом встречи могут быть либо VCG, либо такой же VCE, — и для филиальных VCE такой точкой будет хаб.
Расскажу подробнее о каждом способе построения оверлейной топологии.
Вариант #1: хабом является облачный шлюз.
Отлично подходит для так называемых Hubless-топологий, когда нет собственного ЦОД или точки агрегации корпоративного трафика. В этом случае все филиалы при обмене трафиком или построении прямых динамических тоннелей друг с другом используют VCG. Такой вариант применяется по умолчанию и уже готов к масштабированию. При этом все VCG находятся в отказоустойчивых ЦОД провайдера с круглосуточным мониторингом.
Вариант #2: хабом является VMware SD-WAN Edge.
Позволяет в более явном виде управлять сетью и не зависеть от VCG при построении тоннелей между филиалами. Подходит прежде всего инфраструктурам с четко выделенными ЦОД или точками агрегации трафика, где Hub Edge становится устройством-посредником между DC LAN и фабрикой SD-WAN. Один филиал может быть подключен к нескольким таким хабам, что увеличивает отказоустойчивость сети. Благодаря встроенным механизмам интеграции с Legacy (OSPF/BGP) оверлейная сеть без проблем получает доступ к non-SD-WAN сегментам сети.
Зафиксируем, как выглядит наш тестовый стенд и какие проверки мы будем проводить.
Стенд собран для демонстрации технологий VMware, заложенных в продукт SD-WAN: DMPO, VCMP и других. С его помощью я хочу показать:
Стенд имитирует классическую структуру «филиал — головной офис» и разделен на 2 точки присутствия:
В филиале есть два клиентских ПК (A и B), подключенных напрямую в широковещательный сегмент (LAN port) Velocloud Edge. Сам Edge подключен WAN-интерфейсом в WAN Emulator на базе Raspberry Pi 3. Такой интерфейс в нашем стенде называется Downstream. Другим интерфейсом WAN Emulator подключается к пограничному роутеру, куда приходит канал от провайдера проводного интернета. Этот интерфейс эмулятора называется Upstream.
Каналы в филиале (по умолчанию для стенда) имеют следующую конфигурацию:
Такая конфигурация гарантирует, что более дорогостоящий канал не будет загружен, когда это не нужно, но примет на себя продуктивный трафик с минимальной задержкой на переключение, если основной канал не будет соответствовать параметрам внутреннего SLA заказчика или вовсе будет оборван.
Канал ISP1 подключен через WAN Emulator с использованием Downstream- и Upstream-интерфейсов. Данная операция выглядит прозрачно, так как оба интерфейса одноплатного компьютера объединены с помощью Linux Bridge в один широковещательный домен без использования промежуточной IP-адресации.
В Enterprise Data Center находится виртуальный Edge, выполняющий роль HUB. Назначение HUB — способствовать Edge-to-Edge взаимодействию (data plane или только edge discovery), а также предоставлять доступ к приватным ресурсам, находящимся в центре обработки данных. В данном стенде у HUB Edge один WAN-канал за Firewall и NAT. Основное назначение этого Edge — предоставить доступ к корпоративным ресурсам внутри центра обработки данных. К HUB Edge подключена пара виртуальных машин (Windows Server и Linux Ubuntu), имитирующих корпоративные ресурсы.
Branch Edge подключен к облачному шлюзу (VCG — Velocloud Gateway) через VCMP-тоннели: один канал — один тоннель. Таким образом, от Branch Edge до VCG построено два тоннеля. Edge всегда формирует подключение к VCGs, в рамках стенда будут использоваться VCG #CloudMTS.
Branch Edge подключен к Velocloud HUB (тот же Edge, только в роли HUB), который располагается в корпоративном центре обработки данных. Подключение производится по тому же принципу, что и к Velocloud Gateway.
На схеме стенда можно видеть эти тоннели, они изображены пунктирными линиями. Для удобства каждый тип канала обозначен своим цветом. Подробнее — в легенде на схеме.
ЦОД реализован как VDC (Virtual Data Center на базе публичного облака Elastic Cloud от #CloudMTS). HUB Edge запущен в среде виртуализации VMware как виртуальная машина — Virtual Edge. У VCE в DC один WAN-канал — также публичный интернет, но на этот раз с NAT и Firewall.
SD-WAN лучше всего подходит провайдерская модель распространения plug&play, что подразумевает заранее развернутые системы оркестрации (management plane) и управления (control plane) на стороне сервис-провайдера. Для пилота MSP-сервиса не придется планировать выделение большого объема ресурсов в своей инфраструктуре. Провайдер может настроить виртуальные Edge, готовые к полноценным тестам, в том числе с топологией Hub&Spoke. Администратору останется только развернуть одну или несколько тестовых площадок (филиалов) в зависимости от сложности и масштаба пилота. Помимо этого, оператор обеспечит создание учетной записи организации в своей инфраструктуре и первичную настройку тенанта. В связке с провайдером появляется возможность протестировать настоящую отказоустойчивость сервиса и его реакцию на изменение состояния сети.
Именно поэтому роль MSP очень важна, а VCG располагается именно в инфраструктуре #CloudMTS. Напомню: VCG может использоваться как в качестве Control Plane компонента, так и Data Plane. Почему это важно, я поясню в разделе с тестами.
Тесты разделены на три категории:
В зависимости от характера проверки, мы будем вносить потери или задержки (на каком интерфейсе WAN Emulator — зависит от конкретного теста). Так, например, потери чаще всего будут вносится на Downstream-интерфейсе, так как большинство тестов сосредоточено вокруг получения информации Branch Edge, нежели на ее передаче.
Ранее я упоминал, что VCG может использоваться в разных сценариях как data plane компонент. Если у заказчика нет своего ЦОД или его ресурсы размещены в публичных облаках или SaaS (Azure, Microsoft 365, OneDrive, DropBox и др.), качество доступа к критичным сервисам через интернет может быть нестабильным и непредсказуемым. Например, простой других подключенных на объекте интернет-каналов, увеличение задержек передачи, потеря пакетов или реордеринг, если канал, через который клиент связывается с ресурсами, деградирует. При наличии нескольких каналов, придётся потратить время на переключение трафика на резервный.
Все эти проблемы решаются выходом в Интернет через VCG, развернутый в ЦОД #CloudMTS. Branch Edge передает трафик к облачным ресурсам в VCMP-тоннелях, построенных к VCG, там производится NAT и выход в Интернет. Причем трафик может проходить через VCG по нескольким тоннелям, агрегируя полосу в случае необходимости. То есть механизм DMPO работает как между VCE, так и между VCE и VCG. За счет него можно нивелировать потери, используя пакетный буфер, что сказывается на скорости передачи данных при потерях.
Тест №1. Скачивание файла одним из клиентов за Branch Edge из публичного файлового хранилища
Цель этого теста — продемонстрировать преимущества технологии DMPO, которая помогает компенсировать последствия деградации каналов связи. Также я покажу, как Velocloud измеряет характеристики каналов связи и как визуализирует полученные данные. Также демонстрируются возможности Business Policy для распределения трафика приложений по каналам связи.
Итак, клиент B хочет скачать файл размером 292 мегабайта с ресурса cloud.disk.mts.ru.
На нашем тестовом Edge два канала — проводной интернет и LTE в качестве резервного канала. Пропускная способность канала Интернет — 20 Мбит/с.
Далее мы направляем трафик, связанный с cloud.disk.mts.ru, Direct to Cloud, то есть через Underlay. Ниже представлен скриншот с настроенной политикой, которая будет перенаправлять весь трафик, относящийся к доменному имени disk.mts.ru, без инкапсуляции в VCMP-тоннель.
Так в списке политик выглядит готовое правило. Политики могут распространяться как на одно устройство, так и на целую группу с помощью профиля конфигурации. Он содержит ряд правил, входящих в «Smart Defaults» — набор выполненных вендором предварительных настроек по умолчанию. Настройки выполнены на основе реальных потребностей приложений и в большинстве случаев подходят множеству клиентов.
Проверим, что трафик действительно передается и принимается через Underlay. Для этого будем использовать инструмент оркестратора List Active Flows, который позволяет увидеть, какие сессии установлены через Edge, откуда и куда, а также приложение и политику, которая обрабатывает этот трафик.
Вверху мы видим публичный адрес сервиса Диск #CloudMTS и то, что DPI определил приложение. Обратите внимание, в колонке Route указано «Direct to Cloud», а имя используемой Business Policy совпадает с той, что мы создали.
Политика работает, и мы можем скачать файл.
Файл был скачан за 2 минуты. С помощью WAN Emulator внесем 3% потерь на Downlink и проверим еще раз. Это значение является усредненным и колеблется от 1,7% до 3,5%. Потери вносятся средствами Traffic Control и Netem.
На графике ниже отчетливо видно, какое время затрачено на каждую итерацию. Во время проверки процент потерь варьировался случайным образом. Скачивание файла заняло почти 10 минут. На повторных прогонах при совпадении с нижней границей эмулированных потерь файл мог быть скачан за 7 минут.
Теперь направим трафик через Cloud Gateway, используя все преимущества DMPO и механизма компенсации потерь. Для этого в правиле укажем, что трафик использует Network Service Multipath. Иными словами, разрешим использование и Underlay, и Overlay. Но в силу того, что маршрут через Gateway надежнее (меньше стоимость), Edge должен выбрать именно его.
Мы сохранили настройки, а теперь проверим, какая политика обрабатывает интересующий нас трафик.
Новая политика работает, можно оценить результат.
Дожидаемся окончания скачивания.
Из графика видно, что при получении через VCG время скачивания файла составляет примерно 2,5 минуты. Но при большей пропускной способности можно получить даже лучший результат. Например, вот тест на 50 Мбит/с:
При увеличении пропускной способности до 50 Мбит/с скорость скачивания через Underlay иногда достигала 10 Мбит/с.
Итоговый результат:
Вывод: использование DMPO компенсирует деградацию канала связи в сценариях с публичными файловыми ресурсами и дает прирост сетевой производительности более чем в 2 раза.
Тест №2. Подключение к корпоративному VDI через Интернет
Это популярный и распространенный сценарий: VDI публикуется в интернет, и любые категории пользователей с соответствующим доступом могут использовать виртуальные рабочие столы. Также у них есть возможность подключаться к сервисам VDI в публичных облаках. Для теста я использовал Citrix VDI. Пропускная способность — 20 Мбит/с. Разрешение видео — 720p. Трафик в публичный Интернет передается и принимается из него только через Underlay.
Как можно заметить, видео передается четко, нет потери кадров и артефактов изображения, а также проблем с самим виртуальным рабочим столом.
Теперь внесем наши стандартные 3% потерь и 50 миллисекунд задержки, что довольно критично для сервисов реального времени.
Появились артефакты, снизилось разрешение. При манипуляции элементами внутри виртуального рабочего стола видны задержки смещения фокуса ввода.
И, наконец, после удаления политики и переключения TCP-сессии между сервером VDI и Receiver видно, что разрешение выросло, артефакты исчезли, а задержки отображения и ввода свелись к минимуму.
Тест №1. Скачивание файла с корпоративного файлового сервера
На схеме стенда изображен Server 2 на ОС Windows. Он будет выполнять роль файлового хранилища. Один из клиентов за Branch Edge будет скачивать файл с сервера через VCMP-тоннель, используя вход по приватным адресам. В данном случае при внесении потерь скорость не должна снизиться.
Через Underlay невозможно получить доступ к корпоративным ресурсам в ЦОД (все они имеют приватные адреса), поэтому необходимо соединение между двумя VCE. VCE в ЦОД выступает в роли хаба и анонсирует непосредственно подключенные сети или иные маршруты в таблицу оверлейных маршрутов. DMPO в данном тесте будет работать в любом случае, мы проверяем влияние потерь. В этом сценарии клиент A скачивает с сервера Server 2 файл размером 300 мегабайт, используя VCMP-тоннель. Ширина канала составляет 50 Мбит/с, внесено 3% потерь.
Скачаем файл при без внесения потерь.
DMPO так же, как и в случае с VCG, максимизировал скорость, и файл загрузился за минуту. Добавим ухудшение.
Потеря пакетов не оказала значительного влияния на скорость загрузки. Время скачивания — 1 минута 10 секунд.
Тест №2. Получение видеопотока из корпоративной сети.
Достаточно популярный тест с передачей video/audio stream через VLC с одного endpoint на другой. В этом сценарии мы получаем перекодированный видеопоток, упакованный в RTP, в пределах корпоративной сети.
Характеристики канала до внесения ухудшений.
Внесем 3% потерь. Картинка не «рассыпалась». В некоторых сценах виден пропуск кадров, однако поток не прерывается. Основной эффект от внесенных потерь видно с 40 по 55 секунду.
Характеристики канала и результат:
Усложним тест и внесем 50 msec latency в обе стороны. Хоть картинка на видео местами притормаживает и видно некоторое выпадение кадров, в целом при таком высоком разрешении результат более чем удовлетворительный. Максимальный процент потерь — 3,06%.
Тест №1. Переключение на резервный канал
Обязательная программа — отключение проводного канала для имитации обрыва. Устройство должно переключиться на LTE и благодаря новому режиму Hot Standby очень быстро перенаправить продуктивный трафик на резервный канал.
Опциональная проверка — переключение на резервный канал при несоответствии SLA, то есть деградации канала. Для этого проводной канал выбирается в качестве основного. При достижении определенного процента потерь трафик переключается на резервный канал.
В нашем сценарии используется два канала — проводной и беспроводной LTE.
Через канал, находящийся в статусе Hot Standby, не передается пользовательский трафик, но отправляется служебная информация о его статусе. Благодаря этому в любой момент резервный канал готов к переключению. Согласно условиям проверки мы будем скачивать тот же самый файл, а во время загрузки эмулируем отключение проводного канала.
После потери связности трафик переключился менее чем за одну секунду, при этом сессия не разорвалась.
После возвращении проводного интернета трафик сразу переходит обратно в основной канал, а LTE возвращается в статус резервного.
Проверим контроль за SLA. Переведем наш резервный канал в режим Active и установим пороговое значение потерь в 2%, а затем начнем скачивать файл. При превышении этого значения трафик должен перестроиться на другой канал, соответствующий SLA. Изначально проводной интернет помечается как предпочитаемый. Для этого изменим политику управления трафиком.
Проверим результат. Для это загрузим большой файл размером 2 гигабайта. Как мы помним, потери плавающие, поэтому возможно переключение между каналами. На графике видно, что при достижении порога потерь в 2% трафик переключался на LTE. Провалы в правой части коррелируют с всплесками в левой. Если брать в расчет масштаб отображения, то всплески в левой части составляют около 8 Мбит/с.
Тест №2. Балансировка трафика
Настроим балансировку трафика.
Убедимся, что оба канала имеют статус Active, и проверим балансировку. Для наглядности используем проводной канал с пропускной способностью 20 Мбит/с.
Благодаря возможности задействовать оба канала одновременно мы получили прирост 10 Мбит/с, и общая доступная полоса стала 30 Мбит/c. Пропускная способность выросла на 50%.
Материал изначально планировался как симбиоз теории и практики. Практики, которая находит применение в реальных сетях заказчиков. К сожалению, в рамках одной статьи я не могу детально рассказать обо всех аспектах реализации SD-WAN в MSP и о том, как MSP, обладая необходимыми инструментами, помогает в реализации инфраструктурных проектов. В нашем случае таким инструментом является VMware SD-WAN.
За время работы с VMware SD-WAN я понял, почему VMware является одним из лидеров рынка технологий программно-определяемых глобальных сетей. Собственная линейка продуманных оконечных устройств, отличный мониторинг, уникальные решения для агрегации и балансировки трафика, корректное измерение каналов в реальном времени и подходы к восстановлению сетевой производительности приложений.
Инфраструктура #CloudMTS расширяет возможности VMware SD-WAN: все преимущества облачного провайдера и технологического решения сконцентрированы в сервисе Cloud SD-WAN. Имея обширную сеть ЦОД и отличную экспертизу в предоставляемых сервисах, мы конвертируем все это в business value, стараясь не применять технологии ради технологий.
Если перед вами стоит задача построить защищенную филиальную сеть с централизованным управлением, абстрагироваться от физических каналов и повысить эффективность их утилизации, сохранив качество передачи данных, рекомендую попробовать Cloud SD-WAN. В рамках 30-дневного пилота наши специалисты подберут оптимальную конфигурацию, предоставят VMware SD-WAN Edge и сопроводят в течение всего процесса пилотирования. Оставить заявку на подключение можно на странице сервиса.
Сегодня мы посмотрим, насколько эффективно SD-WAN помогает сохранить требуемую производительность приложений при деградации каналов связи и даже полном отказе основного канала. Дополнительно познакомимся с возможностями встроенного мониторинга WAN-каналов и пользовательских приложений.
Зачем все это нужно? С помощью практических сценариев я хочу показать, как работает решение VMware SD-WAN и каким образом инфраструктура провайдера раскрывает его возможности. Иными словами, мы будем тестировать не абстрактную технологию, а готовый сервис от #CloudMTS. Будет много замеров, сравнений и графиков.
SD-WAN in a nutshell
Чтобы освежить принципы работы технологии, рекомендую обратиться к предыдущей статье. Там мы уже использовали многие термины из парадигмы SD-WAN, но на всякий случай я приведу их здесь еще раз. Все это понадобится нам для понимания методов и результатов тестирования.
Терминология
DMPO (Dynamic Multipath Optimization) — набор технологий, обеспечивающий построение надежной и устойчивой оверлейной сети, которая учитывает производительность каналов WAN в реальном времени.
VCG (Velocloud Gateway / VMware SD-WAN Gateway) — облачный шлюз, выполняющий функцию Control Plane и опционально Data Plane. Размещается в точках обмена трафиком, ЦОД, пиринговых площадках, стыках с IaaS-провайдерами.
SD-WAN фабрика — совокупность всех SD-WAN устройств организации, объединенных в защищенную сеть.
VCO (Velocloud Orchestrator / VMware SD-WAN Orchestrator) — система управления SD-WAN фабрикой.
VCMP — тоннельный протокол в SD-WAN от VMware, также участвует в измерении характеристика каналов.
VCE (Velocloud Edge / VMware SD-WAN Edge) — маршрутизатор, каналообразующее оборудование на удаленной площадке или в ЦОД, реализует Data Plane компонент.
Примечание. Как вы помните из предыдущей статьи, ключевым шагом VMware на рынке SD-WAN стала покупка стартапа Velocloud Networks. На момент сделки терминология решения (VCE — Velocloud Edge, VCO — Velocloud Orchestrator и другие) уже закрепились за ним в индустрии. Эти же обозначения использовались и на момент интеграции SD-WAN by Velocloud в продуктовую линейку VMware. Сейчас компания внедряет новые обозначения (например, VMware SD-WAN Edge вместо Velocloud Edge), но делает это разумно. За годы, прошедшие с момента покупки Velocloud, их оригинальная терминология для многих стала узнаваемой и устоявшейся. А некоторые обозначения — например, название протокола Velocloud Multipath Protocol (VCMP) — не изменились до сих пор.
Application Aware Overlay QoS
Любой стек (набор технологий) подразумевает совокупность компонентов, согласованно работающих для достижения общей цели. Чтобы используемые технологии приносили ожидаемый (а главное — желаемый) результат, необходимо знать принцип их работы. Понимание того, как работает приоритизация трафика, позволит принимать правильные решения при настройке и минимизировать временные затраты. Из предыдущей статьи мы выяснили, что DMPO помогает передаче данных на всех «фронтах»:
- измерение качества канала и его пропускной способности;
- балансировка трафика;
- агрегация каналов;
- перевод трафика на другой канал при несоблюдении SLA на текущем.
Многим известно, что SD-WAN — это не только про сети, но и про приложения. Любой успешный игрок на этом рынке уделяет внимание классификации и обработке трафика различных приложений, используя такие системы как DPI (Deep Packet Inspection).
Необходимость классифицировать трафик и использовать результаты классификации была всегда. Механизмы QoS еще до появления SD-WAN решали задачи приоритизации трафика при недостаточной полосе пропускания. Однако при классическом DiffServ подходе с Per-hop Behavior приходится вручную вносить изменения на каждом устройстве в цепочке, создавая множество списков доступа и классификаторов, связывать различные компоненты подсистемы QoS соответствующими настройками. Такой подход требует затрат времени и сил, а ведь надо еще и контролировать единообразие настроек, выполненных зачастую разными специалистами. С ростом сети задача усложняется, а риск возникновения ошибок лишь повышается. При этом QoS нужен всем, но при текущем темпе роста количества приложений с различными требованиями к качеству каналов связи, он должен быть централизованным и легко адаптироваться к изменениям.
Идея управления сетью в режиме «единого окна» не нова. Однако именно с развитием SD-WAN в корпоративном сегменте появилась возможность управлять качеством обслуживания на уровне приложений, создавать единые политики управления трафиком и распространять их на множество устройств.
Конечно, на начальной стадии своего развития такие решения не могли похвастаться возможностями, речь о которых пойдет ниже. Но все течет, все развивается — и сегодня они уже стали полноценными продуктами в формате Network-as-a-Service.
Как работает QoS в VMware SD-WAN
В первую очередь, это классификация трафика на уровне приложений. В VMware SD-WAN она выполняется автоматически. Администратору больше не нужно самостоятельно определять классы сервиса и вручную маркировать трафик. В SD-WAN он автоматически делится на классы, которые складываются из его типа и приоритета. Получается наглядная и удобная матрица, отражающая философию разделения приложений на классы.
Матрица QoS в VMware SD-WAN
Вместе с тем, в распоряжении администратора интуитивные инструменты для классификации и описания приложений, которые не содержатся в базе DPI.
Во-вторых, интерпретация результатов, полученных на первом шаге. Уже «из коробки» технология DMPO, в зависимости от типа трафика и его направления (SD-WAN тоннель или Direct to Internet), применяет техники, оптимизирующие передачу трафика с учетом наличия нескольких каналов связи на объекте.
Для создания или изменения политик управления трафиком используется Business Policy Framework. Эта подсистема позволяет не только настроить, но и распространить единый набор правил управления трафиком по всей сети.
Давайте разберем, как это работает, на примере. Предположим, что в филиале есть Broadband Internet 90 Мбит/с и MPLS 10 Мбит/с, то есть совокупная пропускная способность (помним про возможность агрегировать каналы) составит до 100 Мбит/с. На основании матрицы со значениями «по умолчанию» приложения из категории Business Collaboration будут иметь гарантированную полосу 35 Мбит/с, а на все активности, связанные с email, будет отведено гарантировано 15 Мбит/с. Политики могут быть установлены как для целых категорий, так и отдельно для каждого приложения, например, Skype for Business.
Но DMPO не работал бы так, как это было задумано, если бы не опирался на надежный оверлейный протокол VCMP. Он позволяет строить защищенные соединения между VCE и VCG, а также между VCE напрямую. Протокол использует в своем заголовке механизм гарантированной доставки, и каждому пакету присваивается номер в последовательности. По нему можно заново отправить потерявшийся пакет.
Взаимодействие между компонентами VMware SD-WAN
Передача трафика внутри фабрики
В SD-WAN существует четкое разделение понятий Overlay и Underlay:
- Если трафик передается в интернет через Underlay (как есть, без SD-WAN Enhancements), такой способ передачи называют Direct (или Direct to Cloud).
- Если передача происходит через VCG, такой способ передачи называют Cloud via Gateway, то есть передача через Overlay.
Underlay нужен для работы Overlay (служебный трафик SD-WAN), а также передачи данных, которые по определённым причинам не должны инкапсулироваться в VCMP. Но какими путями передаются те или иные данные? Глобально я выделяю для себя два пути передачи трафика:
- от VCE к VCE;
- от VCE в публичный интернет.
Для взаимодействия между собой VCE в филиалах должны прийти туда, где хранится информация для подключения — например, адресация. Этим местом встречи могут быть либо VCG, либо такой же VCE, — и для филиальных VCE такой точкой будет хаб.
Расскажу подробнее о каждом способе построения оверлейной топологии.
Вариант #1: хабом является облачный шлюз.
Отлично подходит для так называемых Hubless-топологий, когда нет собственного ЦОД или точки агрегации корпоративного трафика. В этом случае все филиалы при обмене трафиком или построении прямых динамических тоннелей друг с другом используют VCG. Такой вариант применяется по умолчанию и уже готов к масштабированию. При этом все VCG находятся в отказоустойчивых ЦОД провайдера с круглосуточным мониторингом.
Вариант #2: хабом является VMware SD-WAN Edge.
Позволяет в более явном виде управлять сетью и не зависеть от VCG при построении тоннелей между филиалами. Подходит прежде всего инфраструктурам с четко выделенными ЦОД или точками агрегации трафика, где Hub Edge становится устройством-посредником между DC LAN и фабрикой SD-WAN. Один филиал может быть подключен к нескольким таким хабам, что увеличивает отказоустойчивость сети. Благодаря встроенным механизмам интеграции с Legacy (OSPF/BGP) оверлейная сеть без проблем получает доступ к non-SD-WAN сегментам сети.
Тестирование технологий SD-WAN
Зафиксируем, как выглядит наш тестовый стенд и какие проверки мы будем проводить.
Схема тестового стенда
Стенд собран для демонстрации технологий VMware, заложенных в продукт SD-WAN: DMPO, VCMP и других. С его помощью я хочу показать:
- возможности этих технологий;
- разницу в качестве передачи данных при использовании технологий оптимизации и реакцию на изменения в сети;
- как SD-WAN упрощает управление сетью, получение данных о состоянии каналов связи и визуализацию требуемой информации.
Стенд имитирует классическую структуру «филиал — головной офис» и разделен на 2 точки присутствия:
- Branch/Home Office — филиал, подключенный к сети двумя публичными каналами передачи данных: проводной интернет и 4G LTE через USB-модем.
- Enterprise Data Center.
В филиале есть два клиентских ПК (A и B), подключенных напрямую в широковещательный сегмент (LAN port) Velocloud Edge. Сам Edge подключен WAN-интерфейсом в WAN Emulator на базе Raspberry Pi 3. Такой интерфейс в нашем стенде называется Downstream. Другим интерфейсом WAN Emulator подключается к пограничному роутеру, куда приходит канал от провайдера проводного интернета. Этот интерфейс эмулятора называется Upstream.
Каналы в филиале (по умолчанию для стенда) имеют следующую конфигурацию:
- Канал ISP1 проводной и активен все время.
- Канал ISP2 LTE настроен в режиме Hot Standby — это означает, что через данный канал построен VCMP-тоннель, устройство получает и отправляет heartbeat messages (аналог keepalive), но клиентский трафик через этот канал не передается и не принимается.
Такая конфигурация гарантирует, что более дорогостоящий канал не будет загружен, когда это не нужно, но примет на себя продуктивный трафик с минимальной задержкой на переключение, если основной канал не будет соответствовать параметрам внутреннего SLA заказчика или вовсе будет оборван.
Канал ISP1 подключен через WAN Emulator с использованием Downstream- и Upstream-интерфейсов. Данная операция выглядит прозрачно, так как оба интерфейса одноплатного компьютера объединены с помощью Linux Bridge в один широковещательный домен без использования промежуточной IP-адресации.
В Enterprise Data Center находится виртуальный Edge, выполняющий роль HUB. Назначение HUB — способствовать Edge-to-Edge взаимодействию (data plane или только edge discovery), а также предоставлять доступ к приватным ресурсам, находящимся в центре обработки данных. В данном стенде у HUB Edge один WAN-канал за Firewall и NAT. Основное назначение этого Edge — предоставить доступ к корпоративным ресурсам внутри центра обработки данных. К HUB Edge подключена пара виртуальных машин (Windows Server и Linux Ubuntu), имитирующих корпоративные ресурсы.
Как и к чему подключен Branch Edge
Branch Edge подключен к облачному шлюзу (VCG — Velocloud Gateway) через VCMP-тоннели: один канал — один тоннель. Таким образом, от Branch Edge до VCG построено два тоннеля. Edge всегда формирует подключение к VCGs, в рамках стенда будут использоваться VCG #CloudMTS.
Branch Edge подключен к Velocloud HUB (тот же Edge, только в роли HUB), который располагается в корпоративном центре обработки данных. Подключение производится по тому же принципу, что и к Velocloud Gateway.
На схеме стенда можно видеть эти тоннели, они изображены пунктирными линиями. Для удобства каждый тип канала обозначен своим цветом. Подробнее — в легенде на схеме.
Как и к чему подключен HUB Edge
ЦОД реализован как VDC (Virtual Data Center на базе публичного облака Elastic Cloud от #CloudMTS). HUB Edge запущен в среде виртуализации VMware как виртуальная машина — Virtual Edge. У VCE в DC один WAN-канал — также публичный интернет, но на этот раз с NAT и Firewall.
Роль инфраструктуры провайдера
SD-WAN лучше всего подходит провайдерская модель распространения plug&play, что подразумевает заранее развернутые системы оркестрации (management plane) и управления (control plane) на стороне сервис-провайдера. Для пилота MSP-сервиса не придется планировать выделение большого объема ресурсов в своей инфраструктуре. Провайдер может настроить виртуальные Edge, готовые к полноценным тестам, в том числе с топологией Hub&Spoke. Администратору останется только развернуть одну или несколько тестовых площадок (филиалов) в зависимости от сложности и масштаба пилота. Помимо этого, оператор обеспечит создание учетной записи организации в своей инфраструктуре и первичную настройку тенанта. В связке с провайдером появляется возможность протестировать настоящую отказоустойчивость сервиса и его реакцию на изменение состояния сети.
Именно поэтому роль MSP очень важна, а VCG располагается именно в инфраструктуре #CloudMTS. Напомню: VCG может использоваться как в качестве Control Plane компонента, так и Data Plane. Почему это важно, я поясню в разделе с тестами.
Какие проверки будем проводить
Тесты разделены на три категории:
- работа с ресурсами в публичном интернете;
- обращение к корпоративным ресурсам в облаке;
- проверка отказоустойчивости.
В зависимости от характера проверки, мы будем вносить потери или задержки (на каком интерфейсе WAN Emulator — зависит от конкретного теста). Так, например, потери чаще всего будут вносится на Downstream-интерфейсе, так как большинство тестов сосредоточено вокруг получения информации Branch Edge, нежели на ее передаче.
Работа с ресурсами в публичном интернете
Ранее я упоминал, что VCG может использоваться в разных сценариях как data plane компонент. Если у заказчика нет своего ЦОД или его ресурсы размещены в публичных облаках или SaaS (Azure, Microsoft 365, OneDrive, DropBox и др.), качество доступа к критичным сервисам через интернет может быть нестабильным и непредсказуемым. Например, простой других подключенных на объекте интернет-каналов, увеличение задержек передачи, потеря пакетов или реордеринг, если канал, через который клиент связывается с ресурсами, деградирует. При наличии нескольких каналов, придётся потратить время на переключение трафика на резервный.
Все эти проблемы решаются выходом в Интернет через VCG, развернутый в ЦОД #CloudMTS. Branch Edge передает трафик к облачным ресурсам в VCMP-тоннелях, построенных к VCG, там производится NAT и выход в Интернет. Причем трафик может проходить через VCG по нескольким тоннелям, агрегируя полосу в случае необходимости. То есть механизм DMPO работает как между VCE, так и между VCE и VCG. За счет него можно нивелировать потери, используя пакетный буфер, что сказывается на скорости передачи данных при потерях.
Тест №1. Скачивание файла одним из клиентов за Branch Edge из публичного файлового хранилища
Цель этого теста — продемонстрировать преимущества технологии DMPO, которая помогает компенсировать последствия деградации каналов связи. Также я покажу, как Velocloud измеряет характеристики каналов связи и как визуализирует полученные данные. Также демонстрируются возможности Business Policy для распределения трафика приложений по каналам связи.
Итак, клиент B хочет скачать файл размером 292 мегабайта с ресурса cloud.disk.mts.ru.
На нашем тестовом Edge два канала — проводной интернет и LTE в качестве резервного канала. Пропускная способность канала Интернет — 20 Мбит/с.
Далее мы направляем трафик, связанный с cloud.disk.mts.ru, Direct to Cloud, то есть через Underlay. Ниже представлен скриншот с настроенной политикой, которая будет перенаправлять весь трафик, относящийся к доменному имени disk.mts.ru, без инкапсуляции в VCMP-тоннель.
Так в списке политик выглядит готовое правило. Политики могут распространяться как на одно устройство, так и на целую группу с помощью профиля конфигурации. Он содержит ряд правил, входящих в «Smart Defaults» — набор выполненных вендором предварительных настроек по умолчанию. Настройки выполнены на основе реальных потребностей приложений и в большинстве случаев подходят множеству клиентов.
Проверим, что трафик действительно передается и принимается через Underlay. Для этого будем использовать инструмент оркестратора List Active Flows, который позволяет увидеть, какие сессии установлены через Edge, откуда и куда, а также приложение и политику, которая обрабатывает этот трафик.
Вверху мы видим публичный адрес сервиса Диск #CloudMTS и то, что DPI определил приложение. Обратите внимание, в колонке Route указано «Direct to Cloud», а имя используемой Business Policy совпадает с той, что мы создали.
Политика работает, и мы можем скачать файл.
Файл был скачан за 2 минуты. С помощью WAN Emulator внесем 3% потерь на Downlink и проверим еще раз. Это значение является усредненным и колеблется от 1,7% до 3,5%. Потери вносятся средствами Traffic Control и Netem.
На графике ниже отчетливо видно, какое время затрачено на каждую итерацию. Во время проверки процент потерь варьировался случайным образом. Скачивание файла заняло почти 10 минут. На повторных прогонах при совпадении с нижней границей эмулированных потерь файл мог быть скачан за 7 минут.
Теперь направим трафик через Cloud Gateway, используя все преимущества DMPO и механизма компенсации потерь. Для этого в правиле укажем, что трафик использует Network Service Multipath. Иными словами, разрешим использование и Underlay, и Overlay. Но в силу того, что маршрут через Gateway надежнее (меньше стоимость), Edge должен выбрать именно его.
Мы сохранили настройки, а теперь проверим, какая политика обрабатывает интересующий нас трафик.
Новая политика работает, можно оценить результат.
Дожидаемся окончания скачивания.
Из графика видно, что при получении через VCG время скачивания файла составляет примерно 2,5 минуты. Но при большей пропускной способности можно получить даже лучший результат. Например, вот тест на 50 Мбит/с:
При увеличении пропускной способности до 50 Мбит/с скорость скачивания через Underlay иногда достигала 10 Мбит/с.
Итоговый результат:
Вывод: использование DMPO компенсирует деградацию канала связи в сценариях с публичными файловыми ресурсами и дает прирост сетевой производительности более чем в 2 раза.
Тест №2. Подключение к корпоративному VDI через Интернет
Это популярный и распространенный сценарий: VDI публикуется в интернет, и любые категории пользователей с соответствующим доступом могут использовать виртуальные рабочие столы. Также у них есть возможность подключаться к сервисам VDI в публичных облаках. Для теста я использовал Citrix VDI. Пропускная способность — 20 Мбит/с. Разрешение видео — 720p. Трафик в публичный Интернет передается и принимается из него только через Underlay.
Как можно заметить, видео передается четко, нет потери кадров и артефактов изображения, а также проблем с самим виртуальным рабочим столом.
Теперь внесем наши стандартные 3% потерь и 50 миллисекунд задержки, что довольно критично для сервисов реального времени.
Появились артефакты, снизилось разрешение. При манипуляции элементами внутри виртуального рабочего стола видны задержки смещения фокуса ввода.
И, наконец, после удаления политики и переключения TCP-сессии между сервером VDI и Receiver видно, что разрешение выросло, артефакты исчезли, а задержки отображения и ввода свелись к минимуму.
Обращение к корпоративным ресурсам в облаке
Тест №1. Скачивание файла с корпоративного файлового сервера
На схеме стенда изображен Server 2 на ОС Windows. Он будет выполнять роль файлового хранилища. Один из клиентов за Branch Edge будет скачивать файл с сервера через VCMP-тоннель, используя вход по приватным адресам. В данном случае при внесении потерь скорость не должна снизиться.
Через Underlay невозможно получить доступ к корпоративным ресурсам в ЦОД (все они имеют приватные адреса), поэтому необходимо соединение между двумя VCE. VCE в ЦОД выступает в роли хаба и анонсирует непосредственно подключенные сети или иные маршруты в таблицу оверлейных маршрутов. DMPO в данном тесте будет работать в любом случае, мы проверяем влияние потерь. В этом сценарии клиент A скачивает с сервера Server 2 файл размером 300 мегабайт, используя VCMP-тоннель. Ширина канала составляет 50 Мбит/с, внесено 3% потерь.
Скачаем файл при без внесения потерь.
DMPO так же, как и в случае с VCG, максимизировал скорость, и файл загрузился за минуту. Добавим ухудшение.
Потеря пакетов не оказала значительного влияния на скорость загрузки. Время скачивания — 1 минута 10 секунд.
Тест №2. Получение видеопотока из корпоративной сети.
Достаточно популярный тест с передачей video/audio stream через VLC с одного endpoint на другой. В этом сценарии мы получаем перекодированный видеопоток, упакованный в RTP, в пределах корпоративной сети.
Характеристики канала до внесения ухудшений.
Внесем 3% потерь. Картинка не «рассыпалась». В некоторых сценах виден пропуск кадров, однако поток не прерывается. Основной эффект от внесенных потерь видно с 40 по 55 секунду.
Характеристики канала и результат:
Усложним тест и внесем 50 msec latency в обе стороны. Хоть картинка на видео местами притормаживает и видно некоторое выпадение кадров, в целом при таком высоком разрешении результат более чем удовлетворительный. Максимальный процент потерь — 3,06%.
Проверка отказоустойчивости
Тест №1. Переключение на резервный канал
Обязательная программа — отключение проводного канала для имитации обрыва. Устройство должно переключиться на LTE и благодаря новому режиму Hot Standby очень быстро перенаправить продуктивный трафик на резервный канал.
Опциональная проверка — переключение на резервный канал при несоответствии SLA, то есть деградации канала. Для этого проводной канал выбирается в качестве основного. При достижении определенного процента потерь трафик переключается на резервный канал.
В нашем сценарии используется два канала — проводной и беспроводной LTE.
Через канал, находящийся в статусе Hot Standby, не передается пользовательский трафик, но отправляется служебная информация о его статусе. Благодаря этому в любой момент резервный канал готов к переключению. Согласно условиям проверки мы будем скачивать тот же самый файл, а во время загрузки эмулируем отключение проводного канала.
После потери связности трафик переключился менее чем за одну секунду, при этом сессия не разорвалась.
После возвращении проводного интернета трафик сразу переходит обратно в основной канал, а LTE возвращается в статус резервного.
Проверим контроль за SLA. Переведем наш резервный канал в режим Active и установим пороговое значение потерь в 2%, а затем начнем скачивать файл. При превышении этого значения трафик должен перестроиться на другой канал, соответствующий SLA. Изначально проводной интернет помечается как предпочитаемый. Для этого изменим политику управления трафиком.
Проверим результат. Для это загрузим большой файл размером 2 гигабайта. Как мы помним, потери плавающие, поэтому возможно переключение между каналами. На графике видно, что при достижении порога потерь в 2% трафик переключался на LTE. Провалы в правой части коррелируют с всплесками в левой. Если брать в расчет масштаб отображения, то всплески в левой части составляют около 8 Мбит/с.
Тест №2. Балансировка трафика
Настроим балансировку трафика.
Убедимся, что оба канала имеют статус Active, и проверим балансировку. Для наглядности используем проводной канал с пропускной способностью 20 Мбит/с.
Благодаря возможности задействовать оба канала одновременно мы получили прирост 10 Мбит/с, и общая доступная полоса стала 30 Мбит/c. Пропускная способность выросла на 50%.
Подведем итоги
Материал изначально планировался как симбиоз теории и практики. Практики, которая находит применение в реальных сетях заказчиков. К сожалению, в рамках одной статьи я не могу детально рассказать обо всех аспектах реализации SD-WAN в MSP и о том, как MSP, обладая необходимыми инструментами, помогает в реализации инфраструктурных проектов. В нашем случае таким инструментом является VMware SD-WAN.
За время работы с VMware SD-WAN я понял, почему VMware является одним из лидеров рынка технологий программно-определяемых глобальных сетей. Собственная линейка продуманных оконечных устройств, отличный мониторинг, уникальные решения для агрегации и балансировки трафика, корректное измерение каналов в реальном времени и подходы к восстановлению сетевой производительности приложений.
Инфраструктура #CloudMTS расширяет возможности VMware SD-WAN: все преимущества облачного провайдера и технологического решения сконцентрированы в сервисе Cloud SD-WAN. Имея обширную сеть ЦОД и отличную экспертизу в предоставляемых сервисах, мы конвертируем все это в business value, стараясь не применять технологии ради технологий.
Если перед вами стоит задача построить защищенную филиальную сеть с централизованным управлением, абстрагироваться от физических каналов и повысить эффективность их утилизации, сохранив качество передачи данных, рекомендую попробовать Cloud SD-WAN. В рамках 30-дневного пилота наши специалисты подберут оптимальную конфигурацию, предоставят VMware SD-WAN Edge и сопроводят в течение всего процесса пилотирования. Оставить заявку на подключение можно на странице сервиса.