Современные сетевые архитектуры содержат в себе множество технологических решений. Классический подход предполагает построение сетевой инфраструктуры, в которой весь трафик идет по одному и тому же маршруту, независимо от того, какие приложения участвуют в этом информационном обмене. То есть, электронная почта, трафик видеоконференций и HTTP‑ все это пойдет по одному каналу. У сетевого администратора, конечно, есть возможность приоритезировать пакеты одного типа над другими, однако в любом случае все эти пакеты будут передаваться по одному и тому же маршруту.
Однако, далеко не всем приложениям нужна высокая пропускная способность. Так, ничего страшного не произойдет, если электронное письмо придет получателю на минуту позже. А вот для ВКС задержка трафика может оказаться критичной. Таким образом, у нас возникает необходимость в сетевой топологии, позволяющей программно определить маршруты, по которым будет передаваться трафик для каждого конкретного приложения. То есть, даже если у нас несколько приложений взаимодействуют с одним и тем же узлом, пакеты могут идти к нему различными маршрутами.
В прежние времена корпоративные ресурсы жили в дата‑центрах и серверных. Эти дата центры могли принадлежать провайдеру и тогда необходимо было арендовать место в стойке. Для с этими ресурсами требовалось подключение через выделенные каналы связи или VPN. При этом прямого подключения к интернету пользователи из филиальных офисов не имели, и попадали в общие сети через центральную ИТ‑площадку, даже если она располагалась за несколько тысяч километров. Такая иерархия соединений накладывала свои ограничения на пропускную способность каналов связи и сетевое оборудование.
С появлением облачных сервисов бизнес‑приложения стали размещаться в виртуальных средах, предоставляемых облачными провайдерами. Использование для доступа к ним VPN или MPLS уже не позволял получить необходимый уровень производительности. Помимо этого, стали существенно увеличиваться требования к производительности каналов связи. Различные сервисы, требующие работы в режиме реального времени, такие как видеоконференцсвязь, стриминговые сервисы и аналогичные системы требовали достаточно высокой скорости канала.
Так возникла необходимость в программно‑определяемой глобальной сети. По сути, SD‑WAN, (software‑defined networking in a wide area network) представляет собой реализацию концепции программно‑определяемой сети в рамках глобальной сети, то есть в масштабах Интернет. При использовании SD‑WAN мы преследуем цель улучшения эксплуатационных качеств за счёт абстракции сетевого оборудования от механизмов управления им.
Как работает SD-WAN
По сути, решения SD‑WAN это виртуальная надстройка над каналами связи, то есть на основе физической кабельной инфраструктуры мы создаем сетевое облако, которое и используется для передачи данных между удаленными узлами распределенной сети, например между филиалами компании.
При этом, программно‑определяемые распределенные сети поддерживают различные технологии передачи данных: оптоволоконные и кабельные проводные решения и беспроводные (3G, 4G LTE и 5G) и спутниковые каналы. В зависимости от решаемых задач, мы можем перераспределять трафик между различными средами передачи данных для балансировки нагрузки и других нужд. Также решения класса SD‑WAN поддерживают сочетание различных стандартов передачи данных, включая IP, MPLS, ATM и другие. Перенаправление трафика может осуществляться как по выделенным, так и по публичным каналам связи, например через Интернет.
Инфраструктура SD‑WAN состоит из нескольких компонентов. Устройства доступа это те же маршрутизаторы, которые ранее использовались в обычных WAN сетях. Эти устройства должны обеспечивать нужный уровень производительности и предоставлять необходимый функционал, такой как межсетевое экранирование, обработка и оптимизация трафика. Так как оборудование доступа взаимодействует непосредственно с абонентскими устройствами, нам необходимо, чтобы на этих устройствах были интерфейсы нужного типа, например Wi‑Fi или LTE.
Возможны два варианта реализации оконечных устройств: аппаратные и виртуальные устройства. Аппаратные — это по сути собственное железо, которое мы предоставляем заказчику. Виртуальные устройства это установка софтверных решений на аппаратную платформу. Как правило, такой вариант дешевле. Также, заказчик может использовать в качестве платформы для оконечных виртуальных устройств оборудование любого вендора, хотя на практике здесь часто могут возникнуть ограничения, так как софтверные решения протестированы только на определенном железе, и совместимость с другим оборудованием разработчик софта не гарантирует.
Многообразие различных сетевых устройств требует централизованного управления — оркестрации. Для выполнения этих задач используются специальные серверы — оркестраторы. Их основная задача — это настройка параметров оконечных устройств, какие именно политики и правила должны применяться к нашим маршрутизаторам доступа, какие именно параметры безопасности мы используем на нашем оборудовании.
Принцип работы оркестраторов следующий: на оркестраторе создаются конфигурационные файлы для оконечных устройств и других элементов сети SD‑WAN, после чего эти файлы отправляются на сами устройства. Также, оркестратор часто осуществляет и основной мониторинг сети — доступность устройств, портов, каналов связи, загрузку интерфейсов, то есть все то, без чего невозможно полноценное администрирование программно определяемой сети.
Еще один важный элемент сети SD‑WAN это контроллеры. Именно эти устройства отвечают за применение политик маршрутизации трафика на сеть. В традиционных сетях связи подобный функционал выполняют BGP Route Reflector. Использование Route reflectors позволяет избежать необходимости создания полносвязной топологии между всеми iBGP‑соседями и предотвратить образование петель.
Как уже упоминалось чуть выше, в оркестраторе мы создаем или модифицируем глобальные политики, контроллеры меняют состав своих таблиц маршрутизации и рассылают обновленную информацию на оконечные устройства. Как правило, рассылка маршрутной информации в SD‑WAN‑сетях происходит с помощью проприетарных протоколов. Это нужно потому, что SD‑WAN‑маршрут часто содержит не только префиксы и next‑hop, но и внушительный набор дополнительных нестандартных атрибутов, необходимых для работы продвинутой маршрутизации.
Сеть SD‑WAN является достаточно сложным в техническом плане решением, в ней используется множество различных протоколов и технологий и нам требуются средства аналитики, с помощью которых мы можем получать сложные отчеты на основании данных, собираемых с оконечных устройств: историю качества работы каналов, сетевых приложений, доступности узлов и т. п. У многих производителей средства аналитики доступны только из их собственного облака, но существуют и решения, развертываемые на территории заказчика.
Решения SD-WAN
Сейчас на российском рынке присутствует несколько решений программно‑определяемых сетей. Начнем с Kaspersky SD‑WAN. Решение от известного антивирусного вендора обеспечивает не только надежную связь между филиалами и удобное управление с помощью единой консоли, но и легкое подключение единых для всей компании функций безопасности.
С помощью единой политики безопасности можно управлять настройками всех средств безопасности и централизованно управлять конфигурациями устройств, политиками безопасности и правилами обработки трафика, гарантируя их целостность для всей сети.
Еще одну реализацию технологии SD‑WAN предлагает известный телеком провайдер. В MTS Cloud SD‑WAN SD‑WAN также имеется централизованный портал управления и мониторинга, позволяющий осуществлять управление на основе правил и политик. При этом, с консолью управления можно работать через облако Cloud MTS.
Ядро SD‑WAN Edge содержит сетевой маршрутизатор, работающий как Virtual Appliance или как аппаратное решение. Также, имеется свой оркестратор безопасности, который управляет виртуальными функциями безопасности на оборудовании и шлюз центра обработки данных, который агрегирует туннели управления оборудованием.
Заключение
В этой статье мы рассмотрели основы построения программно‑определяемых сетей, поговорили об основных компонентах и предоставляемых сервисах. Пока еще не появилось единого подхода к реализации сетей SD‑WAN и различные вендоры по своему трактуют реализацию данной технологии.
Статья подготовлена в рамках запуска нового потока специализации Network Engineer. По ссылке вы можете подробнее узнать о специализации, а также зарегистрироваться на бесплатные уроки курса.
Комментарии (4)
Megakazbek
11.12.2023 16:45Реальная мотивация для использования SDWAN - это тупо сэкономить. Например, когда провайдер в дополнение к каналам еще и предлагает собственный SDWAN как услугу, тогда может получиться выгоднее эту часть сети как бы зааутсорсить провайдеру. Либо в странах, где MPLS каналы дико дорогие, выгодно заменить их на пару-тройку интернет-каналов и получить в целом такую же надежность и качество с учетом автоматического перераспределения трафика.
А вот просто сами по себе все эти функции не особо то и востребованы, большинству достаточно ip sla на циске, обычного бесплатного мониторинга типа Zabbix и ручного копи-пейста шаблона для настройки новых устройств.
BjLomax
SD-WAN это вендор-лок. Десяток несовместимых между собой предложений.
Aelliari
Вендордок, да, но чем тебе решения типа tailscale(headscale)/zerotier/netbird и прочих - не «программно-определяемая сеть»? Там ведь есть и открытые решения, в том числе с возможностью самостоятельного хостинга. Хотя, я не уверен, умеют ли хоть кто-то из них в бондинг интерфейсов
datacompboy
Ага, типа гугловского Orion, собранном на кроссвендоре