Программно конфигурируемые сети sdn доклад

Обновлено: 28.06.2024

В сфере информационных технологий происходит кардинальная смена подходов к построению сетей на основе конвергенции двух основных технологий, SDN (программно-конфигурируемые сети) и NFV (виртуализация сетевых функций). Эта конвергенция достигается за счет более глубокого проникновения принципа программного управления в реализацию сервисов и развитие техники виртуализации, при этом основной упор делается на использование программных методов, оставляя аппаратной составляющей вспомогательную роль.

Подход SDN - Software Defined Networking - означает физическое разделение плоскости управления и плоскости передачи данных, при котором плоскость управления отвечает за работу нескольких элементов сети. SDN – это новая, простая в управлении, гибкая и экономически эффективная сетевая архитектура, обеспечивающая высокую пропускную способность и динамичность, что принципиально важно для современных приложений.

Архитектура SDN является:

Программируемой: Управление сетью программируется напрямую, поскольку этот уровень отделен от функций передачи данных;
Адаптивной: Отделение функций контроля от функций передач данных позволяет администраторам динамически настраивать транспортные потоки по всей сети для удовлетворения меняющихся потребностей;
Централизованно управляемой: Интеллектуальный центр управления сетью логически централизован в программных SDN-контроллерах, которые дают общее представление о состоянии сети. В свою очередь для приложений и политик обработки контроллеры являются едиными логическими коммутаторами.
Программно конфигурируемой: SDN позволяет сетевым администраторам конфигурировать, управлять, обеспечивать защиту и быстро оптимизировать сетевые ресурсы с помощью динамических, автоматизированных программ SDN, которые они могут писать самостоятельно;
Основанной на открытых стандартах и независимой от вендоров: При реализации на основе открытых стандартов, SDN значительно упрощает проектирование и эксплуатацию сети, поскольку управление сетью обеспечивается не устройствами и протоколами определенных производителей, а программными SDN контроллерами.

Виртуализация сетевых функций (Network Function Virtualization, NFV) предлагает новый способ проектирования, развертывания и управления сетевых сервисов. NFV отделяет такие сетевые функции, такие как NAT, firewall, обнаружение вторжений, DNS, фильтрация трафика и многие другие от аппаратного уровня, чтобы была возможность программирования нужных функций на программном уровне.
NFV был предложен (разработан) чтобы объединить все сетевые компоненты, необходимые для поддержки полностью виртуализованной инфраструктуры - в том числе виртуальных серверов, систем хранения данных, и даже других сетей.

Гибкость: Операторы, стремящиеся быстро разрабатывать и развертывать новые сервисы, требуют гораздо более гибкой и масштабируемой сети.
Стоимость: сегодня фактор стоимости является главным для любого оператора или сервис-провайдера тем более, теперь, когда есть пример Google и нескольких других корпораций, которые перевели свои ЦОДы на коммодити коммутаторы (white box) для снижения затрат.
Масштабируемость: Для быстрого удовлетворения меняющихся потребностей клиентов и предоставления новых услуг, операторы связи и сервис-провайдеры должны иметь возможность масштабировать свою сетевую архитектуру на нескольких серверах, не ограничиваясь возможностью аппаратного уровня.

Таким образом, исторически технологии SDN и NFV развивались параллельно, особо не обращая внимания на особенности и возможности друг друга. SDN – это управление, стек сетевых протоколов, пересмотр принципов управления сетью. NFV – это сокращение ROI, маркетинг, бизнес и архитектура, скорость ввода новых сервисов, дифференциация клиентов. Оба подхода нацелены на то, чтобы уменьшить сложность сети, обеспечить масштабируемость и автоматизацию управления, повысить мощности физической инфраструктуры сетей с наложением виртуальной, упростить развертывание, автоматизировать администрирование и снизить OPEX и CAPEX.

Взаимодействие технологий SDN и NFV

Существуют три варианта совместного использования SDN и NFV: NFV на базе SDN, когда SDN управляет размещением, взаимодействием, чейнингом (chaining) виртуализированных функций, SDN на базе NFV, где SDN является виртуализированным сервисом в неком тенанте, и SDN+NFV, когда две области взаимодополняемы и существуют в самых разных комбинациях.

В случае с NFV на базе SDN, SDN контроллер используется для управления ресурсами физической инфраструктуры и находится в управлении платформой, управляя физическими ресурсами соответствующей инфраструктуры. Сейчас для того, чтобы настроить развитую географически распределенную инфраструктуру с VPN, необходимо использовать MPLS, соответствующим образом настроить оборудование и иметь очень квалифицированный персонал. Представьте себе сеть оператора, который предоставляет услуги организации VPN уровня L2 для предприятий. В настоящее время эту услугу реализуют с помощью решения MPLS/VPLS. Для этого необходимо сначала спроектировать виртуальную сеть, потом настроить все сетевые устройства. Эта задача требует серьезной квалификации персонала и времени. Мы можем виртуализировать функцию проектирования VPLS туннелей с помощью несложного графического интерфейса, а настройку коммутаторов моментально произведет обычный SDN-контроллер. В этом случае мы можем создавать целые цепочки сервисов для различного вида трафика. Мы встраиваем мощный сервер с платформой поддержки и управления виртуализированными сервисами (NFV) в инфраструктуру сети, управляемой SDN-контроллером. Это позволяет управлять цепочками сервисов не только про-активно, но и реактивно, динамически.

Для SDN на базе NFV, где SDN используется как виртуализированный сервис, ярким примером является тенант, который представляет собой виртуализированную инфраструктуру крупного предприятия. Естественное желание CEO такого предприятия – иметь контроль над политикой маршрутизации, над безопасностью траффика в таком сервисе. В этом случае вполне реально разместить контроллер с соответствующей системой приложений на одну из виртуальных машин, и он будет управлять виртуализированной сетью данного тенанта. Иногда директор предприятия не хочет брать на себя всю головную боль, связанную с поддержкой работы контроллера, и тогда возникает необходимость рассмотреть контроллер, как отдельно стоящий виртуализированный сервис, и подключить свой тенант к этой функции. Как исходные данные, при этом задана спецификация политики маршрутизации, администрирования сети, а уже ее реализацией занимается контроллер.

Наконец, третий случай – SDN в сочетании с NFV, когда внутри ЦОД можно использовать 1 или 2 сценарий, но это будет уже географически распределенная среда с единым уровнем оркестрации, при этом владельцу тенанта, конечному пользователю, всё равно, где и как (если это облачная среда) реализуется тот или иной сервис. Таким образом, создается сеть ЦОДов, на которых работают виртуализированные сервисы и которые находятся под управлением единого оркестратора, который и управляет единой средой.

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

— Мы принесли вам подключение к современному миру.
— Через месяц мы вернемся с антидепресантами.

В комментариях к посту было много обсуждений о том, что собственно из себя представляют программно-конфигурируемые сети (ПКС) и насколько все это применимо в реальности. Коротко комментарии можно разделить на следующие группы:

ПКС не нужны, ибо и так все хорошо работает
интересно, но непонятно что и зачем
маркетинговый буллшит
подход строго лабораторный, для тестов в университетах, а в практической жизни скорей всего неприменим

Почему в Стэнфорде и Беркли вообще взялись за попытку поменять сетевую архитектуру? Как объясняют сами авторы похода: Мартин Касадо (Martin Casado) и Ника МакКьоуна (Nick McKeown), они хотели изменить или повлиять на следующие моменты:

По прогнозам компании Cisco в ближайшие 5 лет объем трафика увеличится в 4 раза, причем мобильный трафик будет удваиваться ежегодно. К 2015 г. количество устройств в сети, будет в два раза выше, чем население планеты. Количество сетевых адресов в новом протоколе IPv6 такое, что на 1 м2 поверхности Земли приходится 6,7*1023 адресов (фактически, это количество устройств, которое потенциально могут быть подключены к сетям). Сегодня одновременно в Skype работает свыше 35 млн. пользователей, в Facebook — свыше 200 млн, каждую минуту на YouTube загружают 72 часа видео. Видео-трафик составляет более 50 % потребительского трафика и его доля будет дальше только расти. К 2015 г. трафик от беспроводных устройств превысит объем трафика от фиксированных. Наверняка, если бы сегодня существовала возможность разработать сетевые протоколы с чистого листа и с учетом всего накопленного опыта, они оказались бы абсолютно иными.

Для иллюстрации представьте что все веб-сервера были разработаны в 70-ых и остались без изменений. Это как если бы сейчас не было ни Nginx ни даже Apache, а только ISS образца 1995 года. К сожалению в области протоколов все обстоит именно так.

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

С чего начали исследователи из Стэнфорда и Беркли – они предположили, что в компьютерных сетях возможно разделить функции управления и передачи данных.

Рисунок 1. Обработка и передача данных в коммутаторе Ethernet

При передаче данных коммутатор Ethernet подает запрос к таблице коммутации (рис 1). Затем на основании полученной информации коммутационная матрица осуществляет дальнейшую обработку и передачу данных на целевой исходный порт.

Проблему разделения уровня управления и передачей данных исследователи Стэнфорда и Беркли предложили решить в рамках подхода, получившего название программно-конфигурируемые сети (ПКС).

До OpenFlow сетевую архитектуру можно представить как телефонную связь в самом начале 20 века, когда коммутация осуществлялась вручную (Барышня, Смольный!). В принципе, сейчас администратор также вручную настраивает оборудование по заданным параметрам, и любые дальнейшие изменения осуществляются преимущественно на аппаратном уровне.

В коммутаторе OpenFlow реализован только уровень передачи данных. Вместо контроллера используется гораздо более просто устройство, задача которого состоит в принятии поступающих данных, извлечение их адресов и, если адресат есть в таблице коммутации, немедленной передачи данных коммутационной матрице. Иначе коммутатор по защищенному каналу отправляет запрос на Центральный контроллер сети OpenFlow, и на основании полученной от него информации вносит необходимый изменения в таблицу коммутации, после чего осуществляется обработка полученных данных (больше оборудование не перенастраивается руками, а перенастраивается с помочью ПО).

Поэтому в терминологии ПКС такая таблица коммутации получила название FlowTable (таблица потоков). У каждого контроллера своя уникальная FlowTable, эту таблицу он заполняет только на основании информации, полученной от центрального контроллера.

В сетях новой архитектуры ПКС все маршрутизаторы и коммутаторы объединяются под управлением Сетевой Операционной Системы (СОС), которая обеспечивает приложениям доступ к управлению сетью и которая постоянно отслеживает конфигурацию средств сети.

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

Протокол OpenFlow решает также проблему зависимости от сетевого оборудования какого-либо конкретного поставщика, поскольку ПКС(SDN) использует общие абстракции для пересылки пакетов, которые сетевая операционная система использует для управления сетевыми коммутаторами.

Можно сказать, что OpenFlow – это протокол нижнего уровня для программирования коммутаторов. ПО для сетей SDN/ПКС находится в самом начале своего развития, его в большинстве случаев предстоит только разработать. В ближайшее время разработчикам только предстоит убедиться в правильности подхода, в возможности масштабируемости сетей нового поколения, поскольку технология только-только вышла из стен лабораторий.

Но уже сейчас интерес со стороны производителей огромный. Например, Cisco добавили OpenFlow к своим коммутаторам Nexus и Catalyst 37XX, Jupiper также добавил опцию OpenFlow в JunOS SDK, а в июне этого года объявил о реализации этой технологии в линейке коммутаторов EX and MX Series. Более того, ряд производителей сетевого оборудования уже предлагают коммутаторы, которые реализуют только протокол OpenFlow, а традиционные протоколы не поддерживают: NEC, Pronto, Marvell.

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

Эволюция SDN
Механизм управления сетью до SDN можно упрощенно представить так:

Архитектура SDN версии 1 (SDN v.1)

Пример абстракции SDN.

Архитектура SDN версии 2 (SDN v.2) с NFV

Инфраструктура сети теперь состоит из хорошо определяемых и отслеживаемых модулей (уровней абстракции) – сетевая виртуализация NFV, сетевая операционная система NOS и интерфейс для описания передачи пакетов (например, OpenFlow). NFV и NOS тем не менее, представляют собой достаточно сложный программный код, но все проблемы теперь можно легко отслеживать, локализовывать и решать на соответствующем уровне. Теперь нужно заботиться лишь о том, ЧТО должно происходить в сети, а не о том, КАК сделать так, чтобы это происходило.

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

Ключевые слова: SDN, сеть, маршрутизатор, телекоммуникации, данные

The article is devoted to the analysis of the features of modern SDN network technology. As part of the study, the essence of SDN technology is considered, key advantages and disadvantages are highlighted. Special attention is paid to the prospects for the development of this technology.

Keywords: SDN, network, router, telecommunications, data

Рост спроса на телекоммуникационные услуги обуславливает новые требования к сетевым технологиям, которые должны обеспечить защищенный, надежный, и, что самое важное, качественный доступ пользователей к информационным ресурсам. Одной из основных проблем современных сетей является загруженность каналов связи на 30–40 % от общей пропускной способности, что приводит к неэффективному использованию сетевой структуры в целом [1].

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

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

Анализ научно-технической литературы свидетельствует, что проблемам совершенствования телекоммуникационных технологий на современном этапе развития посвящен целый ряд работ отечественных и зарубежных ученых, к которым относятся: Стеклов В., Якубайтис Е., Лазарев В., Лапа В., Нестерук В., Поспелов С., Лернер А., Фельдбаум А., Шеннон К., Льюс Р. и др.

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

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

SDN — это сеть передачи данных, в которой уровень управления отделен от устройств передачи данных и реализуется программно [3]. В традиционных коммутаторах и маршрутизаторах эти процессы неотделимы друг от друга. В SDN сеть, которая состоит из множества устройств различных производителей, используется как один логический коммутатор. На рис. 1 приведена архитектура SDN.

Программно-конфигурируемые сети эффективны для построения инфраструктурных облачных сервисов, в условиях, когда по запросу потребителей услуг необходимо автоматически и в кратчайшие сроки создавать виртуальные узлы и выделять виртуальные сетевые ресурсы.

Рис. 1 Архитектура SDN [4]

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

Преимущества SDN заключаются в следующем:

‒ упрощение и централизация управления, администрирования и обслуживания, повышение эффективности бизнеса, снижение операционных расходов;

‒ более быстрое развертывание услуг, снижение показателя ТТМ;

‒ создание новых рынков путем перехода к облачным услугам;

‒ операторы могут предоставлять инфраструктуру data-центров как услугу (IaaS) с интеграцией ресурсов каналов связи и облачных IT-ресурсов;

‒ более эффективное использование ресурсов телекоммуникационной сети путем централизации управления ресурсами, виртуализации ресурсов data-центров.

Теоретически SDN предоставляет возможности абсолютной гибкости в управлении трафиком, а также позволяет легко сбалансировать трафик без привлечения отдельного прибора (оборудования) [4]. На практике, в SDN есть три большие проблемы, которые решают все разработчики: транспортировка от контроллера к коммутаторам; пути стыковки с традиционной сетью; безопасность сети.

Вместе с тем, следует отметить, в контексте стремительного набирающей обороты научно-технической революции, современными тенденциями развития SDN являются:

‒ развитие протокола OpenFlow, который пока находится на начальной стадии разработки, и взаимодействует только с базовыми протоколами сетевого и транспортного уровней;

‒ формирование гибридной SDN инфраструктуры, в которой традиционные, SDN-включенные и гибридные сетевые узлы могут работать согласованно;

За последние несколько лет технология ПКС прошла путь от идеи до реальных технических решений. Выполненный анализ материалов в сети показал: ведущие сетевые разработчики предлагают комбинированные решения SDN, которые уже готовы к внедрению, вместе с этим они включают в себя пути внедрения SDN на традиционных сетевых платформах. То есть преимущества новой технологии можно получить без новаторской замены полностью имеющихся установок.

Рассмотрим успешные случаи внедрения SDN –технологии. Google является крупнейшим разработчиком облачных сетей, неудивительно, что многолетний вклад в инновации и развитие их сетевой структуры уже смог принести компании достойные результаты в области программируемых сетей. На данный момент Google реализовала восемь проектов, в основах которых лежит технология ПКС.

Облачные технологии, BYOD, мобильность сотрудников – мода или необходимость бизнеса?

Тотальная мобильность, облачные технологии и консьюмеризация ИТ – это основные тренды, которые будут определять будущее ИТ уже сегодня.

Возможность работать буквально где угодно существенно повышает производительность и мотивирует сознательных сотрудников на многое. Сегодня пользователи могут получать доступ к данным и приложениям из любого места: в офисе, дома, в аэропорту, в отеле. Причем использовать для этого самые разнообразные устройства: ноутбук, планшет, смартфон и, используя любые технологии проводные сетей Ethernet, WiFi или 3G/4G. Корпоративные приложения переносятся с физических серверов на виртуальные машины или даже в облака.

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

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

Программно-определяемые сети

Независимое от производителя управление всеми устройствами из единого центра существенно упрощает конфигурацию и эксплуатацию сети. Благодаря контроллеру с расширенными API интерфейсами, вся сеть становится подобной одному большому логическому коммутатору. Протокол OpenFlow – один из самых универсальных протоколов коммуникации контроллеров и коммутаторов на сегодняшний день предоставляет стандартный подход к программированию таблиц коммутации, в которых основным объектом является поток данных. Однако в то время как OpenFlow позволяет контроллеру программировать коммутаторы, он не определяет, как контроллеру реагировать и отвечать на вызовы, связанные с облаками, BYOD, BYOC, виртуализацией. Решение любых проблемы с производительностью сети, да и просто ее работой, возложены на контроллер и приложения, которые на нем запущены. Именно набор таких приложений и отличает различные внедрения SDN, а также решения разных производителей. Поэтому под зонтиком SDN на данный момент развиваются другие технологии, которые пока привязаны к тому или иному производителю.

Вслед за виртуализацией серверов и приложений пришла очередь сетей. Разработанные 25 лет назад классические виртуальные сети VLAN, работающие на втором уровне модели OSI были отличным решением для логической группировки устройств и управления обменом информацией между ними. Но данный подход имеет ограничения – с его помощью можно организовать всего 4094 сети и невозможно перенести виртуальную машину через границы канального уровня. Таким образом возникла модель создания наложенных виртуальных сетей поверх существующей физической ИТ инфраструктуры.

В качестве самых распространенных протоколов построения наложенных (оверлейных) сетей можно привести VXLAN (компания VMware) и NVGRE (компания Microsoft). Все протоколы подразумевают наличие виртуального коммутатора на базе гипервизора и терминирование туннелей в виртуальных узлах. Что позволяет строить логические сети на канальном уровне в рамках уже существующих сетей уровня 3 модели OSI. Виртуализация сети отвечает на вызовы мобильности и многопользовательского использования, но создает дополнительные проблемы, связанные с вопросами мониторинга, управления и безопасности как для самой физической инфраструктуры, так и наложенных виртуальных сетей. Основные проблемы с которым придется столкнуться — это мониторинг и контроль за синхронизацией управления сетью (физической и наложенной) и управление потоками данных.

Решения на основе SNMP для мониторинга всей сети, скорее всего не будут востребованы, так как SDN-сети строятся на основе простых устройств коммутации и весь разум сосредоточен в контроллере, поэтому основную информацию через API интерфейсы можно будет легко снять. А вот проблему синхронизации и возможных сбоев в общении контроллер-коммутатор придется решать с помощью решений для анализа производительности сервисов и сети на основе глубокого анализа реального трафика.

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

Создание виртуальных сетей и в прошлом и в будущем связано с добавлением дополнительных заголовков в пакеты, что делает затруднительным анализ трафика с помощью решений на коленке (типа ноутбук и анализатор трафика). Также не все существующие анализаторы могут корректно отрабатывать трафик и удаление заголовков, которые относятся к VXLAN, NVGRE и т.д. В данном случае могут быть полезны брокеры сетевых пакетов, которые оперативно обновляют свои функциональные возможности в части анализа новых видов протоколов и инкапсуляций, в том числе и для поддержки SDN сетей. Создание и удаление виртуальных каналов и оверлейных сетей происходит на уровне гипервизора и на уровне физической инфраструктуры этот процесс будет невозможно проконтролировать, что делает поиск неисправностей и управления производительностью каналов связи очень сложным. Например, если пакет данных был отправлен из одной виртуальной машины на другую с использованием VXLAN и не дошел до адресата, то причины могут быть: в гипервизоре; у отправителя; в контроллере SDN сети (неверный маршрут); у получателя; в базовой физической сети. И наконец, разделение потоков управления и пользователя на уровне наложенной сети и на уровне физической, требует контроля с возможностью корреляции, чтобы видеть, как одна сеть влияет на другую.

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

Ответвители трафика устанавливаются в сети и предоставляют доступ к реальному трафику. Далее маркируя трафик, доставляют его в центр для обработки и анализа системами мониторинга или безопасности и выдачей обратной связи для корректировки настроек коммутаторов через контроллер. Компания Gigamon дала название своей философии Unified Visibility Fabric, а компания VSS Monitoring - Unified Visibility Plane:

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

Читайте также: