The Road to SDN

На этом уроке мы расскажем об интеллектуальной истории программно-определяемых сетей, которая охватывает более 25 лет.

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

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

Подробнее о материале, описанном в этом уроке, вы можете прочитать в статье, которая приведена ниже.

Историю развития парадигмы SDN можно разделить на три этапа.

Активные сети, которые ввели понятие программируемых сетей.

Разделение управления и  передачи данных -  развитие OpenSource интерфейсов для  плоскости управления и  плоскости данных.

OpenFlow API и сетевые операционные системы, которые являются первым экземпляром широко распространенного внедрения, OpenSource интерфейсов между плоскостью управления и программируемыми маршрутизаторами и коммутаторами.

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

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

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

Это так и не было реализовано полностью, но  активные сети действительно предлагают видение единой архитектуры для оркестрации middlebox.

Мы видим, что это приносит плоды в таких технологиях, как NFV (виртуализация сетевых функций).

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

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

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

Рабочие группы MIT, такие как Forces, разработали OpenSource интерфейсы между плоскостями управления и данными, другие исследователи  разработали технологии для логически централизованного управления, такие как RCP (платформа управления маршрутизацией).

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

Разделение управления и передачи данных предлагают два важных интеллектуальных вклада.

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

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

Было также несколько мифов вокруг разделения управления и  передачи данных. Но, пожалуй, самым важным мифом было то, что логически централизованное управление каким-то образом нарушает принципы Fate-sharing (Разделение судьбы — это философия инженерного проектирования, в которой связанные части системы соединяются вместе, так что они либо выходят из строя вместе, либо не выходят из строя вообще. Разделение судьбы является примером сквозного принципа. Термин «разделение судьбы» был определен Дэвидом Д. Кларком в его статье 1988 года «Философия дизайна интернет-протоколов DARPA» следующим образом: Модель разделения судьбы предполагает, что допустима потеря информации о состоянии, связанной с объектом, если в то же время теряется сам объект. В частности, информация о синхронизации на транспортном уровне хранится на хосте, подключенном к сети и использующем ее службу связи. Хорошим примером разделения судьбы является передача маршрутных сообщений в протоколах маршрутизации, таких как BGP, где сбой канала или интерфейса канала автоматически приводит к прекращению маршрутных объявлений через этот интерфейс, что в конечном итоге приводит к разрушению состояния. для этого маршрута на каждом конце ссылки. Аналогичные соображения применимы к TCP).

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

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

В некотором смысле OpenFlow был  "perfect storm" (имеющий катастрофически плохие последствия)  для операторов сети, которые столкнулись с реальными проблемами управления сетью.

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

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

OpenFlow внес несколько интеллектуальных вкладов.

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

Вторым -  видение сетевой операционной системы с тремя уровнями.

Плоскость данных с открытым API,

слой для управления состоянием

 слой логики управления,

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

Эти сетевые операционные системы также разработали новые методы управления распределенными состояниями.

Существует также несколько мифов вокруг OpenFlow.

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

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

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

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

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

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

По мере того, как мы распространяем понятия SDN на эти другие части сети, важно учитывать баланс между идеальным и практическим.