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

редактировать

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

SDN обычно ассоциировался с протоколом OpenFlow (для удаленной связи с элементами уровня сети с целью определения пути сетевых пакетов через сетевые коммутаторы ) с момента появления последнего в 2011 году. Однако с 2012 года OpenFlow для многих компаний больше не является эксклюзивным решением, они добавили собственные методы. К ним относятся Cisco Systems 'Open Network Environment и Nicira платформа виртуализации сети.

SD-WAN, применяющая аналогичную технологию к глобальной сети. (WAN).

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

Исследования SDN продолжаются, поскольку для исследовательских целей разрабатывается множество эмуляторов, таких как vSDNEmul, EstiNet, Mininet и т. Д.

Содержание

  • 1 История
  • 2 Концепция
  • 3 Потребность в новой сетевой архитектуре
  • 4 Архитектурные компоненты
  • 5 Плоскость управления SDN
  • 6 Перенаправление потока SDN (sdn)
  • 7 Приложения
    • 7.1 SDMN
    • 7.2 SD-WAN
    • 7.3 SD-LAN
    • 7.4 Безопасность с использованием парадигмы SDN
    • 7.5 Групповая доставка данных с использованием SDN
  • 8 Отношение к NFV
  • 9 Отношение к DPI
  • 10 См. Также
  • 11 Ссылки

История

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

Инженерная группа Интернета (IETF) начала рассматривать различные способы разделения функций управления и пересылки в предлагаемом стандарте интерфейса, опубликованном в 2004 г. и получившем соответствующее название «Разделение элементов управления и пересылки» (ForCES). Рабочая группа ForCES также предложила сопутствующую архитектуру SoftRouter. Дополнительные ранние стандарты IETF, которые преследовали цель отделения управления от данных, включают Linux Netlink как протокол IP Services и архитектуру на основе элемента вычисления пути (PCE).

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

Использование программного обеспечения с открытым исходным кодом в архитектурах разделенного управления / плоскости данных уходит своими корнями в проект Ethane в Стэнфордском отделе компьютерных наук. Простая конструкция переключателя Ethane привела к созданию OpenFlow. API для OpenFlow был впервые создан в 2008 году. В этом же году была создана NOX - операционная система для сетей.

Работа над OpenFlow продолжалась в Стэнфорде, в том числе с созданием испытательных стендов для оценки использования протокол в одной сети университетского городка, а также через глобальную сеть в качестве магистрали для соединения нескольких кампусов. В академической среде было несколько исследовательских и производственных сетей, основанных на переключателях OpenFlow от NEC и Hewlett-Packard ; а также на основе белых ящиков Quanta Computer, начиная примерно с 2009 года.

Помимо академических кругов, Nicira в 2010 году впервые внедрила OVS для управления OVS от Onix, co. -разработано в NTT и Google. Заметным развертыванием было внедрение Google B4 в 2012 году. Позже Google признал свой первый OpenFlow с развертыванием Onix в своих центрах обработки данных одновременно. Еще одно известное крупное развертывание - China Mobile.

Open Networking Foundation было основано в 2011 году для продвижения SDN и OpenFlow.

на Дне взаимодействия и технологий 2014 года, программное обеспечение- определенная сеть была продемонстрирована компанией Avaya с использованием моста кратчайшего пути (IEEE 802.1aq ) и OpenStack в качестве автоматизированного кампуса, расширяющего автоматизацию от центра обработки данных до конечного устройства

Концепция

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

Протокол OpenFlow может использоваться в технологиях SDN. Архитектура SDN:

  • Программируется напрямую: управление сетью программируется напрямую, потому что оно отделено от функций пересылки.
  • Гибкость: отделение управления от пересылки позволяет администраторам динамически регулировать поток трафика в масштабе всей сети для удовлетворения меняющихся потребностей.
  • Централизованное управление: интеллектуальная сеть (логически) централизована в программных контроллерах SDN, которые поддерживают глобальное представление сети, которое для приложений и механизмов политик представляется как единый логический коммутатор.
  • Программно сконфигурированный: SDN позволяет администраторам сети очень быстро настраивать, управлять, защищать и оптимизировать сетевые ресурсы с помощью динамических, автоматизированных программ SDN, которые они могут писать сами, поскольку программы не зависят от проприетарного программного обеспечения.
  • На основе открытых стандартов и без учета поставщика: при реализации через открытые стандарты SDN упрощает проектирование и эксплуатацию сети, поскольку инструкции предоставляются контроллерами SDN, а не несколькими, как указано в спецификации поставщика. Устройства и протоколы ific.

Потребность в новой сетевой архитектуре

Бурный рост мобильных устройств и контента, виртуализация серверов и появление облачных сервисов - вот тенденции, побуждающие сетевую отрасль пересмотреть традиционные сетевые архитектуры. Многие традиционные сети являются иерархическими, построенными из ярусов коммутаторов Ethernet, расположенных в древовидной структуре. Такая конструкция имела смысл, когда доминировали вычисления клиент-сервер, но такая статическая архитектура плохо подходит для динамических вычислений и потребностей хранения данных в современных корпоративных центрах обработки данных, университетских городках и средах операторов связи. Некоторые из ключевых тенденций в области вычислений, обусловливающих потребность в новой сетевой парадигме, включают:

Изменение шаблонов трафика
В корпоративном центре обработки данных шаблоны трафика значительно изменились. В отличие от клиент-серверных приложений, в которых основная часть обмена данными происходит между одним клиентом и одним сервером, современные приложения обращаются к разным базам данных и серверам, создавая поток межмашинного трафика «восток-запад», прежде чем возвращать данные в конец. пользовательское устройство в классической схеме движения «север-юг». В то же время пользователи меняют шаблоны сетевого трафика, стремясь получить доступ к корпоративному контенту и приложениям с любого типа устройства (включая свое собственное), подключаясь из любого места и в любое время. Наконец, многие руководители корпоративных центров обработки данных рассматривают модель коммунальных вычислений, которая может включать частное облако, общедоступное облако или их сочетание, что приведет к дополнительному трафику в глобальной сети.
«Ориентация на потребителя»
Пользователи все чаще используют мобильные личные устройства, такие как смартфоны, планшеты и ноутбуки, для доступа к корпоративной сети. ИТ-отделы вынуждены тщательно размещать эти персональные устройства, защищая корпоративные данные и интеллектуальную собственность и соблюдая нормативные требования.
Рост облачных сервисов
Предприятия с энтузиазмом восприняли как публичное, так и частное облако услуг, что привело к беспрецедентному росту этих услуг. Корпоративные бизнес-подразделения теперь хотят гибкого доступа к приложениям, инфраструктуре и другим ИТ-ресурсам по запросу и по выбору. Чтобы усложнить задачу, ИТ-планирование облачных сервисов должно осуществляться в среде повышенных требований к безопасности, соответствию и аудиту, наряду с реорганизацией, консолидацией и слияниями бизнеса, которые могут изменить предположения в мгновение ока. Предоставление самообслуживания, будь то в частном или общедоступном облаке, требует гибкого масштабирования вычислительных, хранилищ и сетевых ресурсов, в идеале с общей точки зрения и с помощью общего набора инструментов.
«Большие данные» означают большую пропускную способность
Обработка сегодняшних «больших данных» или мегабайт данных требует массивной параллельной обработки на тысячах серверов, каждый из которых требует прямого соединения друг с другом. Рост количества мега-наборов данных вызывает постоянный спрос на дополнительную пропускную способность сети в центре обработки данных. Операторы гипермасштабируемых сетей центров обработки данных сталкиваются с непростой задачей: масштабировать сеть до невообразимых ранее размеров, поддерживая возможность подключения любого к любому без разрушения.

Архитектурные компоненты

Высокоуровневый обзор программно определяемой сетевой архитектуры

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

Приложение SDN
Приложения SDN - это программы, которые явно, напрямую и программно сообщают свои сетевые требования и желаемое сетевое поведение контроллеру SDN через северный интерфейс (NBI). Кроме того, они могут использовать абстрактное представление сети для внутренних целей принятия решений. Приложение SDN состоит из одной логики приложения SDN и одного или нескольких драйверов NBI. Приложения SDN могут сами предоставлять другой уровень абстрактного сетевого управления, таким образом предлагая один или несколько NBI более высокого уровня через соответствующие агенты NBI.
Контроллер SDN
Контроллер SDN - это логически централизованный объект, отвечающий за (i) перевод требований с уровня приложения SDN на каналы данных SDN и (ii) предоставление приложениям SDN абстрактного представления сети (которое может включать статистику и события). Контроллер SDN состоит из одного или нескольких агентов NBI, логики управления SDN и драйвера интерфейса уровня данных управления (CDPI). Определение как логически централизованная сущность не предписывает и не исключает деталей реализации, таких как объединение нескольких контроллеров, иерархическое соединение контроллеров, интерфейсы связи между контроллерами, а также виртуализация или разделение сетевых ресурсов.
SDN Datapath
SDN Datapath - это логическое сетевое устройство, которое обеспечивает видимость и неоспоримый контроль над объявленными возможностями пересылки и обработки данных. Логическое представление может охватывать все или подмножество ресурсов физической подложки. SDN Datapath состоит из агента CDPI и набора из одного или нескольких механизмов пересылки трафика и нуля или нескольких функций обработки трафика. Эти механизмы и функции могут включать простую пересылку между внешними интерфейсами канала данных или функции внутренней обработки или завершения трафика. Один или несколько каналов передачи данных SDN могут содержаться в одном (физическом) сетевом элементе - интегрированной физической комбинации коммуникационных ресурсов, управляемых как единое целое. SDN Datapath также может быть определен для нескольких физических сетевых элементов. Это логическое определение не предписывает и не исключает деталей реализации, таких как логическое отображение на физическое, управление общими физическими ресурсами, виртуализация или разделение SDN Datapath, взаимодействие с сетями без SDN, а также функциональные возможности обработки данных, которые могут включать Функции уровня 4-7 OSI.
SDN Control to Data-Plane Interface (CDPI)
SDN CDPI - это интерфейс, определенный между контроллером SDN и каналом передачи данных SDN, который обеспечивает как минимум ( i) программный контроль всех операций пересылки, (ii) объявление о возможностях, (iii) статистическая отчетность и (iv) уведомление о событиях. Одно из достоинств SDN заключается в ожидании, что CDPI будет реализован открытым, независимым от поставщика и совместимым способом.
Северные интерфейсы SDN (NBI)
NBI SDN - это интерфейсы между приложениями SDN и контроллерами SDN и обычно предоставляют абстрактные представления сети и позволяют напрямую выражать поведение и требования сети. Это может происходить на любом уровне абстракции (широта) и в различных наборах функций (долгота). Одно из достоинств SDN заключается в ожидании, что эти интерфейсы будут реализованы открытым, независимым от поставщика и совместимым способом.

Уровень управления SDN

Централизованный - Иерархический - Распределенный

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

Размещение контроллера

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

Перенаправление потока SDN (sdn)

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

Приложения

SDMN

Программно-конфигурируемые мобильные сети (SDMN) - это подход к проектированию мобильных сетей, при котором все специфические для протокола функции реализованы в программном обеспечении, что позволяет максимально использовать стандартное и стандартное оборудование и программное обеспечение как в базовой сети и сеть радиодоступа. Он предлагается как расширение парадигмы SDN для включения специальных функций мобильной сети. Начиная с версии 3GPP 14, разделение уровней управляющих пользователей было введено в архитектуру базовой сети мобильной связи с протоколом PFCP.

SD-WAN

SD-WAN - это Глобальная сеть (WAN), управляемая с использованием принципов программно-определяемой сети. Основной движущей силой SD-WAN является снижение затрат на WAN с использованием более доступных и коммерчески доступных арендованных линий в качестве альтернативы или частичной замены более дорогих линий MPLS. Контроль и управление осуществляется отдельно от оборудования с помощью центральных контроллеров, что упрощает настройку и администрирование.

SD-LAN

SD-LAN - это Локальная сеть ( LAN) построена на принципах программно-определяемых сетей, хотя есть ключевые различия в топологии, сетевой безопасности, видимости и контроле приложений, управлении и качестве обслуживания. SD-LAN разделяет управление и плоскости данных, чтобы обеспечить управляемую политиками архитектуру для проводных и беспроводных локальных сетей. Для сетей SD-LAN характерно использование системы управления облаком и возможность беспроводного подключения без наличия физического контроллера.

Безопасность с использованием парадигмы SDN

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

В нескольких исследованиях SDN уже были исследованы приложения безопасности, построенные на контроллере SDN, с разными целями. Распределенный отказ в обслуживании (DDoS), обнаружение и смягчение, а также распространение ботнетов и червей - вот некоторые конкретные варианты использования таких приложений: в основном, идея состоит в периодическом сборе сетевой статистики с уровня пересылки сети стандартизованным способом. (например, используя Openflow), а затем примените алгоритмы классификации к этой статистике, чтобы обнаружить любые сетевые аномалии. Если обнаружена аномалия, приложение инструктирует контроллер, как перепрограммировать плоскость данных, чтобы смягчить ее.

Другой вид приложений безопасности использует контроллер SDN путем реализации некоторых алгоритмов защиты от движущейся цели (MTD). Алгоритмы MTD обычно используются, чтобы сделать любую атаку на данную систему или сеть более сложной, чем обычно, путем периодического сокрытия или изменения ключевых свойств этой системы или сети. В традиционных сетях реализация алгоритмов MTD не является тривиальной задачей, поскольку сложно создать центральный орган, способный определять - для каждой части системы, которую необходимо защитить, - какие ключевые свойства скрыты или изменены. В сети SDN такие задачи становятся более простыми благодаря центральной роли контроллера. Одно приложение может, например, периодически назначать виртуальные IP-адреса хостам в сети, а затем сопоставление виртуального IP-адреса / реального IP-адреса выполняется контроллером. Другое приложение может имитировать некоторые поддельные открытые / закрытые / отфильтрованные порты на случайных хостах в сети, чтобы добавить значительный шум во время фазы разведки (например, сканирования), выполняемой злоумышленником.

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

Приложения контроллера SDN в основном развертываются в крупномасштабных сценариях, что требует всесторонних проверок возможных ошибок программирования. Система для этого под названием NICE была описана в 2012 году. Внедрение всеобъемлющей архитектуры безопасности требует комплексного и длительного подхода к SDN. С момента его появления разработчики ищут возможные способы защиты SDN, не ставящие под угрозу масштабируемость. Одна архитектура называется Архитектура безопасности SN-SECA (SDN + NFV).

Групповая доставка данных с использованием SDN

Распределенные приложения, которые работают в центрах обработки данных, обычно реплицируют данные с целью синхронизации, отказоустойчивости, нагрузки балансировка и приближение данных к пользователям (что снижает задержку для пользователей и увеличивает их воспринимаемую пропускную способность). Кроме того, многие приложения, такие как Hadoop, реплицируют данные в центре обработки данных на несколько стоек, чтобы повысить отказоустойчивость и упростить восстановление данных. Все эти операции требуют доставки данных с одного компьютера или центра обработки данных на несколько компьютеров или центров обработки данных. Процесс надежной доставки данных с одного компьютера на несколько компьютеров называется надежной групповой доставкой данных (RGDD).

Коммутаторы SDN могут использоваться для RGDD путем установки правил, разрешающих пересылку на несколько исходящих портов. Например, OpenFlow обеспечивает поддержку групповых таблиц начиная с версии 1.1, что делает это возможным. Используя SDN, центральный контроллер может тщательно и разумно настроить деревья пересылки для RGDD. Такие деревья можно строить, обращая внимание на состояние перегрузки / нагрузки сети для повышения производительности. Например, MCTCP - это схема доставки на многие узлы внутри центров обработки данных, основанная на регулярных и структурированных топологиях сетей центров обработки данных, в то время как DCCast и QuickCast - это подходы для быстрой и эффективной репликации данных и контента между центрами обработки данных по частным глобальным сетям.

Связь с NFV

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

Связь с DPI

DPI Deep Packet Inspection обеспечивает осведомленность сети о приложениях, в то время как SDN предоставляет приложениям информацию о сети. Хотя SDN радикально изменит общую сетевую архитектуру, она должна справиться с работой с традиционными сетевыми архитектурами, чтобы обеспечить высокую функциональную совместимость. Новая сетевая архитектура на основе SDN должна учитывать все возможности, которые в настоящее время предоставляются в отдельных устройствах или программном обеспечении, кроме основных устройств пересылки (маршрутизаторы и коммутаторы), таких как DPI, устройства безопасности

См. Также

Справочная информация

Последняя правка сделана 2021-06-08 08:25:51
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте